# アラートFAQ
Nexthink Alertsの検出およびロジックについて:
どのようなアラート検出モードがありますか？
アラートは、以下の検出モードに基づいて重大な問題を検出します:
* **メトリクスの閾値** - 1つ以上のメトリクスの値がユーザー定義の閾値に達したときにアラートをトリガーします。
* **メトリクスの変化** - 現在のメトリクス値が7日間のグローバル平均を超えた変化を示すときにアラートをトリガーします。
* **メトリクスの季節変化** - 現在のメトリクス値が、過去7日間の時間帯の基準値の標準偏差帯を逸脱したときにアラートをトリガーします。
* **グローバル検出**—この機能は組み込みのモニターでのみ使用可能です。指定されたデバイスが他のバージョンや設定よりも劣る特定のバイナリバージョンやバイナリ設定を使用した場合に警告をトリガーします。
[アラートFAQ ](#how-can-i-investigate-and-query-devices-associated-with-an-existing-alert)で、システムが**メトリクスの変化**または**メトリクスの季節変動**検出モードの基準値を計算する方法について学びましょう。
{% hint style="info" %}
**メトリクスの変化**または**メトリクスの季節変化**を使用して、合計5つのカスタムモニターを設定できます。
最大50のモニターを作成できます。
{% endhint %}
アラートをトリガーする方法は何ですか？
Nexthink モニターは、以下の方法のいずれかを使用してアラートをトリガーします:
* **スケジュール**トリガー方法 - カスタムおよび組み込みのモニターに利用可能で、定期的なチェックに使用されます。 モニターは、設定された**スケジュール頻度**によって定義された定期的な間隔でメトリクスを評価します。
* **イベント**トリガー方法 - [組み込みのモニター](https://docs.nexthink.com/platform/ja/user-guide/alerts-and-diagnostics/getting-started-with-alerts#what-built-in-monitors-are-available-in-nexthink)に制限されており、リアルタイムモニタリングと瞬時の問題検出に使用されます。 設定されたモニターの**クエリと条件**に応じて、設定された閾値がどのくらいの期間超過するかを評価し、アラートをトリガーします。
{% hint style="warning" %}
例えば、アラートの[スケジュール頻度](https://docs.nexthink.com/platform/ja/user-guide/alerts-and-diagnostics/managing-alerts/creating-custom-monitors#creatingcustommonitors-definingschedulingfrequencyschdulingfrequency)を**7日**に設定することは、各月の1日から開始し、アラートを毎7日評価することを意味します。
これにより、システムが予想より早くアラートをトリガーする可能性があります。例えば、ある特定の月の28日に1つのアラートが発動され、その後翌月の1日に再びトリガーされるといった具合です。
{% endhint %}
システムは過剰にトリガーされたアラートをどのように処理しますか？
Nexthinkは、同じアラートをトリガーできるオブジェクトの総数を500に制限し、個々のアラートを関連性のあるものに保っています。
1つのモニターが同時に500以上のアラートをトリガーすると、Nexthinkはシステムの氾濫を防ぐためにアラートグループ化メカニズムを作動します。 つまり、モニターは状況が解決されるまで新たなアラートの生成を停止します。そのため、グループ化されたアラートは処理される際に1つのアラートとして扱われます。
このアラートグループ化の動作は、[NQLデータモデル](https://docs.nexthink.com/platform/ja/user-guide/nexthink-query-language-nql/nql-data-model#alert_alert)の`is_grouped`フィールドにより記録されます。
システムはいつアラートを閉じることを決定しますか？
システムは、監視されているメトリクスが定義された条件を破らなくなったときにアラートを閉じます。
* モニターが\_metric threshold\_を追跡する場合、監視されているメトリクスがしきい値を超えなくなったときにシステムはアラートを閉じます。
* モニターが\_metric change\_を追跡する場合、そのメトリック値が基準値まで低下したときにシステムはアラートを閉じます。
評価中にモニタクエリがデータを返さない場合、アラートは次のルールに従って自動的に閉じます：
* 複数のデバイスにわたって集計されたメトリクスを追跡するアラートの場合、3日連続でデータが返されない場合にアラートが閉じます。
* 単一のデバイスまたはユーザーに対してトリガーされたアラートの場合、クエリの `during past` パラメータで指定された期間の間、モニタークエリが連続してデータを返さない場合にアラートが閉じます。
アラートがトリガーまたは閉じられたとき、システムはいつ通知しますか？
システムは、特定のアラートがトリガーまたは閉じられたときに（設定されていれば）通知を送ります。
前の評価でトリガーされたアラートがすでに\_開いている\_状態である場合、今回の評価でもメトリックが検出基準を満たしている限り通知を送りません。
{% hint style="info" %}
アラート通知にどのように対応するかを学ぶには、[アラートへの対応](https://docs.nexthink.com/platform/ja/user-guide/alerts-and-diagnostics/responding-to-alerts)ドキュメントを参照してください。
{% endhint %}
検出方法の基準値を算出するシステムの仕組み: メトリックの変化とメトリックの季節変化
ベースラインの計算はアラート検出モードに依存します：
* **メトリクスの変化**について：基準値は、モニターのクエリによって返される全データポイントの7日間の移動平均（平均値）です。現在の値は、この平均に対して設定したしきい値を用い評価されます。
* **メトリックの季節変化**の場合：ベースラインは時間で分かれたもので、例えば月曜日の10:00～11:00に同じスロットの過去7日間の平均を計算し、標準偏差バンドを使用して乖離を評価します：
* **わずかに**は標準偏差の1倍以内 (±1σ) — 値は±1σ以内です。
* **中程度に**は標準偏差の2倍以内 (±2σ) — 値は±2σ以内です。
* **非常に**は標準偏差の3倍以内 (±3σ) — 値は±3σ以内です。
{% hint style="info" %}
[Nexthinkのアラートの範囲と実用的な使用例について](https://docs.nexthink.com/platform/ja/responding-to-alerts/diagnostics-for-alerted-issues.md#diagnosticsforalertedissues-alerttimeline)タイムラインダッシュボードで計算されたベースラインを視覚化します。
{% endhint %}
**基準データポイントのスケジューリング頻度**
モニターの **スケジュール頻度** は、検出タイプに応じてベースラインに提供されるデータポイントの数を定義します。
* **メトリックの変化**の場合、システムはベースラインを計算するために約20回の評価を用い、モニターはアクティベーション後7日以内にアラートをトリガーする可能性があります。
* **メトリックの季節変化**の場合、システムがアラートをトリガーするためには7日間待機します。 これにより、少なくとも7つのデータポイント（1日ごとに1つ、同じ時間帯のもの）が標準偏差の推定のために利用可能となります。
その後、スケジューリング頻度は検出タイプに応じて変更されます。
* **メトリックの変化**の場合、スケジュール頻度は**15分**から数日にわたります。
* **メトリックの季節変化**の場合、最大スケジュール頻度は**24時間**です。それ以上の頻度だと、過去7日間の同じスロットの平均計算に寄与しません。
* **12時間**のスケジュールでは1日に2つの時間帯があり、それぞれの時間帯では歴史的に7ポイント（1日ごとに1つ）がそのベースラインに用いられます。
***
Nexthink Alertsの範囲と実用的な使用方法について：
いくつのモニターを設定できますか？
**メトリックの変化**または**メトリックの季節変化**検出モードを使用して、合計で5カスタムモニターまで設定可能です。
最大50のモニターを作成することができます。
アラートを使う場面とデータエクスポーターを使う場面の違いは？
即時の支援または行動が必要な問題を発見するために**アラート**を使用します。 迅速な行動を要求しない他のレポートやイベント、例えば\_ディスク空き容量の少ないすべてのデバイスを報告する\_には、[データエクスポーター](https://docs.nexthink.com/platform/ja/configuring_nexthink/bringing-data-into-your-nexthink-instance/integrating-nexthink-with-third-party-tools/outbound-connectors/data-exporters)を使用します。
また、具体的な条件基準をNQLクエリで表現している大量のオブジェクトを報告する場合、または単一のモニターが同時に[500アラート以上をトリガーする](#handling-excessively-triggered-alerts)と期待される場合には**データエクスポーター**を使用します。
さらに、データ エクスポートのスケジュールオプションを使用してデータを定期的にエクスポートします。
数少ないユーザーにしか影響のないメトリクスの急増でアラートをトリガーしないようにするにはどうすればよいですか？
非常に少数のデバイスがアクティブなとき、たとえば週末などにアラートがトリガーされないようにするには、複数のしきい値を使用することが推奨されます。 モニターを作成し、主要な評価対象メトリクスを定義します。 さらに、アクティブユーザーや問題のあるデバイスの数など、より多くのメトリクスを計算し、それらを追加のしきい値として使用します。
既存のアラートに関連するデバイスの調査とクエリ方法は？
[NQL データモデル](https://docs.nexthink.com/platform/ja/understanding-key-data-platform-concepts/nql-data-model) は、特定のユースケースに基づいて、既存のアラートに関連付けられたデバイスを異なるNQLテーブルに保存します。
| アラートユースケース | デバイスデータを格納するNQLテーブル |
| --------------------------------------------------------- | ------------------------------------- |
| 単一デバイスアラートの場合、1つのアラートが1つのデバイスに結びついています。 | `alert.alerts`はデバイス名を格納します。 |
| 複数デバイスのアラートは広範な問題を示しており、1つのアラートが複数のデバイスにリンクされている可能性があります。 | `alert.impacts`は影響を受けたすべてのデバイスを保存します。 |
{% hint style="info" %}
[アラートの概要](https://docs.nexthink.com/platform/ja/user-guide/getting-started-with-alerts#gettingstartedwithalerts-detectissuesimpactingmultipledevices) ドキュメントを参照して、単一または複数のデバイスに影響を与える問題を検出するアラートモニターの設定方法について学んでください。
{% endhint %}
***
Nexthink Alertsのサードパーティツールとの統合について：
ServiceNowのようなITSMシステムを含む様々なツールとアラートを統合するにはどうすればよいですか？
Webhookを使用して、Nexthinkを他のSoftware as a Service (SaaS)アプリケーションと統合します。 詳細については[Webhook ](https://docs.nexthink.com/platform/ja/configuring_nexthink/bringing-data-into-your-nexthink-instance/integrating-nexthink-with-third-party-tools/outbound-connectors/webhooks)のドキュメントを参照してください。
Webhookを通じたNexthink統合におけるセキュリティ対策は？
現時点では、webhookは以下の認証をサポートしています：
* OAuth2 – クライアント資格情報
* OAuth2 – 認可コード
* Basic
* Bearer Token
* 認証なし（None）
これらのセキュリティ方法のいずれかを受け入れる通知を受け取るサードパーティサービスに依存しています。
特定のアプリケーションに関連するアラートが発動された場合、どのようにしてアプリケーションチームのみに通知できますか？
Webhookを使用して、ペイロード、優先度、タグまたはモニター名などのアラート内容に基づき通知を異なる宛先に配信します。
例えば、Salesforceアプリケーションにアラートがトリガーされるたびに、特定のMS Teamsチャンネルに表示する通知を設定するには、次の手順に従います：
1. MS TeamsチャンネルへのWebhookのアウトバウンドコネクタを作成します。 詳細については[Webhookのドキュメント](https://docs.nexthink.com/platform/ja/configuring_nexthink/bringing-data-into-your-nexthink-instance/integrating-nexthink-with-third-party-tools/outbound-connectors/webhooks)を参照してください。
2. アラートがトリガーされた時に該当するMS Teamsチャンネルに通知を送信するモニターを選択します。 Nexthinkは複数のモニターを特定するためにモニター **タグ** を使用することを推奨します。 この例では、アプリケーションアラートをトリガーするすべてのモニターに対して\_web-applications\_タグを使用します。
3. 各アラートには、[アラートペイロード](https://docs.nexthink.com/platform/ja/user-guide/managing-alerts/configuring-email-and-webhook-notifications-for-alerts#configuringemailandwebhooknotificationsforalerts-alertpayloadinthenotification)、この場合は\_Salesforce\_内にアプリケーション名が含まれていることを確認します。
4. 指定されたチャンネルに通知を送信すべきアラートのみを選択するWebhook NQLクエリを書きます。 以下の例を参照してください。
```nql_/apigateway/nql-editor
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ペイロードを作成します。 動的[変数](https://docs.nexthink.com/platform/ja/configuring_nexthink/bringing-data-into-your-nexthink-instance/integrating-nexthink-with-third-party-tools/outbound-connectors/webhooks/managing-webhooks/configuring-webhook-fields_-method-resource-and-payload)を使用して、トリガーされたアラートの詳細情報を送信します。
ServiceNowに閉じられたアラートの通知を送信してチケットを更新できますか？
はい。 アラートシステムは、各アラートに対して2つのメッセージをWebhookに送信します：アラートがトリガーされたときに1つのメッセージ、アラートがクローズされたときに別のメッセージがあります。 ITSMシステムに通知ペイロードで\_alert.status\_を送信して、両方のメッセージに対応します。 アラートUIDは、両方のメッセージに共通するアラートの一意のキーです。 NQLを使用してアラートイベントをクエリする場合、一意のIDごとに1つのアラートイベントのみを取得します。 アラートがクローズされたとき、そのイベントは新しいステータスで更新されます。
最後にログインしたユーザーやエンティティなど、追加のデバイスフィールドを含めてWebhookを介してServiceNowに送信するアラートを追加できますか？
はい。 [特定のデバイスに影響を与える問題を検出する](https://docs.nexthink.com/platform/ja/user-guide/alerts-and-diagnostics/managing-alerts/creating-custom-monitors/detecting-issues-impacting-a-single-device-or-user)モニターを作成し、通知を送信して単一デバイスのITSMチケットを開くためにペイロードにデバイスを含めます。 追加のデバイスプロパティをアラートペイロードに含めないでください。 代わりに、Webhookの作成時にこれらのデバイスプロパティを通知メッセージで使用してください。 サンプルWebhookクエリ：
```nql_/apigateway/nql-editor
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
```