Application Real-Time Monitoring Service:アラート管理に関するよくある質問

Managed Service for Prometheus のアラート機能の旧バージョンと新バージョンの違い

バージョンは、アラートルールテンプレートとアラート管理サブサービスの 2 つの領域で異なります。

アラートルールテンプレート：新バージョンでは、Alibaba Cloud によって検証されたアラートルールテンプレートを使用します。旧バージョンでは、Alibaba Cloud の検証を受けていないオープンソーステンプレートを使用します。

[アラート管理]：新バージョンのみがアラート管理サブサービスを含みます。アラートルールがトリガーされると、アラートイベントはアラート管理に流れ込み、そこで受信する通知を制御します。

アラート管理は、次の 3 つの方法でアラート機能のワークフローを改善します。

• アラートと通知の構成の分離：アラートルールでトリガー条件のみを定義します。配信を制御するために、通知ポリシーを個別にアタッチします。

• きめ細かなルーティング：Container Service for Kubernetes (ACK) 名前空間などの特定の基準によってアラート通知をルーティングします。

• 再利用可能なポリシー：ルールごとに通知方法を構成する代わりに、1 つの通知ポリシーを複数のアラートルールにバインドします。

通知ポリシーでディスパッチルールを使用して、アラートを適切なユーザーグループにルーティングします。一般的な構成は次のとおりです。

• インフラストラクチャの運用と保守 (O&M)：本番クラスターのリソース使用量と ACK コンポーネント障害に関するアラートをサブスクライブします。ディスパッチルール：

  • ルール 1：alertName == CPU utilization of nodes higher than 80% & clusterName == Production cluster

  • ルール 2：alertname == ApiServer Failures & clusterName == Production cluster

• 決済サービスの運用と保守 (O&M)：本番クラスターの pay および pay-pre 名前空間からのアラートをサブスクライブします。ディスパッチルール：namespace Regex match pay.* & clustername == Production cluster

• P1 レベルの通知: 本番クラスターから発生する重大レベルのアラートをすべて購読します。配信ルール: severity == critial & clustername == Production cluster

以前の通知ポリシーから引き続き通知が届くのはなぜですか?

以前の通知ポリシーのディスパッチルールがアラートと引き続き一致するため、通知が送信され続けます。確認するには：

1. 受信したアラート通知の [通知ポリシー] フィールドをメモします。詳細については、「履歴アラートの表示」をご参照ください。

2. ARMS コンソールで、その通知ポリシーを見つけ、そのディスパッチルールがアラートと一致するかどうかを確認します。詳細については、「通知ポリシーの作成と管理」をご参照ください。

ルールが一致する場合は、これらの通知を停止するために更新または削除します。

不要なアラートの通知が届くのはなぜですか?

通知ポリシーは、意図せずとも、ディスパッチルールに一致するすべてのアラートに対して通知を送信します。原因を特定するには：

1. 不要な通知の [通知ポリシー] フィールドをメモします。詳細については、「履歴アラートの表示」をご参照ください。

2. ARMS コンソールで、その通知ポリシーを見つけ、そのディスパッチルールを確認します。詳細については、「通知ポリシーの作成と管理」をご参照ください。

ルールが広すぎる場合は、不要なアラートを除外するように絞り込みます。

通知ポリシーに _aliyun_arms_alert_rule_id が表示されるのはなぜですか?

アラートルール作成時に通知ポリシーを指定すると、システムは自動的に _aliyun_arms_alert_rule_id == {{Alert rule ID}} をそのポリシーのディスパッチルールとして追加します。これにより、アラートルールが通知ポリシーにリンクされます。

アラートルールに通知ポリシーを指定しなくても通知が届くのはなぜですか?

アラートルールで通知ポリシーを指定しているかどうかにかかわらず、すべてのアラートはアラート管理サブサービスに送信されます。アラートが既存の通知ポリシーのディスパッチルールに一致する場合、そのポリシーは通知を送信します。

通知ポリシーの優先度は同じですか?

はい。すべての通知ポリシーは同じ優先度を持ちます。アラートが複数のポリシーのディスパッチルールに一致する場合、一致する各ポリシーは独立して独自の通知を送信します。

ディスパッチルール間の論理関係

通知ポリシー内のディスパッチルールは、次の 2 つの論理演算子を使用します。

例：通知ポリシーにルール A (条件 C1 と C2 を含む) とルール B があります。アラートがルール A またはルール B のいずれかに一致する場合、通知がトリガーされます。ルール A が一致するには、アラートが C1 と C2 の両方を満たす必要があります。

アラートルール作成時に通知ポリシーを指定すべきですか?

ご利用のユースケースによって異なります。

誤検知アラートが生成されるのはなぜですか?

次の誤検知アラートは、古いアラートルールテンプレートの無効な構成によって引き起こされます。

• ノードの CPU 使用率が 8,000% を超える

• Pod のステータスが異常

• Pod の起動中にタイムアウト

アラート管理サブサービスは、更新されたテンプレートをリリースしました。これらのアラートを修正するには、ルールを移行します。

1. 古いテンプレートから作成されたアラートルールを削除します。

2. 更新されたテンプレートを使用してアラートルールを再作成します。

アラートルール管理手順については、関連するモニタリングサービスのドキュメントをご参照ください。

アラート管理と Alertmanager の関係

オープンソース Prometheus では、アラートは Alertmanager に送信され、ディスパッチと通知には手動構成が必要です。Managed Service for Prometheus では、アラート管理サブサービスは Alibaba Cloud によってホストされるマルチテナント Alertmanager として機能します。アラートは自動的にアラート管理にルーティングされ、処理されます。このサービスは、オープンソース Alertmanager のコア機能をサポートしています。

自己管理の Alertmanager インスタンスへのアラートの送信はサポートされていません。 代替策として、Alert Management は Webhook を使用して、Alertmanager フォーマットでアラート通知を転送できます。 詳細については、「Webhook を使用して送信されるアラート通知のフォーマット」をご参照ください。

アラート通知に設定していない「新しいイベント」メッセージが含まれるのはなぜですか?

アラート管理は、アラートイベントをラベルでグループ化し、イベントグループごとに 1 つの通知を送信します。新しいイベントが既存のグループに参加すると、アラート管理は、グループが更新されたことを示す New event メッセージを含む別の通知を送信します。

DingTalk アラートカードのコンテンツを変更するにはどうすればよいですか?

DingTalk アラートカードには、アラートコンテンツ (通知テンプレートによって制御) とカードスタイル (チャットボットによって制御) の 2 つの部分があります。