カスタムアラートソースを ARMS に接続して集中モニタリング - Application Real-Time Monitoring Service - Alibaba Cloud - Application Real-Time Monitoring Service

ステップ1：カスタムインテグレーションの作成

ARMS コンソールにログインします。左側のナビゲーションウィンドウで、[アラート管理] > [統合] を選択します。
アラート統合 タブで、カスタム統合 をクリックします。
カスタムイベント統合の作成 ダイアログボックスで、インテグレーション名を入力し、アラートの自動回復時間を設定し、必要に応じて説明を追加してから、保存と設定 をクリックします。

説明
指定された期間内にアラートイベントが再度トリガーされない場合、アラートイベントは自動的にクリアされます。

ステップ2：API エンドポイントの設定

提供された API エンドポイント URL を使用して、サードパーティのソースから ARMS のアラート管理にアラートを送信します。

統合の編集 ページの インターフェイスの設定 セクションで、エンドポイント URL と API キーをコピーします。

サードパーティのアラートソースから、エンドポイント URL を使用してアラート内容を報告します。

例：

curl -k -H "Content-Type: application/json" -d '{
  "trigger-type": "network",
  "trigger-location": "cn-hangzhou",
  "trigger-severity": "MAX",
  "trigger-policy": "package errors > 5%",
  "trigger-event": "inbound tcp package errors is 20%",
  "trigger-check": "tcp package error percentage",
  "trigger-value": "20",
  "trigger-time": "1629702922000",
  "metadata": [
    {
      "agent": "SERVER",
      "ip": "141.219.XX.XX",
      "fqdn": "websrv1.damenport.org",
      "microServiceId": "ms-login-2251",
      "accountId": "1504000433993",
      "service": "login-0"
    },
    {
      "agent": "CONTAINER",
      "ip": "172.1.XX.XX",
      "fqdn": "websrv2.damenport.org",
      "microServiceId": "ms-login-2252",
      "accountId": "129930302939",
      "service": "login-1"
    }
  ],
  "equipments": [
    {
      "equipmentId": "112"
    },
    {
      "equipmentId": "113"
    }
  ]
}' "https://alerts.aliyuncs.com/api/v1/integrations/custom/ymQBN******"

初めて curl コマンドを実行すると、次のエラーが返されます：

