Oracle Observability and Managementソリューション: OpenTelemetryを使用したOCIでのKubernetesアプリケーションの監視 (2025/02/08)

Oracle Observability and Managementソリューション: OpenTelemetryを使用したOCIでのKubernetesアプリケーションの監視 (2025/02/08)

https://blogs.oracle.com/observability/post/using-opentelemetry-to-monitor-kubernetes-applications-in-oci-observability-and-management-solutions

投稿者:Mahesh Sharma | Consulting Member of Technical Staff

Juergen Fleischer | Master Product Manager

Ashwini R | Senior Member Technical Staff


今日のクラウドネイティブな環境では、Kubernetesとマイクロサービスで構築されたアプリケーションの信頼性、パフォーマンス、スケーラビリティを確保するために、可観測性が重要です。可観測性により、アプリケーションの動作の包括的なビューが提供されるため、開発者はパフォーマンスのボトルネックを特定し、問題をトラブルシューティングし、アプリケーションを最適化できます。


Oracleは、可観測性をサポートする自動計測用の可観測性および管理ソリューションを提供します。Oracle Application Performance Monitoring (APM) Java Agentは、Javaベースのアプリケーションへの詳細な可視性を提供するそのようなソリューションの1つです。また、OpenTelemetry演算子は、OpenTelemetryを使用してアプリケーションをインストゥルメントするプロセスを簡素化する別の主要な製品です。


このブログでは、KubernetesアプリケーションからOracleのObservability and Management (O&M) APM and Monitoring Servicesにテレメトリ・データを送信する、完全なOpenTelemetry (OTel)ベースのアプローチを紹介しています。これにより、エージェント、コレクタ、オペレータなどのOTelコンポーネントの標準化が可能になります。このアプローチにより、柔軟性と選択肢が得られ、ニーズに合ったソリューションを選択できます。また、ログをLogging Analyticsに送信する方法についても説明します。



可観測性ソリューションを設計する際の選択は重要です。


包括的な可観測性ソリューションが鍵であることをすでに理解しています。これは、要件に応じて異なるソリューションが必要となる可能性があることを意味します。1つのベンダーにソリューションを検討しているか、ベンダーに依存しないビューがあるか、一貫した監視アプローチを提供するために他のシステムと統合する必要がある場合があります。Oracleには、これらの要件を満たすために複数のソリューションを組み合せて使用できます。テレメトリ・データをOCIサービスに送信するOpenTelemetryオプションを確認します。



Oracle Application Performance Monitoringエージェントによるアプリケーションのインストゥルメント


Oracle Application Performnce Monitoringサービスは、アプリケーションをインストゥルメントするための複数のエージェントを提供します。このエージェントは、必要に応じて、OTelコレクタを必要とせずに、APMにテレメトリ・データを直接送信するように構成できます。


  • APM Javaエージェント: Javaアプリケーションの自動インストゥルメンテーション用
  • APM .NETエージェント: Windowsで実行されている.NETアプリケーションの場合
  • APMブラウザ・エージェント: ユーザー・ブラウザのパフォーマンスを監視する場合
  • APM Javaトレーサ: javaアプリケーションのトレースをより詳細に制御できます。


これらのエージェントは、OpenTelemetryおよびJaegerやZipkinなどのオープンソース・トレース・ツール(ここで説明)のサポートとともに、Oracleの多様な可観測性ソリューションを示します。メトリックをOCI Monitoringサービスに送信し、ログをKubernetesおよびアプリケーションからLogging Analytics Serviceに送信することもできます。これを組み合せると、アプリケーションのパフォーマンス、状態およびトラブルシューティングの包括的なビューが提供されます。



データを収集およびエクスポートするためのOpenTelemetryアプローチ


OpenTelemetryは、テレメトリ・データを収集およびエクスポートするために連携する一連のツールを提供します。エコシステムの主要なコンポーネントを見てみましょう。


  • OpenTelemetryエージェント: エージェントは、Kubernetesポッドまたはコンテナ内に存在し、アプリケーションからテレメトリ・データを自動的に取得します。使用できる言語固有のエージェントが複数あり、アプリケーション環境に応じて自動インストゥルメンテーション・オプションがあります。自動インストゥルメンテーション・オプションを確認します。
  • OpenTelemetryコレクタ: コレクタはバックエンドにデータを送信するときにオプションですが、設定に依存する大きな利点があります。コレクタは、エージェントから遠隔測定データを受信するための中心的なハブとして機能できます。テレメトリ・データをフィルタで除外またはエンリッチし、複数のバックエンドに送信するように構成できます。これにより、特定のニーズに応じてデータをルーティングおよび処理できます。
  • OpenTelemetry演算子: オペレータは、KubernetesでのOpenTelemetryコンポーネントの管理およびデプロイメントを簡略化します。インストール、スケーリング、アップグレードなどのタスクを自動化します。


