OTLPでサクッと繋げられて、かつ思いのままにトレース分析できるツール

ツール導入前の課題

・トレース単体の分析の課題

導入前はGoogle CloudのCloud Traceによってトレース監視を行っていました。ただCloud Traceではスパンに対する属性値（例えばDBのクエリなど）が、長すぎる場合に途中で文字がカットされてしまう問題がありました。このため、各トレースで何が起きていたか正確に把握することが困難でした。

・トレース横断の分析の課題

Cloud TraceはGoogle Cloud配下にある場合、導入が簡単な一方で、機能的には他のトレース監視系ツールと比べると簡素なものでした。例えば、トレースの検索条件を保存できないので、毎回条件を手打ちするのが面倒だったりしていました。やっぱりよく使う検索条件は保存したいです。

どのような状態を目指していたか

• トレースの分析が十分にできること
• 組織が一定以上拡大したときも費用面での懸念がないこと

• Sentry
• Datadog
• New Relic

• OpenTelemetry Protocol（OTLP）に対応していること
• OpenTelemetry Protocol（OTLP）の繋ぎこみが容易なこと

分析のリッチさ（探索可能性の高さ）

例えばレイテンシーの高いAPIリクエストの対策をしたいとして、BtoB SaaSにおいては利用している企業IDが多いAPIリクエストについては対応の優先度が高い一方、利用企業IDが少ないAPIの改善は効果が薄いので優先度をコントロールしたい時があります。

例えばこのような場合下記のようなフローを踏みます。

1. APIリクエストをエンドポイントごとにGROUP BYして、レイテンシーでリストアップ
2. リストアップしたエンドポイント一覧で、最もレイテンシーが高いAPIを選ぶ
3. 分散しているレイテンシーのうち、高いレイテンシーを記録しているリクエストにフォーカスして、それを利用している企業数を見る
4. 利用企業が分散しているなら重要度を上げて対応

ここまでのフローが、一つのクエリからの流れでボタンぽちぽちするだけで分析できます。クエリからの流れで、というのが大事なポイントで、ツールによってはそれ専用のクエリを書き直したりするわけなのですが、これがHoneycombだと、クエリからそのまま欲しい結果まで辿り着くことまでできます。

なかなか画像抜きだと伝わりづらいですが、この体験はとても良いと同時に、Observability担保においては大事だと思っています。なぜなら、見たい結果をすぐ得られることは、Observabilityの重要な概念としてある「探索可能性（explorability）」を満たすからです。Honeycombはデータを柔軟に探索してインサイトを得るにはとても良いプラットフォームと考えています。

Honeycombは「Observability Engineering」の著者の一人が参加しているプロダクトということもあって、そのエッセンスを随所に感じます。例えばクエリした後、Bubble Up機能を使うとディメンジョンごとの統計を全て出してくれるのは、「さあこの結果からインサイトを得てくれ」というメッセージを感じます。

無料枠が太っ腹

「2000万 Event / 月」まで無料です。Eventは、トレースの文脈においては 1 span に該当します。Honeycomb においてはログやメトリクスも送信できるのでその場合はそれぞれの計測単位で 1 Event となるようです。

スタートアップにおいてはこの太っ腹な無料枠はとても嬉しいです。シリーズAのスタートアップにしては2000万スパンはむしろ少ない量だと思いますが、スロークエリやバグはあっても全体的な作りが良いためN+1などが発生せず、スパンの発生自体が抑えられていたのと、Otel Collecterによって連携するスパンを絞り込めていたので、スパンの効率がよかったのも、この無料枠内に抑えられた背景です。

またユーザー課金がないのも推しポイントです。Observabilityにおいては組織のエンジニアが自由にシステムを探索し、各々がインサイトを得られる状態を確保するのが良いと思いますが、ユーザー課金があるとそれを阻害するバイアスが働くかと思います。

OTLPに対応 / 繋ぎこみが容易

OTLP対応していることはマストでした。2024年3月当時、まだOpenTelemetry Protocolはそこまで日本においてメジャーな選択肢ではなかったと記憶してますが、当時から、各ベンダーが作るSDKを経由して計装するより、業界標準のプロトコルを利用していた方が、ベンダーロックインがなく、将来的な変化に強いと考えており、そのためにOTLPでのトレースログ受信に対応していることはマストでした。その点でHoneycombはOTELに標準で対応していました。

またHoneycombはOTLP経由での繋ぎ込みが圧倒的に容易です。OpenTelemetry CollectorのconfigにエンドポイントとAPIKeyを追記するだけで繋ぎこみの実装はほぼ終わりました。他サービスを見てみると、当時はOTLP自体がまだ新しいプロトコルだったこともあってか、対応するためにごちゃごちゃと実装させられることが多く、ドキュメントも複雑でわかりづらかった記憶があります。その点Honeycombは下記ドキュメントを見ていれば、さっと実装ができて感動しました。

https://docs.honeycomb.io/send-data/opentelemetry/collector/

改善したかった課題はどれくらい解決されたか

当初の課題だったトレース単体の分析やトレース横断の分析においては問題なく利用できています。特に不満な点はなく、課題は解消されたと言えます。

ただ正直、現状は高機能すぎて持て余しているところもあります。もっと自分たちで踏み込んで利用したいのですが、そこまでできていません。

どのような成果が得られたか

顧客起点ですが、特定のAPIの動作が遅いというフィードバックが来た際、トレースの内容を分析し、ボトルネックを突き止めることに役立ちました。

その他、特定の動作が遅いという問題があった際、ボトルネックを特定するのに役立っています。

ほぼありませんでしたが、サーバーがアメリカにあるので、画面を表示する時に少し遅さを感じる時がたまにありました。ただ現在はサーバーが追加されたのか、ほぼ気にならないです。

分析については圧倒的にリッチなので、言語が英語であることや日本ではまだまだ市民権を得ていないことを懸念されないならオススメです。

もっと組織レベルで踏み込んで利用し、システムの改善に活かしたい。