メトリクス モニター

メトリクスモニターは、アプリケーションとインフラが Status200 に送るメトリクスを照会し、比率や合計が必要なときは数式で組み合わせ、その結果をローリングの時間範囲で条件と比べます。リクエストレート、エラー率、キューの深さ、CPU、メモリー、ディスク（あらゆる数値の系列）に使えます。グループ化すれば、ホストやコンテナーごとに 1 つのアラートを出せます。

しくみ#

Status200 は毎分、モニターの各メトリクスクエリをその時間範囲で実行します。クエリは時間の区切りごとに 1 つのデータポイントを返し、数式はクエリを区切りごとに組み合わせます。そのあと各条件が、チェック対象のクエリまたは数式のデータポイントを 1 つにまとめ（平均、最大、または各ポイントのテスト）、その結果をしきい値と比べます。

始める前に#

• アプリケーションやインフラが OpenTelemetry でメトリクスを Status200 に送っていること。OpenTelemetry を参照してください。
• メトリクスの名前と、フィルターやグループ化に使う属性を把握しておきます。メトリクス と グループ化 のリストには、Status200 が受信済みの名前と属性だけが表示されます。

メトリクスモニターを作成する#

1. 新しいモニターを始める#

   モニター に移動し、モニターを作成 をクリックします。

2. Metrics を選ぶ#

   モニターの種類 で その他のモニターの種類 をクリックし、テレメトリ の下の メトリクス を選ぶか、検索ボックスに metrics と入力します。名前 を入力し、次へ をクリックします。

3. 時間範囲を選ぶ#

   メトリクスモニターの設定 で 時間範囲 を選びます。各評価がどこまでさかのぼるかです。最初は Past 1 Minute です。

4. メトリクスのクエリを追加する#

   メトリクスを選択 で メトリクス と、その 集計の基準 を選びます。属性でフィルターしたり グループ化 したりするには フィルターとグループ化 を開きます。クエリをもう 1 つ追加するには メトリクスを追加 を、組み合わせるには 数式を追加 をクリックします。クエリの下のチャートで時間範囲をプレビューでき、条件がチェックする値を確認できます。

5. 条件を設定する#

   モニター条件 では、各条件がチェックする メトリクス（クエリまたは数式）、その 集計、条件、しきい値 を選びます。新しいモニターが最初に持つ条件は 条件 を参照してください。

6. モニターを作成する#

   モニターを作成 をクリックします。モニターは 概要 ページで開き、1 分以内に最初の評価が行われます。

何を照会するか#

メトリクスのクエリ#

各クエリと数式には、追加した順に変数（a、b、c など）が割り当てられます。

数式#

数式は、クエリの変数を +、-、*、/、%、^ とかっこで、時間区切りごとに組み合わせます。変数は先頭に $ を付けても付けなくても書けます。

• a / b * 100: a が b に占める割合（パーセント）
• a + b: 2 つのメトリクスの合計
• a - b: 両者の差

ローリング時間枠#

時間範囲 は、各評価がどこまでさかのぼるかを決めます: Past 1 Minute、過去 5 分、Past 10 Minutes、過去 15 分、過去 30 分、過去 1 時間、過去 2 時間、過去 3 時間、Past 6 Hours、Past 12 Hours、過去 1 日、過去 2 日、Past 3 Days、Past 7 Days、Past 14 Days、Past 30 Days、Past 60 Days、Past 90 Days、Past 180 Days、Past 365 Days。

範囲が長いほど各時間区切りが広くなり、1 つのデータポイントが表す時間も長くなります。

評価のしくみ#

• 毎分。 メトリクスモニターはプローブでチェックされないため、設定する間隔も プローブと間隔 ページもありません。
• まずクエリ、次に数式。 各クエリは、その 集計の基準 を使って、時間範囲の時間区切りごとに 1 つのデータポイントを返します。数式は、クエリのデータポイントから区切りごとに計算されます。
• そのあと条件の集計。 各条件は、その メトリクス のデータポイントを、しきい値と比べる値にまとめます。

• 条件は上から順に。 Group By のないモニターでは最初に一致した条件で決まるため、最も重大なものを先頭に置きます。グループ化されたモニターは、系列ごとにすべての条件をチェックします（条件の評価が異なる を参照）。
• データがないことはゼロではありません。 時間範囲内にクエリがデータポイントを返さない場合、条件は その他の項目 の データがない場合 設定に従います: Ignore（デフォルト。条件は一致しない）、Treat As Zero、トリガー。
• All Values には時間範囲全体が必要です。 系列が All Values の条件を満たすのは、そのデータポイントが時間範囲の開始から現在までをカバーし、欠けたデータポイントが 1 つを超える空白がない場合だけです。CloudWatch のようにモニターのデータがすべて遅れて届く場合は、最新のデータポイントが現在の代わりになります。データを送り始めたばかりのホスト、コンテナー、Deployment や、しばらく沈黙していたものは、時間範囲全体のデータがそろうまで待ちます。評価ログには、どこまで進んだかが表示されます: Waiting for 15 minutes of data: 2 of 15 minutes so far。アラートやインシデントがすでに開いている系列は、そのデータポイントだけで判定されるため、データの短い空白で解決されることはありません。メトリクスの送信間隔が時間範囲より長い場合、単独のデータポイントは数分たつと範囲全体の値として扱われます。値がどれだけ続いたかを判断するには、時間範囲を送信間隔の 2 倍以上にしてください。
• Status200 自身の停止は沈黙ではありません。 Status200 自身がデータを受信していなかった時間（再起動中、アップグレード中、遅れの取り戻し中）が時間範囲に含まれている間、チェックは待ちます。データがない場合 の設定にかかわらず、ステータスは変わらず、インシデントやアラートが開かれたり解決されたりすることもありません。Status200 がデータを受信していないとき を参照してください。

