ダッシュボードは緑色ですが、顧客はチェックアウトが壊れていると苦情を言っています。この立場にいたことがある方なら、モニタリングと可観測性の違いをすでに理解しているでしょう。あなたの監視は、あなたがチェックすべきと考えたものをチェックしただけであり、この失敗は新しいものです。

このガイドでは、両方のアイデアをマーケティング用語を使わずに説明し、1 つの架空の事件を警告から根本原因まで追跡します。ログ、トレース、数値はプロセスを説明するために考案されたものです。また、ベンダーと実務者はこの線引きの仕方が異なり、マーケティング上の区別の一部であると考える人もいることを知っておく必要があります。私たちは実践的な部分に重点を置いています。

短い答え

モニタリングはアクティビティです。 CPU、エラー率、ディスク容量など、何を監視するかを事前に決定し、アラートをトリガーするしきい値を設定します。 「私が心配していた事は起こったのでしょうか？」と答えます。

可観測性はシステムの特性です。この用語は制御理論に由来しており、外部出力からシステムの内部状態をどの程度正確に推測できるかを表します。実際には、「何が起こっているのか、またその理由は何ですか? (予想していなかった問題も含めて)」と答えます。

車のことを考えてみましょう。ダッシュボードの警告灯が監視しています。これらは一連の既知の問題をカバーしています。整備士の完全な診断ポートは、エンジンのあらゆる部分について新しい質問をすることができ、可観測性に近づいています。

監視と可観測性を並べて見る

これは二者択一ではありません。いつ見るべきかを知らせるアラートが依然として必要です。

モニタリングだけでは不十分な理由

1 つのサーバー上に 1 つのアプリケーションがあれば、問題が発生する可能性のあるもののリストはかなり短いため、すべてを監視できます。最新のシステムには、数十のサービス、キュー、サードパーティ API に加えて、行き来する コンテナ が含まれる場合があります。障害は、1 つのリージョン、1 つの顧客タイプ、特定のアプリのバージョン、および 1 つの遅い依存関係など、誰も予測しなかった組み合わせになります。

自分が考えていない質問について、事前にダッシュボードを作成することはできません。後で質問できるデータが必要です。

ログ、メトリクス、トレース

これら 3 種類のテレメトリは、可観測性の柱と呼ばれることがよくあります。それぞれが異なる質問に答えます。

メトリクス

http_requests_total{service="checkout", status="500"} 1832
http_request_duration_seconds{service="checkout", quantile="0.95"} 2.4

メトリクスは保存コストが低く、クエリも迅速に実行できるため、ダッシュボードやアラートに最適です。多くのメトリック システムでは、ユーザー ID などのカーディナリティの高いラベルを使用すると、コストが大幅に増加する可能性があるため、注意してください。

痕跡

トレースは、複数のサービスにわたる 1 つのリクエストに従います。各ステップは開始時刻と期間を持つ スパン です。

POST /checkout                      2410 ms
├─ auth-service: verify token         18 ms
├─ cart-service: load cart            42 ms
├─ pricing-service: calculate       2290 ms   <-- slow
│  └─ SELECT coupons ...            2265 ms
└─ payment-service: not reached

トレースにより、遅いステップが明らかになりますが、これを別のサービスの別のログで確認するのは非常に困難です。

ログ

ログには、ある瞬間に何が起こったかの詳細が記録されます。これらをすぐに役立つようにする方法を見てみましょう。

事件のウォークスルー

架空の例で、ピースがどのように組み合わされるかを次に示します。

モニタリングはステップ 1 を処理しました。その後はすべて可観測性でした。各質問が前の回答からどのように派生したかに注目してください。 「今日のキャンペーンのモバイル アプリ クーポンのクエリ」用のダッシュボードを事前に構築できた人は誰もいませんでした。修正自体については、SQL クエリの最適化 に関するガイドで、その種の計画を読み取る方法が示されています。

より良いログ

プレーン テキスト ログは人間の目のために作成されており、クエリするのは困難です。 構造化ログは、マシンがフィルタリングできる次のフィールドを使用します。

# Hard to search
ERROR Payment failed for user 42 after 3 tries

# Easy to search
{"level":"error","event":"payment_failed","user_id":"42",
 "attempts":3,"provider":"acme","trace_id":"a1b2c3","duration_ms":2410}

