• /
  • EnglishEspañol日本語한국어Português
  • ログイン今すぐ開始

この機械翻訳は、参考として提供されています。

英語版と翻訳版に矛盾がある場合は、英語版が優先されます。詳細については、このページを参照してください。

問題を作成する

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

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

以下の手順を完了すると、 New Relic UIを使用して、 OpenTelemetryのアプリケーション レベルのメトリックをKubernetesインフラストラクチャ メトリックと相関させることができます。 これにより、テレメトリデータの全体像を把握し、チーム間で連携して、 環境の問題の平均解決時間 (MTTR )Kubernetes を短縮できます。

データの相関関係

このドキュメントでは、アプリケーションがインフラストラクチャ固有のデータをテレメトリデータに挿入できるようにする手順について説明します。 その結果、New Relic UI に実用的な情報が表示されます。 開始するには、次の手順に従います。

あなたが始める前に

以下の手順を正常に完了するには、OpenTelemetry と Kubernetes についてすでに理解しており、次の操作を実行しておく必要があります。

でのコレクターの使用に関する一般的な質問がある場合は、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.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コレクターの構成とデプロイ

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

次のオプションのいずれかを選択してクラスタを監視できます。

  • (推奨) KubernetesOpenTelemetryを使用して クラスタをインストールします 。このオプションは、コレクターをエージェントとして自動的にデプロイします。すべてが箱から出してすぐに動作し、Kubernetes APMテレメトリーとKubernetes UI に メタデータが含まれます。

  • 手動設定とデプロイメント: 手動で設定したい場合は、次の手順に従います。

    OTLPエクスポーターを構成する

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

    exporters:
    otlp:
    endpoint: $OTEL_EXPORTER_OTLP_ENDPOINT
    headers: 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: 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

    Kubernetes 属性プロセッサ (RBAC) を構成する

    ロールベースアクセス制御 (RBAC) の設定を追加する必要があります。 k8sattributesプロセッサには、構成されたフィルターに含まれるポッドおよびネームスペース リソースに対するgetwatch 、および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_NAME
    valueFrom:
    fieldRef:
    apiVersion: v1
    fieldPath: spec.nodeName

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

    k8sattributes:
    filter:
    node_from_env_var: KUBE_NODE_NAME

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

OpenTelemetryデータとKubernetesデータが正常にリンクされると、設定が機能していることを確認できるようになります。

注意

Kubernetes概要ページには、 New RelicエージェントまたはOpenTelemetryによるアプリケーション モニターからのデータのみが表示されます。 ご使用の環境でさまざまなインストゥルメンテーション プロバイダーが混在している場合、このページに完全なデータが表示されない場合があります。

  1. one.newrelic.com > All capabilities > APM & Servicesに移動し、 Services - OpenTelemetry内のアプリケーションを選択します。

  2. 左側のナビゲーション ペインでKubernetesをクリックします。

This is an image of the Kubernetes APM page

Kubernetes の概要ページを表示するには、 one.newrelic.com > All capabilities > APM & Services > (selected app) > Kubernetesに移動してください。

次のステップを選択

See our best practices guide

OpenTelemetry と New Relic の使用を改善する方法を学びます。

Check out this blog post

OpenTelemetry 、メトリクス、ログをKubernetesパフォーマンスデータと相関させる

Copyright © 2024 New Relic株式会社。

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.