PrometheusとOpenTelemetryのよりよい相互運用

PrometheusやOpenTelemetryなどのツールは、複雑な分散システムの健全性やパフォーマンス、可用性を監視するのに役立ちます。どちらもCloud Native Computing Foundation（CNCF）の傘下にある、オープンソースのプロジェクトです。では、オブザーバビリティにおいてそれぞれが果たす役割は何でしょうか？

OpenTelemetry（略してOTel）は、テレメトリーデータの計装、生成、収集、エクスポートのためのベンダーニュートラルなオープン規格です。Prometheusは、組織内の監視とアラート送信に広く使用されている、オブザーバビリティ領域において欠かせない存在です。

PrometheusとOTelはどちらもメトリクスを生成しますが、その相違と類似性について説明すべきことは多く、それらを今回のブログで取り上げることはしません。それよりも今回は、Kubernetes（K8s）環境において、OTelがどのようにPrometheusをサポートするかについてご紹介したいと思います。以下の内容を扱います。

• OTelコレクターのPrometheusレシーバーを、どうやってPrometheusのメトリクス取り込みに使用するか
• K8sクラスタレシーバーやKubelet statsレシーバーなどのOTelネイティブなオプションを通じてPrometheusのメトリクスを収集する代替的方法
• Target Allocator（TA）をPrometheusのサービス検出にどのように使用し、Prometheusのターゲットの均等な分散をどう確実に行うか

最後に、PrometheusとOTelのデータに関してNew Relicが提供するオプションを確認していきます。

OTelとPrometheus

OTelは、基本的にオブザーバビリティのインストゥルメンテーション段階を扱うため、テレメトリー保存のためのバックエンドは提供しません。データのストレージ、アラート送信、クエリを実行するには、バックエンドのベンダーに転送する必要があります。

一方、Prometheusは、インストゥルメンテーションクライアントに加え、メトリクスに使用できる時系列のデータ保存を提供します。ウェブのユーザーインタフェースを介して図表を確認したり、アラートを設定したり、データのクエリを実行できます。また、テキストベースのPrometheus Exposition Formatとして知られるデータ形式にも対応します。

Prometheusのデータは、次元時系列として保存されます。すなわち、データは属性（ラベルやディメンションなど）とタイムスタンプを有します。

Prometheusのサーバーは、設定ファイルで定義されたターゲットからPrometheusのメトリクスデータを収集します。ターゲットは、Prometheusのサーバーが保存するメトリクスを表示するエンドポイントです。

Prometheusは、監視領域においてきわめて汎用性が高く、 Kubernetes やHashiCorp Nomadをはじめとする多くのツールがPrometheus形式のメトリクスをネイティブに生成します。そうでないツールに関しては、Prometheusでデータを集計し、PrometheusにインポートするためのPrometheusエクスポーターが、ベンダーやコミュニティによりいくつも構築されています。

Prometheusはさまざまなインフラストラクチャやアプリケーションのメトリクス監視に使用できますが、もっとも一般的なユースケースはKubernetes監視です。今回のブログでは、Prometheus監視のこの側面について詳しく見ていきます。

OpenTelemetryでのPrometheusメトリクス

このセクションでは、OTelとPrometheus間の相互運用性を可能にしているいくつかのOTelコレクターのコンポーネントについてご紹介します。

OTelコレクター

はじめに、コレクターをざっと復習しましょう。これは、複数のソースからテレメトリーを収集し、複数の目的地へデータをエクスポートするために使用できる、OTelのコンポーネントです。またコレクターは、データ属性の変更や個人を特定する情報の排除といったテレメトリーの処理も行います。例えば、PrometheusのSDKを使用してメトリクスを生成し、それをコレクターで取り込み、処理し（必要な場合）、それを任意のバックエンドに転送できます。

Prometheusレシーバー

Prometheusレシーバーにより、Prometheusメトリクスを表示するどんなソフトウェアからもメトリクスを収集できるようになります。サービスをスクレイピングするためのPrometheusの簡単な代替として機能し、scrape_configの設定のフルセットに対応します。

