Cloud Foundry レシーバー

Cloud FoundryのRLP（Reverse Log Proxy）ゲートウェイに接続し、メトリクスを抽出します。

Cloud Foundry レシーバは、Splunk Distribution of OpenTelemetry Collector が Cloud Foundry の RLP（Reverse Log Proxy）ゲートウェイに接続し、メトリクスを抽出することを可能にします。サポートされているパイプラインのタイプは metrics です。詳細については「パイプラインでデータを処理する」を参照してください。

はじめに

以下の手順に従って、コンポーネントの設定とアクティベーションを行ってください：

  1. Splunk Distribution of the OpenTelemetry Collector をホストまたはコンテナプラットフォームにデプロイします：

  2. 次のセクションで説明するようにレシーバーを設定します。

  3. Collector を再起動します。

サンプル構成

  1. レシーバを有効化するには、以下の設定サンプルのように、設定ファイルの receivers セクションに cloudfoundry を追加します。詳細については、「設定」を参照してください。
    CODE 
    receivers:
  cloudfoundry:
  2. 設定を完了するには、設定ファイルの service セクションの metrics パイプラインに、レシーバーを含めます：
    CODE 
    service:
  pipelines:
    metrics:
      receivers: [cloudfoundry]

コンフィギュレーション設定

レシーバーには以下の設定オプションがある：

  • rlp_gateway.endpointします。必須。RLP ゲートウェイの URL です。通常は https://log-stream.<cf-system-domain> となります。

  • rlp_gateway.tls.insecure_skip_verify。デフォルトでは false です。RLP ゲートウェイエンドポイントの TLS 検証をスキップするかどうかを決定します。

  • rlp_gateway.shard_idします。メトリクスは、同じシャード ID を使用するレシーバ間でロードバランシングされます。そのためこの設定は、複数のレシーバがそれらの間でバランスをとるのではなく、すべてのメトリクスを受信する必要がある場合に使用します。

  • uaa.endpointします。必須。UAA プロバイダーの URLです。通常は https://uaa.<cf-system-domain> となります。

  • uaa.tls.insecure_skip_verify。デフォルトでは false です。UAA エンドポイントの TLS 検証をスキップするかどうかを指定します。

  • uaa.usernameします。必須。UAA ユーザーの名称です。

  • uaa.passwordします。必須。UAA ユーザーのパスワードです。

これらの設定を使用するには、「Authenticate the RLP gateway」を参照してください。rlp_gateway 設定セクションは、HTTP クライアント設定の設定オプションも引き継ぐのでご注意ください。

設定例

このサンプル設定を参照してください:

YAML 
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"

こちらも参照してください：

YAML 
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
YAML 
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

RLP ゲートウェイを認証する

Oauth2トークンを Authorization ヘッダーとして追加して、RLP ゲートウェイを認証します。OAuth2 トークンを取得するには、OAuth2 プロバイダとして機能する UAA コンポーネントに要求を行います。 uaa_url 設定オプションで URL を指定できます。通常、https://uaa.<cf-system-domain> を使用できます。

注: UAA を使用するには、client_credentials と refresh_token の権限付与タイプ、および logs.admin 権限が必要です。
以下は、uaac コマンドラインユーティリティを使用して、UAA ユーザーを作成するための一連のコマンドの例です：
CODE 
uaac target https://uaa.<cf-system-domain>
CODE 
uaac token client get identity -s <identity-user-secret>
CODE 
uaac client add <uaa_username> --name opentelemetry --secret <uaa_password> --authorized_grant_types client_credentials,refresh_token --authorities logs.admin

UAA 認証では、ユーザー名とパスワード/シークレットの組み合わせを使用します。<uaa_username> と <uaa_password> は、レシーバの設定に指定した値と一致する限り、任意に設定できます。

新しいクライアントを作成する権限を持つ admin アカウントは、異なるセットアップで異なる名前を持つことができます。--name の値はレシーバの設定には使用されません。

設定

次の表に Cloud Foundry レシーバーの設定オプションを示します：

同梱

https://raw.githubusercontent.com/splunk/collector-config-tools/main/cfg-metadata/receiver/cloudfoundry.yaml

メトリクス

すべてのメトリクスは、ゲージまたは合計のいずれかです。詳しくは「Data types in Splunk Observability Cloud」をご確認ください。レポートされたメトリクスは、otelcol/cloudfoundry という名前のインストルメンテーションライブラリの下にグループ化されます。

メトリクス名は Cloud Foundry によって指定され、オリジン名はメトリクス名の前に . セパレータで付加されます。詳細については、Cloud Foundry ドキュメントの「https://docs.cloudfoundry.org/running/all_metrics.html」を参照してください。

属性

すべてのメトリクスは以下の属性を持ちます：

  • origin: Cloud Foundryによって文書化されたオリジン名。

  • source: アプリケーションの場合、アプリケーションの GUID。

BOSH にデプロイされた Cloud Foundry または Tanzu Application Service の場合、以下の属性も BOSH の正規の意味を使用して存在します：

  • deployment: BOSH デプロイ名。

  • index: BOSH インスタンス ID (GUID).

  • ip: BOSH インスタンス IP.

  • job: BOSH ジョブ名。

アプリケーションに固有の rep origin 名を起点とするメトリクスには、以下の属性があります：

  • instance_id：アプリケーションインスタンスの数値インデックス。これは bbs origin でも存在し、インデックスの値と一致します。

  • process_id：プロセス ID（GUID）。アプリケーションのメインプロセスである web タイプのプロセスでは、これは source_id と app_id に等しくなります。

  • process_instance_id：プロセスインスタンスの一意の ID。不透明な文字列として扱ってください。

  • process_type：プロセスタイプです。各アプリケーションには、web 型のプロセスが正確に 1 つ存在しますが、その他の種類のプロセスは複数存在する場合があります。

TAS/PCF バージョン 2.8.0 以降、および cf-deployment バージョン 11.1.0 以降では、アプリケーションメトリクスのために以下の追加属性が存在します： app_id、app_name、space_id、space_name、organization_id、organization_name。アプリケーション、スペース、および組織のそれぞれの GUID と名前を提供します。

レシーバーは、ゲートウェイが提供するどのような属性でも受け渡すので、より多くの属性を利用できる可能性があります。

トラブルシューティング

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 community #observability Slack channel to communicate with customers, partners, and Splunk employees worldwide.