CLOUD SECURITY LAB

OpenTelemetry Sumメトリックを完全に理解する：2つの主要な軸 📈

—

by

cslab
in

こんにちは！今日は、OpenTelemetry（OTel）の主要なメトリックタイプの一つであるSumについて深く掘り下げていきます。🕵️‍♂️ 多くの人がSumを単に「合計を出すメトリック」と考えていますが、その動作を決定する2つの重要な属性があることをご存知でしたか？

それが単調性（Monotonicity）と集計一時性（Aggregation Temporality）です。この2つの軸を理解して初めて、Sumメトリックを正確に解釈し、活用することができます。さあ、それでは今からこの2つの概念を詳しく見ていきましょう！

🗺️ 全体像を見る：Sumメトリックの2つの軸

Sumメトリックの動作を決定する2つの主要な要素をまず理解することが重要です。これらは独立した概念ではなく、互いに組み合わさってSumメトリックの最終的な性質を定義します。

  1. 単調性 (Monotonicity): この値は増加のみが可能か、それとも増加と減少の両方が可能か？
  2. 集計一時性 (Aggregation Temporality): メトリックを報告（エクスポート）する際、全体の累積値を送るのか、それとも最近の変化量のみを送るのか？

この2つの質問への答えの組み合わせが、皆さんが目にするSumメトリックの姿です。

The image you are requesting does not exist or is no longer available

1️⃣ 最初の軸：単調性 (Monotonicity)

単調性は、値の変化方向に関するルールです。

✅ Monotonic: true (単調増加)

値が増加するか、または同じ値を維持し、決して減少することはないという意味です。まるで車の総走行距離計のように、オドメーターは後戻りしません！ 🚗

  • 特徴: 0または正の値のみが加算されます。
  • 使用例:
  • 累積APIリクエスト数
  • サービス開始後に発生した総エラー数
  • 転送された総データバイト数(bytes)
  • 関連OTelインストゥルメント: Counter

↕️ Monotonic: false (非単調、増加/減少可能)

値が増加することも、減少することも可能であるという意味です。まるで部屋にいる人数のように、入ってくれば増加し、出て行けば減少します。👨‍👩‍👧‍👦

  • 特徴: 正または負の値が加算されることがあります。
  • 使用例:
  • 現在のアクティブな接続数（接続時に+1、切断時に-1）
  • メッセージキューに蓄積されている項目数（発行時に+1、消費時に-1）
  • 使用中のメモリ量の変化
  • 関連OTelインストゥルメント: UpDownCounter

2️⃣ 2番目の軸：集計一時性 (Aggregation Temporality)

集計一時性は、収集されたメトリック値をどの時点基準で報告するかを決定する非常に重要な属性です。通常、この設定は最終データをエクスポートするExporterレベルで決定されます。

🧱 Cumulative (累積)

Cumulativeは、その名の通り、プロセス（アプリケーション）が開始された時点から現在までの全体の累積合計を報告する方式です。

  • 特徴: 報告時点ごとに値が初期化されず、継続的に蓄積されます。（ただし、Monotonic: falseの場合、値は減少することもあります。）
  • なぜ使うのか？: Prometheusのような監視システムはこの方式を好みます。特定の時間における変化率（rate）を計算する際、全体の累積値に基づいて計算する方が、データ損失（例：収集失敗）に対してより堅牢だからです。もし変化量のみを受け取っていて、途中で一度収集を逃すと、その期間のデータは永遠に分からなくなってしまいます。
  • 報告方式の例（累積リクエスト数）:
// 1分間隔でメトリックが報告されると仮定
// T=0: サービス開始

// T=1分: 100件のリクエストが発生
export({"http.server.requests": 100})

// T=2分: さらに150件のリクエストが発生
export({"http.server.requests": 250}) // 以前の100 + 新しい150

// T=3分: さらに60件のリクエストが発生
export({"http.server.requests": 310}) // 以前の250 + 新しい60

ご覧の通り、値は常に全体の累積合計を示します。

💧 Delta (デルタ、変化量)

Deltaは、最後に報告した時点以降の変化量（増加分または減少分）のみを報告する方式です。

  • 特徴: 一度報告が完了すると、内部の集計値は次の報告のために初期化されます。
  • なぜ使うのか？: StatsDのように「瞬間の変化」を重視するシステムと相性が良いです。また、OTLP（OpenTelemetry Protocol）のデフォルト値であり、収集エージェントやバックエンドでデータを柔軟に処理できる余地を与えます。
  • 報告方式の例（累積リクエスト数）:
// 1分間隔でメトリックが報告されると仮定
// T=0: サービス開始

// T=1分: 100件のリクエストが発生
export({"http.server.requests": 100})

// T=2分: さらに150件のリクエストが発生
export({"http.server.requests": 150}) // 過去1分間の変化量

// T=3分: さらに60件のリクエストが発生
export({"http.server.requests": 60}) // その後の1分間の変化量

Cumulativeとは異なり、各報告は独立した期間の値のみを示します。

📊 一目でわかる要約

特徴 説明 関連インストゥルメント 主な使用例
Monotonicity 値が増加のみするか(true)、あるいは増減両方が可能か(false)を決定します。 Counter (true) http.server.request.count (累積リクエスト数)
UpDownCounter (false) system.processes.active (アクティブなプロセス数)
Aggregation Temporality プロセス開始後の全体累積値(Cumulative)を報告するか、最後の報告以降の変化量(Delta)のみを報告するかを決定します。 (Exporter設定) Cumulative: Prometheusが好む Delta: OTLP Exporterのデフォルト値

—

🚀 結論

これで、OpenTelemetryのSumメトリックが単なる「合計」ではないことを確信していただけたでしょう。Monotonicityを通じてデータの増減特性を定義し、Aggregation Temporalityを通じてそのデータをどのように報告するかを決定します。

この2つの主要な軸を理解することで、皆さんはどのような監視環境でもメトリックを正確に設定し、ダッシュボードに表示されるグラフを明確に解釈できる強力な武器を手に入れたことになります。さあ、皆さんのシステムをより深く観察してみましょう！

Comments

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です