ネットワークデータモニタリング¶
本ドキュメントの位置づけ
本書は、モニタリングルール設定フローの第2ステップです。設定が完了したら、メインドキュメントに戻り第3ステップ：イベント通知に進んでください。
ワークスペース内のネットワークパフォーマンスメトリクスを監視し、ユーザーがしきい値範囲を設定し、メトリクスがこれらのしきい値を超えた場合にアラートをトリガーできるようにします。個々のメトリクスにアラートルールを設定し、アラートの重大度レベルをカスタマイズできます。
データ範囲：データソースが netflow、httpflow のメトリクスデータをサポートします。
ネットワークレベルの主要なパフォーマンス指標を監視するのに適しています。例：
- ホストのデータソースが
netflowのTCP接続数、再送信回数、レイテンシーなどのネットワーク層メトリクスを監視 - データソースが
httpflowのリクエスト数、エラー数、エラー率、応答時間などのアプリケーション層メトリクスを監視
モニタリング設定¶
モニタリング頻度¶
モニタリングを実行する時間間隔を設定します。
-
プリセットオプション：1分、5分（デフォルト）、15分、30分、1時間、6時間、12時間、24時間
-
Crontabモード：「Crontabモードに切り替える」をクリックすると、カスタム間隔を設定できます。秒、分、時、日、月、週などの単位でスケジュールされたタスクの実行を設定できます。
モニタリング範囲¶
各モニタリングでクエリするデータの時間範囲を設定します（❗️モニタリング範囲はモニタリング頻度以上に設定し、実際のデータ報告間隔と一致させる必要があります。そうしないと、モニタリングの漏れや誤報が発生する可能性があります）。
| モニタリング頻度 | モニタリング範囲（ドロップダウン） |
|---|---|
| 30s | 1m/5m/15m/30m/1h/3h |
| 1m | 1m/5m/15m/30m/1h/3h |
| 5m | 5m/15m/30m/1h/3h |
| 15m | 15m/30m/1h/3h/6h |
| 30m | 30m/1h/3h/6h |
| 1h | 1h/3h/6h/12h/24h |
| 6h | 6h/12h/24h |
| 12h | 12h/24h |
| 24h | 24h |
- カスタム形式：モニタリング範囲をカスタム入力できます。例：20m（過去20分）、2h（過去2時間）、1d（過去1日）。
モニタリングメトリクス¶
モニタリングするメトリクスを設定します。ワークスペース内の全サービスまたは特定のサービスリストから、一定期間のメトリクスデータを設定できます（❗️高カーディナリティフィールドをモニタリングディメンションとして選択しないでください。設定が不適切でトリガー条件が緩すぎると、頻繁なアラートが発生する可能性があります。現在のクエリの最大返却レコード数は10万件です）。
設定項目¶
| 設定項目 | 説明 |
|---|---|
| データソース | 選択可能： • netflow：ネットワークトラフィックデータ（TCP層メトリクス）• httpflow：HTTPトラフィックデータ（アプリケーション層メトリクス） |
| メトリクス | 選択したデータソースに基づいて対応するメトリクスを表示： netflow メトリクス： • 送信バイト数 • 受信バイト数 • TCP レイテンシー • TCP ジッター • TCP 接続数 • TCP 再送回数 • TCP クローズ数 httpflow メトリクス： • リクエスト数 • エラー数 • エラー率 • 平均応答時間 • P99 応答時間 • P95 応答時間 • P75 応答時間 • P50 応答時間 |
| フィルター条件 | メトリクスのタグに基づいてモニタリングメトリクスのデータをフィルタリングし、モニタリングのデータ範囲を制限します。1つ以上のタグフィルターを追加可能。あいまい一致およびあいまい不一致のフィルター条件をサポートします。 |
| モニタリングディメンション | 設定データ内の対応する文字列型（keyword）フィールドをモニタリングディメンションとして選択できます。現在、最大3つのフィールドを選択できます。複数のモニタリングディメンションのフィールドを組み合わせることで、特定のモニタリング対象を決定します。システムは、モニタリング対象に対応する統計メトリクスがトリガー条件のしきい値を満たしているかどうかを判断し、条件を満たした場合にイベントを生成します。（例：モニタリングディメンションとして host と host_ip を選択した場合、モニタリング対象は {host: host1, host_ip: 127.0.0.1} のようになります。） |
トリガー条件¶
トリガー条件と重大度を設定します。クエリ結果が複数の値である場合、いずれかの値がトリガー条件を満たすとイベントが生成されます。
致命的、重大、重要、警告の4段階のしきい値と、正常（回復）条件の設定をサポートします。
| レベル | 設定 | 説明 |
|---|---|---|
| 致命的 | Result >= [値] の場合 |
最高レベルのアラート。即時対応が必要 |
| 重大 | Result >= [値] の場合 |
高レベルのアラート。優先的な対応が必要 |
| 重要 | Result >= [値] の場合 |
中レベルのアラート。注意が必要 |
| 警告 | Result >= [値] の場合 |
低レベルのアラート。留意が必要 |
| 正常（回復） | [N] 回のモニタリングでイベントが発生しない場合 |
モニタリングルールが有効になった後、設定されたカスタムモニタリング回数内にデータモニタリング結果が異常（致命的、重大、重要、警告）から正常に回復した場合、回復アラートイベントがトリガーされます。 ❗️ 回復アラートイベントはアラートミュートの影響を受けません。回復アラートイベントのモニタリング回数が設定されていない場合、アラートイベントは回復せず、イベント > 未復旧イベント一覧に残り続けます |
詳細については、イベントレベルについてを参照してください。
詳細オプション¶
連続トリガー判定¶
有効にすると、トリガー条件が継続的に満たされた場合にのみイベントが生成され、一時的な変動による誤報を防ぎます（❗️最大設定上限は10回です）。
大量アラート保護¶
デフォルトで有効です。
1回のモニタリングで生成されるアラート数が事前設定されたしきい値を超えると、システムは自動的にステータスごとの集約戦略に切り替わります：アラート対象を個別に処理するのではなく、イベントステータスに基づいて少数のサマリーアラートを生成し、プッシュします。
これにより、通知の即時性を確保しつつ、アラートノイズを大幅に削減し、過剰なアラート処理によるタイムアウトのリスクを回避できます。
このスイッチが有効な場合、後続のモニターが異常を検出して生成したイベント詳細には、履歴レコードや関連イベントは表示されません。
データ欠落¶
モニタリングメトリクスのクエリ結果がモニタリング範囲内で空の場合の処理戦略：
| オプション | 説明 |
|---|---|
| イベントをトリガーしない（デフォルト） | モニタリング範囲の時間枠に連動し、指定された最近の分数におけるモニタリングメトリクスのクエリ結果に基づいて、イベントを生成するかどうかを判断します。データ欠落が許容されるシナリオに適しています。 |
| クエリ結果を0とみなす | モニタリング範囲の時間枠に連動し、指定された最近の分数におけるモニタリングメトリクスのクエリ結果を0とみなし、上記のトリガー条件で設定されたしきい値と再度比較して、異常イベントをトリガーするかどうかを判断します。 |
| カスタム値を設定してイベントをトリガー | モニタリング範囲の値をカスタム設定し、以下のイベントタイプを個別にトリガーできます：データ欠落イベント、致命的イベント、重大イベント、重要イベント、警告イベント、回復イベント。 ❗️この戦略を選択する場合、カスタムデータ欠落時間の設定は ≥ モニタリング範囲の間隔 にすることを推奨します。設定時間 ≤ モニタリング範囲の間隔の場合、データ欠落と異常が同時に発生する可能性があります。その場合、データ欠落の処理結果が優先的に適用されます。 |
トリガー条件、データ欠落、情報生成を同時に設定する場合、トリガーの優先順位は次のようになります：データ欠落 > トリガー条件 > 情報イベント生成。
つまり、最初にデータ欠落の有無を判断し、次にしきい値トリガーの有無を判断し、最後に情報イベントを生成するかどうかを判断します。
情報生成¶
このオプションを有効にすると、情報生成条件を設定する必要があります。モニタリング結果が「致命的」「重大」「重要」「警告」のいずれのしきい値もトリガーせず、かつ情報生成条件を満たす場合にのみ、システムは「情報」イベントを書き込みます。
正常な状態変化や低優先度の情報を記録する必要があるシナリオに適しています。
後続の設定¶
上記のモニタリング設定が完了したら、以下の設定を続けて行ってください：