OTelのコンテキストをメトリクスイベントに関連付ける記録値の見本に関心がある場合、Prometheusレシーバーを使用してそれらをPrometheusの形式で取り込み、OpenTelemetry Protocol（OTLP）形式へと変換することもできます。これにより、トレースをメトリクスに相関づけることができます。

このコンポーネントについて考慮すべきことは、これが開発中であるということです。そのため、これがステートフルコンポーネントであるということを含めていくつかの制限があります。さらに、OTelコミュニティは、コレクターの複数のレプリカが実行されている時にはこのコンポーネントを使用しないことを推奨しています。 そのような状況では、以下のことが起こるためです。

• コレクターがスクレイピンクを自動スケーリングできない
• 同じ設定で実行されているレプリカがターゲットを複数回スクレイピングする
• スクレイピングを手動でシャードするために、各レプリカで異なるスクレイピング設定が必要になる

エクスポーター

OTelコレクターからPrometheusにメトリクスをエクスポートする場合、PrometheusエクスポーターとPrometheusリモート書き込みエクスポーターの2つの選択肢があります。

Prometheusエクスポーターにより、データはPrometheus形式で送信でき、その後、Prometheusサーバーでスクレイピングされます。これは、PrometheusスクレイピングHTTPエンドポイントを介してメトリクスをレポートするのに使用されます。この例を試してみることで、詳細を確認できます。ただし、すべてのメトリクスが1回のスクレイピングで送信されるため、このスクレイピングにはあまり拡張性はありません。

スケーリングの懸念を解決するには、代わりにPrometheusリモート書き込みエクスポーターを使用することもできます。複数のコレクターインスタンスから、データを問題なくPrometheusにプッシュできます。Prometheusはリモート書き込みの取り込みに対応するため、このエクスポーターを使用してOTelメトリクスを生成し、それをPrometheusリモート書き込みとの互換性があるバックエンドに送信することもできます。これらのエクスポーターのアーキテクチャーについては、こちらをご覧ください。

ターゲットアロケーター 

拡張性とは、パフォーマンスとリソースの割り当てを効果的に維持しながら、監視対象のターゲットやメトリクスの増加に対応するための能力であり、これはPrometheusの一般的な課題です。これに対するオプションの1つは、ラベルやディメンションに基づきワークロードをシャーディングすることです。すなわち、複数のPrometheusインスタンスを使用して、特定のパラメーターに従いメトリクスを管理します。これにより、個々のインスタンスの負担を軽減できます。ただし、このアプローチに関しては、検討すべきことが2つあります。

1つ目は、シャーディングされたインスタンスのクエリを実行するために、管理インスタンスが必要だということです。つまり、+1がNと同じメモリを持つN+1のPrometheusインスタンスが必要になるため、メモリのリクエストが倍増します。2つ目は、Prometheusのシャーディングでは、たとえ後で破棄されるとしても、各インスタンスがターゲットをスクレイピングする必要があることです。

注記すべき点は、もしPrometheusのインスタンスのメモリ量が個々のインスタンスのメモリの合計だった場合、シャーディングのメリットはあまりないことです。より大きいインスタンスを使用すれば、すべてを直接スクレイピングできます。シャーディングを行う理由は、通常、フォールトトレランスの量の確保のためです。例えば、1つのPrometheusインスタンスがメモリ不足（OOM）となった場合、アラートのパイプライン全体がオフラインになるわけにはいきません。

幸いなことに、OTelオペレーターのTAがこの問題に効果を発揮します。例えば、スクレーピングされないことが明らかなターゲットを自動的に排除できます。Hashmodでシャーディングを行う一方、保有するレプリカの数に基づき設定を更新する必要があります。さらに、もしすでにKubernetesインフラストラクチャに関するPrometheusメトリクスを収集しているのなら、TAの使用はうってつけのオプションです。

TAはOTelオペレーターの一部です。OTelオペレーターは、以下のことができるKubernetesオペレーターです。

• OpenTelemetryコレクターの管理
• ポッドへの自動インストゥルメンテーションの挿入と設定

