しきい値警告がトリガーされる条件の指定

アラート・エディターで、 「メトリック」&「条件」 セクションで以下を指定します。

有効範囲

アラートは、デフォルトでチーム・スコープの 「インフラストラクチャー全体」 に適用されるように設定されています。 ただし、 container_name や kube_namespace_name などの特定のラベルでフィルタリングすることによって、アラート範囲を制限することができます。

メトリック

モニターするメトリックを選択し、どのようにデータを集約するかを構成します。 その後、ニーズに最も適した集計方法を選択できます。 例えば、クラスター全体の平均待ち時間を把握したい場合は、平均集約を使用できます。 あるいは、待ち時間が最も長いノードを識別する場合は、最大集約を使用できます。

セグメント別にグループ化

container_name などのラベルでメトリックをグループ化することにより、コンテナーごとに固有のセグメントが生成されます。 これにより、特定のコンテナーがパフォーマンス低下の原因となっているかどうかを素早く検出できます。

時間集計

警告ルールの時間集約は、選択したメトリックが集約される時間ウィンドウを決定する。 例えば、 cassandra_read_latency メトリックに対して、範囲を指定して avg 集計を選択すると、その時間ウィンドウの cassandra_read_latency メトリックの平均値が計算される。 この範囲は、メトリック値が時間集計のためにどの程度過去に遡って考慮されるかを定義する。

Duration

Durationは、アラートをトリガーする前にアラート条件が継続的に満たされなければならない時間を定義します。 例えば、継続時間が 10mというのは、10分間継続的に条件を満たさなければならないことを意味する。 この期間内に警告条件が満たされなかった場合、10分間タイマーはリセットされ、再び10分間、完全に、中断することなく、警告条件を満たさなければならない。 期間を長く設定することで、短時間のしきい値違反でアラートがトリガーされるのを防ぎ、誤検知を減らすことができる。

時間集約と持続時間

アラートクエリの時間集約は、関連するメトリックデータが評価される期間を定義する。 これは、アラートがトリガーされる前にアラート条件が満たされなければならない時間の長さを意味するアラートルールのDurationと混同してはならない。

しきい値

アラート条件を評価するためのしきい値と時刻範囲を定義します。

しきい値アラート通知の画像

SlackまたはEメールに転送される閾値アラート通知には、トリガーとなった時系列データのスナップショットが含まれます。 Slack 通知チャネルの場合、通知チャネル設定内でスナップショットを有効または無効にすることができます。 チャネルが *「解決時に通知」*に構成されている場合、アラートを解決する時系列データのスナップショットも通知で提供されます。

複数のしきい値の構成

アラートしきい値に加えて、警告しきい値を構成できます。 警告しきい値およびアラートしきい値は、さまざまな通知チャネルに関連付けることができます。 以下の例では、ユーザーは警告およびアラート通知を Slack に送信することができますが、アラートしきい値が満たされている場合は、Pager義務についてオンコール・チームのページを作成することもできます。

警告しきい値とアラートしきい値の両方が同じ通知チャネルに関連付けられている場合、アラートしきい値をすぐに超えるメトリックは警告しきい値を無視し、アラートしきい値のみをトリガーします。

メトリック・データがない場合のアラート

メトリックがデータの報告を停止すると、それらのメトリックを使用するアラートは評価できません。 これがいつ発生するかを確実に認識するために、 「設定」 セクションの 「データなし」 オプションを「無視」または「通知」に構成することで、 「データなし」 について通知するようにアラートを構成できます。

アラート構成の PromQL への変換

PromQLの柔軟性と能力を活用するために、フォームから PromQL に自動的に変換できます。 「 PromQL」 オプションを使用すると、複雑な照会を構成できます。

例えば、以下の照会は、ホスト上の使用可能メモリーのパーセンテージを調べます。

sysdig_host_memory_available_bytes / sysdig_host_memory_total_bytes * 100

しきい値は照会とは別個に構成されるため、ユーザーはアラートしきい値と警告しきい値の両方を指定できます。