# Prometheus は OpenTelemetry のリソース属性をどう扱うべきか？ - UX リサーチレポート

LLMS index: [llms.txt](/llms.txt)

---

<!-- markdownlint-configure-file {"no-shortcut-ref-link": {"ignore_pattern": "^[Ww]ith$"}} -->

2025年5月29日、[Linux Foundation Mentorship Program](https://mentorship.lfx.linuxfoundation.org/project/36e3f336-ce78-4074-b833-012015eb59be) を通じた Prometheus でのメンターシップを完了しました。
私のプロジェクトは、Prometheus が OpenTelemetry のリソース属性をどのように扱っているかを理解し、そのユーザー体験をどう改善できるかに焦点を当てたものでした。
私の仕事は、この課題に対するユーザーの視点を得るためにユーザーリサーチを実施することでした。
3か月の間に、ユーザーおよびステークホルダーへのインタビューを行い、アンケート調査を実施し、結果を分析しました。

この記事では、リサーチの実施方法、明らかになったこと、そして関連コミュニティが今後どのように進められるかを共有します。

## プロジェクトの背景 {#project-background}

OpenTelemetry（OTel）には[リソース](/docs/concepts/resources/)属性と呼ばれるものがあり、これはメトリクスのソースに関する追加情報で、それを生成したサービス、ホスト、環境などを表します。
時系列データベースである Prometheus はラベルを使ってメトリクスを識別しクエリします。
リソース属性がラベルに変換されると、「カーディナリティ爆発」と呼ばれる問題を引き起こす可能性があります。
これは本質的に、システムを圧倒するほどの一意な組み合わせを生み出すことです。
これは通常、属性が頻繁に変化する場合や、ユーザー ID や Pod 名のように多数の一意な値を含む場合に発生します。

現在、この課題に対処するための主なアプローチは3つあります。

- **すべてのリソース属性をラベルにマッピングする：**
  属性の数が多い場合や属性値が頻繁に変化する場合、カーディナリティ爆発の問題を引き起こします。
- **選択的なプロモーション：**
  ユーザーが手動で、Prometheus のラベルに変換するのに十分重要なリソース属性を選択します。
- **target info パターン：**
  すべてのリソース属性を `target_info` という別のメトリクスに格納します。
  ユーザーが特定のリソース属性を含むメトリクスをクエリする必要がある場合、target info と実際のメトリクスの間で「結合」を行う必要があります。

これらは技術的には悪い解決策ではありませんが、最高のユーザー体験を提供するものではありません。
そこで、Prometheus のメンテナーがユーザー体験について見落としている可能性があることを理解するために、このリサーチを実施しました。

リサーチの目的は以下の通りです。

- エンジニアが現在 OpenTelemetry のリソース属性を Prometheus でどのように使用しているかを理解する
- 現在のインテグレーションにおけるペインポイントを特定する
- リソース属性がどのように表現されるべきかについてのユーザーの期待を明らかにする

## リサーチのアプローチ {#research-approach}

私のリサーチアプローチは、定性調査と定量調査を組み合わせたものでした。
まず、ステークホルダーインタビューから始めて、歴史的な文脈を理解し、私のリサーチの結果として生じうる変更にステークホルダーがどの程度オープンであるかを評価しました。
私が話したステークホルダーは、プロジェクトの創設者や共同創設者から、歴史的な文脈を持つ長年のメンテナー、そしてリソース属性の扱いに関する現在進行中の課題により直接関わっている人まで、さまざまな役割の人々でした。

次に、実際にこれらのツールを使っている人々から直接話を聞くために、ユーザーインタビューを実施しました。
最後に、より広い層にリーチし、インタビューで聞いた内容を検証するためにアンケート調査を行いました。

## ステークホルダーインタビューの洞察 {#stakeholder-interviews-insights}

6人のステークホルダーに話を聞きました。各プロジェクトから3人ずつです。

**Prometheus のステークホルダー：**

- [Julius Volz](https://github.com/juliusv) – Prometheus 共同創設者
- [Beorn Rabestein](https://github.com/beorn7) – Prometheus 長年のメンテナー
- [Richard Hartmann](https://github.com/RichiH) – OpenMetrics 共同創設者、Prometheus メンテナー

**OpenTelemetry のステークホルダー：**

- [Juraci Paixão Kröhling](https://github.com/jpkrohling) – OpenTelemetry ガバナンス委員会メンバー
- [Josh Suereth](https://github.com/jsuereth) – OpenTelemetry 技術委員会メンバー
- [Austin Parker](https://github.com/austinlparker) – OpenTelemetry 共同創設者、ガバナンス委員会メンバー

ステークホルダーとの会話から、いくつかの興味深い発見がありました。

- Prometheus と OpenTelemetry のコミュニティは常にうまくコミュニケーションが取れていたわけではなく、それが早期の協力を妨げていました。
- 現在存在する相互運用性の問題の多くは、各プロジェクトが構築されている異なる哲学的・技術的基盤に起因しています。

  > 「探索的な状況やユースケースについて考えると、OpenTelemetry の設計上の決定の多くを正当化できます。
  > そして、メトリクスとスケーリング、巨大なインフラのモニタリングについて考えると、Prometheus の設計上の決定もまた正当化されます。
  > つまり、どちらも非常に優れた論拠を持っています。」
  > — _Juraci Paixão Kröhling_

  <!-- markdownlint-disable no-shortcut-ref-link -->

  > 「最大の [相互運用性の問題] の1つは、プッシュとプルの違いだと思います。」
  > — _Julius Volz_

  Julius は後に、彼の懸念は配信メカニズムそのものを超えたものであると詳しく述べました。
  彼の言葉によると：

  > 「OTLP を使って Prometheus にメトリクスをプッシュすることの最大の欠点の1つは、モニタリングシステムとしての Prometheus のコア機能の1つを捨てることになる点です。
  > それは、動的なサービスディスカバリー情報に基づくプルベースのメトリクス収集モデル（そのため Prometheus は現在どのターゲットが存在すべきかを常に把握しています）と、各ターゲットスクレイプに対して生成される合成的な 'up' メトリクスによる自動的なターゲットヘルスモニタリングです。」

- 両者には、いくつかの譲れない点（たとえば、Prometheus がプルモデルを維持し、既存ユーザーを疎外しないこと）を守りつつも、ユーザーのニーズを最優先にすることの重要性が共通して認識されています。

インタビューから得た重要な気づきの1つは、現在の相互運用性の問題は失敗ではなく、異なるコミュニティが異なる時期に異なる問題を解決した結果として自然に生じたものであるという認識でした。
そして、ユーザー体験をより良くするために両プロジェクトが今協力していることは素晴らしいことです。

## ユーザーインタビューの洞察 {#user-interviews-insights}

ユーザーインタビューは、ステークホルダーとの会話と同じくらい示唆に富んでいました。
約10人のユーザーに話を聞くことを目指していましたが（確かに野心的でした）、7人にインタビューすることができ、全員が非常に有益な視点を共有してくれました。

ユーザーが共有した最も顕著なペインポイントは、現在のインテグレーションにおける結合操作の複雑さでした。
もう1つ挙がった問題は、文字セットの制限によるメトリクス名の不一致でしたが、最近の Prometheus リリースが UTF-8 文字をサポートするようになったことで対処されたと理解しています（ただし、これにより PromQL でより煩雑な引用符付きセレクター構文が必要になります）。

メンタルモデルに関して、多くのユーザー（インタビュー対象者とアンケート回答者の両方）は、リソース属性と Prometheus のラベルを区別していません。
同じものとして捉える傾向があります。

> 「リソース属性は原則として、トレーサーやメトリクスに付与される属性とまったく同じように扱われるべきだと思います。
> それらの間に境界線を引くべきではないでしょう。」
> — _インタビュー参加者 1_

また、リソース属性の問題に対処するために、各自のユースケースで人々が使っているさまざまな回避策についても学びました。
選択したリソース属性をラベルにプロモートする人もいれば、Prometheus で対処するかわりに OpenTelemetry Collector のレベルで変換を行う人もいます。
また、通常は属性の数が少ない場合に限り、すべての属性を変換する人もいます。

## アンケート調査の洞察 {#survey-insights}

アンケートは、インタビューで聞いていた内容を定量化し、より広い層にリーチするのに役立ちました。
執筆時点で134件の回答があり、そのうち61件がターゲットグループである OTel と Prometheus を一緒に使っている人々からのものでした。

主な調査結果は以下の通りです。

- ユーザーはリソース属性を通常のラベルとは異なるものとして概念化していないが、現在の実装ではそれらを別のメタデータとして扱っている。
- 複雑な結合構文は導入の大きな障壁であり、平均的な開発者はリソース属性にアクセスする基本的なクエリを書くことができない。
- 手動での属性プロモーションは、チームの規模と複雑さに応じてスケールしにくい運用オーバーヘッドを生む。
- 回答者の78%がリソース属性の使用においてドキュメントのギャップを課題として挙げている。

![Prometheus における OpenTelemetry リソース属性の課題を示す棒グラフ](Chart.PNG)

アンケートの傾向は、定性調査から得られた結果と一致していました。
詳細な結果については、[匿名化されたアンケート回答](https://github.com/prometheus-community/ux-research/blob/acc0194a79aa0f2ee1c6eb93462c9488d236a275/prom-otel-research/survey-results.csv?from_branch=main)を参照してください。

## 予期していなかったが学んだこと {#what-i-didnt-expect-to-learn-but-did}

リソース属性の扱いに関するユーザーのペインポイントを理解するためにこのリサーチを始めましたが、予想外の重要な発見がいくつかありました。

最も驚いた発見の1つは、[OpenTelemetry のリソース検出機能](/docs/specs/otel/resource/#telescoping)が、「テレスコーピング」と呼ばれることもある概念的なパターンを使って、関連性に基づいてリソース属性を選択的に保持または破棄できるということでした。
その可能性にもかかわらず、多くのユーザーや Prometheus コミュニティの一部のメンバーさえもこの機能を知らないようです。
この認知不足が、その後問題が多いことが判明した「結合」パターンの採用につながった可能性があります。

これはより広い問題を浮き彫りにしています。ドキュメントと教育のギャップは大きな障壁です。
アンケートでは、回答者の78%がドキュメントのギャップを課題として挙げました。

もう1つの重要な気づきは、結合への依存といった初期のインテグレーションの決定が、各ツールの機能を十分に理解しないまま行われたことです。
これは Prometheus と OpenTelemetry コミュニティ間の早期の協力とコミュニケーションの欠如から生じた避けられない結果でした。

## 推奨される解決策 {#recommended-solutions}

ステークホルダーやエンドユーザーとの会話に基づいて、提案された解決策のいくつかを、短期的に実現可能なものと長期的なビジョンに分けて紹介します。

### 短期的な解決策 {#short-term-solutions}

- **属性の扱いに関するドキュメントの改善**
  ユーザーは target info での結合よりも属性のプロモーションの方が簡単だと感じているため、結合に関するドキュメントの重要性を下げる（あるいは廃止する）一方で、まだその選択肢を知らない人に向けて[属性プロモーションのドキュメント](https://prometheus.io/docs/guides/opentelemetry/#promoting-resource-attributes)をより目立たせることが価値あるかもしれません。
  OpenTelemetry におけるリソース検出のテレスコーピングパターンもまた、より高い認知度と適切なドキュメントが必要です。
  さらに、ユーザーからは、両システムがリソース属性をどのように扱うかを明確に説明する Prometheus–OpenTelemetry の統合ドキュメントの作成が提案されています。

### 長期的なビジョン {#long-term-vision}

- **エンティティフレームワーク**
  OpenTelemetry が開発中のエンティティの概念は、Prometheus が識別用の属性と説明用の属性を区別するのに役立つ可能性があります。
  これにより、どの属性がラベルになり、どの属性が保存または除外するかのガイドになります。

- **メタデータストレージ**
  ステークホルダーは、Prometheus 自体にファーストクラスのメタデータサポートを追加するアイデアについても議論しました。
  これにより、特定のリソース属性をメタデータ（ラベルではなく）として保存でき、カーディナリティコストを回避しつつ、クエリや結合で情報を利用可能に保てます。

- **探索的テレメトリーへの拡張**
  大きな飛躍かもしれませんが、Prometheus は探索的テレメトリーのユースケースをより良くサポートするためにスコープを拡張することを検討できるかもしれません。
  ステークホルダーは、Prometheus のコアアーキテクチャが維持され、既存ユーザーが疎外されない限り、変更に対してオープンな姿勢を見せました。
  これは、特に新しい機能が現在の動作を置き換えるのではなく補完できるのであれば、進化の余地がある可能性を示唆しています。

  > OTel と Prometheus は、テレメトリーの一般的な動作について非常に異なる前提から出発していると思います。
  > Prometheus は時系列ストレージについて非常に意見が強い一方で、OTel はトレーシングの背景から来ており、Prometheus よりも探索的です。
  > Prometheus では、必要なものが事前にある程度わかっています。
  > OpenTelemetry では、何が必要になるかわからないので、すべてを保存します。
  > — _Juraci Paixão Kröhling_

- **クロスシグナル相関**
  ユーザーは、すべてのテレメトリータイプを取り込み、単一のシステム内でメトリクス、トレース、ログを相関させることができるプラットフォームの使用について言及しています。
  Prometheus はメトリクスのみに焦点を当て続ける可能性が高いですが、他のデータベースに保存されたテレメトリーとメトリクスを相関させるツールを可能にすることはできるかもしれません。
  Prometheus は現在[エグゼンプラー](https://prometheus.io/docs/specs/om/open_metrics_spec/#exemplars)をサポートしており、メトリクスをトレースにリンクすることができますが、対応できるのはおおむねそこまでです。
  エグゼンプラーはトレーシングの存在に依存するため、トレースが利用できない環境や計装されていない環境ではあまり役に立ちません。

  > 「OpenCensus における重要な革新的なことの1つは…リクエストごとに CPU 使用率を分割でき、'リクエスト別の CPU 使用率がこちらです'というメトリクスが得られたことです。
  > これは OpenCensus で実現可能でした。なぜなら、すべてがコンテキストベースのメトリクスだったからです。」
  > — _Josh Suereth_

まだやるべきことは残っています。
コミュニティは解決策を開発しテストするために時間が必要です。
しかし、このリサーチがその作業のためのユーザー中心の基盤を提供できたことを誇りに思います。

進行中の議論、提案、およびこれらのアイデアに関するフィードバックに興味がある方は、すべてが文書化されている GitHub リポジトリをご覧ください。
[Prometheus における OpenTelemetry リソース属性の UX リサーチ](https://github.com/prometheus-community/ux-research/tree/a2f8c6684321fd04de7b94cfbd39a48bb1d7beb4/prom-otel-research?from_branch=main)

## 謝辞 {#acknowledgments}

この記事は、素晴らしいメンターの方々への感謝なしには完成しません。
[Amy Super](https://github.com/amy-super)、[Andrej Kiripolsky](https://github.com/AndrejKiri)、[Arthur Silva Sens](https://github.com/ArthurSens) の3名です。
この挑戦的なプロジェクトを任せてくださり、私のキャリアの成長を心から気にかけてくださったことに感謝します。
皆さんこそ真のスーパースターです。

時間を割いてくださったすべてのステークホルダーとユーザーの皆さんに感謝します。
この研究に関わり、率直なフィードバックを信頼して共有してくださったことに感謝します。
皆さんの洞察がこのリサーチを意味あるものにしました。

## 今後の私について {#whats-next-for-me}

UX とクラウドネイティブシステムの交差点で仕事を続けることにワクワクしています。
このメンターシップに類似した機会をご存じでしたら、ぜひお知らせください。
私は努力家です。メンターに聞いてみてください。