実際、オペレーターはKubernetesで2つの新たなカスタムリソース（CR）タイプ（OpenTelemetryコレクターCRと自動インストゥルメンテーションCR）を作成し、この機能に対応します。

TAは、オペレーターのOTelコレクター管理機能に関するオプションのコンポーネントであり、 Prometheusのサービス検出とメトリクス収集機能を分離して、それぞれを個別に拡張できるようにするためのメカニズムとして機能します。OTelコレクターは、Prometheusのインストール不要でPrometheusのメトリクスを管理します。TAは、コレクターのPrometheusレシーバーの設定を管理しますが、2つのメイン機能は以下の通りです。

• 一連のOTelコレクター間でのPrometheusターゲットの均等な分散
• Prometheusのカスタムリソースの検出

それぞれについて、詳しく見ていきましょう。

Prometheusターゲットの均等な分散

TAが最初に行うのは、スクレイピングするターゲットと、ターゲットを割り当てるOTelコレクターの検出です。流れは以下の通りです。

1. TAがスクレイピングするすべてのメトリクスターゲットを検出
2. TAが使用できるすべてのコレクターを特定
3. TAがどのコレクターがどのメトリクスをスクレイピングするかを決定
4. コレクターがTAにクエリを行い、どのメトリクスをスクレイピングするかを特定
5. コレクターが割り当てられたターゲットをスクレイピング

つまり、メトリクスを収集するのは、PrometheusスクレーパーではなくOTelコレクターです。

ターゲットとは、Prometheusに保存するメトリクスを供給するエンドポイントです。スクレイピングとは、ターゲットとなるインスタンスからHTTPリクエストを通じてメトリクスを収集するアクションで、レスポンスを解析し、収集されたサンプルをストレージに取り込みます。

Prometheusのカスタムリソースの検出

TAが次に行うのは、PrometheusオペレーターCR、すなわちServiceMonitorとPodMonitorの検出です。

以前は、Prometheusでの設定のスクレイピングはすべてPrometheusレシーバー経由で行われなければなりませんでした。TAのサービス検出機能が可能になり、TAがクラスタ内にデプロイされたPodMonitorとServiceMonitorインスタンスからPrometheusレシーバー内でスクレイピング設定を作成することで、Prometheusレシーバーの設定は簡素化されています。

Prometheus CRの検出にTAを使用するために、PrometheusがKubernetesクラスタにインストールされている必要はありませんが、TAにはServiceMonitorとPodMonitorのインストールが必要です。これらのCRは、Prometheusオペレーターとバンドルになっていますが、スタンドアロンでのインストールも可能です。一番簡単な方法は、PodMonitor YAMLとServiceMonitor YAMLそれぞれのカスタムリソース定義（CRD）の複製を使用することです。

OTelは、PodMonitorとServiceMonitorのPrometheusのリソースをサポートしています。これらはKubernetesインフラストラクチャ監視で広く使用されているため、それを受けて、OTelオペレーターの開発者はこれらをOTelのエコシステムに簡単に追加できるようにしたいと考えました。

PodMonitorとServiceMonitorは、Kubeletメトリクス収集などのクラスタレベルのメトリクス収集には有用ではないことに留意してください。その場合には、やはりコレクターのPrometheusレシーバーのPrometheusスクレイピング設定を使用する必要があります。TAの設定に関しては、こちらのドキュメンテーションをご覧ください。

Kubernetes向けの追加的OTelコンポーネント

Kubernetesメトリクスの収集に使用できるOTelコレクターのコンポーネントには、さらに以下のものがあります。

データ受信：

• Kubernetesクラスタレシーバー：Kubernetes APIサーバーからクラスタレベルのメトリクスとエンティティイベントを収集
• Kubernetesオブジェクトレシーバー：Kubernetes APIサーバーから（pull/watch）オブジェクトを収集
• Kubelet Statsレシーバー：APIサーバーからKubeletのノード、ポッド、コンテナ、ボリュームメトリクスを取得し、メトリクスパイプラインに送信してさらなる処理を実行
• ホストメトリクスレシーバー：クラスタを構成するホストからのシステムメトリクスをスクレイピング

