Docs » Supported integrations in Splunk Observability Cloud » Collector components: Receivers » Cloud Foundry receiver

Cloud Foundry receiver 🔗

The Cloud Foundry receiver allows the Splunk Distribution of the OpenTelemetry Collector to connect to the Reverse Log Proxy (RLP) gateway of Cloud Foundry and extract metrics. The supported pipeline type is metrics. See Process your data with pipelines for more information.

Get started 🔗

Follow these steps to configure and activate the component:

  1. Deploy the Splunk Distribution of the OpenTelemetry Collector to your host or container platform:

  1. Configure the receiver as described in the next document.

  2. Restart the Collector.

Sample configuration 🔗

To activate the receiver, add cloudfoundry to the receivers section of your configuration file, as in the following sample configurations. See Settings for more details.

receivers:
  cloudfoundry:

To complete the configuration, include the receiver in the metrics pipeline of the service section of your configuration file:

service:
  pipelines:
    metrics:
      receivers: [cloudfoundry]

Configuration settings 🔗

The receiver has the following configuration options:

  • rlp_gateway.endpoint. Required. URL of the RLP gateway, typically https://log-stream.<cf-system-domain>.

  • rlp_gateway.tls.insecure_skip_verify. false by default. Whether to skip TLS verify for the RLP gateway endpoint.

  • rlp_gateway.shard_id. Metrics are load balanced among receivers that use the same shard ID, therefore use this if there are multiple receivers which must both receive all the metrics instead of them being balanced between them.

  • uaa.endpoint. Required. URL of the UAA provider, typically https://uaa.<cf-system-domain>.

  • uaa.tls.insecure_skip_verify. false by default. Whether to skip TLS verify for the UAA endpoint.

  • uaa.username. Required. Name of the UAA user.

  • uaa.password. Required. Password of the UAA user.

To understand how to use these settings, see Authenticate the RLP gateway. Note that the rlp_gateway configuration section also inherits configuration options from the HTTP Client Configuration .

Configuration examples 🔗

See this sample config:

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"

See also:

cloudfoundry/one:
  rlp_gateway:
    endpoint: "https://log-stream.sys.example.internal"
    shard_id: "otel-test"
    timeout: "20s"
    tls:
      insecure_skip_verify: true
  uaa:
    endpoint: "https://uaa.sys.example.internal"
    username: "admin"
    password: "test"
    tls:
      insecure_skip_verify: true

cloudfoundry/invalid:
  rlp_gateway:
    endpoint: "https://[invalid"
    shard_id: "otel-test"
    timeout: "20s"
    tls:
      insecure_skip_verify: true
  uaa:
    endpoint: "https://uaa.sys.example.internal"
    username: "admin"
    password: "test"
    tls:
      insecure_skip_verify: true

Authenticate the RLP gateway 🔗

Add the Oauth2 token as the Authorization header to authenticate the RLP gateway. To obtain an OAuth2 token, make a request to the UAA component, which acts as the OAuth2 provider. You can specify the URL in the uaa_url configuration option, typically https://uaa.<cf-system-domain> is used.

Note

To use UAA you 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

UAA authentication uses a username and password/secret combination. You can set the <uaa_username> and <uaa_password> above to anything as long as they match the values you provide to the receiver configuration.

The admin account, which has the permissions to create new clients, can have a different name on different setups. The value of --name is not used for receiver configuration.

Settings 🔗

The following table shows the configuration options for the Cloud Foundry receiver:

Metrics 🔗

All metrics are either gauges or sums. For more information, see Data types in Splunk Observability Cloud. Reported metrics are grouped under an instrumentation library named otelcol/cloudfoundry.

Metric names are specified by Cloud Foundry, and the origin name is prepended to the metric name with the . separator. Learn more at Cloud Foundry Component Metrics .

Attributes 🔗

All the metrics have the following attributes:

  • origin: Origin name as documented by Cloud Foundry.

  • source: For applications, the GUID of the application, otherwise equal to origin.

For Cloud Foundry or Tanzu Application Service deployed in BOSH, the following attributes are also present, using their canonical BOSH meanings:

  • deployment: BOSH deployment name.

  • index: BOSH instance ID (GUID).

  • ip: BOSH instance IP.

  • job: BOSH job name.

For metrics originating with rep origin name, specific to applications, the following attributes are present:

  • instance_id: Numerical index of the application instance. It’s also present for bbs origin, where it matches the value of index.

  • process_id: The process ID (GUID). For a process of the type web, which is the main process of an application, this is equal to source_id and app_id.

  • process_instance_id: The unique ID of a process instance. Treat it as an opaque string.

  • process_type: Process type. Each application has exactly one process of type web, but many have any number of other processes.

On TAS/PCF versions 2.8.0 or higher and cf-deployment versions v11.1.0 or higher, the following additional attributes are present for application metrics: app_id, app_name, space_id, space_name, organization_id, and organization_name. They provide the GUID and name of the application, space and organization respectively.

More attributes might be available since the receiver passes on whatever attributes the gateway provides.

Troubleshooting 🔗

If you are a Splunk Observability Cloud customer and are not able to see your data in Splunk Observability Cloud, you can get help in the following ways.

Available to Splunk Observability Cloud customers

Available to prospective customers and free trial users

  • Ask a question and get answers through community support at Splunk Answers .

  • Join the Splunk #observability user group Slack channel to communicate with customers, partners, and Splunk employees worldwide. To join, see Chat groups in the Get Started with Splunk Community manual.

This page was last updated on Sep 18, 2024.