How Honeycomb Is Embracing the Challenges of End-to-End Observability with Embrace

Honeycombの視点から

顧客はフロントエンドからバックエンドまでを結びつけることで可観測性の問題を解決しようと頻繁に私たちに相談してきます。理論上は単純に聞こえますが、実際には現代のアプリケーション監視において最も困難な問題の一つです。すでに導入しているフロントエンド監視ツールはプロプライエタリなものやフロントエンドに特化した狭い範囲のものになりがちで、本当のトリアージを可能にするコンテキスト豊富なバックエンドデータが不足しています。何か問題が発生したとき、その症状はユーザーのブラウザやモバイルアプリに現れるかもしれませんが、根本原因は3ホップ先のバックエンドサービスに埋もれていることがあります。

結果として予想されるのは、チームが2つのソリューションを並行して運用し、ダッシュボード間を行き来しながら、手動でタイムスタンプやユーザーIDを相関付け、互いに連携するよう設計されていない2つの半分から一貫したストーリーを組み立てようとする状況です。

EmbraceがHoneycombの適切なパートナーである理由は、共通の基盤にあります。EmbraceはHoneycombと同様に、最初からOpenTelemetryに基づいて構築されており、モバイルおよびWebのパフォーマンスを私たちと同じようにアプローチしています。つまり、それを独立した分野としてではなく、一級の可観測性の問題として扱うということです。この整合性は、思った以上に重要です。2つのプラットフォームが同じオープンスタンダードに基づいて構築されている場合、生成されるデータは本質的に互換性があります。情報の欠落を伴う変換レイヤーもなく、プロプライエタリなスキーマの不一致もなく、あるツールがもう一方のツールのデータを理解するためにテレメトリを再構築する必要もありません。

EmbraceがWebまたはモバイルアプリケーションからフロントエンドのテレメトリを取得すると、重要なシグナルはシンプルな統合を通じてHoneycombにシームレスに流れ込みます。バックエンドサービスのトレースをフロントエンドのセッションやデプロイメントに結びつけるメトリクスとネットワークスパンが得られ、通常、クロススタックの可観測性プロジェクトに伴う大規模なエンジニアリング作業は必要ありません。Honeycombユーザーにとって、すでにクエリしているトレースがこれまで以上に拡張され、ユーザーのデバイスまで到達することを意味します。

Embraceの視点から

Embraceでは、常にフロントエンドの可観測性はブラックボックスであってはならないと考えてきました。あまりにも頻繁に、エンジニアリングチームは断片化されたデータ（ここにクラッシュレポート、あそこにANRトレース、どこかにネットワークログ）を扱わされ、ユーザーのフラストレーションを伴う体験と、実際にシステム内で何が間違っていたのかを結びつける明確な糸が見つかりません。そのため、Embraceは最初からOpenTelemetryに基づいて構築されました。私たちは単にデータを収集するのではなく、どんなOpenTelemetryネイティブのバックエンドでも理解できる、リッチで構造化されたテレメトリを出力します。高いカーディナリティとイベント駆動型の可観測性への同じ基本的なコミットメントを共有するHoneycombは、そのデータの自然な受け皿となります。

Honeycombとのパートナーシップは、顧客から常に耳にする問題を解決します。バックエンドチームは1つのツールで作業し、モバイルおよびWebチームは別のツールで作業しており、何か問題が発生したときに誰も完全な全体像を持っていないという問題です。EmbraceのネットワークスパンをW3Cトレースコンテキストとともに直接Honeycombに転送することで、バックエンドエンジニアにこれまで欠けていたフロントエンドのシグナルを提供し、モバイルおよびWeb開発者には遅いセッションを苦戦しているマイクロサービスに結びつける方法を提供します。EmbraceはメトリクスとログもHoneycombに転送し、チームがセッション数、クラッシュ率、リクエスト量などのトレンドをバックエンドデータと並行して追跡できるようにします。これにより、インシデントに反応的にデバッグするだけでなく、問題が発生する前にパターンを発見できるようになります。

私たちのソリューション

では、具体的にどのように機能するのでしょうか？

まず、WebおよびモバイルプロジェクトにEmbraceのSDKをセットアップします。Embraceのドキュメントには、Android、iOS、Web、React Native、Unity、Flutter向けの主要な統合パスが記載されているため、チームが使用しているスタックに関わらず、サポートされている方法があります。大きな利点は、すべてのEmbrace SDKがOpenTelemetryを基本的な可観測性標準として構築されている点で、アプリケーションから出力されるデータは、残りの可観測性エコシステムが理解できる形式になっているということです。

