端末のイベントビューアーと中央の収集画面で、同じ事象の時刻が違って見えることがあります。すぐに「端末の時計が壊れている」「ログが欠けた」と決めず、どの端末が記録した時刻か、画面がどのタイムゾーンで表示しているか、収集先へいつ届いたかを分けて確認します。この記事は管理権限のある環境での読み取りと記録を対象とし、本番の時刻設定や収集設定を無断で変える手順ではありません。
Microsoftのイベントスキーマでは、TimeCreatedのSystemTimeをイベントが記録されたシステム時刻と説明しています。またWindows Event Forwardingの資料は、イベント発生から収集先へ届くまでに遅れが生じ得ると説明しています。この二つを同じ「ログの時刻」として比較しないことが出発点です。
1. まず元の端末と収集先を区別する
調査対象のイベントIDだけでなく、発生元の端末名、ログ名、イベントレコードID、記録時刻を控えます。収集先にしか表示されない時刻や取込日時がある場合は、その項目名と収集製品も残します。製品によって表示項目の意味が異なるため、画面の列名だけでイベント発生時刻だと断定しません。
| 確認項目 | 読み取り時の問い |
|---|---|
| 発生元 | どの端末・どのログに記録されたか |
| イベント自体の時刻 | 元のイベントのTimeCreatedは何を示すか |
| 表示の基準 | 端末・閲覧端末・収集画面のタイムゾーンは同じか |
| 収集側の時刻 | 受信または取込を示す列なら、発生時刻と区別できるか |
| 比較する範囲 | 前後のイベントと順序が矛盾しないか |
ログの保持や上書きが疑わしい場合はイベントログがすぐ消えるときの確認順へ、4625が元端末にも存在しない場合は4625が記録されないときの確認項目へ分けて進みます。
2. タイムゾーン表示と転送の遅れを切り分ける
同じイベントでも、閲覧する画面の表示設定と、XMLにある時刻を無造作に並べると差があるように見えます。まず時刻の表記にタイムゾーンやUTC表記があるかを確認し、比較する時刻を同じ基準に揃えます。ログのエクスポートや表計算への貼り付けでは、タイムゾーン情報が消えていないかにも注意します。
元端末の記録時刻は揃っているのに収集画面への到着だけ遅い場合、転送の経路や購読設定を調べる方向です。Microsoftは転送遅延の要因として購読構成、収集側・送信側の性能、ネットワークを挙げています。ただし、数分の差が必ず転送遅延だとは決められません。収集製品の項目定義と実際の状態を確認します。
次は説明用の架空例であり、実測ログ・実際の障害記録ではありません。
| 記録 | 説明用の表示 | 確認すること |
|---|---|---|
| 元端末のイベント時刻 | 10:00(表示例) | タイムゾーンと発生元を記録 |
| 収集先の受信時刻 | 10:04(表示例) | 受信時刻を発生時刻と混同しない |
| 別端末の関連イベント | 10:02(表示例) | 同じ基準に換算して順序を比較 |
この例の4分差は製品の標準遅延や許容値を示しません。実際に調査する場合はイベントそのものの情報と収集側のメタデータを分けて保存します。
3. 時計のずれが疑わしいときは変更前に影響を確認する
表示基準と転送遅延を切り分けても、複数端末のイベント順が合わない場合は、組織の時刻同期の状態を管理担当へ確認します。本番環境で時計や時刻同期先を突然変更すると、認証、スケジュール、証跡の時系列へ影響し得ます。診断結果、関係する端末、変更の承認者、戻し方を揃え、組織の変更管理に従ってください。この記事では時刻を強制変更するコマンドを掲載しません。
まとめ
Windowsログの時刻差は、発生元、イベント記録時刻、画面表示の基準、収集時刻のどこで生じたかを分けて確認します。時刻の前提を揃えたら認証ログの見方で、関連イベントの対象と結果を確認してください。
