# カスタムモニターの作成

カスタムモニタを作成するには、ナビゲーションパネルの**アラートと診断** > **アラートの管理**から操作します。

1. 画面右上の「**新しいモニター**」ボタンをクリックし、モニター構成を開きます。
2. **一般**タブのフィールドに入力してください。
3. **NQLクエリと条件**タブを定義してください。
   * **トリガー条件**と**スケジューリング頻度**を含めます。
4. プロアクティブアラート管理のために[メールまたはWebhookで通知を設定します](https://docs.nexthink.com/platform/ja/user-guide/alerts-and-diagnostics/managing-alerts/configuring-email-and-webhook-notifications-for-alerts)。

<figure><img src="https://3549141153-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FeLm8O7QKZDn6z806e7Sv%2Fuploads%2Fgit-blob-e20c859aa75e890c47f8ec7073c542ccd75b0037%2Fimage%20(827).png?alt=media" alt=""><figcaption></figcaption></figure>

## 一般的なモニター設定の構成

{% hint style="info" %}
最初からモニターを作成する代わりに、Nexthinkは組み込みモニターをカスタマイズすることを推奨しています。組み込みモニターはカスタムモニターよりも多くの機能を提供します。
{% endhint %}

**新規モニタ**設定ページから**一般**タブのフィールドを以下のように入力します。

<figure><img src="https://3549141153-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FeLm8O7QKZDn6z806e7Sv%2Fuploads%2Fgit-blob-bb75175a387ccb0c6743334fb61c5ee9f27875af%2Fimage%20(825).png?alt=media" alt=""><figcaption></figcaption></figure>

{% hint style="warning" %}
**イベントトリガー**と**グローバル検出**は、組み込みモニター（システムモニター、またはNexthinkライブラリーからインストールされたもの）でのみ利用可能です。
{% endhint %}

* **トリガー:** カスタムモニターは、定期的なチェックに使用される**スケジュール**トリガー方法を提供します。 特定の間隔を[スケジュール頻度](#customizingbuilt-inmonitors-schedulingfrequency)セクションの**クエリと条件**タブで設定します。
* **タイプ**: カスタムモニタは以下の**タイプ**の検出モードを提供します。

<details>

<summary>メトリックのしきい値</summary>

**メトリックのしきい値**は、1つ以上のメトリックの値がユーザー定義のしきい値に達するとアラートをトリガーします。

</details>

<details>

<summary>メトリックの変化</summary>

**メトリックの変更**は、現在のメトリック値が**7日間のグローバル平均**と異なる場合にトリガーされます。詳細は[こちら](https://docs.nexthink.com/platform/ja/user-guide/alerts-faq#how-does-the-system-compute-the-baseline-for-the-detection-methods-metric-change-and-metric-seasonal)を参照してください。

</details>

<details>

<summary>メトリックの季節的変化</summary>

**メトリック季節変動**は、現在のメトリック値が直近7日間の[時刻別基準値](https://docs.nexthink.com/platform/ja/user-guide/alerts-faq#how-does-the-system-compute-the-baseline-for-the-detection-methods-metric-change-and-metric-seasonal)から外れる場合にアラートをトリガーします。これは設定された標準偏差帯に基づいています。

</details>

{% hint style="info" %}
最大5つのカスタムモニターを**メトリックの変化**または**メトリックの季節変動**を使用して構成できます。

最大50個のモニターを作成できます。
{% endhint %}

* **名前**: モニターに意味のある名前をつけてください。 システムはこの名前を使用して通知を送信し、アラート概要ページでモニターを視覚化します。
* **NQL ID**: システムはモニタ**名**から自動的に一意の識別子を生成します。 このモニタをNexthink内でクエリするためにNQL IDを使用します。
  * NQL IDはモニター作成時にのみ編集可能で、`a-z、0-9、_`の文字を使用してください。
  * 削除されたモニターに関連付けられているイベントがシステム内にまだ存在する限り、削除されたモニターで使用されたNQL IDのモニターを作成できません（最大30日）。
* **優先度**: 優先度レベルを設定してください。 デフォルトレベルは中間です。
* **タグ**: モニター用のカスタムタグを作成します。 これにより、**アラート概要**および[Webhook](https://docs.nexthink.com/platform/ja/user-guide/alerts-and-diagnostics/managing-alerts/configuring-email-and-webhook-notifications-for-alerts#configuringemailandwebhooknotificationsforalerts-webhooknotifications)の統合でアラートをフィルタリングすることが可能です。 現在、モニターごとに最大で10個のタグを定義できます。

## カスタムモニタのNQLクエリと条件の定義 <a href="#creatingcustommonitors-definingannqlquery" id="creatingcustommonitors-definingannqlquery"></a>

モニター構成ページから、**クエリと条件** タブに以下の項目を入力します。

必要に応じて、**調査で表示**ボタンをクリックしてクエリ調査結果を表示します。

1. 監視するメトリックを定義するために、**NQLクエリ**を書いてください。 NQLを使用して、次のことが可能です:
   * 1つまたは複数のメトリックを選択します。
   * `where`句を使って範囲を指定します。
   * 時間集計とグループ化のための`by`キーワードを使用して、アラートの粒度を定義します。

{% hint style="warning" %}
システムは、10000を超える結果コンテキスト/グループを計算するNQLクエリ用のエラーメッセージを表示します。
{% endhint %}

これらの場合、各グループは独自の\[ベースライン]\(../../getting-started-with-alerts.md#baseline-computation-depending-on-the-aler t-detection-mode)を必要とするため、粒度を減らし、'by'句を簡素化するかフィルタを追加します。

<details>

<summary>モニタクエリのNQLルールと制限</summary>

モニターをサポートするためには、NQLクエリはいくつかのルールに従う必要があります。

1. モニターのNQLクエリは、計算されたメトリクスまたは集約されたメトリクスを含む必要があります。つまり、すべてのクエリはモニターと互換性のある`compute`または`summarize`句を必要とします。

```
devices
| with device_performance.system_crashes during past 7d 
| compute 
  total_number_of_system_crashes = number_of_system_crashes.sum()
```

```
execution.crashes during past 24h
| summarize total_number_of_crashes = count()
```

2. オプションで、複数の条件を設定してアラートをトリガーするために、クエリに1つ以上の計算または集約されたメトリクスを含めることが可能です。

```
execution.crashes during past 24h
| summarize 
  total_number_of_crashes = count(), 
  devices_with_crashes = device.count()
```

3. 少なくとも1つのメトリクスを使用して監視条件の閾値を設定してください。 元のクエリにメトリクスが含まれていない場合は、追加のメトリクスを作成してください。

モニターと互換性がありません：

```
devices
| with antiviruses
| where is_up_to_date == no
```

モニターと互換性があります：

```
devices
| with antiviruses
| where is_up_to_date == no
| compute device_count = count()
```

4. NQLレベルで評価されたメトリクスに条件を追加しないでください。 代わりに、[トリガー条件](#creatingcustommonitors-definingtriggerconditionstriggercondition)セクションを使用して条件を定義します。

不正解のモニターNQLクエリ：

```
execution.crashes during past 24h
| summarize total_number_of_crashes = count()
| where total_number_of_crashes >= 10
```

条件付き正しいモニターNQLクエリ：

```
execution.crashes during past 24h
| summarize total_number_of_crashes = count()
```

5. `where`句を使用してモニターのスコープを特定の場所、アプリケーション、その他のカテゴリに絞ります。

```
execution.crashes during past 24h
| where binary.name == "excel.exe"
| summarize total_number_of_crashes = count()
```

6. `summarize... by`を使用してアラートコンテキストの適切な粒度を定義します。 以下の例では、バイナリ名ごとに1つのアラートがトリガーされます。

```
execution.crashes during past 24h
| summarize total_number_of_crashes = count() by binary.name
```

複数のデバイスに影響を与える問題の検出については[こちら](https://docs.nexthink.com/platform/ja/user-guide/alerts-and-diagnostics/managing-alerts/creating-custom-monitors/detecting-issues-impacting-multiple-devices)をご覧ください。また、単一のデバイスまたはユーザーへの影響については[こちら](https://docs.nexthink.com/platform/ja/user-guide/alerts-and-diagnostics/managing-alerts/creating-custom-monitors/detecting-issues-impacting-a-single-device-or-user)をご覧ください。

</details>

2. アラートをアクティブにする、**トリガー条件**を定義します。 トリガー条件は、モニターの選択した**検出タイプ**に敏感です。\n条件を絞り込むために、NQLクエリで計算された各メトリックを使用してください。

<details>

<summary><strong>メトリックしきい値</strong>のトリガー条件</summary>

**メトリックしきい値**の検出でのトリガー条件において\*\*、モニターはメトリック値が指定された値より**大きいまたは等しい**、または**小さいまたは等しい**場合にアラートをトリガーします。

すべてのトリガー条件が満たされると、システムはアラートをトリガーします。

<figure><img src="https://3549141153-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FeLm8O7QKZDn6z806e7Sv%2Fuploads%2Fgit-blob-797eb57effd75515b1a565291e344ddb1dfe0802%2Fimage%20(818).png?alt=media" alt=""><figcaption></figcaption></figure>

</details>

<details>

<summary><strong>メトリック変化</strong>のトリガー条件</summary>

**メトリック変化** 検出を持つモニターのための **トリガー条件** ：

* 最初のトリガー条件は偏差ルール—**高い**か**低い**—を表しており、現在のメトリックを[基準値](https://docs.nexthink.com/platform/ja/user-guide/getting-started-with-alerts#baseline-computation-depending-on-the-alert-detection-mode)（7日間の全球平均）と比較しています。
* 追加のトリガー条件は、値が**指定されたしきい値以上またはそれ以下**であるときに、アラートを有効にする条件を定義します。

すべてのトリガー条件が満たされると、システムがアラートをトリガーします。

以下の例では、最初のトリガー条件により、**CPU使用率**の値が過去7日間のメトリック平均の2倍になるとアラートが起動します。

{% hint style="info" %}
これらのトリガー条件は、[スケジュールおよびイベントトリガーモニター](#customizingbuilt-inmonitors-general)の両方に適用されます。
{% endhint %}

<figure><img src="https://3549141153-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FeLm8O7QKZDn6z806e7Sv%2Fuploads%2Fgit-blob-04a53ae6fbd96cce73830c953fa1e0f90b0dc71b%2Fimage%20(813).png?alt=media" alt=""><figcaption></figcaption></figure>

</details>

<details>

<summary><strong>メトリック季節変化</strong>のトリガー条件</summary>

**メトリック季節変動**検出を持つモニターの**トリガー条件**において:

* 最初のトリガー条件は、直近7日間の[時刻別基準値](https://docs.nexthink.com/platform/ja/user-guide/alerts-and-diagnostics/getting-started-with-alerts#baseline-computation-depending-on-the-alert-detection-mode)から計算された感度帯または範囲を設定します。 モニターは、現時点のメトリック値がその時間枠の選択された標準偏差範囲から外れるときにアラートをトリガーします:
  * **わずかに** ＝ 標準偏差1（±1σ）
  * **適度に** = 2倍の標準偏差 (±2σ)
  * **高度に** = 標準偏差の三倍（±3σ）
* 追加のトリガー条件は、値が**指定されたしきい値以上またはそれ以下**であるときに、アラートを有効にする条件を定義します。

すべてのトリガー条件が満たされると、システムはアラートを発します。

以下の例では、最初のトリガー条件は、**接続の失敗率**が基準値から2標準偏差（±2σ）帯域外の場合にアラートを作動させます。

<figure><img src="https://3549141153-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FeLm8O7QKZDn6z806e7Sv%2Fuploads%2Fgit-blob-aa1777e02a042de4853564ec4d183b7afba9df23%2Fimage%20(815).png?alt=media" alt=""><figcaption></figcaption></figure>

</details>

2. モニターの**スケジューリング頻度**を設定して、システムがトリガー条件を評価する頻度を決定します。
   * 可能なタイムフレームは15分、1時間、3時間、6時間、12時間、24時間、48時間、そして7日です。 これらのタイムフレームは、モニター[NQLクエリ](#how-does-the-nql-query-affect-the-available-scheduling-timeframes)内（`過去`句）、および構成済みの検出方法に依存します：
     * **メトリックの変化**については、スケジューリング頻度は**15分**から数日にわたります。
     * **メトリックの季節変動**の場合、最大スケジューリング頻度は**24時間**です。1日以上の頻度では同じスロットの平均を過去7日間で計算することには寄与しません。

{% hint style="warning" %}
アラートの**スケジューリング頻度**を、例えば**7日**に設定すると、モニターは月の1日から7日ごとにアラートを評価します。

これによりシステムが予想より早くアラートを発する可能性があります。特定の月の28日に1つのアラートが、翌月の1日に再び発されることがあります。
{% endhint %}

<details>

<summary><strong>NQLクエリ</strong> は利用可能なスケジューリングタイムフレームにどのように影響しますか？</summary>

**スケジューリング頻度**のタイムフレームの可用性は、`過去`句およびモニター**NQLクエリ**に定義されたイベントに依存します。

モニタークエリの設定により利用可能なスケジューリング頻度がどのように決定されるかを理解するために、次の例を参照してください：

<table><thead><tr><th width="428">過去の監視イベント</th><th>最小頻度</th><th>最大頻度</th></tr></thead><tbody><tr><td><pre class="language-nql_/apigateway/nql-editor"><code class="lang-nql_/apigateway/nql-editor">device_performance.boots during past 24h
</code></pre></td><td>15分</td><td>7日間</td></tr><tr><td><pre class="language-nql_/apigateway/nql-editor"><code class="lang-nql_/apigateway/nql-editor">device_performance.boots during past 7d
</code></pre></td><td>24時間</td><td>7日間</td></tr><tr><td><pre class="language-nql_/apigateway/nql-editor"><code class="lang-nql_/apigateway/nql-editor">session.events during past 1h
</code></pre></td><td>15分</td><td>7日間</td></tr><tr><td><pre class="language-nql_/apigateway/nql-editor"><code class="lang-nql_/apigateway/nql-editor">session.events during past 24h
</code></pre></td><td>12時間</td><td>7日間</td></tr><tr><td><pre class="language-nql_/apigateway/nql-editor"><code class="lang-nql_/apigateway/nql-editor">execution.events during past 1h
</code></pre></td><td>15分</td><td>7日間</td></tr><tr><td><pre class="language-nql_/apigateway/nql-editor"><code class="lang-nql_/apigateway/nql-editor">execution.events during past 24h
</code></pre></td><td>12時間</td><td>7日間</td></tr><tr><td><pre class="language-nql_/apigateway/nql-editor"><code class="lang-nql_/apigateway/nql-editor">execution.events during past 7d
</code></pre></td><td>7日間</td><td>7日間</td></tr><tr><td><pre><code>session.vdi_events during past 1h
</code></pre></td><td>15分</td><td>7日間</td></tr><tr><td><pre><code>session.vdi_events during past 7d
</code></pre></td><td>24時間</td><td>7日間</td></tr></tbody></table>

</details>

4. アラートの**自動復旧**オプションを選択してください。 多くのアラートシナリオでは、**トリガー条件**が標準化されているため、モニターが**72時間**の回復期間を延長する必要がありません。
   * このような場合、モニターの最初の評価で無活動によるデータが返されなかった場合は、**直ちに**アラートを回復します。
   * 逆に、たとえば週末の休暇に対応するために**72時間**待つことを決定し、この無活動期間中にアラートを開いたままにすることもできます。」

***

## 仮想デスクトップ（VDI）のカスタムモニター作成 <a href="#creatingcustommonitors-importingacustommonitor" id="creatingcustommonitors-importingacustommonitor"></a>

{% hint style="warning" %}
内蔵のNexthink Library VDIモニターをアラートに使用するには、[Nexthink VDIエクスペリエンス](https://docs.nexthink.com/platform/ja/user-guide/vdi-experience)が必要です。
{% endhint %}

仮想デスクトップ（VDI）用の組み込みモニターは、[一部のカスタマイズ](https://docs.nexthink.com/platform/ja/library-packs/it-operations/vdi-essentials/configuration-guide-vdi-essentials)が可能な標準機能を提供しますが、特定の組織ニーズに応じてカスタムVDIモニターを作成することもできます。

カスタムVDIモニターを作成する際は、次の点を考慮してください：

* カスタムVDIモニターでは、最小粒度**15分**の**スケジュール**トリガーのみが利用可能です。
* **クエリと条件**でVDI関連のNQLテーブルおよびフィールドを使用します。 以下のクエリ例では、デスクトッププールごとに平均ネットワーク遅延を計算します。
  * 必要に応じて、プール内の平均レイテンシーが閾値を超えたときにアラートを作動させるトリガー条件を追加できます。たとえば、50ミリ秒です。

```
session.vdi_events during past 15min
| where session.vdi_event.network_rtt != null
| summarize average_network_latency = network_rtt.avg(), 
total_number_of_sessions = vdi_session.count() by vdi_session.desktop_pool
```

***

関連トピック

* [複数のデバイスに影響を及ぼす問題の検出](https://docs.nexthink.com/platform/ja/user-guide/alerts-and-diagnostics/managing-alerts/creating-custom-monitors/detecting-issues-impacting-multiple-devices)
* [単一のデバイスまたはユーザーに影響を及ぼす問題の検出](https://docs.nexthink.com/platform/ja/user-guide/alerts-and-diagnostics/managing-alerts/creating-custom-monitors/detecting-issues-impacting-a-single-device-or-user)
* [Nexthink Library](https://docs.nexthink.com/platform/ja/user-guide/nexthink-library)
* [製品の構成](https://docs.nexthink.com/platform/ja/user-guide/administration/system-configuration/product-configuration)