条件#

これらのモニターは常に Metric Value、つまり設定したメトリクスクエリまたは数式の集計値を評価します。条件のフォームにはフィルタータイプの選択はなく、メトリクス、集計、条件、しきい値 が表示されます。メトリクスに単位がある場合は、しきい値の横で単位を選びます。

異常の条件にはしきい値がありません。代わりにフォームには 感度（Low、デフォルトの Medium、High）と ベースラインウィンドウ（デフォルトの 14 日、28 日、60 日、90 日）が表示され、各データポイントを、そのウィンドウから作った同じ曜日・時間帯のベースラインと比べます。その曜日・時間帯の履歴が十分にたまるまで、条件は学習中でアラートを出しません。

新しいメトリクスモニターは、最初のクエリに対する 2 つの条件から始まります。どちらも集計は Any Value です。

実例: 増えていくキュー#

checkout のキューが深いままのときにインシデントにしたいとします。クエリ a はゲージ checkout.queue.depth で、集計の基準 は最大、時間範囲 は 過去 5 分 です。1 回の評価で、次の 1 分ごとのデータポイント 5 つが見えます。

メトリクス a、条件 より大きい、しきい値 1000 の条件は、集計 ごとに異なる答えを出します。

平均 は持続的な滞留でアラートを出し、1 分だけ深い状態は無視します。All Values は範囲内のすべての分が深くなるまで待ちます。Any Value は最初の深い 1 分でアラートを出します。

系列ごとのアラート（Group By）#

メトリクスクエリの グループ化 は、そのクエリを属性の一意な値ごと（ホストごと、コンテナーごと、マウントポイントごと）の系列に分け、Group By を設定したモニターは各系列を独立して評価します。この 1 つの設定が、「フリート全体が不調」と「prod-db-01 が不調」の違いになります。

グループごとに 1 つのアラート#

Group By を host.name にすると、50 台のホストを監視するディスク使用率モニターは しきい値を超えたホストごとに 1 つのアラート（またはインシデント） を出します。ホスト A がいっぱいになると専用のアラートが開き、10 分後にホスト B がいっぱいになると、その隣に 2 つ目の別のアラートが開きます。

Group By がないと、同じモニターは 1 つのスカラーになります。クエリはすべてのホストを 1 つの数値にまとめ、モニターは モニター全体で 1 つのアラート を出します。そのアラートが開いている間に 2 台目のホストがしきい値を超えても何も起きず（モニターはすでにアラート中で、新しく出すものがないため）、オンコールのエンジニアはホスト B のことを知りません。ホストごとのアラートは Group By の設定で得られます。 ホストごと、コンテナーごと、マウントポイントごとに呼び出されたいなら、設定してください。

独立した解決#

グループごとのアラートは、それぞれ自分のグループを追います。ホスト A がしきい値を下回ると、そのアラートは自動で解決し、ホスト B のアラートはホスト B が回復するまで開いたままです。あるグループの回復で、別のグループのアラートが閉じることはありません。

条件の評価が異なる#

• グループ化されたモニターはすべての条件を評価します。 そのため、重大度の段階が異なるグループで同時に発火することがあります。「Critical: 95 より大きい」を「Warning: 80 より大きい」の上に置くと、同じチェックで 96% のホストは重大なアラートを、85% のホストは警告のアラートを開きます。両方の段階を超えたホストでも受け取るアラートは、最初に一致した条件からのちょうど 1 つです。そのため、条件は最も重大なものから順に並べてください。
• グループ化されていないモニターは、最初に一致した条件で止まります。 発火するのはその条件だけです。これも、アラートの条件を正常な条件より上に置く理由です。広い正常な条件を先頭に置くと、ほぼ毎回のチェックで一致し、その下のアラート条件が評価されることがなくなります。

グループ化する属性の選び方#

誰かを呼び出す理由になる、本当に別個のものを示す属性でグループ化します。フリート全体のホストメトリクスならホストの属性、コンテナーのメトリクスならコンテナーや Pod の属性、ファイルシステムやディスク I/O のメトリクスならマウントポイントやデバイスの属性、ネットワークのメトリクスならインターフェースの属性です。グループ化 のドロップダウンにはコレクターが実際に送っている属性が入るため、キーを手入力するのではなくリストから選んでください。

すでにシステム全体で 1 つのスカラーであるメトリクス（クラスター全体のリーダーフラグ、スケジューラーの滞留、単一ホストのモニターでのそのホストの CPU）はグループ化しないでください。グループ化しても系列はちょうど 1 つで、変わるのはアラートのタイトルだけです。

グループ化の属性の値は、アラートやインシデントのタイトル、説明、修復メモで テンプレート変数 としても使えます。host.name でグループ化すると、タイトルを Disk almost full on {{host.name}} にできます。

トラブルシューティング#

次のステップ#