モニター内部原理¶

ネットワークやシステム負荷などの要因により、モニターの検出実行にはいくつかの特別な内部処理メカニズムがあります。

検出トリガー時間¶

ユーザーが設定した検出頻度は、システム内部で Crontab 式に変換されます。モニターはこの式に従って厳密にスケジュール起動され、作成または保存後に単純に N 分ごとに実行されるわけではありません。

たとえば、ユーザーが「モニター A」の実行頻度を「5 分」に設定した場合、対応する Crontab 式は */5 * * * * となります。具体的なトリガー時間の関係は次のとおりです。

データ待機ウィンドウ¶

データ待機ウィンドウは、計画実行時間に達した後、能動的にモニター判断を遅延させ、遅延して報告されたデータが取り込みを完了するための時間を確保するために使用されます。

モニターが 10:00 に実行予定で、検出区間が直近の 1 時間、データ待機ウィンドウが 5 分の場合を仮定します。

データ待機ウィンドウは実際の実行時間のみを遅らせ、クエリ範囲は計画実行時間を基準としたまま、全体が後方にシフトすることはありません。待機中、実行記録の状態は「データ待機中」と表示されます。タスクのキューイングの影響で、実際の実行時間が「計画実行時間 + 待機時間」より遅れた場合でも、タスクは実行され、実行記録には計画実行時間、待機設定、実際の開始時間が保持されます。

注意点：

• デフォルトでは待機しません。既存のモニターも待機なしで実行されます。
• 待機時間は、隣接する 2 回の計画実行時間の間隔よりも短くなければなりません。
• 待機中にモニターが無効化または削除された場合、まだ実行されていない待機タスクはキャンセルされます。

検出範囲の調整¶

プラットフォームはすべてのユーザーが設定した数千のモニターを処理する必要があるため、同じ時刻にトリガーされた検出タスクを同時に実行することはできず、ほとんどのタスクはキューに入って待機します。

したがって、ほとんどの検出タスクは、T 時刻にトリガーされる予定だが、実際には T + Δt 時刻に実行されるという状況に遭遇します。

実際の実行時間をクエリの終了時刻として直接使用すると、検出時間範囲に重複やギャップが生じます。例：

検出時間範囲を 5 分と仮定します。

この場合：

• 「アクション 1」と「アクション 2」の検出範囲は 00:05:05 ~ 00:05:10 で重複します。
• 「アクション 2」と「アクション 3」の検出範囲は 00:10:05 ~ 00:10:30 でギャップが生じ、この時間帯のデータがカバーされません。

現在の解決策¶

タスクのキューイングによる検出範囲の変動を避けるため、モニターのデータクエリ範囲は、実際の実行時間ではなく、計画トリガー時間を基準に調整されます。

検出時間範囲を 5 分と仮定します。

これにより、検出タスクがどれだけキューイングされても、データクエリ範囲は常に計画トリガー時間に基づいており、時間ウィンドウの連続性と安定性が保証されます。

検出範囲のドリフト¶

ネットワーク遅延やデータ処理などの要因により、データが報告されてから通常数秒から数十秒かけてディスクに書き込まれ（つまり DQL でクエリ可能になります）、完了します。この間、モニターの検出はこれらの「途中」データをクエリできません。

これにより、固定時間範囲で検出する際にデータ欠落が発生しやすくなります。例：

検出時間範囲を 5 分と仮定します。

データ A は 2 回目の検出実行前に報告されていましたが、初回の検出時には書き込まれていなかったため見落とされました。書き込まれた後も、そのタイムスタンプが古いため、後続の検出の時間範囲内になく、継続的に検出されません。

現在の解決策¶

この問題を解決するために、すべてのモニターは検出実行時に、データクエリ範囲を過去方向に 1 分ドリフトさせ、データ書き込み中の空白期間を回避します。

この方式を適用すると、上記の例は次のようになります。

検出時間範囲を 5 分と仮定します。

データ A は 00:10:00 の検出では見落とされましたが、そのタイムスタンプ 00:09:59 は 00:15:00 の検出範囲（00:09:00 ~ 00:14:00）に含まれるため、2 回目の検出で正常に捕捉されます。

データ欠落判定ロジック¶

Guance は時系列データプラットフォームであり、従来の資産管理ソフトウェアのような「資産マスターリスト」の概念はありません。システムはクエリされたデータに基づいて「存在する」ものを判断できるだけであり、「本来存在するはずだが現在存在しない」オブジェクトを認識することはできません。

例を挙げると、箱の中に鉛筆と消しゴムがあることがわかっています。「箱の中に鉛筆と消しゴムが存在する」とは明確に言えますが、「箱の中にペンは存在しない」とは断言できません。なぜなら、箱に「本来」何があるべきかわからないからです。

したがって、モニターの「データ欠落検出」は、実際には「エッジトリガー」メカニズムを使用して判断を行います。つまり、連続する 2 回のクエリ結果を比較して変化を検出します。

その中核ロジックは、「前回の検出でオブジェクト X が存在したが、今回の検出でオブジェクト X が消失した場合、X にデータ欠落が発生したと判定する」というものです。

検出時間範囲を 5 分と仮定します。

データ欠落 / データ復旧イベント¶

モニターが「データ欠落」または「データ再報告」を判定した場合、ユーザー設定に基づいて、「データ欠落イベント」または「データ欠落復旧イベント」を生成するかどうかを決定します。

重複または無意味なアラートの発生を避けるため、システムはイベント生成前に、既存のイベント状態を参照して判断します。

したがって、「データ欠落イベント」と「データ欠落復旧イベント」は常に交互に発生し、データ欠落イベントが連続したり、復旧イベントが連続したりすることはありません。

よくある質問¶

イベントに表示された時刻とイベント生成時刻が一致しない

イベント詳細やアラート通知に表示される時刻（例：00:15:00）は、モニターの計画トリガー時間（つまり Crontab 式に基づく定時時間）であり、システムでイベントが実際に生成された時刻ではありません。

例外：モニター一覧で手動で「実行」をクリックした場合、生成されるイベント時刻はクリックして実行した実際の時刻になります。

イベントに表示された時刻と実際の障害発生時刻が一致しない

イベントに表示された時刻はモニターの計画トリガー時間であり、「検出範囲のドリフト」メカニズムが存在するため、実際に検出されるデータ範囲は 計画トリガー時間 - 検出範囲 - ドリフト時間 から 計画トリガー時間 - ドリフト時間 までとなります。

したがって、実際に障害が発生したデータポイントの時刻は、計画トリガー時間 - 検出範囲 から 計画トリガー時間 という直感的な区間内にない可能性が高くなります。これは正常な現象です。

プラットフォームで直接クエリしたときに障害の疑いがあるデータを発見したが、モニターがアラートを生成しなかった

この問題は通常、以下の原因により発生します。

1. データ書き込み遅延が高すぎる：検出実行時に、障害データが遅延のためまだクエリ可能になっていない。
2. DQL クエリ実行の失敗：検出プロセスがクエリ失敗により中断された。

このような状況は通常、データパイプラインまたはクエリエンジンの問題に起因し、モニター自身の制御範囲外です。