データ処理：

• Kubernetes属性プロセッサ：Kubernetesコンテクストを追加し、アプリケーションテレメトリーをKubernetesテレメトリーと相関づける。OpenTelemetryでのKubernetes監視における、もっとも重要なコンポーネントのひとつ

また、Kubernetes属性プロセッサは、ポッドやネームスペースに追加したKubernetesラベルとKubernetesアノテーションを用いたトレース、メトリクス、ログのカスタムリソース属性の設定にも使用できます。

その他にも、Kubernetes監視に実施できるコレクターコンポーネントは、バッチ、メモリリミッター、リソースプロセッサなど、Kubernetes専用のものや一般的に使用できるプロセッサを含めていくつかあります。詳細はこちらをご覧ください。

PrometheusおよびKubernetesのNew Relicインテグレーション

New Relicは、いくつかのPrometheusインテグレーションを提供しています。

• Kubernetes向けPrometheusエージェント
• Docker向けPrometheus OpenMetricsインテグレーション
• Prometheusリモート書き込みインテグレーション

すでにPrometheusサーバーを保有している場合、New Relicはリモート書き込みインテグレーションからの使用開始を推奨しています。お客様に最適なオプションについては、こちらをご覧ください。どのソリューションを選択しても、以下のメリットを得られます。

• New Relicが、より細やかなセキュリティとユーザー管理のオプションを提供
• Prometheusメトリクスの一元化された長期的データストアとしてNew Relicデータベース（NRDB）を使用し、オブザーバビリティツールを統合
• New RelicのPrometheus APIを介してGrafanaなどのクエリツールを使用可能
• New Relicがクエリ実行の拡張をサポート

また、New Relicは、Kubernetesクラスタ監視のためのKubernetesインテグレーションのソリューションを提供します。サービス監視にすでにNew Relic APMエージェントを使用している場合は、Kubernetesメタデータを表面化してAPMエージェントと紐づけることができます。これにより、あらゆる問題をさらに理解し、トランザクションエラーのトラブルシューティングを行えるようになります。

もしくは、OTelで計装されていたり、Kubernetesで実行されているアプリケーションがある場合、New Relic UIを使用して、OTelのアプリレベルのメトリクスをKubernetesインフラストラクチャメトリクスに相関づけることができます。これにより、テレメトリデータに関する総合的なビューが得られ、チーム全般がより効果的に業務を遂行できるようになり、最終的にはKubernetes環境でのあらゆる問題の平均解決時間を短縮できます。OTelアプリケーションをKubernetesに紐づける方法は、こちらをご覧ください。

まとめ

Prometheusの保守管理者は、2つのプロジェクトの相互運用性をPrometheus側からさらに発展させており、OTLPメトリクスのバックエンドとしてより機能しやすくなるようにしています。例えば、PrometheusはOTLPを受け入れるようになり、近いうちにPrometheusエクスポーターを使用してOTLPのエクスポートが可能になります。そのため、Prometheus SDKでインストゥルメントされたサービスがある場合、OTLPをプッシュして、OTelユーザー向けの充実したPrometheusエクスポーターエコシステムの恩恵を受けられるようになります。また、保守管理者は、デルタの一時性へのサポート追加に取り組んでいます。このコンポーネントでは、各々の累積カウンターパートにデルタのサンプルを集計します。PrometheusのOTelへの取り組みはこちらをご覧ください。

Prometheusメトリクスの収集にOTelの使用を決めたとしても、究極的には、自社組織にとって何が正解かはお客様のビジネスニーズによります。ここまで述べてきたように、OTelコンポーネントを使用すると、すべてのメトリクスをPrometheus形式に変換したり、PrometheusメトリクスをOTLPに変換することができます。New RelicはPrometheusデータ向けに即座に使用を開始できるソリューションと、OTLPをネイティブにサポートするプラットフォームUIも提供しているため、このオプションを使用することもできます。