図1: OTelツールセットがOCI O&Mサービスにテレメトリを送信



Kubernetes環境へのOpenTelemetryツールセットのインストール


OpenTelemetryをKubernetes環境に統合するには、いくつかのステップが必要です。OTelオペレータ、コレクタおよびエージェントをインストールするには、いくつかの方法があります。以下は一例です。オプションと詳細情報については、こちらをご覧ください。

Step1: OpenTelemetry演算子のインストール


オペレータは、インストゥルメンテーションのライフサイクル管理を自動化します。ほとんどの場合、cert-managerの前提条件が必要です。


Cert-Managerをインストールします。


kubectl apply -f https://github.com/cert-manager/certmanager/releases/latest/download/cert-manager.yaml


次に、OpenTelemetryオペレータ・マニフェストをインストールします。


kubectl apply -f https://github.com/open-telemetry/opentelemetry-operator/releases/latest/download/opentelemetry-operator.yaml


続行する前にオペレータポッドが実行中状態であることを確認してください:


kubectl get pods -n opentelemetry-operator-system


ステップ2: OpenTelemetryコレクタの構成


コレクタは、アプリケーションとO&Mサービスの間の仲介として機能します。このコレクタの構成を定義するOpenTelemtryCollectorカスタム・リソース(CR)を作成するOpenTelemetry-collector.yamlファイルの例を次に示します。


apiVersion: opentelemetry.io/v1alpha1  

kind: OpenTelemetryCollector  # The type of resource we are creating 

metadata:

  name: OpenTelemetry-collector # Name of the collector (can be anything descriptive)

  namespace: my-app # Namespace where the app is installed (adjust as needed) 

spec: 

  mode: deployment # Deployment mode for the collector 

  serviceAccount: default 

  config: >  

    receivers: # Defines where to receive telemetry data 

      otlp: # Receiver for OpenTelemetry Protocol messages

        protocols:

          grpc: # Enable gRPC protocol

          http: # Enable HTTP protocol

    processors: # Modify or enrich telemetry data before sending it to exporters 

      batch: # Batch processor for efficiency

    exporters:  

       otlphttp/ociapm: # Exporter for sending traces to OCI APM 

         endpoint: "https://123456789abcdefgh.apm-agt.us-ashburn-1.oci.oraclecloud.com/20200101/opentelemetry/" # Endpoint URL (see note below, to find your endpoint)

         headers:

            Authorization: "dataKey ABCDEFGH123456789" # APM private key

       otlphttp/ocimetrics: # Exporter for sending metrics to OCI Metrics

         endpoint: "https:// 123456789abcdefgh.apm-agt.us-ashburn-1.oci.oraclecloud.com/20200101/observations/metric?dataFormat=otlp-metric&dataFormatVersion=1" # Endpoint URL (see note below, to find your endpoint)

         headers:  # Authorization header 

           authorization: "dataKey ABCDEFGH123456789"   

         tls:

           insecure: false # Disable insecure connections

    service:

      pipelines:

        traces:   # Pipeline configuration for traces 

          receivers: [otlp]

          processors: [batch] 

          exporters: [otlphttp/ociapm]

        metrics:  # Pipeline configuration for metrics 

          receivers: [otlp]

          processors: [batch]

          exporters: [otlphttp/ocimetrics]

  resources: # Resource limits and requests

    limits:

      cpu: 1

      memory: 2Gi 

    requests: 

      cpu: 0.5

      memory: 1G


ノート: エンドポイントURLは、データがアップロードされる場所です。認可データ・キーを使用すると、APMはテレメトリ・データを受け入れることができます。エンドポイントとデータ・キーを見つけるには、次の手順に従ってください。



ステップ3: コレクタのデプロイ


構成の準備が整ったら、次を使用してコレクタをデプロイします。


kubectl apply -f OpenTelemetry-collector.yaml


このコマンドを実行すると、Kubernetesは、OpenTelemetry-collector.yaml定義に基づいて必要なリソースを作成します。


OpenTelemetryコレクタが実行されているかどうかを確認できます。


kubectl get pods -n <your_namespace>


実行中ステータスのOpenTelemetry-collector-xxxxのようなポッド名が表示されます。



ステップ4: エージェントでアプリケーションを計測


次に、トレースおよびメトリックを送信するためにアプリケーションを自動的にインストゥルメントする方法を見てみましょう。


以下は、Kubernetesでアプリケーションをインストゥルメントするカスタム・リソース(CR)のYAML (my-app-instrumentation.yaml)の例です。これは、このケースではJavaアプリケーションです。


