👀概要
この記事ではオブザーバビリティツールを以下の分類に分け、どこの層にどのようなツールが分類されるのかを考察する試みです。
- インストゥルメンテーション層 : サーバー本体への計測器のインストール
- コレクター層 : テレメトリデータを集約し、可視化層へ送信する
- ストレージ層 : テレメトリデータを保存する
- 可視化層 : テレメトリーデータを可視化する
厳密に言うと異なる整理もあり得ますが、ツール群としてはこの分類が妥当だと考えています。
注意
各ツールは必ずしも単一の層に厳密に属するわけではありませんし、公式に定義されているものでもありません。
複数の層の責務を兼ねるものも存在します。
この記事はオブザーバビリティツールの分類わけの結果を共有する試みです。
関連記事
- オブザーバビリティツールをカテゴライズする試み
- OpenTelemetry + Flask + Jaeger で始める、最小構成の分散トレーシング【OpenTelemetryサクッと入門】
- オブザーバビリティの3本柱｜ログ・メトリクス・トレース【OpenTelemetryサクッと入門】
- OpenTelemetryを汚さず入れる。Pythonゼロコード実装【OpenTelemetryサクッと入門】
- OpenTelemetry Collector を導入するメリットと構成の勘所【OpenTelemetryサクッと入門】
📌関連リンク
👨👩👧👦対象者(Who)
- オブザーバビリティツールを検討している方
📝 内容
オブザーバビリティツールの分類分け
インストゥルメンテーション層
アプリケーションやミドルウェアの内部に組み込み、以下のデータを生成する層です。
- トレース
- メトリクス
- ログ
これらのデータを総称して テレメトリデータ と呼び、
オブザーバビリティの三本柱 を構成します。
（詳細は別記事で解説予定）
製品例
- OpenTelemetry SDK
- OpenTelemetry Auto Instrumentation
- Prometheus Client Libraries (メトリクス特化)
- AWS X-Ray SDK (AWS環境に特化したトレーシングSDK)
コレクター層
コレクター層は、テレメトリデータを 受信・加工・転送 する中継層です。
製品例
- OpenTelemetry Collector
- Prometheus
（コレクター層 + ストレージ層を兼ねる） - AWS Distro for OpenTelemetry （インストゥルメンテーション層 + コレクター層を兼ねる）
- Fluentd / Fluent Bit（ログ中心の軽量コレクター）
- Vector (高性能・Rust製のログ／メトリクス向けコレクター)
- Telegraf (InfluxDBエコシステムで使われるエージェント型コレクター)
ストレージ層
受信したテレメトリデータを永続的に保存する層です。
製品例
- Tempo（トレース）
- Prometheus （コレクター層 + ストレージ層 を兼ねる）
- Loki
- AWS X-Ray
（ストレージ層 + 可視化層 トレースデータのみ） - Elasticsearch (ログ保管)
- InfluxDB (時系列メトリクスデータ保管)
- ClickHouse
可視化層
テレメトリデータを、人間が理解できる「意味」に変換する層です。
製品例
-
トレース中心
- AWS X-Ray（保存 + 可視化。トレースのみ）
- Jaeger UI
- Zipkin
-
ログ中心
- AWS CloudWatch
- Kibana
- OpenSearch Dashboards
-
メトリクス中心
- Prometheus UI
-
テレメトリデータ
- Grafana
オールインワン型
SaaS型のオブザーバビリティツールにはオールインワン型もあります。
- NewRelic
- Datadog
- Dynatrace
いずれのツールも独自のインストゥルメンテーションを提供しているが、OpenTelemetryと統合することでベンダーロックを回避することも可能です。
まとめ
オブザーバビリティは、単なるログ収集やメトリクス監視の枠を超え、システムの「状態」と「因果」を継続的に理解するための土台です。
インストゥルメンテーション／コレクター／ストレージ／可視化の4層に分けて捉えることで、各ツールの役割や責務、そして重複領域を明確にできると感じました。