はじめに
こんにちは、Datadog Japan で Sales Engineer をしている AoTo です。
この記事は OpenTelemetry Advent Calendar 2023 22日目の記事です。
昨日は、逆井（さかさい）さん(@k6s4i53rx)の『OpenTelemetry Collector の Span Metrics Connector を使ってメトリクスを生成してみる』でした！
昨日の記事の最後には…
明日は @AoToLog_ の 「OpenTelemetry と〇〇」です。〇〇 に何が入るかは 当日のお楽しみということで楽しみです！
ということで、実ははじめからこの〇〇に入れる内容は決めていました。Prometheus については個人のアドベントカレンダーで入門してきたので、今回は OpenTelemetry との関係性を深掘りしていきます。
どういう関係なの？
まずはそれぞれのプロジェクトの概要から押さえておきましょう。
両ページの What is 〇〇 の章から考察していきます。
OpenTelemetry
OpenTelemetry はトレース・メトリクス・ログなどのテレメトリデータを作成および管理するために設計された Observability フレームワーク及びツールキットです。OTel はベンダーやツールに依存せず、Jaeger や Prometheus などのオープンソースツール・商用製品などあらゆる Observability バックエンドで使用できます。
2019年5月7日から Cloud Native Computing Foundation(CNCF) に参加しており、2021年8月26日に Incubationg 成熟度レベルに移行しています。
「High-quality, ubiquitous, and portable telemetry to enable effective observability」
主なコンポーネントは以下の通りです。
- すべてのコンポーネントの仕様
- テレメトリ データの形式を定義する標準プロトコル
- 一般的なテレメトリ データ型の標準命名スキームを定義するセマンティック規則
- テレメトリ データの生成方法を定義する API
- 仕様、API、テレメトリ データのエクスポートを実装する言語 SDK
- 共通のライブラリとフレームワークのインストルメンテーションを実装するライブラリエコシステム
- コード変更を必要とせずにテレメトリ データを生成する自動計測コンポーネント
- OTel Collector、テレメトリ データを受信、処理、エクスポートするプロキシ
- Kubernetes 用の OTel Operator、 OTel Helm Charts、 FaaS 用のコミュニティ アセットなど、その他のさまざまなツール
Prometheus
Prometheus は元々 SoundCloud が構築したもので、2012年に開始され現在はスタンドアロンのオープンソースプロジェクトです。メトリクスをラベルと呼ばれるオプションのキーと値のペアと共に、記録されたタイムスタンプと合わせて、時系列データとして収集して保存します。
2016年5月9日に Cloud Native Computing Foundation(CNCF) に参加しており、2018年8月9日に Graduated 成熟度モデルに到達しています。
「From metrics to insight」
主なコンポーネントは以下の通りです。
- 時系列データを収集して保存するメインのPrometheus サーバー
- アプリケーション コードをインストルメントするためのクライアントライブラリ
- 短期間のジョブをサポートするためのプッシュゲートウェイ
- HAProxy、StatsD、Graphite などのサービスの専用エクスポーター
- アラートを処理するアラートマネージャー
- 各種サポートツール
関係性(relationship)
互いに Cloud Native Computing Foundation(CNCF) プロジェクト の1つであり、Prometheus の方が先に参加し現在は卒業しており、つまり先輩です。
お互いの概要ページにはそれぞれのプロジェクトを説明する内容が書かれていますが、OpenTelemetry のページには Prometheus が登場し逆のページには何もなく、つまり OTel の片思いです。
以上をまとめると両者の関係性は、OpenTelemetry は卒業した憧れの Prometheus を一方的に慕っている後輩だと言うことがわかります。1
違い(difference)
冗談はこのくらいにして、両者には根本的な違いが何点かあります。
- 記録する対象のテレメトリデータ
- 収集する先のバックエンドと独立性
OpenTelemetry はトレース・メトリクス・ログの3つを主なテレメトリとして対象としている反面、Prometheus はメトリクスだけにフォーカスをしたプロジェクトです。OpenTelemetry vs Prometheus のように語られることもありますが、両者は根本的に性質の異なるにて非なるプロジェクトであることを押さえておきましょう。
さらに、OpenTelemetry は Observability のバックエンドではないことを明言しており、Prometheus を含む既存のバックエンドのデータの保存と可視化を委任しています。これが OpenTelemetry が Prometheus と並行して利用される理由です。
OpenTelemetry Collector
ここからは OpenTelemetry のエコシステムを中心に、Prometheus への統合を見ていきましょう。OpenTelemetry はベンダーに依存しない形でデータの受信・処理・送信を行うため OpenTelemetry Collector を提供しています。
ここで見られるように、Prometheus から OTel Collector へ、OTel Collector から Prometheus へデータを受け渡すことができるようになっています。これは、前述の通り「多次元データモデルのメトリクスを生成する Prometheus」と「分散ストレージに依存しない自律的なバックエンドの Prometheus」の両面として、OpenTelemetry と互いの長所を活かしながらツールの活用ができるということです。
OTel Collector は Receiver, Processor, Exporter, Connector の4つの分類の構成からなります。それぞれの構成について、Prometheus とそのメトリクスに関連してできることを確認していきましょう。
Receiver
Receiver は1つ以上のソースからテレメトリをプッシュ・プル形式で収集する OTel Collector のコンポーネントです。
Prometheus Receiver は Prometheus 形式でメトリクスデータを収集できます。Prometheus の完全互換を目指していますが、現在でも一部の機能をサポートしていません。2
Prometheus 形式の一般的な構成の通り、Prometheus Receiver はプル型でメトリクスをターゲットにスクレイピングします。Prometheus Reviever の yaml ファイルは receivers: prometheus: config で構成することができ、GitHub では一例として以下のサンプル構成ファイルが記載されています。
receivers:
prometheus:
config:
scrape_configs:
- job_name: 'otel-collector'
scrape_interval: 5s
static_configs:
- targets: ['0.0.0.0:8888']
この構成は、5秒毎に otel-collector ジョブを実行し 0.0.0.0:8888 に対しメトリクスの取得を行います。この他にも Prometheus でのメトリクス収集と同様に、Kubernetes のリソースメトリクスをラベルを付与しながら収集することも可能です。
Prometheus Receiver の利点は、従来 Prometheus で行ってきた高機能なメトリクス生成・収集を変更することなく、ログ・トレースを受信・処理・送信できる OTel Collector に統合できることです。これにより、OTel がサポートしていないメトリクス収集を Prometheus のエコシステムの恩恵を受けながら補完することができます。
昨年の OpenTelemetry Advent Calendar 2022 でも解説されている記事があるので、是非ご参照ください🔭
Processor
Processor は Receiver によって収集されたデータを取得し、Exporter へ送信する前に処理を行いデータを変換する OTel Collector のコンポーネントです。
Span Metrics Processor は OpenTelemetry によって計装されたアプリケーションのトレース内の処理単位であるスパンをもとに、R.E.D メトリクスを生成します。このメトリクスの形式として、Prometheus 形式を選択できます。
このコンポーネントは Processor から Connector を利用する変更により、現在非推奨です。スパンからメトリクスを生成する場合は、後述する Span Metrics Connector をご利用ください、
Span Metrics Processor によって生成されるメトリクスは、少なくとも以下の次元(dimentions)を持ちます。
- Service name
- Operation
- Span kind
- Status code
これと同時に、元のトレースを処理せずにパイプラインに流すことができます。これらの構成は以下のように記載可能です。
processors:
batch:
spanmetrics:
metrics_exporter: otlp/spanmetrics
latency_histogram_buckets: [100us, 1ms, 2ms, 6ms, 10ms, 100ms, 250ms]
dimensions:
- name: http.method
default: GET
- name: http.status_code
dimensions_cache_size: 1000
aggregation_temporality: "AGGREGATION_TEMPORALITY_CUMULATIVE"
metrics_flush_interval: 15s
Exporter
Exporter は1つ以上のバックエンドにデータをプッシュ・プル形式で送信するコンポーネントです。
Prometheus Exporter は Prometheus バックエンドに Prometheus 形式でデータを送信するために、スクレイピングのエンドポイントを公開します。このエンドポイントには Prometheus サーバー以外にもアクセスでき、メトリクスを問い合わせて取得できます。
exporters:
prometheus:
endpoint: "1.2.3.4:1234"
tls:
ca_file: "/path/to/ca.pem"
cert_file: "/path/to/cert.pem"
key_file: "/path/to/key.pem"
namespace: test-space
const_labels:
label1: value1
"another label": spaced value
send_timestamps: true
metric_expiration: 180m
enable_open_metrics: true
add_metric_suffixes: false
resource_to_telemetry_conversion:
enabled: true
Prometheus Exporter は主要な Exporter として、OpenTelemetry の公式ドキュメントにもその仕様について説明があります。
細かいですが、メトリクスに付与するリソース属性の仕様はデフォルトでは設定されないため、必要な際は構成に追加する必要があります。
Connector
Connector は2つのパイプラインを結合し、それぞれの Exporter, Receiver としての機能を持ちます。Connector で扱うデータ型は同一のままでも、変換することも可能なため、データの要約・変換・複製・ルーティングに使用できます。
Connector は OTel Collector における新しいアーキテクチャとして誕生しました。OTel Collector のパイプラインは1種類のデータのみを対象とするにも関わらず、従来の Processor のうちデータ型を変換するものは変換後のデータを直接エクスポートしていました。
このような場合に、本来の OTel Collector のパイプラインと概念に合致するように2種類のデータパイプラインを接続するようなアーキテクチャを実現するコンポーネントとして Connector が誕生し、前述のデータ型を変換する Processor は非推奨となりました。
Span Metric Connector は OTel を始めとするトレースからメトリクスを生成出来ます。
詳しい解説は、ちょうど前日の素晴らしい記事でまとめられています🔭
おわりに
OpenTelemetry のコンポーネントから各1つずつ取り上げていきましたが、この他にも Prometheus 形式でのメトリクスを扱う技術は OTel Collector の中に含まれています。
是非、OpenTelemetry × Prometheus で Cloud Native な Observability を実践してみてください🐶