Cloud Foundry レシーバー 🔗

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

はじめに 🔗

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

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

インストーラ・スクリプトを使用して Linux 用 Collector をインストールします。

インストーラ・スクリプトを使用して Collector for Windows をインストールします。

Install the Collector for Kubernetes using Helm

次の文書で説明するようにレシーバーを設定します。
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をご利用のお客様

Submit a case in the Splunk Support Portal .
Contact Splunk Support .

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

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

このページは 2024年12月12日に最終更新されました。

Related Topics