インテグレーションを設定すると、これらの機能にアクセスできるようになります：

• メトリクスを表示します。独自のカスタムダッシュボードを作成することができ、ほとんどのモニターは組み込みのダッシュボードも提供しています。ダッシュボードの詳細については、「Splunk Observability Cloudでダッシュボードを表示する」を参照してください。

• Infrastructure Monitoring に表示される環境内の物理サーバー、仮想マシン、AWS インスタンス、およびその他リソースのデータ駆動型の視覚化を表示します。ナビゲータの詳細については、「Splunk Infrastructure Monitoring でナビゲーターを使用する」を参照してください。

• Metric Finder へアクセスし、モニターから送信されたメトリクスを検索します。詳細は、「メトリクス・ファインダーとメタデータ・カタログを検索する」を参照してください。

このインテグレーションを導入するには、以下の手順に従ってください：

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

   • Kubernetes にインストールする

   • Linux にインストールする

   • Windows へのインストール

2. [設定] セクションの説明に従ってインテグレーションを設定します。

3. Splunk Distribution of OpenTelemetry Collector を再起動します。

Smart Agent モニターとCollector のインテグレーションを使用するには、以下の手順に従います：

1. Smart Agent レシーバーを設定ファイルに含めます。

2. レシーバーセクションおよびパイプラインセクションの両方で、Collector 構成にモニタータイプを追加します。

   • 「Collector でSmart Agent モニターを使用する」を参照してください。

   • Smart Agent レシーバーの設定方法を参照してください。

   • 一般的な構成オプションのリストについては、「モニターの共通設定」を参照してください。

   • Collector の詳細については、「はじめに：Collector を理解して使用する」を参照してください。

• Splunk Observability Cloud で利用可能なメトリクスタイプの詳細は、「メトリクスタイプ」を参照してください。

• ホストベースのサブスクリプションプランでは、デフォルトのメトリクスは、ホスト、コンテナ、バンドルメトリクスなど、Splunk Observability Cloud のホストベースのサブスクリプションに含まれるメトリクスです。カスタムメトリクスはデフォルトでは提供されていないため、料金が発生する場合があります。詳細については、「メトリクスカテゴリ」を参照してください。

• MTSベースのサブスクリプションプランでは、すべてのメトリクスがカスタムです。

• メトリクスを追加するには、「その他のメトリクスの追加」で extraMetrics の設定方法を参照してください。

「バインド：すでに使用されているアドレス」というエラーメッセージが表示されます

「bind：すでに使用されているアドレス」のようなエラーメッセージが表示された場合は、現在の設定で必要なポートを別のリソースがすでに使用しています。このリソースは、別のアプリケーションや、Jaeger や Zipkin などのトレースツールである可能性があります。

別のポートを使用するように設定を変更できます。これらのエンドポイントやポートを変更することができます：

• レシーバー・エンドポイント

• 拡張機能のエンドポイント

• メトリクスアドレス（ポート8888の場合）

Kubernetesでこのエラーメッセージが表示され、Helmチャートを使用している場合は、コンフィギュレーションと公開ポートの両方のチャート値を更新してコンフィギュレーションを修正してください。

