Status | |
---|---|
Stability | development: logs |
beta: metrics | |
Distributions | contrib |
Issues | |
Code Owners | @crobert-1 | Seeking more code owners! |
Emeritus | @agoallikmaa, @pellared |
The Cloud Foundry receiver connects to the RLP (Reverse Log Proxy) Gateway of the Cloud Foundry installation, typically
available at the URL https://log-stream.<cf-system-domain>
.
RLP Gateway authentication is performed by adding the Oauth2 token as the Authorization
header. To obtain an OAuth2
token to use for the RLP Gateway, a request is made to the UAA component which acts as the OAuth2 provider (URL
specified by uaa_url
configuration option, which typically is https://uaa.<cf-system-domain>
). To authenticate with
UAA, username and password/secret combination is used (uaa_username
and uaa_password
configuration options). This
UAA user must have the client_credentials
and refresh_token
authorized grant types, and logs.admin
authority.
The following is an example sequence of commands to create the UAA user using the uaac
command line utility:
uaac target https://uaa.<cf-system-domain>
uaac token client get identity -s <identity-user-secret>
uaac client add <uaa_username> --name opentelemetry --secret <uaa_password> --authorized_grant_types client_credentials,refresh_token --authorities logs.admin
The <uaa_username>
and <uaa_password>
above can be set to anything as long as they match the values provided to the
receiver configuration. The admin account (which is identity
here) which has the permissions to create new clients may
have a different name on different setups. The value of --name
is not used for receiver configuration.
The receiver takes the following configuration options:
Field | Default | Description |
---|---|---|
rlp_gateway.endpoint |
required | URL of the RLP gateway, typically https://log-stream.<cf-system-domain> |
rlp_gateway.tls.insecure_skip_verify |
false |
whether to skip TLS verify for the RLP gateway endpoint |
rlp_gateway.shard_id |
opentelemetry |
metrics or logs are load balanced among receivers that use the same shard ID, therefore this must only be set if there are multiple receivers which must both receive all the metrics instead of them being balanced between them. This string will be a prefix used to build a different ShardID for each envelope type; for logs the final ShardID will have the _logs suffix, for metrics will be _metrics |
uaa.endpoint |
required | URL of the UAA provider, typically https://uaa.<cf-system-domain> |
uaa.tls.insecure_skip_verify |
false |
whether to skip TLS verify for the UAA endpoint |
uaa.username |
required | name of the UAA user (required grant types/authorities described above) |
uaa.password |
required | password of the UAA user |
The rlp_gateway
configuration section also inherits configuration options from the global from:
Example:
receivers:
cloudfoundry:
rlp_gateway:
endpoint: "https://log-stream.sys.example.internal"
tls:
insecure_skip_verify: false
shard_id: "opentelemetry"
uaa:
endpoint: "https://uaa.sys.example.internal"
tls:
insecure_skip_verify: false
username: "otelclient"
password: "changeit"
The full list of settings exposed for this receiver are documented here with detailed sample configurations here.
The receiver maps the envelope attribute tags to the following OpenTelemetry attributes:
origin
- origin name as documented by Cloud Foundry
For Cloud Foundry/Tanzu Application Service deployed in BOSH, the following attributes are also present, using their canonical BOSH meanings:
deployment
- BOSH deployment nameindex
- BOSH instance ID (GUID)ip
- BOSH instance IPjob
- BOSH job name
On TAS/PCF versions 2.8.0+ and cf-deployment versions v11.1.0+, the following additional attributes are present for application metrics: app_id
, app_name
, space_id
, space_name
, organization_id
, organization_name
which provide the GUID and name of application, space and organization respectively.
This might not be a comprehensive list of attributes, as the receiver passes on whatever attributes the gateway provides, which may include some that are specific to TAS and possibly new ones in future Cloud Foundry versions as well.
Reported metrics are grouped under an instrumentation library named otelcol/cloudfoundry
. Metric names are as
specified by Cloud Foundry metrics documentation, but the
origin name is prepended to the metric name with .
separator. All metrics either of type Gauge
or Sum
.
The receiver maps the envelope attribute to the following OpenTelemetry attributes:
source_id
- for applications, the GUID of the application, otherwise equal toorigin
For metrics originating with rep
origin name (specific to applications), the following attributes are present:
instance_id
- numerical index of the application instance. However, also present forbbs
origin, where it matches the value ofindex
process_id
- process ID (GUID). For a process of type "web" which is the main process of an application, this is equal tosource_id
andapp_id
process_instance_id
- unique ID of a process instance, should be treated as an opaque stringprocess_type
- process type. Each application has exactly one process of typeweb
, but many have any number of other processes
The receiver maps loggregator envelopes of these types to the following OpenTelemetry log severity text and severity number:
- type
OUT
becomesinfo
and severity number9
- type
ERR
becomeserror
and severity number17
- If any other log types are received, they're discarded and result in an error log message in the collector.
The receiver maps the envelope attribute tags to the following OpenTelemetry attributes:
source_id
- for applications, the GUID of the application, otherwise the GUID of the log generatorsource_type
- The source of the log, any subset of{API|APP|CELL|HEALTH|LGR|RTR|SSH|STG}
, forAPP
type extra labels are separated by a dash, example:APP/PROC/WEB
instance_id
- numerical index of the origin. If origin isrep
(source_type
isAPP
) this is the application index. However, for other cases this is the instance index.process_id
- process ID (GUID)process_instance_id
- unique ID of a process instance, should be treated as an opaque stringprocess_type
- process type. Each application has exactly one process of typeweb
, but many have any number of other processes