Kubernetesでアプリケーションを実行している開発者であれば、 New Relicを使用して、 KubernetesインフラストラクチャがOpenTelemetryインストゥルメントされたアプリケーションにどのように影響するかを理解できます。
以下の手順を完了すると、 New Relic UIを使用して、 OpenTelemetryのアプリケーション レベルのメトリックをKubernetesインフラストラクチャ メトリックと相関させることができます。 これにより、テレメトリデータの全体像を把握し、チーム間で連携して、 環境の問題の平均解決時間 (MTTR )Kubernetes を短縮できます。
データの相関関係
このドキュメントでは、アプリケーションがインフラストラクチャ固有のデータをテレメトリデータに挿入できるようにする手順について説明します。 その結果、New Relic UI に実用的な情報が表示されます。 開始するには、次の手順に従います。
各アプリケーション コンテナーで、テレメトリー データをコレクターに送信するための環境変数を定義します。
関連するメタデータ (クラスタ、コンポーネント、ネームスペース名) を挿入するために、
resourcedetection
、resource
、batch
、およびk8sattributes
プロセッサを使用してOpenTelemetry Collector をDaemonSet
インエージェント モードとしてデプロイします。
あなたが始める前に
以下の手順を正常に完了するには、OpenTelemetry と Kubernetes についてすでに理解しており、次の操作を実行しておく必要があります。
次の環境変数を作成しました:
OTEL_EXPORTER_OTLP_ENDPOINT
詳細については、 New Relic OTLP エンドポイントを参照してください。NEW_RELIC_API_KEY
: 詳細については、 New Relic APIキーを参照してください。
を使用してKubernetes クラスタをOpenTelemetry インストールしました。
アプリケーションが でインストゥルメントされ、OpenTelemetry New RelicOpenTelemetryProtocol (OTLP) 経由で にデータを正常に送信しました。
でのコレクターの使用に関する一般的な質問がある場合は、New Relic OpenTelemetryでの コレクターの概要New Relic を 参照してください。
テレメトリ データを OpenTelemetry Collector に送信するようにアプリケーションを構成する
これを設定するには、Kubernetes YAML ファイルのenv
セクションにカスタム スニペットを追加する必要があります。 以下の例は、サンプルのフロントエンド マイクロサービス ( Frontend.yaml
) のスニペットを示しています。 スニペットには、次の操作を実行する 2 つのセクションが含まれています。
Section 1: テレメトリーデータがコレクターに送信されていることを確認します。 これにより、環境変数
OTEL_EXPORTER_OTLP_ENDPOINT
がホスト IP で設定されます。 これは、下位 API を呼び出してホスト IP を取得することによって行われます。Section 2: インフラストラクチャ固有のメタデータを添付します。 これを行うには、下向き API を使用して
metadata.uid
をキャプチャし、それをOTEL_RESOURCE_ATTRIBUTES
環境変数に追加します。 この環境変数は、 OpenTelemetryのresourcedetection
およびk8sattributes
プロセッサによって、テレメトリーデータにインフラストラクチャ固有の追加のコンテキストを追加するために使用されます。
OpenTelemetryでマイクロサービス インストゥルメントされた各場合、以下の強調表示された行をマニフェストの env
セクションに追加します。
# Frontend.yamlapiVersion: apps/v1kind: 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コレクターの構成とデプロイ
クラスター内のすべてのノードでコレクター をエージェントとして デプロイすることをお勧めします。Kubernetesエージェントはテレメトリーデータを受信し、テレメトリーデータをメタデータで強化できます。 たとえば、コレクターは、プロセッサーを介してカスタム アトリビュートやインフラストラクチャ情報を追加したり、クライアント インストゥルメンテーション レベルではあまり効率的に処理されないバッチ処理、再試行、圧縮、および追加の高度な機能を処理したりできます。
次のオプションのいずれかを選択してクラスタを監視できます。
(推奨) KubernetesOpenTelemetryを使用して クラスタをインストールします 。このオプションは、コレクターをエージェントとして自動的にデプロイします。すべてが箱から出してすぐに動作し、Kubernetes APMテレメトリーとKubernetes UI に メタデータが含まれます。
手動設定とデプロイメント: 手動で設定したい場合は、次の手順に従います。
OTLPエクスポーターを構成する
OTLPOpenTelemetry エクスポータを New Relicとともにヘッダーとして Collector 設定 YAML ファイル に追加します。
exporters:otlp:endpoint: $OTEL_EXPORTER_OTLP_ENDPOINTheaders: api-key: $NEW_RELIC_API_KEYバッチプロセッサを構成する
バッチ プロセッサは、スパン、メトリクス、またはログを受け入れ、それらをバッチに配置します。 これにより、データの圧縮が容易になり、コレクターからの送信要求が削減されます。
processors:batch:リソース検出プロセッサを構成する
resourcedetection
プロセッサは、ホスト固有の情報を取得して、コレクターを通じて処理されるテレメトリーデータに追加のコンテキストを追加します。 この例では、Google Kubernetes Engine (GKE) と Google 計算 Engine (GCE) を使用して、次のようなGoogle Cloud固有のメタデータを取得します。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]
Kubernetes 属性プロセッサを構成する (一般)
エージェントとして実行される OpenTelemetry Collector の一部として
k8sattributes
プロセッサを実行すると、テレメトリ データを OpenTelemetry Collector エージェントに送信するポッドの IP アドレスが検出され、ポッドのメタデータの抽出に使用されます。以下は、プロセッサ セクションのみを含む基本的な Kubernetes マニフェストの例です。OpenTelemetry Collector をDaemonSet
としてデプロイするには、この 包括的なマニフェストの例をお読みください。processors:k8sattributes:auth_type: "serviceAccount"passthrough: falsefilter:node_from_env_var: KUBE_NODE_NAMEextract:metadata:- k8s.pod.name- k8s.pod.uid- k8s.deployment.name- k8s.cluster.name- k8s.namespace.name- k8s.node.name- k8s.pod.start_timepod_association:- from: resource_attributename: k8s.pod.uidKubernetes 属性プロセッサ (RBAC) を構成する
ロールベースアクセス制御 (RBAC) の設定を追加する必要があります。
k8sattributes
プロセッサには、構成されたフィルターに含まれるポッドおよびネームスペース リソースに対するget
、watch
、およびlist
権限が必要です。 この例では、ClusterRole
のロールベース アクセス制御 (RBAC) を構成して、ServiceAccount
にクラスタ内のすべてのポッドとネームスペースに対する必要な権限を付与する方法を示します。Kubernetes 属性プロセッサ (検出フィルター) を構成する
コレクターをエージェントとして実行する場合は、プロセッサが実行されている同じホストからのポッドのみを検出するように、検出フィルターを適用する必要があります。 フィルターを使用しない場合、特に大規模なクラスターでは、リソースの使用量が不必要に高くなる可能性があります。 フィルターが適用されると、各プロセッサーは、自身のノードで実行されている Pod 用のKubernetes APIのみを記述します。
フィルターを設定するには、下向きAPI使用して、 OpenTelemetryコレクター エージェント設定 YAML ファイルの Pod
env
セクションに環境変数としてノード名を挿入します。 例については、GitHub のotel-collector-config.yml
ファイルを参照してください。 これにより、 OpenTelemetryコレクターエージェントのコンテナに新しい環境変数が挿入されます。 値は、ポッドの実行がスケジュールされたノードの名前になります。spec:containers:- env:- name: KUBE_NODE_NAMEvalueFrom:fieldRef:apiVersion: v1fieldPath: spec.nodeName次に、
k8sattributes
のノードでフィルタリングできます。k8sattributes:filter:node_from_env_var: KUBE_NODE_NAME
構成が機能していることを確認します
OpenTelemetryデータとKubernetesデータが正常にリンクされると、設定が機能していることを確認できるようになります。
注意
Kubernetes概要ページには、 New RelicエージェントまたはOpenTelemetryによるアプリケーション モニターからのデータのみが表示されます。 ご使用の環境でさまざまなインストゥルメンテーション プロバイダーが混在している場合、このページに完全なデータが表示されない場合があります。
one.newrelic.com > All capabilities > APM & Servicesに移動し、 Services - OpenTelemetry内のアプリケーションを選択します。
左側のナビゲーション ペインでKubernetesをクリックします。
Kubernetes の概要ページを表示するには、 one.newrelic.com > All capabilities > APM & Services > (selected app) > Kubernetesに移動してください。