|
| 1 | +# Cloud Foundry Receiver |
| 2 | + |
| 3 | +The Cloud Foundry receiver connects to the RLP (Reverse Log Proxy) Gateway of the Cloud Foundry installation, typically |
| 4 | +available at the URL `https://log-stream.<cf-system-domain>`. |
| 5 | + |
| 6 | +## Authentication |
| 7 | + |
| 8 | +RLP Gateway authentication is performed by adding the Oauth2 token as the `Authorization` header. To obtain an OAuth2 |
| 9 | +token to use for the RLP Gateway, a request is made to the UAA component which acts as the OAuth2 provider (URL |
| 10 | +specified by `uaa_url` configuration option, which typically is `https://uaa.<cf-system-domain>`). To authenticate with |
| 11 | +UAA, username and password/secret combination is used (`uaa_username` and `uaa_password` configuration options). This |
| 12 | +UAA user must have the `client_credentials` and `refresh_token` authorized grant types, and `logs.admin` authority. |
| 13 | + |
| 14 | +The following is an example sequence of commands to create the UAA user using the `uaac` command line utility: |
| 15 | + |
| 16 | +* `uaac target https://uaa.<cf-system-domain>` |
| 17 | +* `uaac token client get identity -s <identity-user-secret>` |
| 18 | +* `uaac client add <uaa_username> --name opentelemetry --secret <uaa_password> --authorized_grant_types client_credentials,refresh_token --authorities logs.admin` |
| 19 | + |
| 20 | +The `<uaa_username>` and `<uaa_password>` above can be set to anything as long as they match the values provided to the |
| 21 | +receiver configuration. The admin account (which is `identity` here) which has the permissions to create new clients may |
| 22 | +have a different name on different setups. The value of `--name` is not used for receiver configuration. |
| 23 | + |
| 24 | +## Configuration |
| 25 | + |
| 26 | +The receiver takes the following configuration options: |
| 27 | + |
| 28 | +| Field | Default | Description | |
| 29 | +| --- | --- | --- | |
| 30 | +| `rlp_gateway_url` | required | URL of the RLP gateway, typically `https://log-stream.<cf-system-domain>` | |
| 31 | +| `rlp_gateway_skip_tls_verify` | `false` | whether to skip TLS verify for the RLP Gateway endpoint | |
| 32 | +| `rlp_gateway_shard_id` | `opentelemetry` | metrics 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 | |
| 33 | +| `uaa_url` | required | URL of the UAA provider, typically `https://uaa.<cf-system-domain>` | |
| 34 | +| `uaa_skip_tls_verify` | `false` | whether to skip TLS verify for the UAA endpoint | |
| 35 | +| `uaa_username` | required | name of the UAA user (required grant types/authorities described above) | |
| 36 | +| `uaa_password` | required | password of the UAA user | |
| 37 | +| `http_timeout` | `10s` | HTTP socket timeout used for RLP Gateway | |
| 38 | + |
| 39 | +Example: |
| 40 | + |
| 41 | +```yaml |
| 42 | +receivers: |
| 43 | + cloudfoundry: |
| 44 | + rlp_gateway_url: "https://log-stream.sys.example.internal" |
| 45 | + rlp_gateway_skip_tls_verify: false |
| 46 | + rlp_gateway_shard_id: "opentelemetry" |
| 47 | + uaa_url: "https://uaa.sys.example.internal" |
| 48 | + uaa_skip_tls_verify: false |
| 49 | + uaa_username: "otelclient" |
| 50 | + uaa_password: "changeit" |
| 51 | + http_timeout: "20s" |
| 52 | +``` |
| 53 | +
|
| 54 | +The full list of settings exposed for this receiver are documented [here](./config.go) |
| 55 | +with detailed sample configurations [here](./testdata/config.yaml). |
| 56 | +
|
| 57 | +## Metrics |
| 58 | +
|
| 59 | +Reported metrics are grouped under an instrumentation library named `otelcol/cloudfoundry`. Metric names are as |
| 60 | +specified by [Cloud Foundry metrics documentation](https://docs.cloudfoundry.org/running/all_metrics.html), but the |
| 61 | +origin name is prepended to the metric name with `.` separator. All metrics either of type `Gauge` or `Sum`. |
| 62 | + |
| 63 | +### Attributes |
| 64 | + |
| 65 | +All the metrics have the following attributes: |
| 66 | +* `origin` - origin name as documented by Cloud Foundry |
| 67 | +* `source` - for applications, the GUID of the application, otherwise equal to `origin` |
| 68 | + |
| 69 | +For CF/TAS deployed in BOSH, the following attributes are also present, using their canonical BOSH meanings: |
| 70 | +* `deployment` - BOSH deployment name |
| 71 | +* `index` - BOSH instance ID (GUID) |
| 72 | +* `ip` - BOSH instance IP |
| 73 | +* `job` - BOSH job name |
| 74 | + |
| 75 | +For metrics originating with `rep` origin name (specific to applications), the following metrics are present: |
| 76 | +* `instance_id` - numerical index of the application instance. However, also present for `bbs` origin, where it matches |
| 77 | + the value of `index` |
| 78 | +* `process_id` - process ID (GUID). For a process of type "web" which is the main process of an application, this is |
| 79 | + equal to `source_id` and `app_id` |
| 80 | +* `process_instance_id` - unique ID of a process instance, should be treated as an opaque string |
| 81 | +* `process_type` - process type. Each application has exactly one process of type `web`, but many have any number of |
| 82 | + other processes |
| 83 | + |
| 84 | +On TAS/PCF versions 2.8.0+ and cf-deployment versions v11.1.0+, the following additional attributes are present for |
| 85 | +application metrics: `app_id`, `app_name`, `space_id`, `space_name`, `organization_id`, `organization_name` which |
| 86 | +provide the GUID and name of application, space and organization respectively. |
| 87 | + |
| 88 | +This might not be a comprehensive list of attributes, as the receiver passes on whatever attributes the gateway |
| 89 | +provides, which may include some that are specific to TAS and possibly new ones in future Cloud Foundry versions as |
| 90 | +well. |
0 commit comments