OpenTelemetry

OpenTelemetry（OTel）は、アプリやシステムの「観測（Observability）」のための標準規格＋ツール群です。ざっくり言うと、分散したサービスの中で「何が起きているか」を追えるようにするために、ログやトレースなどのデータを共通フォーマットで集めて外部に送る仕組みを提供します。

何ができる？（何を集める？）

OTelは主に次の3種類のテレメトリ（観測データ）を扱います。

  • トレース（Tracing） 1つのユーザーリクエストが、API → DB → 別サービス…と渡り歩く流れを「一本の線」で追跡。 どこで遅い・失敗したが分かりやすい。
  • メトリクス（Metrics） レイテンシ、エラー率、CPU、リクエスト数などの数値を時系列で収集（グラフ化向き）。
  • ログ（Logs） いわゆるアプリログ。OTel形式で整えると、トレースID等と紐づけやすくなります。

    • どういう位置づけ？

  • OTel自体は「監視SaaSそのもの」ではなく、データを取って運ぶための標準です。
  • 収集したデータは、たとえば Jaeger / Prometheus / Grafana / Datadog / New Relic / Elastic / Honeycomb など、好きなバックエンドに送れます（ベンダーロックインを減らせるのが強み）。

    • 主要コンポーネント（よく出てくる用語）

  • Instrumentation（計装）：アプリに埋め込む計測コード（自動/手動）
  • SDK：アプリ側でトレース/メトリクス/ログを生成するライブラリ
  • Collector：アプリからデータを受け取って、加工して、各バックエンドに転送する中継役（実運用で重要）
  • Context Propagation：サービス間でトレースをつなぐための仕組み（traceparent など）

    • どんなときに嬉しい？

  • マイクロサービス/分散システムで「遅い原因がどこか分からない」
  • エラーが「どのAPI呼び出しの連鎖で起きたか」追えない
  • 監視基盤を変えたい（または複数併用したい）ので、アプリ側を特定ベンダーに依存させたくない

    • 必要なら、あなたの環境（例：Node.js/Nest.js、Next.js、AWS、Kubernetes など）に合わせて「最小構成でどう導入するか（Collector置く？どこに送る？）」を短く整理して説明します。

    ← 戻る