オープンソースオブザーバビリティ比較：Grafana vs OpenTelemetry vs Jaeger で分散トレーシングとメトリクスを統合する

マイクロサービスの問題を素早く発見するには「メトリクス・ログ・トレース」の三本柱を統合した観測可能性（Observability）が必要です。Grafana・OpenTelemetry・Jaegerをオープンソースで組み合わせてDatadog・New Relicの代替を構築しましょう。

オブザーバビリティの三本柱

• メトリクス（Metrics）: CPU・メモリ・HTTPリクエスト数・レイテンシなどの数値データ
  • ツール: Prometheus（収集）+ Grafana（可視化）
• ログ（Logs）: アプリケーションが出力するテキストイベント
  • ツール: Loki（収集）+ Grafana（検索）
• トレース（Traces）: リクエストがサービスをまたいでどのように処理されたかの追跡
  • ツール: OpenTelemetry（計装）+ Jaeger/Tempo（保存・検索）

主要ツールの概要

Grafana + Prometheusスタック

クラウドネイティブ監視の標準スタックです。PrometheusがメトリクスをスクレイプしてGrafanaが可視化します。AlertmanagerでSlack・PagerDuty・メールに通知できます。

# docker-compose（Prometheus + Grafana + Alertmanager）
version: '3.8'
services:
  prometheus:
    image: prom/prometheus:v2.52.0
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus_data:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.retention.time=30d'
      - '--web.enable-lifecycle'

  grafana:
    image: grafana/grafana:11.0.0
    ports:
      - "3000:3000"
    environment:
      GF_SECURITY_ADMIN_PASSWORD: admin
      GF_USERS_ALLOW_SIGN_UP: "false"
    volumes:
      - grafana_data:/var/lib/grafana
      - ./grafana/provisioning:/etc/grafana/provisioning

  alertmanager:
    image: prom/alertmanager:v0.27.0
    ports:
      - "9093:9093"
    volumes:
      - ./alertmanager.yml:/etc/alertmanager/alertmanager.yml

# prometheus.yml - スクレイプ設定
global:
  scrape_interval: 15s
  evaluation_interval: 15s

rule_files:
  - "alerts.yml"

alerting:
  alertmanagers:
    - static_configs:
        - targets: ["alertmanager:9093"]

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

  - job_name: 'my-app'
    static_configs:
      - targets: ['my-app:8080']
    metrics_path: '/metrics'

  # Kubernetes Podの自動検出
  - job_name: 'kubernetes-pods'
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
        action: keep
        regex: true

# PythonアプリにPrometheusメトリクスを追加（prometheus-client）
from prometheus_client import Counter, Histogram, Gauge, start_http_server
import time

# メトリクス定義
REQUEST_COUNT = Counter(
    "http_requests_total",
    "Total HTTP requests",
    ["method", "endpoint", "status_code"],
)
REQUEST_LATENCY = Histogram(
    "http_request_duration_seconds",
    "HTTP request latency",
    ["method", "endpoint"],
    buckets=[0.01, 0.05, 0.1, 0.5, 1.0, 2.0, 5.0],
)
ACTIVE_USERS = Gauge("active_users_total", "Number of active users")

# FastAPIミドルウェアでメトリクスを計測
from fastapi import FastAPI, Request
import uvicorn

app = FastAPI()

@app.middleware("http")
async def track_metrics(request: Request, call_next):
    start = time.time()
    response = await call_next(request)
    duration = time.time() - start

    REQUEST_COUNT.labels(
        method=request.method,
        endpoint=request.url.path,
        status_code=response.status_code,
    ).inc()
    REQUEST_LATENCY.labels(
        method=request.method,
        endpoint=request.url.path,
    ).observe(duration)

    return response

start_http_server(8001)  # /metricsをポート8001で公開

OpenTelemetry

CNCF管理の統一計装フレームワークです。コード変更なしに（または最小限の変更で）アプリケーションからトレース・メトリクス・ログを収集し、任意のバックエンド（Jaeger・Prometheus・Grafana Tempo・Datadog）に送信できます。

# FastAPIにOpenTelemetry自動計装を追加
from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
from opentelemetry.instrumentation.fastapi import FastAPIInstrumentor
from opentelemetry.instrumentation.httpx import HTTPXClientInstrumentor
from opentelemetry.instrumentation.sqlalchemy import SQLAlchemyInstrumentor

# トレースプロバイダーの設定
provider = TracerProvider()
exporter = OTLPSpanExporter(endpoint="http://otel-collector:4317")
provider.add_span_processor(BatchSpanProcessor(exporter))
trace.set_tracer_provider(provider)

# FastAPIの自動計装（全エンドポイントを自動でトレース）
FastAPIInstrumentor().instrument()
HTTPXClientInstrumentor().instrument()

# カスタムスパンを追加
tracer = trace.get_tracer(__name__)

async def process_order(order_id: str):
    with tracer.start_as_current_span("process_order") as span:
        span.set_attribute("order.id", order_id)
        span.set_attribute("order.status", "processing")

        # DBクエリ（SQLAlchemyが自動でスパンを生成）
        order = await db.get_order(order_id)

        span.set_attribute("order.amount", order.amount)
        return order