2 番目の形式を使用すると、「過去 1 時間でプロバイダーごとに何回障害が発生しましたか?」をすぐに尋ねることができます。 trace_id フィールドは、ログ行がアクセスされたすべてのサービスにわたるリクエスト全体にリンクされるため、特に価値があります。

パスワード、トークン、カード番号は決して記録しないでください。個人データには注意してください。私たちのガイドで説明されているように、JWT はログから読み取る誰でも再利用できます。

黄金の信号

何を監視すればよいかわからないですか? Google のサイト信頼性エンジニアリングの本では、ユーザー向けシステムに対する 4 つのシグナルが提案されています。

負荷テストとストレス テストで示したように、平均値では遅いリクエストが隠れてしまうため、レイテンシーにはパーセンタイルを使用します。

人々が信頼するアラート

アラートが常に発せられると、人々はアラートを読まなくなります。優れたものはいくつかのルールに従います。

• ユーザーが感じている症状に関する警告。 「2% を超えるチェックアウト エラー」が「CPU 85%」を上回ります。誰も害を及ぼさない高い CPU は、誰も起こしてはなりません。
• すべてのアラートを実行可能にします。 誰も何もする必要がない場合は、ダッシュボード アイテムにするか、削除します。
• ランブックへのリンク。 どこを調べて何を試すべきかを応答者に伝えます。
• 定期的に確認してください。 先月無視されたアラートは削除または修正してください。

サービスレベルの目標

SLO は、「サイトは高速で信頼性が高くなければならない」を、「30 日間でチェックアウト リクエストの 99.9% が成功する」などの測定可能な目標に変えます。これにより、エラー バジェットとして知られる約 0.1% の失敗が許容されます。十分に残っている場合はより早く発送できますし、使い切ってしまう場合は信頼性を優先できます。これは、配信速度と安定性の間の議論を解決するのに役立つ方法です。

OpenTelemetry とツール

OpenTelemetry は、テレメトリを生成およびエクスポートするためのオープンソースでベンダー中立の標準です。これは、Cloud Native Computing Foundation のプロジェクトです。これをインストルメント化すると、コードを書き直すことなく、後でバックエンドを変更できるようになります。それ自体はストレージまたはダッシュボード製品ではないため、次のいずれかと組み合わせます。

これらの製品は頻繁に変更されるため、現在の機能と価格をご自身で確認してください。データ量が増えるとコストが急速に増大する可能性があるため、サンプリングを使用し、保持制限を設定します。

始め方

1. 最も重要なサービスについては、ゴールデン シグナルから始めます。
2. ユーザーが気づいた症状について 1 つまたは 2 つのアラートを追加。
3. 構造化ログに切り替えます。各行にリクエスト ID が含まれます。
4. 自動インストルメンテーションは多くの一般的なフレームワークをカバーできるため、OpenTelemetry を使用してメインのユーザー ジャーニーにトレースを追加します。
5. デプロイメントをグラフにリンクすると、CI/CD パイプラインからのリリースによって変更が生じたかどうかを確認できます。
6. それぞれのインシデントから学びます。 それぞれのインシデントの後に、どのようなデータがあればより早く解決できたかを尋ね、それを追加します。

1 つのサービスを扱う小規模なチームには、巨大なプラットフォームは必要ありません。基本的なメトリクス、適切なログ、およびいくつかのアラートがあれば十分かもしれません。サービスの数が増えるにつれて、トレースはその価値を維持していきます。

よくある間違い

• ツールを購入し、それを可観測性と呼びます。価値は、優れたインストルメンテーションとデータの使用方法から生まれます。
• 3 つの柱をチェックリストとして扱う。 個別のデータをリンクする方法がなく、タブを探し回る必要があります。共有IDは重要です。
• すべてを収集する。 フィルタリングされていないテレメトリは高価になり、ノイズも増えます。
• ダッシュボードが多すぎます。 少数の信頼できるビューは、誰も開かない 100 のビューよりも優れています。
• テストの代わりになると考えています。 リリース前にはまだテストが必要です。ただし、カナリア リリースはこれらのシグナルとよく合います。

まとめ

監視することで何か問題が発生したことがわかり、可観測性によってその理由を見つける手段が得られます。実践的なテストは簡単です。見慣れない問題が発生したときに、新しいコードを出荷せずに原因を見つけることができますか?次回、事件に遭遇したときは、答えられなかった質問をすべて書き留めてください。そのリストがロードマップです。

よくある質問

学び続ける