Alerts FAQ

ServiceNowなどのITSMシステムを含むさまざまなツールとアラートを統合するにはどうしたらよいですか？

Webhookを使用して、Nexthinkを他のSoftware as a Service (SaaS)アプリケーションと統合します。 Webhookのドキュメントを参照して詳細を確認してください。

セキュリティ上の目的で統合を確認する必要があります。 Webhookを介したNexthink統合にはどのようなセキュリティ対策がありますか？

現時点では、webhookは以下の認証をサポートしています：

• OAuth2 – クライアント資格情報

• OAuth2 – 認可コード

• Basic

• Bearer Token

• 認証なし（None）

これらのセキュリティ方法のいずれかを受け入れる通知を受け取るサードパーティサービスに依存しています。

特定のアプリケーションでトリガーされたアラートに関する通知を、それぞれのアプリケーションチームにのみ送るにはどうすればよいですか？

Webhookを使用して、ペイロード、優先度、タグ、またはモニター名など、アラートの内容に基づいて異なる宛先に通知を配信します。

例えば、Salesforceアプリケーションにアラートがトリガーされるたびに、特定のMS Teamsチャンネルに表示する通知を設定するには、次の手順に従います：

1. MS TeamsチャンネルへのWebhookのアウトバウンドコネクタを作成します。 Webhookのドキュメントを参照して詳細を確認してください。

2. アラートがトリガーされた時に該当するMS Teamsチャンネルに通知を送信するモニターを選択します。 Nexthinkは複数のモニターを特定するためにモニター タグ を使用することを推奨します。 この例では、アプリケーションアラートをトリガーするすべてのモニターに対して_web-applications_タグを使用します。

3. 各アラートにはアプリケーション名（この場合は_Salesforce_）をアラートペイロードに含めてください。

4. 指定されたチャンネルに通知を送信すべきアラートのみを選択するWebhook NQLクエリを書きます。 以下の例を参照してください。

   alert.alerts
   | where monitor.tags contains "web-applications"
   | where alert.context contains "*Salesforce*"
   | list alert.monitor.name, alert.status, monitor.tags, alert.context, 
          trigger_time, recovery_time, alert.monitor.thresholds, 
          monitor.priority, alert.trigger_values, 
          alert.trigger_reference_value, alert.recovery_values

5. システムが通知メッセージとして送信するWebhookペイロードを作成します。 トリガーされたアラートの詳細を送信するために動的変数を使用します。

クローズされたアラートに関する通知をServiceNowに送信してチケットを更新することはできますか？

はい。 アラートシステムは、各アラートに対して2つのメッセージをWebhookに送信します：アラートがトリガーされたときに1つのメッセージ、アラートがクローズされたときに別のメッセージがあります。 ITSMシステムに通知ペイロードで_alert.status_を送信して、両方のメッセージに対応します。 アラートUIDは、両方のメッセージに共通するアラートの一意のキーです。 NQLを使用してアラートイベントをクエリする場合、一意のIDごとに1つのアラートイベントのみを取得します。 アラートがクローズされたとき、そのイベントは新しいステータスで更新されます。

WebHookを介してServiceNowに送信されるアラートに、最後にログインしたユーザーやエンティティなどの追加のデバイスフィールドを含めることはできますか？

はい。 特定のデバイスに影響を与える問題を検出するモニターを作成し、通知を送信して単一デバイスのITSMチケットを開くためにペイロードにデバイスを含めます。 追加のデバイスプロパティをアラートペイロードに含めないでください。 代わりに、Webhookの作成時にこれらのデバイスプロパティを通知メッセージで使用してください。 例のWebhookクエリ：

alert.alerts
| where monitor.tags contains "device"
| list alert.monitor.name, alert.status, alert.uid, 
       trigger_time, recovery_time, device.Entity, 
       device.hardware.type, device.login.last_login_user_name

少数のユーザーのみが影響を受けた場合に、メトリクスのスパイクによってアラートがトリガーされることを防ぐにはどうすればよいですか？

非常に少数のデバイスがアクティブなとき、たとえば週末などにアラートがトリガーされないようにするには、複数のしきい値を使用することが推奨されます。 モニターを作成し、主要な評価対象メトリクスを定義します。 さらに、アクティブユーザーの数や問題を抱えるデバイスの数などの追加メトリクスを計算し、それらを追加のしきい値として使用します。

既存のアラートに関連付けられたデバイスを調査し、クエリする方法を教えてください。

NQLデータモデルは、特定のユースケースに基づいて、異なるNQLテーブルに既存のアラートに関連するデバイスを格納します。

アラートユースケース	デバイスデータを格納するNQLテーブル
単一デバイスアラートの場合、1つのアラートが1つのデバイスに結びついています。	alert.alertsはデバイス名を格納します。
複数デバイスのアラートは広範な問題を示しており、1つのアラートが複数のデバイスにリンクされている可能性があります。	alert.impactsは影響を受けたすべてのデバイスを保存します。

アラートの概要 ドキュメントを参照して、単一または複数のデバイスに影響を与える問題を検出するアラートモニターの設定方法について学んでください。