# OpenTelemetry Collectorの設定（otel-collector-config.yaml）
receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch:
    timeout: 1s
  memory_limiter:
    limit_mib: 512

exporters:
  jaeger:
    endpoint: jaeger:14250
    tls:
      insecure: true
  prometheus:
    endpoint: "0.0.0.0:8889"
  loki:
    endpoint: http://loki:3100/loki/api/v1/push

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [jaeger]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [prometheus]

Jaeger

Uberが開発した分散トレーシングシステムです。マイクロサービス間でリクエストがどのサービスをどの順序で通り、どこでボトルネックが発生しているかをフレームグラフで可視化します。

# Jaegerをオールインワンで起動（開発用）
docker run -d   --name jaeger   -p 16686:16686   -p 14250:14250   -p 4317:4317   -p 4318:4318   jaegertracing/all-in-one:1.57
# UIは http://localhost:16686 でアクセス

# Jaeger + ElasticsearchでKubernetesにデプロイ（本番用）
helm repo add jaegertracing https://jaegertracing.github.io/helm-charts
helm install jaeger jaegertracing/jaeger   --set provisionDataStore.cassandra=false   --set provisionDataStore.elasticsearch=true   --set storage.type=elasticsearch   --set elasticsearch.master.persistence.size=10Gi   --namespace observability --create-namespace

機能比較表（オブザーバビリティスタック）

比較項目	Grafana+Prometheus	OpenTelemetry	Jaeger
役割	可視化・アラート	計装・収集	分散トレース
メトリクス	✅	✅	❌
ログ	✅ Loki連携	✅	❌
分散トレース	✅ Tempo連携	✅	✅
ベンダー依存なし	✅	✅ 標準	✅
自動計装	❌（手動）	✅	❌
ダッシュボード	✅ 豊富	❌	✅ 限定
アラート	✅	❌	❌
Datadog代替	組み合わせで✅	収集層	トレース層
ライセンス	AGPL 3.0	Apache 2.0	Apache 2.0
GitHub Stars	63k+	4k+	20k+

オブザーバビリティ・監視ツールはDevOpsカテゴリ（/categories/devops）で一覧でき、セキュリティ監視SIEMツールはセキュリティカテゴリ（/categories/security）でも探せます。

FAQ

Q. DatadogをGrafana+Prometheusに置き換えられますか？

A. 機能の大部分は置き換えられます。推奨スタック: Prometheus（メトリクス収集）+ Grafana（可視化・アラート）+ Loki（ログ）+ Grafana Tempo（トレース）+ OpenTelemetry（計装）。Datadogと比べてコストを大幅に削減できますが、自己管理コスト・エンタープライズサポートの不在・一部APM機能の差があります。エージェントレスでAWSリソースを監視するDatadogの統合数はOSSスタックでは全て再現できないケースもあります。

Q. OpenTelemetryは既存コードを大幅に変更しないといけませんか？

A. ほとんどの言語で「ゼロコード自動計装」が使えます。例: JavaはJavaエージェント（-javaagent:opentelemetry-javaagent.jar）をJVM起動時に追加するだけ・Pythonはopentelemetry-instrument python app.py・Node.jsはnode --require @opentelemetry/auto-instrumentations-node/register app.jsで自動計装が有効になります。カスタムスパン・カスタム属性を追加する場合のみコード変更が必要です。

Q. GrafanaとKibanaはどちらを選ぶべきですか？

A. 主な違い: GrafanaはPrometheus・Loki・InfluxDB・ClickHouse等多様なデータソースに対応したダッシュボードツール。KibanaはElasticsearch専用の可視化ツールです。ログをElasticsearchに保存している場合はKibana（またはOpenSearch Dashboards）が自然です。Prometheus+Lokiを使う場合はGrafanaが最適です。最近はGrafanaにもElasticsearchデータソースが追加されているため、Grafana一本化することも可能です。

Q. Jaegerのトレースデータはどのくらい保存できますか？

A. Jaegerのデフォルトのインメモリストレージは再起動するとデータが消えます。本番用途では永続ストレージが必要で、主な選択肢: Elasticsearch（大規模・全文検索可能）・Cassandra（大規模・書き込み最適化）・Grafana Tempo（S3互換ストレージにトレースを保存）。Grafana Tempoはオブジェクトストレージ（MinIO・S3等）にトレースを保存できるため、ストレージコストを大幅に削減できます。

まとめ

ユースケース	推奨スタック
Datadog代替フルスタック	Prometheus + Grafana + Loki + Tempo + OTel
分散トレースのみ	Jaeger + OpenTelemetry
メトリクス・アラートのみ	Prometheus + Grafana
すでにELKを使っている	OpenTelemetry + Kibana

関連外部リソース

• Grafana GitHubリポジトリ↗
• OpenTelemetry GitHubリポジトリ↗
• Jaeger GitHubリポジトリ↗
• OpenTelemetry公式ドキュメント↗