オブザーバビリティのベンダーを切り替えた経験のあるエンジニアリングチームなら誰もが知っている通り、本当のコストは契約そのものではなく、すべてのサービスへの再計装、すべてのエクスポーターの書き直し、そして新しいエージェントに合わせたオンコール体制の再教育です。これこそOpenTelemetryが解決しようとした課題そのものであり、だからこそ公式のVendorsリストはオブザーバビリティ業界で密かに最も注目されるページの一つとなっています。それは「OTelデータを実際に任せられるプラットフォームはどれか」という問いに対して、市場が持つ最も中立的な答えに最も近いものだからです。
TrueWatchはこのリストに掲載され、AWS、Microsoft Azure、Google Cloud、Datadog、Dynatrace、Elastic、Grafana Labs、New Relic、Splunkと並んで名を連ねています。TrueWatchの項目にはCommercial: YesとNative OTLP: Yesという2つの属性が記載されています。
ベンダーニュートラルなテレメトリが今や必須要件である理由
OpenTelemetry(OTel)は、トレース、メトリクス、ログをベンダーニュートラルな形式で生成・収集・送信するための、CNCFがホストするオープンソース標準です。これが存在するのは、「一度計装したら永遠にロックインされる」という従来のモデルが、オブザーバビリティの選択がほとんどのエンジニアリング組織にとって複数年・複数ベンダーにまたがる意思決定になった瞬間に、意味を成さなくなったからです。
「企業はもはや、先にベンダーを選び、後からツールが追いついてくることを期待するようなやり方をしません。OpenTelemetryでは標準が先にあり、ベンダーはそれを満たすか、議論から外れるかのどちらかです。リストに掲載されたということは、TrueWatchがOTelを標準化するあらゆるチームにとって、当然検討すべき選択肢の一つになったことを意味します。」— Mike Loong、CEO、TrueWatch
この変化は、米国、シンガポール、インドネシアといった急成長市場のチームにとって特に重要です。これらの地域では、インフラが当初からクラウドファースト・マルチリージョンで構築されることが多いためです。OpenTelemetryを標準化するということは、バックエンドやリージョン、ベンダーが背後で変わっても、計装レイヤーは変わらないままであることを意味します。
TrueWatchの掲載がOpenTelemetryベンダーマップに加えるもの
OpenTelemetry Vendorsページは単なるマーケティング用のディレクトリではありません。OTLP経由でOTelデータをネイティブに取り込み、単なる通過パイプではなく、エンドユーザーにとって実用的なオブザーバビリティソリューションへと変換できるプラットフォームの登録簿です。掲載されるということは、データシート上で「OTel対応」を謳うだけでなく、その基準を実際にクリアしていることを意味します。 プラットフォームを比較検討しているチームにとって、これはTrueWatchの立ち位置を変えるものです。たまたまOTelデータを受け付ける代替手段としてではなく、すでにリストに載っているベンダーと肩を並べる存在としてです。
「Datadog、Grafana、New Relicと並べて私たちを評価しているチームにとって、これは『どのプロプライエタリなエージェントにロックインするか』という問いを、『どのOTelネイティブなバックエンドが自分たちのスタックに合うか』という問いに変えるものです。これはずっと『イエス』と言いやすい判断であり、うまくいかなかった場合に撤回するのもずっと容易です。」— Brandon Foo、Head of Growth & GTM、TrueWatch
TrueWatchのネイティブOTLPサポートの内側
ネイティブOTLPサポートは、紙の上では単純に聞こえます。データを受信し、データを保存する、というだけです。しかし実際には、OTLPペイロードを単に受け付けるだけのプラットフォームと、実際の本番負荷の下でそのデータを実用的なものにできるプラットフォームとの間には大きな違いがあります。
TrueWatchは、DataKitのOpenTelemetry inputを通じてOpenTelemetryのトレース、メトリクス、ログをネイティブに取り込み、あらゆる言語やフレームワークからのテレメトリを単一のオブザーバビリティコンテキストにまとめます。プロトコルレベルでは、TrueWatchは以下をサポートしています。
- OTLP over gRPC
- OTLP over HTTP/Protobuf
- トレース、メトリクス、ログ用の独立したエンドポイント
- HTTPおよびgRPC転送の両方に対応したgzip圧縮
- OpenTelemetry Java Agent(V1・V2両対応)
「OTLPをサポートするということは、単にgRPCやHTTPのエンドポイントを開くことではありません。本当の作業は取り込み後に発生します。サンプリングの判断、カーディナリティの制御、本番規模でのトレースとログの相関関係の維持などです。今回の掲載を実際に勝ち取ったのは、設定フラグ一つではなく、こうした部分です。」— Jimmy Soh、Head of Product & Solutions Engineers、TrueWatch
本番環境向けに設計:サンプリング、ガバナンス、そして大規模運用時のコスト
OTLPトラフィックを受け付けることと、それを本番規模で実用的かつ手頃なコストに保つことは、まったく別の話です。TrueWatchのOpenTelemetry連携は、エンジニアリングチームが一貫して求める3つの本番要件を軸に設計されています。
- 柔軟なガバナンス — トレースサンプリング、まれなリソースの保持、エラーフィルタリング、タグの許可/拒否リスト、ローカルキャッシュにより、すべてを保存するコストをかけずに重要なシグナルだけを保持できます
- 互換性のある分析 — リクエスト量、エラー率、レイテンシ、Apdexスコアをトレースデータから直接抽出し、既存のDDTrace計装との互換性も備えているため、総入れ替えなしで移行できます
- 統合されたコンテキスト — トレース、メトリクス、ログが3つの分断されたサイロではなく、同一のオブザーバビリティモデルに集約されます
ここでOpenTelemetry自体の限界も明らかになります。OTelはテレメトリがどのように生成・収集・転送されるかを解決しますが、チームが異常をどう発見し、複数のシグナルにまたがって相関させ、インシデントの対応を完結させるかという課題は解決しません。それには依然として、その下支えとなる完全なオブザーバビリティプラットフォームが必要です。TrueWatchは、OTel由来のデータをAPM、インフラおよびコンテナ監視、ログ管理、ユーザーエクスペリエンス監視(RUM)、アラート、インシデント管理と組み合わせることで、トレースは単に届くだけでなく、発見・分析・特定・解決というワークフローの一部となります。
1つのプラットフォーム、650以上のインテグレーション — OpenTelemetryはほんの出発点
OpenTelemetryはTrueWatchへの一つの経路であり、唯一の経路ではありません。本プラットフォームは現在、ホスト、コンテナ、Kubernetes、クラウドプラットフォーム、データベース、ミドルウェア、ネットワーク機器、ログ、アプリケーション、RUMにまたがる650以上のインテグレーションをサポートしており、収集方法としてOpenTelemetry、Prometheus、Telegrafを並行して利用できます。
この幅広さは実際の運用において重要です。ほとんどのエンジニアリング組織は、純粋なOTelのみのスタックを運用しているわけではなく、Prometheusエクスポーター、レガシーエージェント、OTel移行以前から存在するクラウドネイティブなインテグレーションと並行してOTelを運用しています。DataKitの統合された収集レイヤーにより、チームは一つの収集方法を選んで他をすべて取り除く必要はありません。他のすべてが同じオブザーバビリティコンテキストに報告を続ける一方で、自分たちのペースでOpenTelemetryを採用していくことができます。
詳細はこちら:
- OpenTelemetry公式Vendorsページ: https://opentelemetry.io/ecosystem/vendors/
- TrueWatch OpenTelemetry連携ドキュメント: https://docs.truewatch.com/integrations/opentelemetry/