「2021-10-19T20:18:40.556Z info builder/receivers_builder.go:112 どのパイプラインでも使用されていないため、レシーバーを無視しています {kind": "receiver", "name": "error message"」というメッセージが表示されます

このエラーは、コンポーネント（レシーバー、プロセッサ、またはエクスポータ）が構成されているが、レシーバーパイプラインで使用されていない場合に発生します。たとえば、次のエラーメッセージは、smartagent/http レシーバーが設定されているが、どのパイプラインでも使用されていないことを示しています。

"2021-10-19T20:18:40.556Z info builder/receivers_builder.go:112 Ignoring receiver as it is not used by any pipeline {"kind": "receiver", "name": "smartagent/http"

構成が完了したら、サービスセクションのパイプラインを使用してすべてのコンポーネントをオンにする必要があります。サービスセクションは、構成ファイルのコンポーネントセクションで見つかった構成に基づいてアクティブ化されるコンポーネントを構成するために使用されます。コンポーネントが構成されていてもサービスセクション内で定義されていない場合、そのコンポーネントはアクティブになりません。

以下に設定例を示します：

service:
  pipelines:
  # Pipelines can contain multiple subsections, one per pipeline.
    traces:
    # Traces is the pipeline type.
      receivers: [otlp, jaeger, zipkin]
      processors: [memory_limiter, batch]
      exporters: [otlp, jaeger, zipkin]

詳細については「パイプラインでデータを処理する」を参照してください。

Splunk Distribution of OpenTelemetry Collector がメモリ不足です

メモリ使用量が多い、またはメモリ不足の警告が表示される場合は、サポート・ケースを開く前に次のことを行ってください：

1. 最新バージョンの OpenTelemetry Collector for Kubernetes の Splunk ディストリビューションがインストールされていることを確認します。

2. 構成ファイルで memory_limiter プロセッサを追加または変更します。例：

   processors:
     memory_limiter:
        ballast_size_mib: 2000
        check_interval: 5s
           # Check_interval is the time between measurements of memory usage for the  purposes of avoiding goingover the limits.
           # The default is 0. Values below 1s are not recommended, as this can result in unnecessary CPU consumption.
        limit_mib: 4000
           # ​​Maximum amount of memory, in MiB, targeted to be allocated by the process heap.
           # The total memory usage of the process is typically about 50 MiB higher than this value.
        spike_limit_mib: 500
           # The maximum, in MiB, spike expected between the measurements of memory usage.
        ballast_size_mib: 2000
           # BallastSizeMiB is the size, in MiB, of the ballast size being used by the process.
           # This must match the value of the mem-ballast-size-mib command line option (if used).
           # Otherwise, the memory limiter does not work correctly.

3. エラーを再現し、メモリキルが発生したポイントの近くでヒープダンプを収集してみます：

   1. 失敗しているコンポーネントの構成に pprof 拡張機能を追加します。サービスセクションのパイプラインでこの拡張機能をオンにしたことを確認してください。

   2. 問題のあるポッドに対する以下のコマンドの出力をキャプチャします：

      curl http://127.0.0.1:1777/debug/pprof/goroutine?debug=2 (http://127.0.0.1:1777/debug/pprof/goroutine?debug=2)
      curl http://127.0.0.1:1777/debug/pprof/heap > heap.out

例えば、ポッドが強制終了されるまで5分間経過していることがわかったとします：

1. ポッドをバウンスさせ、始動後の最初のデータセットを収集します。

2. 3 分間待ってから、別のデータセットを収集します。データには適切なラベルを付けてください。

3. 可能であれば、クラッシュ前に別のデータを収集します。

メモリ制限のためにポッドが強制終了されるまで、どれくらいの時間がかかりますか？問題が発生した時点のログをチェックして、明らかな繰り返しエラーがないかどうかを確認してください。

エンドツーエンドのアーキテクチャ情報など、追加で裏付けとなる情報を収集します。「サポートリクエストを開くために情報を収集する」を参照してください

__ ___ ___ _ ______ _____________ _____ ________ ___ ___ ___ ____ __ ___ ____ ____ __ ______ _____________ ______ ___ ___ ___ ____ __ ___ _________ _____

_________ __ ______ _____________ _____ _________

• ______ _ ____ __ ___ ______ _______ _______

• _______ ______ ________

_________ __ ___________ _________ ___ ____ _____ _____

• ___ _ ________ ___ ___ _______ _______ _________ _______ __ ______ ________

• ____ ___ ______ ______________ ____ _____ _____ _______ __ ___________ ____ __________ _________ ___ ______ _________ __________ __ _____ ___ ____ _______