Kubernetesの運用チームには、CPUやメモリの使用量、エラー率を表示するダッシュボード以上のものが必要です。クラウドネイティブ環境の複雑さにより、1つのリクエストがゲートウェイ、サービス、キュー、ストレージ、バックグラウンド処理を通過する一方、ワークロードは移動し、バージョンは継続的に変化します。そのため、Deploymentのレベルではデプロイが正常に見えても、後続の依存関係、再試行ループ、あるいはコントロールプレーンの経路への負荷が、レイテンシの上昇を引き起こす可能性があります。
CNCFのブログに掲載された記事で、StackgenのNeel Shahは、従来の監視は「CPU使用率が一定のしきい値を超えたか」「エラーが増加しているか」といった、あらかじめ定められた質問に答えるものだと説明しています。一方、記事の主張によれば、オブザーバビリティは、チームが予期していなかった問題を調査し、症状の把握から原因と範囲の理解へ進むことを支援することを目的としています。
メトリクスは調査を始めるものであり、終わらせるものではない
メトリクスは、数値化され、保存とクエリが効率的で、アラートや傾向分析に適しているため、依然として自然な出発点です。Kubernetesでは、ノードの逼迫、コンテナの再起動、リクエストレイテンシの上昇、APIサーバーの低速化、キュー項目の蓄積などを示すことができます。
記事では、サービス向けのRED、すなわちリクエスト率、エラー、期間と、インフラストラクチャ向けのUSE、すなわち使用率、飽和度、エラーを活用することを提案しています。これらの指標は、インシデントの初期像を描くのに役立ちます。たとえば、リクエスト率が上昇してもレイテンシが安定している場合と、トラフィックが一定なのに期間と飽和度が上昇している場合では、状況が異なります。
しかし、あらゆる詳細をメトリクスのラベルに変換すると、カーディナリティの問題が生じます。固有の組み合わせが大量に発生すると、コストが増加し、クエリが遅くなるためです。記事は特に、リクエストIDやユーザーID、準一意の値をメトリクスに含めないよう警告しています。こうした詳細は、ログやトレースの方が適しています。
各シグナルは異なる質問に答える
ログは、通常グラフには保存されないローカルなコンテキストを追加します。時刻、重要度、サービス名、名前空間、コンテナの識別情報、リクエストパス、トレースコンテキストなどの一貫したフィールドを使用して構造化されていれば、特定のイベントを、それを生成したサービスや処理に結び付けやすくなります。メトリクスが決済サービスに影響があることを示していても、ログはタイムアウト、例外、依存関係の失敗を明らかにする可能性があります。
一方、分散トレースは別の問いに答えます。1つのリクエストがシステム内をどのように移動し、どこで時間を消費したのか、という問いです。Kubernetesでは、障害が複数のサービス、再試行、キューの境界、データベース呼び出しに分散している可能性があるため、その重要性が際立ちます。トレースコンテキストを伝播することで、異なる区間を1つのリクエストのコンテキスト内で結び付けられます。また、共通のセマンティック規約は、メトリクス、ログ、トレース間でフィールド名と属性を統一するのに役立ちます。
記事では、プロファイリングも全体像の一部に位置付けています。メトリクスが遅いサービスを特定し、トレースが影響を受けたリクエストの経路を特定し、ログがローカルイベントを明らかにした後、プロファイリングデータは、CPUやメモリを消費している関数またはコードパスの特定に役立ちます。
インシデント中に実際に何が変わるのか
記事では、新しいデプロイ後にcheckoutサービスがレイテンシ目標を超え始めた一方、CPUとメモリの指標は正常なままだった例を示しています。メトリクスが問題の存在を明らかにし、その後、低速なリクエストのトレースによって、遅延の大部分が決済認可のステップにあることが示されます。続いてログには、同じリクエストコンテキストに関連するタイムアウトメッセージが繰り返し現れます。
この流れにより、チームは「なぜ決済サービスが遅くなったのか」という一般的な問いから、依存関係の変更をロールバックする、再試行の増幅を抑える、調査中にトラフィックを一時的に切り替えるといった、より具体的な運用上の選択肢へ移行できます。記事はまた、より良いアラートとは、インフラストラクチャのリソースに関する単なる生の異常ではなく、サービス品質や信頼性目標へのリスクを反映するものだと強調しています。例として、10分間にわたりレスポンスタイムのp99が1秒を超えたことに関連するアラートを挙げています。
適用可能な設計ルール
- 利用可能なメトリクスとログから始め、目的なくすべてを収集するのではなく、カバレッジを段階的に拡大する。
- メトリクス内で非常に高い一意性を持つラベルを使用するより、サービスとワークロードに関連するディメンションを優先する。
- メトリクス、ログ、トレース間で一貫したメタデータ構造を使用する。
- シグナル間の移動を容易にするため、リクエストIDまたはトレースIDをログに追加する。
- リソースの逼迫だけでなく、信頼性リスクとサービス品質を中心にアラートを構築する。
- オブザーバビリティを、デプロイ後に追加するものではなく、アプリケーションとプラットフォームの設計の一部とみなす。
certi.newsによる編集部の見解：ここでの基本的な価値は、ツールの購入や単一の実装の採用を呼びかけることではなく、オブザーバビリティの目的を再定義することにあります。実際に変わるのは、データの使い方です。メトリクスは逸脱を捉え、トレースは経路を特定し、ログはイベントを説明し、プロファイリングはコードレベルで原因を特定する可能性があります。実務上の明確な制約も残ります。より多くのシグナルを収集しても、より良い理解が保証されるわけではありません。また、統一された名前やフィールドがないと相関付けが脆弱になり、一意性の高い詳細情報はメトリクスのコストを押し上げ、クエリの性能を低下させる可能性があります。したがって、価値はダッシュボードの数ではなく、設計の品質とシグナル間の関連付けに依存します。