監視と可観測性: メトリック、ログ、トレース、アラームルール

利益:

可観測性の 3 つの柱 (メトリック、ログ、トレース) と 4 つのゴールデンシグナルを理解し、人工知能に PromQL クエリ、アラームルール、ダッシュボードを生成させる能力
アラームをアクション指向で適切な緊急度に保ち、独自のシステムの履歴データに対してしきい値をテストすることで、アラーム疲労を防ぐ機能
ログを人工知能に渡す前に機密領域をマスクすることで、プライバシーと秘密の漏洩を防ぐ機能

システムは動作しているように見えても、内部では停止している可能性があります。メモリが徐々にいっぱいになり、応答時間が増加し、エラー率が上昇しています。これに気づく唯一の方法は、システムを常に監視することです。より高度な概念は可観測性です。つまり、外部の兆候を見てシステム内で何が起こっているかを理解する能力です。可観測性には 3 つの柱があり、DevOps プロフェッショナルは 3 つすべてを使用します。

メトリクス: 一定期間にわたって測定された数値 — CPU 使用率、リクエスト数、応答時間、エラー率。 "いくら？"という質問に答えます。
ログ: システムによって生成されたテキストイベントレコード (「ユーザーがログインしました」、「データベース接続が失われました」)。「いったい何が起こったの？」という質問に答えます。
トレース: リクエストがシステム内でサービスからサービスに渡される際にたどるパスと各ステップの期間。「どこが遅いのですか？」という質問に答えます。

最も一般的なツール: メトリクス用の Prometheus、視覚化用の Grafana、ログ用の Loki/ELK、トレース用の Jaeger/OpenTelemetry。 AI は、クエリ言語 (特に Prometheus の PromQL)、アラームルール、およびこれらのツールのダッシュボード構成を作成することに非常に熟練しています。これは、大量のログとメトリクスを要約し、異常を報告するという、AI が最も得意とする分野でもあります。

モニタリングとオブザーバビリティの違いを一文で明確にしましょう。モニタリングとは、すでに知っている質問をすることです (「CPU は 90% を超えていますか?」)。可観測性とは、まだ知らなかった質問をできることです (「この奇妙な遅さは、特定の時間に特定の顧客にのみ発生するのはなぜですか?」)。最新のシステムは非常に複雑であるため、すべての障害モードを予測することはできません。したがって、豊富なメトリクス、ログ、トレースを収集し、それらを詳細にクエリする機能、つまり可観測性が重要になります。ここで、「これまで知られていなかった質問」に答えるときに AI が活躍します。AI は、手元にある生データをすばやくスキャンし、パターンや異常を提案し、これらの手がかりを検証することで根本原因に到達します。

ステップバイステップ: 何をどのように監視するか?

適切な指標を選択してください。業界では、遅延、トラフィック、エラー、飽和、つまりリソースの空き状況を示す「4 つのゴールデンシグナル」が基準とされています。これらは、ほとんどのサービスの健全性を要約したものです。
メトリクスを収集します。 Prometheus が読み取れるエンドポイントをアプリケーションに提示させます。
ダッシュボードをセットアップします。これらのメトリクスを Grafana で視覚化します。
アラームルールを作成します。しきい値を超えた場合、誰にどのように警告されますか?
ログを一元化します。すべてのサービスログを 1 か所で検索できるようにします。
ノイズを軽減します。警報が多すぎると「警報疲労」が生じます。重要なアラームが消えます。

ヒント: 優れたアラームとは、実用的であり、適切な緊急性を備えているという 2 つの条件を備えています。午前 3 時に誰かを起こすアラームは、実際には夜間の介入を必要とするものに違いありません。「CPU 70%」など、それ自体でアクションを必要としないもののために誰かを起こさないでください。それをボードに表示します。

アラームルールの書き方は？

アラートは 3 つの要素で構成されます。条件 (どのメトリックがどのしきい値をどのくらいの期間超過するか)、継続時間 (瞬間的な変動を引き起こすのを避けるために「5 分間」)、および重要性/アクション (誰に対して、どのチャネルを通じて)。 AI はこれら 3 つを適切なコンテキストで巧みに確立します。たとえば、「エラー率が 5 分間 5% を超えた場合にクリティカルアラーム」のようなルールを PromQL に変換するのは、AI にとっては一瞬の作業ですが、しきい値がシステムに適切であるかどうかはユーザーが判断します。

注意: AI によって提案されるアラームしきい値は一般的な仮定です。システムの通常の負荷、許容範囲、作業への影響は異なります。 prod にしきい値を直接設定する前に、履歴データを確認して、「このしきい値は過去に何回トリガーされましたか? そのうち実際の問題は何回か?」と尋ねます。質問に答えてください。

ログのプライバシー: 重要な警告

ログは漏洩の最も頻繁に見落とされるソースです。ログ行にパスワード、クレジットカード番号、または個人データ (KVKK/GDPR に基づく) が誤って含まれる可能性があります。分析のためにログを AI に貼り付ける場合:

敏感な部分をマスクします。トークン、パスワード、電子メール、ID 番号などの値を <REDACTED> に置き換えます。
すべてではなく例を挙げてください。多くの場合、100 万行ではなく、数百行の代表的な行で十分です。
機関が承認した車両を選択してください。特に本番ログの場合は、データがトレーニングに使用されないツールを使用してください。

4 つの黄金の信号とアラームテーブル

信号

によって測定される

アラームしきい値の例

緊急性

レイテンシー

応答時間

p95 > 800 ミリ秒、5 分

高い

交通

リクエスト/秒

突然の300%増減

中程度

エラー