apiVersion: opentelemetry.io/v1alpha1

kind: Instrumentation

metadata:

  name: my-app-instrumentation # Name of the instrumentation resource

  namespace: my-app # Namespace where your application is running

spec:

  java:

    image: ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-java:2.5.0 # Java auto-instrumentation image


  env:

    exporting

    - name: OPENTELEMETRY _TRACES_EXPORTER # Enable OTLP (OpenTelemetry Protocol) for trace

      value: otlp

    - name: OPENTELEMETRY _EXPORTER_OTLP_ENDPOINT # Endpoint where traces will be sent (see note below)

      value: "http://OpenTelemetry -collector.my-app:4318"

    - name: OPENTELEMETRY _EXPORTER_OTLP_PROTOCOL # Define the protocol used for trace exporting 

      value: "http/protobuf"    

    - name: OPENTELEMETRY _METRICS_EXPORTER # Enable OTLP for metrics exporting

      value: otlp

    - name: OPENTELEMETRY _EXPORTER_OTLP_METRICS_ENDPOINT # Endpoint where metrics will be sent 

      value: "http://OpenTelemetry -collector.my-app:4317"

    - name: OPENTELEMETRY _EXPORTER_OTLP_METRICS_PROTOCOL # Define the protocol used for metrics exporting

      value: grpc

    - name: OPENTELEMETRY _SERVICE_NAME # Define a unique service name to identify telemetry data from this application

      value: "my-java-app"


注意: OPENTELEMETRY _EXPORTER_OTLP_ENDPOINTは、設定によって異なります。エンドポイントの作成方法を確認するには:


kubectl get services -n <namespace>


サービス名を検索し、ネームスペースとポート(<service-name>. <namespace>.<port>)を追加します。




YAMLの準備ができたので、適用します。


kubectl apply -f my-app-instrumentation.yaml


インストゥルメンテーションが適用されているかどうかを確認します。


kubectl get instrumentation -n my-app



ステップ5: Annotationを使用してエージェントをアプリケーションに統合


OTelツールセットがインストールされたので、最後のステップは、エージェントをアプリケーションに統合するようにKubernetesに指示することです。これは注釈によって行われます。この例では、StatefulSetsを使用して、様々なレベル(デプロイメント、StatefulSetsおよびネームスペース)で注釈を適用できます。


kubectl edit statefulset <statefulset-name> -n <namespace>


「メタデータ」の下に、注釈を追加します。


metadata:

  annotations:

    instrumentation.opentelemetry.io/inject-java: "true"


ここで、StatefulSetを再起動して変更を適用します。


kubectl rollout restart statefulset <statefulset-name> -n <namespace>


または、自動インジェクションを適用する必要があるポッドを再起動します:


kubectl delete pod <your-pod-name> -n <your-namespace-name>


設定が完了し、OCI O&Mサービスでトレース/スパンおよびメトリックが表示されるはずです。


図2: OCI O&Mサービスの詳細のトレース/スパン



Kubernetesクラスタの可視性のためのログによる可観測性の完了


トレース、スパンおよびメトリックの取得方法を示しています。OCI O&M Servicesにログを送信して、OCI Management AgentおよびFluentdを使用してKubernetesクラスタを完全に可視化することもできます。これに関する指示に従うのは簡単です。ここを参照してください。


可観測性は、クラウドネイティブのアプリケーション環境において最も重要であり、オラクルには様々な方法で実現できます。Oracleは、オープンソースのトレース・ソリューションをサポートしながら、Java、.NET、ブラウザなどの特定のテクノロジに対して一連のエージェントを提供します。OpenTelemetryツールセット(エージェント、コレクタおよびオペレータ)は、標準化および制御を求めるユーザーに柔軟でベンダーに依存しない代替手段を提供します。


組織にとって最適な方法は、特定の要件とプリファレンスによって異なります。OracleとOpenTelemetryの両方のすべてのソリューションを探索して、ニーズに最も適したソリューションを見つけてください。OCIのObservability and Management Servicesは、テレメトリ・データの送信にどのパスを選択しても、トラブルシューティング、パフォーマンスの監視、アプリケーションに関する優れたインサイトを提供します。APMを無料で試してみるのはなぜですか?


リソース:

コメント

このブログの人気の投稿

Oracle Database 19cサポート・タイムラインの重要な更新 (2024/11/20)

Oracle GoldenGate 23aiでMicrosoft Fabricでのオープン・ミラーリングがサポートされるようになりました (2024/11/19)

Oracle APEXのInteractive Gridで、Oracle Formsと比較して、重複行の検証を制御/通過させる方法 (2022/07/21)