計装が完了すると、Embraceダッシュボードがフロントエンドからテレメトリの収集を開始します。これにより、Embrace内でアプリケーションの健全性の完全なビューが得られますが、本当の価値は、その可視性をHoneycombに拡張し、バックエンドチームとフロントエンドチームが同じ信頼できる情報源に基づいて作業できるようにすることにあります。

その後、Embrace内でHoneycombをデータ送信先として設定します。これはHoneycombのAPIキーを入力するだけで完了します。SDKがすでに計装とデータフォーマットの重い作業を行っているため、設定は意図的に軽量になっています。この接続が有効になると、EmbraceはHoneycombにメトリクスのストリーミングを開始します。これには、セッション数、スパン数、ネットワークリクエスト、例外、所要時間などが含まれます。

これらのメトリクスを組み合わせることで、フロントエンドアプリケーションが時間とともにどのようにパフォーマンスを発揮しているかを理解するために必要な主要なシグナルが得られ、Honeycombユーザーがすでに使い慣れているダッシュボードやクエリに自然に組み込まれます。

Embrace integrationsEmbrace dashboard

メトリクスはトレンドや集計には優れていますが、特定のユーザーの体験を理解したり、特定の障害を追跡したりする必要がある場合は、トレースが必要です。そのため、Embraceは重要なネットワークスパンもHoneycombに転送します。

ネットワーク経由でフロントエンドからバックエンドに移動するリクエスト（そのため「ネットワーク」と呼ばれる）は、W3Cトレースコンテキストを伴います。これは、分散システムが単一のリクエストをサービス間で移動する際に識別する方法について合意するためのオープンスタンダードです。対応するバックエンドスパンが生成されると、それらは単一のトレースに縫い合わされます。デバイス種別、オペレーティングシステム、アプリケーションのバージョンなどのコンテキストとともに、ネットワーク側の性能データが1つのタイムライン上で得られます。突然、「なぜこのリクエストはこのユーザーにとって遅かったのか？」という質問に、推測ではなく本当の答えが出るようになります。

When backend spans are generated, they are stitched together into a single trace

これらのネットワークスパンにはEmbraceダッシュボードへのリンクも含まれており、Honeycombユーザーはクリックすることでセッションアクティビティやユーザータイムラインに直接ジャンプできます。そこから、Embrace側でキャプチャされたすべてのユーザーアクション、ネットワークリクエスト、Core Web Vitalsを確認でき、トレースデータの背後にある人間のコンテキストを得られます。障害が発生する数秒前にユーザーが何をしていたかを確認でき、システムが何をしていたかだけでなく、それもわかります。

Grouped sessionsEvery user action, network request, and Core Web Vitals was captured on the Embrace side

Embrace側では、同じセッション中に追加のネットワークリクエストが行われたかどうかを確認できます。この種の相互確認は、根本原因が隠れている場所であることが多く、単一の障害が物語のすべてを語ることは稀だからです。

バックエンドに送信されたエラーレスポンスを発見したとしましょう。

Erroneous response sent to the backend

Embraceは、その情報がHoneycombに転送されたかどうかを表示します。緑色の「Forwarded」ラベルは、データが正常に通過したことを確認します。トレースコンテキスト（例: 00-2593fc10a27ab64bb5dd237616dbdbf1-80a9d71ce8c208aa-01）を使用することで、Honeycombで直接検索してその500エラーの根本原因を調査し、完全なトレースを表示できます。この場合、トレースは製品カタログサービスが利用できないことを示しており、これはフロントエンドデータだけでは発見しにくい結果です。

（注: 2番目のセグメント 2593fc10a27ab64bb5dd237616dbdbf1 はバックエンドへのリクエストのトレースIDであり、Honeycombで一致するトレースを取得するために最も頻繁に貼り付ける部分です。）

Query resultsTrace view

HoneycombとEmbraceのチームは現在、この移行をより簡単にするために、Embrace UI内から直接トレースビューを表示するリンクを提供するよう共同で取り組んでいます。

結論

結局のところ、ツール間を行き来するのではなく、単一の統合されたビューを持つことができない理由があるでしょうか？OpenTelemetryという共通言語を話すことで、HoneycombとEmbraceはついにフロントエンドとバックエンドのギャップを埋めています。コンテキストの切り替えをやめて、画面の最初のタップからバックエンドの最終応答まで、ユーザーの体験の完全なストーリーを見る時が来ました。

このブログはHoward YooとAissa Mamdouhによって書かれました。