OpenTelemetryをインストルメント化したアプリケーションをKubernetesにリンクする

Kubernetesでアプリを実行している開発者の場合は、New Relicを使用して、KubernetesインフラストラクチャがOpenTelemetryが計測されたアプリケーションにどのように影響するかを理解できます。

以下の手順を完了すると、New Relic UIを使用して、OpenTelemetryのアプリケーションレベルの指標をKubernetesインフラストラクチャの指標と関連付けることができます。これにより、テレメトリデータの全体像を確認し、チーム間で作業して、Kubernetes環境の問題の平均解決時間（MTTR）を短縮できます。

概要：データをどのように関連付けるか

このガイドの手順により、アプリケーションはインフラストラクチャ固有のメタデータをテレメトリデータに挿入できます。その結果、NewRelicUIに実用的な情報が入力されます。これを実行するために実行する手順は次のとおりです。

各アプリケーションコンテナで、テレメトリデータをコレクタに送信するための環境変数を定義します
OpenTelemetry Collector を、 resourcedetection、 resource、 batch 、および k8sattributes プロセッサを備えたエージェントモードの DaemonSet としてデプロイして、関連するメタデータ (クラスタ名、デプロイメント名、名前空間名) を挿入します。

前提条件

以下の手順を成功させるには、OpenTelemetry と Kubernetes についてすでに理解しており、次のことを行っている必要があります。

次の環境変数を作成しました。
- OTEL_EXPORTER_OTLP_ENDPOINT (地域または目的に応じた New Relic エンドポイント)
- NEW_RELIC_API_KEY (
  )
クラスターにNewRelicKubernetes統合をインストールしました
OpenTelemetryを使用してアプリケーションをインストルメント化し、OpenTelemetry Protocol（OTLP）を介してNewRelicにデータを正常に送信しました

New Relicでのコレクターの使用に関する一般的な質問がある場合は、NewRelicでのOpenTelemetryコレクターの概要を参照してください。

テレメトリデータを OpenTelemetry Collector に送信するようにアプリケーションを構成する

これを設定するには、Kubernetes YAML ファイルのenvセクションにカスタムスニペットを追加する必要があります。以下の例は、サンプルフロントエンドマイクロサービス ( Frontend.yaml ) のスニペットを示しています。このスニペットには、次のことを行う 2 つのセクションが含まれています。

セクション1：テレメトリデータがコレクターに送信されていることを確認します。これにより、環境変数OTEL_EXPORTER_OTLP_ENDPOINTにホストIPが設定されます。これは、ダウンワードAPIを呼び出してホストIPをプルすることによって行われます。
セクション 2: インフラストラクチャ固有のメタデータを添付します。これを行うには、下向き API を使用して metadata.uid をキャプチャし、それを OTEL_RESOURCE_ATTRIBUTES 環境変数に追加します。この環境変数は、OpenTelemetry Collector の resourcedetection および k8sattributes プロセッサによって使用され、追加のインフラストラクチャ固有のコンテキストをテレメトリデータに追加します。

OpenTelemetry が組み込まれた各マイクロサービスについて、マニフェストのenvセクションに以下の強調表示された行を追加します。

# Frontend.yaml
apiVersion: apps/v1
kind: Deployment
...
spec:
  containers:
  - name: yourfrontendservice
    image: yourfrontendservice-beta
  env:
  # Section 1: Ensure that telemetry data is sent to the collector
  - name: HOST_IP
        valueFrom:
          fieldRef:
            fieldPath: status.hostIP
      # This is picked up by the opentelemetry sdks
      - name: OTEL_EXPORTER_OTLP_ENDPOINT
        value: "http://$(HOST_IP):55680"
  # Section 2: Attach infrastructure-specific metadata
     # Get pod ip so that k8sattributes can tag resources
- name: POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: POD_UID
valueFrom:
fieldRef:
fieldPath: metadata.uid
      # This is picked up by the resource detector
    - name: OTEL_RESOURCE_ATTRIBUTES
      value: service.instance.id=$(POD_NAME),k8s.pod.uid=$(POD_UID)”

OpenTelemetry Collector をエージェントとして構成および展開する

Kubernetes クラスター内のすべてのノードにコレクターをエージェントとしてデプロイすることをお勧めします。エージェントはテレメトリデータを受信し、メタデータを使用してテレメトリデータを強化できます。たとえば、コレクタは、プロセッサを通じてカスタム属性やインフラストラクチャ情報を追加したり、バッチ処理、再試行、圧縮、およびクライアントインストルメンテーションレベルではあまり効率的に処理されない追加の高度な機能を処理したりできます。

コレクターの構成については、以下のサンプルコレクター構成ファイルと、これらのオプションの設定に関するセクションを参照してください。

OTLPエクスポーター
バッチプロセッサ
リソース検出プロセッサ
k8sattributesプロセッサ：一般
k8sattributesプロセッサ：RBAC
k8sattributesプロセッサ：フィルタ

receivers:
  otlp:
    protocols:
      grpc:

processors:
  batch:
  resource:
    attributes:
      - key: host.id
        from_attribute: host.name
        action: upsert
  resourcedetection:
    detectors: [ gke, gce ]
  k8sattributes:
    auth_type: "serviceAccount"
    passthrough: false
    filter:
      node_from_env_var: KUBE_NODE_NAME
    extract:
      metadata:
        - k8s.pod.name
        - k8s.pod.uid
        - k8s.deployment.name
        - k8s.cluster.name
        - k8s.namespace.name
        - k8s.node.name
        - k8s.pod.start_time
    pod_association:
      - from: resource_attribute
        name: k8s.pod.uid

