Docs » Splunk Observability Cloud でサポートされているインテグレーション » Collectorコンポーネント: レシーバー » Cloud Foundry レシーバー

Cloud Foundry レシーバー 🔗

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

はじめに 🔗

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

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

  1. 次の文書で説明するようにレシーバーを設定します。

  2. Collector を再起動します。

サンプル構成 🔗

レシーバーを有効にするには、以下の設定例のように、設定ファイルの receivers セクションに cloudfoundry を追加します。詳細については、設定 を参照してください。

receivers:
  cloudfoundry:

設定を完了するには、設定ファイルの service セクションの metrics パイプラインに、レシーバーを含めます：

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 ユーザーのパスワード。

これらの設定の使用方法については、RLP ゲートウェイを認証する を参照してください。rlp_gateway 設定セクションは、HTTP クライアント設定 の設定オプションも継承していることに注意してください。

設定例 🔗

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

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"

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

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

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

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

注釈

UAA を使用するには、client_credentials と refresh_token の権限付与タイプ、および logs.admin 権限が必要です。

以下は、uaac コマンドラインユーティリティを使用して、UAA ユーザーを作成するための一連のコマンドの例です：

  • 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 認証では、ユーザー名とパスワード/シークレットの組み合わせを使用します。上記の <uaa_username> と <uaa_password> は、レシーバーの設定に指定した値と一致する限り、何でも設定できます。

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

設定 🔗

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

メトリクス 🔗

すべてのメトリクスは、ゲージか合計のいずれかです。詳細については、Splunk Observability Cloud のデータ型 を参照してください。報告されたメトリクスは、otelcol/cloudfoundry という名前のインストルメンテーションライブラリの下にグループ化されています。

メトリクス名は Cloud Foundry によって指定され、オリジン名はメトリクス名の前に . セパレータで付加されます。詳細については、Cloud Foundry Component Metrics を参照してください。

属性 🔗

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

  • 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 にも存在し、index の値と一致します。

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

  • process_instance_id: プロセスインスタンスの一意の ID。不透明な文字列として扱います。

  • process_type: プロセスタイプ。各アプリケーションは、web 型のプロセスを 1つだけ持ちますが、多くは他のプロセスをいくつでも持ちます。

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

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

トラブルシューティング 🔗

Splunk Observability Cloudをご利用のお客様で、Splunk Observability Cloudでデータを確認できない場合は、以下の方法でサポートを受けることができます。

Splunk Observability Cloudをご利用のお客様

見込み客および無料トライアルユーザー様

  • Splunk Answers のコミュニティサポートで質問し、回答を得る

  • Splunk #observability ユーザーグループの Slack チャンネルに参加して、世界中の顧客、パートナー、Splunk 社員とのコミュニケーションを図る。参加するには、Get Started with Splunk Community マニュアルの チャットグループ を参照してください。

This page was last updated on 2024年05月29日.