イベントのタイムスタンプ (クラシック)
Last updated
Last updated
EngineがCollectorによって送信されたパケットの受信時間と各イベントの個別タイム情報を組み合わせてデータベース内のイベントのタイムスタンプをどのように計算するかを学びます。
Collectorはメモリに記録することで興味のあるイベントに反応します。 後で、蓄積されたイベントが十分な量に達すると、一定の間隔で、またはEngineに送ります。 インストール先のシステムでの活動を検出するために、Collectorはシステムコールのインターセプトなどのさまざまな技術を使用して、イベントが発生する正確な瞬間を特定します。
この従業員のデバイスでのイベントのタイムスタンプ付けは、前回のシステムブートから経過した時間に基づいて行われます。 したがって、Collectorは相対時間を使用して従業員のデバイスでのイベントのタイムスタンプを付けます。 以下で説明するように、Collectorが使用する時間が相対的であることは、Engineで正確なタイムスタンプを計算するうえで重要ではありません。
Collectorが十分なイベントとその対応するタイムスタンプを収集すると、ネットワークパケットを構築し、それをEngineに送ります。 送信直前に、Collectorはシステムブートに対するローカル時間を使用してパケット内にタイムスタンプを設定します。 したがって、Collectorが送信するすべてのパケットには以下が含まれます：
パケット内で送信される各個別イベントのタイムスタンプ。
パケット自体の一般的なタイムスタンプ。
Engineはパケットの時間と各個別イベントの時間の差を使用して、イベントの全体的なタイムスタンプを計算します。
EngineがCollectorからパケットを受信すると、システム時間を使用して受信時間を記録します。 イベントのグローバル時間を計算するために、Collectorパケットが従業員のコンピュータからEngineに送信される時間は無視できるとEngineは仮定します。 この方法で、Collectorがパケットを送信した絶対時間は、Engineでのパケット受信の絶対時間と同じと見なされます。 したがって、送信直前にパケットでCollectorが設定した時間は、システムブートに対する従業員機のローカル時間であり、Engineがパケットを受け取る時間と等しくなります。 イベントが発生した時間を取得するために、Engineは受信時間からパケットのローカル時間と各イベントの差を引きます。以下の図に示すように:
Engineで受け取ったイベントは、順序通りではない可能性があることに注意してください。 最も一般的なケースは、短い間隔で2つのパケットを受け取り、それぞれが異なるCollectorから送信された場合です。 2つのパケットが時間的に重なるイベントを持っている可能性が高いですが、Engineは2番目のパケットの全イベントを最初のそれらの後に処理します。 Engineはこの状況に適切に対応します。 また、Engineは常に自身の現在の時間に対して過去のイベントを挿入することにも注意してください。 これは明らかです。なぜなら、Engineはまだ発生していないイベントを受け取ることはできないからです。 しかし、過去に遡りすぎるイベントについては、Engineはメモリ内データベースの更新ができません。それはコストがかかりすぎるからです。 Engineは、現在の時間に対して30分以上前のイベントを拒否します。
しかし、ローカルネットワーク内のCollectorに関しては、こうしたケースは非常に稀で、通常Collectorをホストするデバイスに問題が発生していることを示しています。
Collectorは、TCP接続については他のすべてのイベントとは異なり、タイムスタンプの設定を扱います。 他の全てのイベントは、何らかの活動を開始するとすぐにそのタイムスタンプが設定されます。 一方で、従業員デバイスがサーバーにTCP接続を開くと、Collectorは接続が確立されるまで待ち、TCP接続イベントのタイムスタンプを設定します。