{ "requestId":null,"traceId":"0bc3b4a********71e4aa7","code":601,"data":{},"success":false,"errorCode":"Invalid incident, labels.alertname is required","message":"Invalid incident, labels.alertname is required","httpStatusCode":601,"errorCodeParams":null,"dynamicMessage":null

ステップ 3 でマッピングを完了し、コマンドを再度実行すると、正しいデータが返されます。

テストデータを送信してアラートを報告することもできます。初めてこれを行うと、ステップ 3 でマッピングを完了するように促すメッセージが表示されます。

[Send Test Data] ポップアップウィンドウで、初めて [Send] をクリックすると、ページに 「Upload successful, but no event was generated. Please configure event mapping rules based on the raw data!」 というメッセージが表示されます。このプロンプトに従って、ステップ 3 でマッピングを完了してください。

ステップ3：イベントマッピングの設定

イベントマッピング セクションで、サードパーティのアラートソースのフィールドを ARMS のアラートイベントのフィールドにマッピングします。

このセクションでは、例を用いてプロセスを説明します。

シナリオ：マシンネットワーク上で TCP パケットエラーが発生しました。

サードパーティのアラート内容：

{
  "trigger-type": "network",    // イベントタイプ： network。
  "trigger-location": "cn-hangzhou",    // イベントが発生したリージョン。
  "trigger-severity": "MAX",    // カスタムイベントの重要度レベル。例：MAX、MID、MIN。
  "trigger-policy": "package errors > 5%",     // トリガーポリシー。
  "trigger-event": "inbound tcp package errors is 20%",    // イベント内容：サービスのインバウンド TCP パケットエラー率が 20% です。
  "trigger-check": "tcp package error percentage",    // イベントチェック項目： TCP パケットエラー率。
  "trigger-value": "20",    // アラートのサンプル値。
  "trigger-time": "1629702922000",    // アラートの開始時間。
  "metadata": [
    {
      "agent": "SERVER",    // エージェントタイプ： サーバー。
      "ip": "141.219.XX.XX",   // IPアドレス。
      "fqdn": "websrv1.damenport.org",    // サービスドメイン名情報。
      "microServiceId": "ms-login-2251",    // マイクロサービス ID。'agent' が 'CONTAINER' の場合、このフィールドは条件付きで ARMS の 'service' フィールドにマッピングされます。
      "accountId": "1504000433993",    // ユーザーID。アラート通知には含まれません。
      "service": "login-0" // サービス ID。'agent' が 'SERVER' の場合、このフィールドは条件付きで ARMS の 'service' フィールドにマッピングされます。
    },
    {
      "agent": "CONTAINER",   // エージェントタイプ： コンテナー。
      "ip": "172.1.XX.XX",  // IPアドレス。
      "fqdn": "websrv2.damenport.org",    // サービスドメイン名情報。
      "microServiceId": "ms-login-2252",   // マイクロサービス ID。'agent' が 'CONTAINER' の場合、このフィールドは条件付きで ARMS の 'service' フィールドにマッピングされます。
      "accountId": "129930302939",  // ユーザーID。アラート通知には含まれません。
      "service": "login-1"    // サービス ID。'agent' が 'SERVER' の場合、このフィールドは条件付きで ARMS の 'service' フィールドにマッピングされます。
    }
  ],
  "equipments": [  // 別の配列ノード。
    {
      "equipmentId": "112"
    },
    {
      "equipmentId": "113"
    }
  ]
}

[イベントマッピング] セクションで、[テストデータを送信] をクリックします。
テストデータの送信 ダイアログボックスで、サードパーティソースからのアラート内容を JSON 形式で入力し、送信をクリックします。
説明
- [アップロードされました。イベントは生成されません。元のデータに基づいてマッピングを設定してください。] というメッセージが表示された場合、アラートソースのフィールドは ARMS アラートイベントのフィールドにマッピングされていません。送信されたデータは左側のボックスに表示されます。これにより、マッピングを設定するときにソースフィールドを選択できます。
- [アップロードされました。] というメッセージが表示された場合、アラート内容はアラートイベント履歴ページに報告されます。詳細については、「履歴アラートイベントを表示する」をご参照ください。
[テストデータの送信] ダイアログボックスで、[無効化] をクリックします。
[イベントマッピング] セクションの左側で、マッピングを設定するデータレコードをクリックして詳細を表示します。

イベントマッピング セクションの右側のペインで、アラートソースのフィールドと ARMS のアラートフィールド間のマッピングを設定します。

説明

アラートが解決された後に回復通知や回復メールを受信しない場合は、以下を確認してください：

回復イベントと元のアラートイベントが同じカスタムインテグレーションチャネルを通じて送信されていることを確認してください。
元のアラートがまだ [Triggered] 状態であること、つまりタイムアウトによる自動回復や手動でのクローズが行われていないことを確認してください。
回復イベントの alertname の値が、元のアラートの alertname の値と完全に一致していることを確認してください。

オプション：ルートノードの選択 セクションで、バッチ処理を使用するかどうかを指定します。
アラートデータに配列が含まれている場合、それをバッチ処理のルートノードとして指定できます。
[Use Batch Processing] を選択した後、バッチで処理したい配列ノードをルートノードとして選択してください。

説明アラートデータに複数の配列ノードが含まれている場合、ARMS のアラート管理ではバッチ処理用に 1 つの配列ノードしか選択できません。

たとえば、サンプルアラートでは、metadata 配列ノードに 2 つの service フィールドが含まれています。metadata をルートノードとして選択すると、このノードの下にある 2 つの service フィールドは、同じ ARMS のアラートフィールドにマッピングされます。
- ルートノードを選択した場合、配列内のすべての要素の $.metadata[*].service 属性の値を、ARMS の service フィールドにマッピングできます。
- ルートノードを選択しない場合、特定の要素の値、たとえば $.metadata[0].service や $.metadata[1].service を、ARMS の service フィールドにマッピングできます。
オプション:[アラートリカバリイベントを設定] を選択し、アラートをクリアするためのフィールド条件を設定します。
ARMS はイベントを受信した後、指定されたフィールド値を含むアラートを検索し、これらのアラートをクリアします。アラートをクリアするために指定するフィールドは、イベントのアラート重大度に相当するフィールドである必要があります。$.severity フィールドを使用してアラートをクリアすることはできません。たとえば、アラートをクリアするために指定するフィールドが {$.eventType ="resolved"} の場合、システムは連携で eventType の値が resolved であるすべてのアラートを自動的にクリアします。

ソースフィールドからターゲットフィールドへのマッピング セクションで、アラートソースのフィールドを ARMS のアラートフィールドにマッピングします。

マッピングアイコンをクリックして、フィールドのマッピング方式を変更できます。

Direct：指定されたアラートソースのフィールドが、対応する ARMS アラートフィールドに直接マッピングされます。
Series：複数のソースフィールドを区切り文字で区切って 1 つに結合し、その結果を ARMS アラートフィールドにマッピングします。区切り文字として使用できるのは特殊文字のみです。
たとえば、アンダースコア (_) を使用して $.trigger-type フィールドと $.trigger-policy フィールドを $.trigger-type_$.trigger-policy のように連結し、その結果を ARMS の alertname フィールドにマッピングできます。
Condition：指定された条件が満たされた場合にのみ、ソースフィールドをターゲットの ARMS フィールドにマッピングします。
たとえば、metadata 配列ノードの agent フィールドに対して、次の条件を設定できます：agent の値が CONTAINER の場合、microServiceId 属性の値を ARMS の service フィールドにマッピングします (If 条件)。agent の値が SERVER の場合、service 属性の値を ARMS の service フィールドにマッピングします (Else If 条件)。
マッピングテーブル：アラートソースのアラートの重要度レベルと ARMS の重要度レベルとの間のマッピングを設定します。マッピングテーブルは、severity フィールドにのみ必要です。

次の表に、ARMS のアラートフィールドを示します。

パラメーター	説明	マッピング方式の例	ソースフィールドの例
alertname	カスタムアラート名。	Series	`$.trigger-type`、`$.trigger-policy`
severity	アラートの重要度レベルをマッピングするフィールド。マッピングテーブルの設定は必須で、マッピング方式は Direct に設定する必要があります。	方式： Direct (必須) マッピングテーブル： MAX: P1 MID: P2 MIN: P3	`$.trigger-severity`
message	アラートイベントの詳細情報。通知で使用されます。最大長： 15,000 文字。	Direct	`$.trigger-event`
value	メトリックのサンプル値。	Direct	`$.trigger-value`
imageUrl	メトリックの折れ線グラフの URL。Grafana のメトリックグラフをマッピングするために使用されます。	なし	なし
check	アラートのチェック項目。例： CPU、JVM、アプリケーションクラッシュ、デプロイメント。	Direct	`$.trigger-check`
source	アラートイベントのソース。	Direct	`$.metadata[*].ip`
class	アラートイベントのオブジェクトタイプ (ホストなど)。	Direct	`$.trigger-type`
service	ビジネス関連のソースサービス (logService など)。	Condition	`$.metadata[].agent` が CONTAINER の場合、`$.metadata[].microServiceId` を ARMS の `service` フィールドにマッピングします。 `$.metadata[].agent` が SERVER の場合、`$.metadata[].service` を ARMS の `service` フィールドにマッピングします。
startat	イベントの開始タイムスタンプ。	Direct	`$.trigger-time`
endat	イベントの終了タイムスタンプ。	なし	なし
generatorUrl	イベント詳細の URL。	なし	なし

説明

複数条件アラートモード (単一のアラートルールに複数の条件が含まれるモード) を使用していて、アラート数の予測が 0 と表示されたり、グラフにデータの異常が表示されたりする場合は、フィールドマッピングを確認してください。alertname と severity の両方のフィールドが正しくマッピングされ、イベントラベルが完全であることを確認してください。複数条件アラートモードでマッピングが不完全または不正確だと、アラート数の予測が 0 になったり、グラフデータが正しく表示されなくなったりすることがあります。

ステップ4：イベントの重複排除の設定

冗長なデータを削減するため、システムは指定されたフィールドをイベントの重複排除の基準として使用します。ARMS のアラート管理では、イベントマッピング セクションの履歴イベントデータに対する重複排除のグルーピング結果をプレビューできます。必要に応じて重複排除フィールドを調整できます。

説明

クリアされていないイベントに対してのみ重複排除を設定できます。

イベントの重複除去 セクションで、重複排除に使用するフィールドを選択します。
複数のイベントで選択したフィールドの値が同じ場合、それらは単一のアラート通知にマージされます。
たとえば、ARMS の source フィールドと check フィールドを重複排除キーとして設定したとします。このシナリオ例では、サードパーティのアラートソースの $.metadata[*].ip フィールドが ARMS の source フィールドにマッピングされ、$.trigger-check フィールドが ARMS の check フィールドにマッピングされます。その結果、同じ IP アドレスとチェック項目を持つイベントは単一のイベントにマージされ、IP アドレスまたはチェック項目が異なるイベントは別々のままになります。
重複排除テスト をクリックして、重複排除後のアラートグループをプレビューします。

説明重複排除テストは、イベントマッピング セクションの左ペインにアップロードされた直近 10 件のテストデータレコードに適用されます。
[Select fields for deduplication] エリアで source と check を選択し、[Deduplication Test] をクリックします。テスト結果は、選択したフィールドによってグループ化されます。たとえば、イベントは異なるソース IP アドレス (141.219.xxx と 172.1.xxx) と同じチェック項目 (tcp package error percentage) に基づいて 2 つのグループに分割されます。各グループ内のアラートイベントは、source フィールドと check フィールドの値が同じです。
設定が完了したら、保存をクリックします。

結果

設定が完了すると、統合ページに作成したカスタムインテグレーションが表示されます。このリストには、カスタムインテグレーションの名前、エンドポイント URL、タイプ、作成時間、ステータスなどの情報が表示されます。エンドポイント URL の横にある [Copy] をクリックしてコピーできます。[Actions] 列には、[Edit]、[Delete]、[Disable] などの操作が用意されています。

インテグレーションの管理

左側のナビゲーションウィンドウで、[アラート管理] > [統合] を選択します。[アラート統合] タブで、作成した統合に対して次の操作を実行できます。

統合の詳細を表示する: 統合を見つけて、行をクリックします。[統合の詳細] ページで、統合の詳細を表示します。
キーを更新する：対象のインテグレーションの操作列で、詳細 > キーの更新 を選択します。表示されるダイアログボックスで、確認をクリックします。
重要キーを更新した後は、ステップ 2 で説明されているように、アラートソースのエンドポイント URL も更新する必要があります。
統合を変更する: 統合を見つけて、[アクション] 列の [編集] をクリックします。[統合の詳細] ページで、統合情報を変更し、[保存] をクリックします。
統合を有効または無効にする: 統合を見つけて、[アクション] 列の [無効化] または [有効化] をクリックします。
統合を削除する: 統合を見つけて、[アクション] 列の [削除] をクリックします。表示されるメッセージで、[OK] をクリックします。
統合にイベント処理フローを追加する: 統合を見つけて、[アクション] 列の [イベント処理フローを追加] をクリックします。詳細については、「イベント処理フローを操作する」をご参照ください。
通知ポリシーを作成する: 通知ポリシーを作成する統合を見つけて、[アクション] 列の [詳細] をクリックします。表示されるリストで、[通知ポリシーを作成] をクリックします。詳細については、「通知ポリシーを作成および管理する」をご参照ください。

Application Real-Time Monitoring Service:カスタムアラートのインテグレーション

ステップ1：カスタムインテグレーションの作成

ステップ2：API エンドポイントの設定

ステップ3：イベントマッピングの設定

ステップ4：イベントの重複排除の設定

結果

インテグレーションの管理

次のステップ