失敗したリクエスト率

> 5%、5分

クリティカル

彩度

リソース占有率

ディスク > 85%

高い

ミニケース3個

ケース 1 — 30 秒に要約された 400 行のログ。サービスの速度が低下しました。エンジニアはマスクされた400行のログをAIに渡し、「繰り返されるエラーのパターンと時間の強さを要約してください」と述べた。 AI は、特定の外部 API 呼び出しが 30 秒ごとにタイムアウトになることを示しました。根本原因は 30 秒で見つかります。ログを手動でスキャンすると 30 分かかります。

ケース 2 — アラーム疲労が解決されました。あるチームは 1 日に 200 件のアラームを受信していましたが、実際の停止アラームも見逃されるまで、それらをすべて無視していました。 AI にすべてのアラートルールを与え、「どれが実行不可能で、どれが組み合わせ可能か?」と尋ねます。彼らは尋ねた。アラームの数は 1 日あたり 12 件に減少しました。今ではあらゆる警報が真剣に受け止められました。

ケース 3 — 間違ったしきい値が早期に発見されました。 YZ は、ディスクの「95% がいっぱいになったら警告する」ことを提案しました。エンジニアは過去のデータを調べました。ディスクが 95% に達すると、介入する時間はほとんどありませんでした。しきい値を 80% に下げ、「増加率」に基づいた 2 番目のアラームを追加しました。検証により、実際の深夜の停止は回避されました。

コピー可能な 4 つのテンプレート

1) ログの要約 (マスク):

以下のログの例を分析してください (機密値を <編集済み> でマスクしました)。 (1) 繰り返されるエラーのパターン、(2) 長期にわたる集中力、(3) 最も可能性の高い根本原因、(4) 検証するために検討する 3 つの指標を教えてください。ログ: [LINE]

2) アラームルールの生成:

Prometheus/Alertmanager のアラームルールを作成します。[THRESHOLD] が [METRIC][DURATION] を超えた場合、[SEVERITY] アラームを生成します。ルールはアクション指向であり、注釈と Runbook リンクフィールドを含める必要があります。 PromQL について説明し、このしきい値が妥当である理由を書きます。

3) PromQL クエリの作成/宣言:

以下を測定する PromQL クエリを作成します。 [EX.過去 5 分間の 5xx エラー率パーセンテージ]。クエリをステップごとに説明します。次に、この値の健全な範囲を教えてください。

4) ダッシュボードのデザイン:

[SERVICE] 用の Grafana ダッシュボードを設計します。4 つのゴールデンシグナル (レイテンシ、トラフィック、エラー、飽和) をどのパネルで表示すべきですか?各パネルのメトリクス、視覚化タイプ、および適切なしきい値を提案します。目的: 警備員の健康状態を 10 秒で確認する。

弱いプロンプト / 強いプロンプト

弱者：「そのログには何が書いてあるの？」 (その後に 5000 行の生のログが続き、その中にトークンが含まれます)

結果: あなたが秘密を漏らすと、AI は的を絞った表面的な要約を与えます。

Strong: 「以下の 300 行のマスクされたログの例から、繰り返し発生するエラーのパターンと時間の強度を見つけてください。最も可能性の高い根本原因と、検証するために参照するメトリクスを教えてください。私はトークンを <編集済み> にしました。」

違い: 2 番目のプロンプトでは、マスクされて焦点が絞られた例が示され、明確な分析出力が求められます。安全かつ便利です。

よくある間違い

ログをマスクせずに AI に貼り付けます。最も一般的な機密/個人データの漏洩。
すべてにアラームを設定します。アラームの疲労により、実際のアラームが埋もれてしまいます。
対処不可能なアラーム。それは誰もどうすることもできない警告音です。
AIの敷居を疑いなく受け入れる。しきい値はシステムの履歴に従って設定する必要があります。
指標を見ただけです。ログとトレースがなければ、ほとんどの場合、根本原因を見つけることができません。
アラーム時刻を設定していません。瞬間的な変動により誤警報が発生します。

要約すれば

可観測性。メトリクス、ログ、トレースを使用して、システムの内部を外部から理解する機能です。 4 つのゴールデンシグナル (遅延、トラフィック、エラー、飽和) は、ほとんどのサービスの健全性を要約します。 AI は、PromQL クエリ、アラームルール、ダッシュボードの作成、および大量のログの要約と異常の検出において非常に強力です。ただし、自分のシステムの履歴に対してアラームのしきい値を検証し、アラームをアクション指向に保ち、ログをマスクせずに共有しないようにするのはユーザーの責任です。

アプリケーションタスク

サービス (またはサンプルサービス) の場合: (1) 「アラームルール生成」テンプレートを使用してエラー率に対するアラームルールを生成し、推奨しきい値を「過去に何回トリガーしたか」に設定します。質問でテストしてください。 (2) 所有するログサンプルをマスクし、「ログの要約」テンプレートを使用して分析します。 (3) 最も可能性の高い根本原因を確認するためにどのメトリクスを確認するかを書き留めます。

チェックリスト

[ ] 4 つのゴールデンシグナルに基づいて追跡するメトリクスを選択しました。
[ ] AI に提供したすべてのログを機密領域に関してマスクしました。
[ ] 各アラームがアクション指向であり、正しい緊急性を持っていることを確認しました。
[ ] システムの履歴データに対してアラームしきい値をテストしました。
[ ] アラームに for (継続時間) を追加することで瞬間的な変動をフィルタリングしました。
[ ] 根本原因にはメトリック + ログ + トレースを併用しました。

監視と可観測性: メトリック、ログ、トレース、アラーム ルール