ログ、メトリクス、トレース、構造化イベント

可観測性信号は重複しますが、交換可能ではありません。質問に答える最小の信号を選択することで、計測器が理解しやすくなり、コストも管理されます。

それぞれの信号が得意なこと

テキストログ 特定のプロセスと時間の詳細な診断コンテキストを保存します。これらは、例外、異常な分岐、人間が判読できるライフサイクル メッセージに役立ちます。

メトリクス 経時的な数値測定を要約します。カウンタ、ゲージ、およびヒストグラムは、サービス全体のレート、飽和、待ち時間の傾向に対して効率的ですが、行レベルのコンテキストを意図的に破棄します。

痕跡 接続はリクエスト パス全体にまたがります。これらは、どのサービスまたは依存関係が時間を消費したかを示し、1 つの操作が複数のシステムにまたがる場合に役立ちます。

構造化されたイベント 完了したビジネスまたはアプリケーションの事実をクエリ可能な行として記述します。これらは、SQL がアカウント、機能、モデル、ルート、またはリリース別にグループ化する必要がある、ジョブの結果、Webhook 配信、LLM リクエスト、アクティベーション マイルストーン、および顧客に影響を与えるエラーに対して適切に機能します。

調査から始める

「サービスは異常ですか?」については、メトリクスとアラートで十分な場合があります。 「このリクエストがどこに時間を費やしたか?」については、トレースを使用します。 「このプロセスで何が失敗したのか?」については、ログを調べてください。 「リリース後に同期失敗が発生したアカウントはどれですか?」については、構造化イベントをクエリします。

すべての属性をどこにでもコピーしなくても、信号を接続できます。金庫を置く request_id または trace_id 構造化されたイベントと診断ログについて。メトリクスでカーディナリティの低いサービスの健全性を維持します。スパン固有のタイミングをトレースに保存します。これにより、それぞれの目的を維持しながら、システム間のパスが作成されます。

Telemetry が適合する場所

Telemetry は、構造化イベント テーブルと SQL を中心に設計されています。これは、インフラストラクチャ メトリクスまたは分散トレースを置き換えるのではなく、補完します。ワークフローが有益な結果をもたらす境界でイベントを発行し、そのテーブルをクエリして、割合、パーセンタイル、コホート、および最近の例を取得します。

たとえば、1 回のチェックアウトに 4 秒かかった理由をトレースによって説明できます。あ checkout_completed イベントはバージョンを示すことができます v2 すべての顧客で p95 遅延または支払い失敗が増加しました。

識別子を追加する前に確認してください 高カーディナリティフィールド そして 相関ID。実装パターンについては、以下から始めます。 構造化されたロギングガイド.