コンテンツにスキップ

日本におけるOpenTelemetry活用実態調査の結果

概要

日本の OpenTelemetry コミュニティが実施した調査の結果が公開された。日本語訳版：https://opentelemetry.io/ja/blog/2026/japanese-survey/

著者の Yoshi Yamaguchi（@ymotongpoo）は Google のエンジニアで OpenTelemetry のコントリビューター。

詳細

OpenTelemetry とは

OpenTelemetry（OTel）は CNCF プロジェクトで、Metrics / Logs / Traces の3本柱を統一 API・SDK・プロトコル（OTLP）で扱えるオブザーバビリティフレームワーク。

アプリケーション
  │
  ├── OTel SDK（Go/Java/Python/etc.）
  │     ├── Traces  → Jaeger / Tempo
  │     ├── Metrics → Prometheus
  │     └── Logs    → Loki / Elasticsearch
  │
  └── OTel Collector（エージェント）
        └── OTLP → バックエンドへ転送

調査のポイント（日本コミュニティ向け）

日本企業での OTel 採用状況・課題・使い方のパターンを調査。主な観点： - どのシグナル（Traces/Metrics/Logs）から始めたか - どの言語 SDK を使っているか - OTel Collector の使用率 - 導入時の障壁

OTel を始めるときの実践的な手順（Go 例）

// トレースプロバイダーの初期化
tp := trace.NewTracerProvider(
    trace.WithBatcher(otlpExporter),
    trace.WithResource(resource.NewWithAttributes(
        semconv.SchemaURL,
        semconv.ServiceName("my-service"),
    )),
)
otel.SetTracerProvider(tp)

// スパンの作成
tracer := otel.Tracer("my-tracer")
ctx, span := tracer.Start(ctx, "operation-name")
defer span.End()

なぜ重要か / いつ使うか

  • マイクロサービスのデバッグ: 分散トレーシングでリクエストの全経路を追える
  • ベンダー非依存: Datadog → Jaeger の移行など、バックエンドを変えてもコード変更不要
  • 日本企業の事例: 日本語の調査結果なので国内での採用実態・課題を把握しやすい
  • SRE/DevOps 必須知識: オブザーバビリティの標準として業界全体が OTel に移行中