Prometheus メトリクスが設定されたしきい値を超えたり、異常なパターンを示したりした場合、タイムリーに通知することでインシデントの拡大を防ぐことができます。ARMS の Prometheus アラートルールを使用すると、プリセットされたメトリクスを選択するか、カスタム PromQL 文を記述することによって、任意のメトリクスに条件を定義し、テキストメッセージ、メール、電話、DingTalk チャットボット、WeCom チャットボット、または Webhook を通じてチームに通知を送信できます。
前提条件
Prometheus に接続されています。詳細については、次をご参照ください。
エントリ
にログインします。 Prometheusコンソールのマネージドサービス。
左側のナビゲーションペインで、アラートルールリスト をクリックします。
Prometheus アラートルール ページで、Prometheus アラートルールの作成 をクリックします。
静的しきい値に基づくPrometheus アラートルールの作成
静的しきい値のチェックタイプでは、定義済みのアラートメトリクスを使用できます。これらのメトリクスを選択することで、迅速にアラートルールを作成できます。
Prometheus アラートルールの作成 ページで、次のアラートパラメーターを設定します。
パラメーター
説明
例
アラート名
アラートの名前。
prod-cluster-container-cpu-alert
チェックタイプ
[静的しきい値] を選択します。
静的しきい値
Prometheus インスタンス
アラートを作成するPrometheus インスタンスを選択します。
Production Cluster
アラートグループ
アラートグループを選択します。
Prometheus のタイプによってサポートされるアラートグループは異なります。選択可能なアラートグループのオプションは、選択したPrometheus インスタンスのタイプに基づいて異なります。
Kubernetes Workloads
アラートメトリクス
アラートを設定するメトリクスを選択します。各アラートグループは異なるメトリクスに対応しています。
Container CPU utilization
アラート条件
事前定義されたアラートメトリクスに基づいて、アラートをトリガーする条件を設定します。
コンテナの CPU 使用率が
greater than80% の場合にアラート条件が満たされます。フィルター条件
アラートメトリクスに基づいてアラートルールの範囲を定義します。フィルター条件に一致するいずれかのリソースでアラートルールが満たされた場合に、アラートがトリガーされます。
次のフィルター条件を使用できます。
[トラバーサル]:アラートルールは、現在の Prometheus インスタンス内のすべてのリソースに適用されます。走査はデフォルトのフィルター条件です。
[等しい]:この条件を選択した後、特定のリソース名を入力します。アラートルールはそのリソースにのみ適用されます。複数のリソース名を入力することはできません。
[次の値に等しくない:]:この条件を選択した後、特定のリソース名を入力します。アラートルールは指定されたリソースを除くすべてのリソースに適用されます。複数のリソース名を入力することはできません。
[正規表現に一致]:この条件を選択した後、必要に応じてリソース名を照合するための正規表現を入力します。アラートルールは正規表現に一致するすべてのリソースに適用されます。
[正規表現と一致しない]:この条件を選択した後、必要に応じてリソース名を照合するための正規表現を入力します。アラートルールは正規表現に一致するすべてのリソースを除外します。
説明フィルター条件を設定すると、データプレビュー エリアが表示されます。
フィルター条件は 300 文字を超えることはできません。
走査
データプレビュー
データプレビュー エリアには、アラート条件に対応する Prometheus クエリ言語 (PromQL) 文が表示されます。また、監視メトリクスの値を時系列曲線で表示します。
デフォルトでは、1つのリソースのリアルタイム値のみが表示されます。このエリアのフィルターボックスでターゲットリソースと時間範囲を選択すると、異なるリソースと時間範囲の値を表示できます。
説明アラートのしきい値は、時系列曲線上に赤い実線として表示されます。しきい値を超えた部分は濃い赤色で、超えていない部分は青色で表示されます。
時系列曲線にカーソルを合わせると、特定の時点でのリソースの詳細を表示できます。
時系列曲線で時間範囲を選択すると、その期間の曲線を表示できます。
なし
継続期間
アラート条件が満たされた場合、アラートは即時にトリガーされます。いずれかのデータポイントがしきい値に達すると、アラートがトリガーされます。
アラート条件が N 分間継続した場合にのみアラートがトリガーされます。しきい値に達した状態が N 分以上続いた場合に、アラートがトリガーされます。
秒単位での継続期間の設定はサポートされていません。これは製品の仕様です。
1
アラートレベル
アラートレベルをカスタマイズします。デフォルトのアラートレベルはDefault です。重要度は Default、P4、P3、P2、P1 の順に高くなります。
Default
アラート内容
ユーザーが受信するアラート通知の内容です。Goテンプレート構文を使用して、アラート内容のパラメーター変数をカスタマイズできます。
Namespace: {{$labels.namespace}} / Pod: {{$labels.pod_name}} / Container: {{$labels.container}} CPU utilization {{$labels.metrics_params_opt_label_value}} {{$labels.metrics_params_value}}%, Current value: {{ printf "%.2f" $value }}%
アラート通知
[シンプルモード]:Notification Receiver、[Notification Period]、繰り返しポリシー を設定できます。
[通常モード]:
通知ポリシーを指定しない:このオプションを選択した場合、アラートルールを作成した後、通知ポリシー ページで新しい通知ポリシーを作成し、アラートルール名などの一致条件を指定して、アラートルールを関連付けることができます。アラートルールがトリガーされてアラートが生成されると、アラート情報は通知ポリシーで指定された連絡先または連絡先グループに送信されます。詳細については、「通知ポリシー」をご参照ください。
通知ポリシーを指定する:このオプションを選択すると、ARMS は対応する通知ポリシーに一致ルールを自動的に追加します。一致ルールの内容はアラートルール ID で、アラートルール名として表示されます。これにより、現在のアラートルールによって生成されたアラートが、選択された通知ポリシーに一致することが保証されます。
重要通知ポリシーをここで指定しても、現在のアラートルールからのアラートがそのポリシーに一致し、対応するアラートが生成されることが保証されるだけです。ただし、現在のアラートルールからのアラートは、あいまい一致で設定された他の通知ポリシーにも一致する可能性があり、その結果アラートが生成されることがあります。アラートと通知ポリシーは多対多の関係です。
通知ルールを指定しない
[詳細設定]
アラートチェック間隔
システムがアラートルールをチェックし、データがアラート条件を満たしているか判断する間隔です。デフォルトは 1 分、最小は 1 分です。15 秒など、1 分未満の値を入力した場合でも、システムは 1 分ごとにチェックを実行します。これは製品の仕様です。
1
データが完全になった後にチェック
はい
いいえ
はい
タグ
アラートにタグを設定します。タグは通知ポリシーの一致条件として使用できます。
なし
アノテーション
アラートにアノテーションを設定します。
なし
保存 をクリックします。 Prometheus アラートルール一覧ページで、作成したアラートルールのステータスを確認できます。
アラートルールのStatus が自動的に中断する の場合は、ルールを編集して中断の原因を解決してください。その後、起動 をクリックし、表示されるダイアログボックスでConfirm をクリックします。問題が解決しない場合は、DingTalk (ID: d9j_rg9e4062f) でARMS アラート機能チームにお問い合わせください。
アラートルールが自動的に中断される主な理由は次のとおりです。
ルールクエリが 1,500 件を超える結果を返しました。
アラート管理システムに通知受信者が設定されていません。
Prometheus インスタンスがアンインストールされたか、利用できません。
カスタム PromQL クエリを使用した Prometheus アラートルールの作成
事前に設定された静的しきい値ではカバーされないメトリクスを監視するには、カスタム Prometheus クエリ言語 (PromQL) クエリを使用してアラートルールを作成します。
Prometheus アラートルールの作成 ページで、次のアラートパラメーターを設定します。
パラメーター
説明
例
アラート名
アラートの名前。
Pod CPU usage is greater than 8%
チェックタイプ
[カスタム PromQL クエリ] に設定します。
カスタム PromQL クエリ
Prometheus インスタンス
アラートを作成するPrometheus インスタンスを選択します。
なし
参照アラートグループ
アラートグループを選択します。
Prometheus のタイプによってサポートされるアラートグループは異なります。選択可能なアラートグループのオプションは、選択したPrometheus インスタンスのタイプに基づいて異なります。
Kubernetes Workload
参照アラートメトリクス
オプション。一般的なメトリクス用のカスタム PromQL 設定が参照用として提供されています。類似のメトリクスを選択して各フィールドに値を事前入力し、必要に応じて設定を変更できます。
[参照アラートメトリクス] パラメーターでは、選択されたPrometheus インスタンスタイプに基づいて、サポートされているアラートメトリクスが自動的にフィルタリングされます。
Pod disk usage alert
カスタム PromQL 文
PromQL 文を使用して、アラートルールの式を設定します。
max(container_fs_usage_bytes{pod!="", namespace!="arms-prom",namespace!="monitoring"}) by (pod_name, namespace, device)/max(container_fs_limit_bytes{pod!=""}) by (pod_name,namespace, device) * 100 > 90
データプレビュー
データプレビュー エリアには、アラート条件に対応する Prometheus クエリ言語 (PromQL) 文が表示されます。また、監視メトリクスの値を時系列曲線で表示します。
デフォルトでは、1つのリソースのリアルタイム値のみが表示されます。このエリアのフィルターボックスでターゲットリソースと時間範囲を選択すると、異なるリソースと時間範囲の値を表示できます。
説明時系列曲線にマウスカーソルを合わせると、特定のデータポイントのリソース詳細を表示できます。
グラフ上で時間範囲を選択すると、その期間の時系列を表示できます。
なし
継続期間
いずれかのデータポイントがしきい値に達すると、アラートは即時にトリガーされます。
条件が N 分間継続した場合にのみアラートがトリガーされます。
秒単位での継続期間の設定はサポートされていません。これは製品の仕様です。
1
アラートレベル
アラートレベルをカスタマイズします。デフォルトのアラートレベルはDefault です。重要度は Default、P4、P3、P2、P1 の順に高くなります。
Default
アラート内容
ユーザーが受信するアラート通知の内容です。Goテンプレート構文を使用して、アラート内容のパラメーター変数をカスタマイズできます。
以下の例は、Pod の再起動アラートのテンプレートです。これにより、読みやすい通知内容を設定するのに役立ちます。
Namespace: {{$labels.namespace}}/Pod: {{$labels.pod_name}} restarted more than {{ $labels.metrics_params_value}} times in {{$labels.metrics_params_time}} minutes. Current restarts: {{ $value }}
Namespace: {{$labels.namespace}}/Pod: {{$labels.pod_name}}/Disk device: {{$labels.device}} usage exceeds 90%, current value {{ printf "%.2f" $value }}%
アラート通知
[シンプルモード]:Notification Receiver、[Notification Period]、繰り返しポリシー を設定できます。
[通常モード]:
通知ポリシーを指定しない:このオプションを選択した場合、アラートルールを作成した後、通知ポリシー ページで新しい通知ポリシーを作成し、アラートルール名などの一致条件を指定して、アラートルールを関連付けることができます。アラートルールがトリガーされてアラートが生成されると、アラート情報は通知ポリシーで指定された連絡先または連絡先グループに送信されます。詳細については、「通知ポリシー」をご参照ください。
通知ポリシーを指定する:このオプションを選択すると、ARMS は対応する通知ポリシーに一致ルールを自動的に追加します。一致ルールの内容はアラートルール ID で、アラートルール名として表示されます。これにより、現在のアラートルールによって生成されたアラートが、選択された通知ポリシーに一致することが保証されます。
重要通知ポリシーをここで指定しても、現在のアラートルールからのアラートがそのポリシーに一致し、対応するアラートが生成されることが保証されるだけです。ただし、現在のアラートルールからのアラートは、あいまい一致で設定された他の通知ポリシーにも一致する可能性があり、その結果アラートが生成されることがあります。アラートと通知ポリシーは多対多の関係です。
通知ルールを指定しない
詳細設定
アラートチェック間隔
アラートルールをチェックする間隔 (分) です。最小値は 1 分です。15 秒など、1 分未満の値を入力した場合でも、システムは 1 分ごとにチェックを実行します。これは製品の仕様です。
1
データが完全になった後にチェック
はい
いいえ
はい
タグ
アラートにタグを設定します。タグは通知ポリシーの一致条件として使用できます。
なし
アノテーション
アラートにアノテーションを設定します。
なし
パラメーターを設定した後、保存 をクリックします。 Prometheus アラートルール一覧ページで、アラートルールのステータスを確認できます。
アラートルールのStatus が自動的に中断する の場合は、表示された理由に基づいてルールを再度編集してください。その後、起動 をクリックし、表示されるダイアログボックスでOK をクリックします。中断が解決しない場合は、ARMS アラート機能サービスアカウント (d9j_rg9e4062f) にお問い合わせください。
アラートルールが自動的に中断される主な理由は次のとおりです。
ルールクエリが 1,500 件を超える結果を返しました。
アラート管理システムに通知受信者が設定されていません。
Prometheus インスタンスがアンインストールされたか、利用できません。
アラートルールの管理
Managed Service for Prometheus コンソールの [Alerting Rules] ページで作成されたアラート (静的しきい値アラートやカスタム Prometheus クエリ言語 (PromQL) アラートなど) については、編集、有効化 (停止中のアラート)、無効化 (実行中のアラート)、削除、コピー、イベント履歴の表示が可能です。
他の Alibaba Cloud 製品のコンソールで生成されたアラートについては、アラートイベント履歴の表示や、対応する製品のアラート一覧への移動が可能です。
アラートルールを変更した後、既存の未解決のアラートは、以前のルールに基づいて引き続きトリガーされます。新しいルールは、[Alert Sending History] ページで対応する未解決のイベントを要求して解決した後にのみ、以降のアラートに適用されます。
よくある質問
アラートの回復通知が遅れるのはなぜですか?
システムには、エージェントの報告遅延による偽陰性を防ぐための遅延が組み込まれています。各チェック中に、アラートエンジンは過去 10 分間のデータを確認します。アラートは、メトリクスがアラート条件を満たさなくなった後でも、この時間枠が経過した後にのみ回復したと見なされます。
回復時間:回復通知は、メトリクスがアラートをトリガーしなくなってから約 10 分後に送信されます。
メカニズムの詳細:Prometheus 自体には自動回復機能はなく、ARMS の検出メカニズムによって実現されています。
アラートルールテンプレートを適用した後に通知ポリシーが失われた場合はどうすればよいですか?
原因:アラートルールテンプレートには通知ポリシー設定が含まれていません。テンプレートを再適用すると、ルール ID が変更される可能性があります。これにより、元の通知ポリシーは_aliyun_arms_alert_rule_id ラベルと一致しなくなり、機能しなくなります。
解決策: に移動し、影響を受けるポリシーを見つけます。[Dispatch Conditions] セクションで、ルール ID を使用する代わりに、alertname やクラスター名 cluster などのより安定したラベルを使用して、ルールを再設定します。
アラート式を変更しても重複したアラートを受信し続ける場合はどうすればよいですか?
原因:通知ポリシーが「N 分ごとに再通知」かつ「手動で解決」に設定されている場合、メトリクスが新しい式の条件を満たしている限り、システムは新しいアラートを生成し続けます。
解決策:通知ポリシーを変更してください。繰り返し通知の設定を「初回のみ通知」に変更するか、モードを「自動で解決」に切り替えます。また、新しい式が保存され、有効になっていることを確認してください。
データがない、または設定後にトリガーされない Prometheus アラートルールのトラブルシューティング
以下の手順に従って調査してください。
コンポーネントの確認:ACK クラスターに kube-state-metrics コンポーネントがインストールされていることを確認します。インストールされていない場合は、インストールします。Prometheus コンポーネントのステータスを確認します。必要に応じて、ack-arms-prometheus コンポーネントを再インストールします。
トリガー履歴の確認:ルールの横にある[Alert History] をクリックして、トリガー履歴を確認します。履歴がない場合は、ルールの条件が満たされていなかったことを示します。考えられる原因には、メトリクス名が正しくない、データが空である、クエリの時間範囲が無効である、などがあります。履歴は存在するが通知が送信されなかった場合は、通知ポリシーの振り分け条件を確認してください。ラベル、クラスター名、およびその他の条件が振り分け条件の基準と一致していることを確認してください。
推奨事項:最新の Alibaba Cloud 検証済みアラートテンプレートの使用を推奨します。これにより、古いテンプレートで発生する可能性のある誤検知やトリガーされないアラートを防ぐことができます。
構文の確認:ページエラーが表示された場合は、PromQL クエリの正規表現を確認してください。空の式 (
{pvc=~}など) は無効であり、エラーの原因となります。{pvc=~".*"}または特定の値に修正してください。
ACS クラスターでの Prometheus モニタリングによる Pod メモリアラートに料金はかかりますか?
はい。ACS クラスターは Pod のメモリメトリクスの監視とアラートに対応しています。テキストメッセージと音声通話によるアラート通知は有料です。DingTalk チャットボットと Webhook による通知は無料です。