exporters:
  otlp:
    endpoint: $OTEL_EXPORTER_OTLP_ENDPOINT
    headers:
      api-key: $NEW_RELIC_API_KEY
  logging:
    logLevel: DEBUG

service:
  pipelines:
    metrics:
      receivers: [ otlp ]
      processors: [ resourcedetection, k8sattributes, resource, cumulativetodelta, batch ]
      exporters: [ otlp ]
    traces:
      receivers: [ otlp ]
      processors: [ resourcedetection, k8sattributes, resource, batch ]
      exporters: [ otlp ]
    logs:
      receivers: [ otlp ]
      processors: [ resourcedetection, k8sattributes, resource, batch ]
      exporters: [ otlp ]

ステップ1：OTLPエクスポーターを構成する

まず、New Relic とともに OTLP エクスポーターを OpenTelemetry Collector 設定 YAML ファイルに追加します。ヘッダーとして。

exporters:
  otlp:
    endpoint: $OTEL_EXPORTER_OTLP_ENDPOINT
  headers: api-key: $NEW_RELIC_API_KEY

ステップ2：バッチプロセッサを構成する

バッチプロセッサはスパン、メトリック、またはログを受け入れ、それらをバッチに配置して、データの圧縮を容易にし、コレクタからの送信リクエストの数を減らします。

processors:
  batch:

手順3：リソース検出プロセッサを構成する

resourcedetectionプロセッサは、ホスト固有の情報を取得して、コレクタを介して処理されているテレメトリデータにコンテキストを追加します。この例では、Google Kubernetes Engine（GKE）とGoogle Compute Engine（GCE）を使用して、次のようなGoogleCloud固有のメタデータを取得します。

cloud.provider（ "gcp"）
cloud.platform（ "gcp_compute_engine"）
cloud.account.id
cloud.region
cloud.availability_zone
host.id
host.image.id
host.type

processors:
  resourcedetection:
Detectors: [ gke, gce ]

手順4：Kubernetes属性プロセッサを設定する（一般）

エージェントとして実行される OpenTelemetry Collector の一部として k8sattributes プロセッサを実行すると、テレメトリデータを OpenTelemetry Collector エージェントに送信するポッドの IP アドレスが検出され、ポッドのメタデータの抽出に使用されます。以下は、プロセッサセクションのみを含む基本的な Kubernetes マニフェストの例です。OpenTelemetry Collector を DaemonSetとしてデプロイするには、この包括的なマニフェストの例をお読みください。

processors:
  k8sattributes:
    auth_type: "serviceAccount"
    passthrough: false
    filter:
      node_from_env_var: KUBE_NODE_NAME
    extract:
      metadata:
        - k8s.pod.name
        - k8s.pod.uid
        - k8s.deployment.name
        - k8s.cluster.name
        - k8s.namespace.name
        - k8s.node.name
        - k8s.pod.start_time
    pod_association:
      - from: resource_attribute
        name: k8s.pod.uid

手順5：Kubernetes属性プロセッサ（RBAC）を設定する

ロールベースのアクセス制御 (RBAC) の構成を追加する必要があります。k8sattributes プロセッサには、構成されたフィルタに含まれるポッドと名前空間リソースに対する get 、 watch 、および list 権限が必要です。ClusterRole のロールベースのアクセス制御 (RBAC) を構成して、クラスター内のすべてのポッドと名前空間に必要な権限を ServiceAccount に付与する方法のこの例を参照してください。

手順6：Kubernetes属性プロセッサを設定する（検出フィルタ）

コレクターをエージェントとして実行する場合は、プロセッサーが実行しているのと同じホストからのみポッドを検出するように、検出フィルターを適用する必要があります。フィルタを使用しない場合、特に非常に大規模なクラスタでは、リソースの使用量が不必要に高くなる可能性があります。フィルタが適用されると、各プロセッサは、独自のノードで実行されているポッドについてのみKubernetesAPIにクエリを実行します。

フィルターを設定するには、下向き API を使用して、OpenTelemetry Collector エージェント構成 YAML ファイルのポッド env セクションに環境変数としてノード名を挿入します (例については、 GitHub を参照)。これにより、新しい環境変数が OpenTelemetry Collector エージェントのコンテナに挿入されます。値は、ポッドが実行されるようにスケジュールされたノードの名前になります。

spec:
  containers:
  - env:
    - name: KUBE_NODE_NAME
      valueFrom:
        fieldRef:
          apiVersion: v1
          fieldPath: spec.nodeName

次に、 k8sattributesのノードでフィルタリングできます。

k8sattributes:
    filter:
      node_from_env_var: KUBE_NODE_NAME

構成が機能していることを確認します

OpenTelemetryデータをKubernetesデータに正常にリンクすると、分散トレースUI内のスパンにk8s.cluster.nameやk8s.deployment.nameなどのKubernetes属性が表示されるはずです。

クリックして画像を拡大します。

次は何ですか？

OpenTelemetryをインストルメント化したアプリをKubernetesに接続したので、OpenTelemetryとNewRelicの使用を改善するためのヒントについてのベストプラクティスガイドを確認してください。

上記の手順の詳細については、このブログ投稿「OpenTelemetry トレース、メトリクス、およびログを Kubernetes パフォーマンスデータと相関させる」を参照してください。