서버 시계가 다를 때 로그의 사건 순서를 맞추는 법

여러 호스트의 로그를 비교할 때는 원본 timestamp와 시간대, 시계 동기화 근거, 추정 오차 범위를 함께 봐야 합니다. 시간대를 UTC로 바꾸는 일은 표시 기준을 맞추는 것이지 시계가 정확하다는 증명은 아닙니다.

두 이벤트의 가능한 발생 시간 구간이 겹치면 로그 순서만으로 실제 선후를 확정하지 않습니다. 수집 시각, 동기화 상태, 요청 ID나 프로세스 관계 같은 별도 연결 근거를 추가로 찾습니다.

시간대 변환과 시계 정확도는 별개입니다

한 서버는 UTC로, 다른 서버는 한국 표준시(KST, UTC+09:00)로 기록할 수 있습니다. 이를 같은 기준으로 바꾸면 서로 다른 표기 형식을 비교할 수 있지만, 실제 시계가 얼마나 앞서거나 늦었는지는 해결되지 않습니다. RFC 5424는 syslog timestamp와 선택적인 timeQuality 정보를 정의합니다. 이 metadata는 발신자가 시간대 지식, 동기화 여부, 기대 정확도를 표현할 수 있게 하지만, 모든 시스템 로그에 들어 있거나 사실 검증을 대신하는 표시는 아닙니다.

systemd 262의 timedatectl 문서는 status로 현재 시계·시간대와 네트워크 시간 동기화 서비스의 활성 표시를 조회할 수 있다고 설명합니다. 이 값은 확인 시점의 상태입니다. 사건이 발생했던 시점에도 계속 동기화됐는지, 오차가 몇 초였는지는 과거 모니터링 기록이나 시간 서비스 로그를 봐야 합니다. 표시 상태만 남아 있다면 과거 시각의 정확도는 미확정으로 둡니다. RFC 5424의 timeQuality 예시처럼 발신자가 동기화 여부나 기대 오차를 함께 기록했는지도 보되, 그 메타데이터 자체를 독립 측정값으로 오해하지 않습니다.

시각을 바꾸고 오차 범위까지 비교합니다

첫 두 구간은 분리되어 프록시 수신이 앱 시작보다 약 56초 앞선 것으로 볼 수 있습니다(오차 경계 사이 최소 56초). 그러나 세 번째 구간은 앱 시작 구간과 09:02:58–09:03:00 구간에서 겹칩니다. 배치 호스트의 09:01:30이 겉으로 더 이르더라도 가능한 실제 시각 범위가 넓으므로, 파일 갱신이 앱 시작보다 먼저 일어났다고 단정할 수 없습니다. 이 오차 ±90초는 연습 조건으로 주어진 가정이지 관측 증명이 아닙니다.

원본을 보존하고 비교 기준을 만듭니다

1. 원본 로그의 timestamp 문자열, offset 또는 시간대 정보, 호스트, 수집 시각을 각각 보존합니다.
2. 모든 비교값을 UTC로 변환하되 원본 열을 덮어쓰지 않고 변환 규칙을 남깁니다.
3. 사건 당시의 동기화 기록과 오차 관측을 찾습니다. 현재 상태 조회 결과는 현재 시점 근거로 따로 표시합니다.
4. 각 이벤트를 단일 시각 대신 가능한 오차 구간으로 표현하고 두 구간이 겹치는지 확인합니다.
5. 구간이 겹치거나 offset을 모르면 선후를 미확정으로 분류하고 요청 ID·세션 ID·프로세스 계보 같은 별도 인과 단서를 찾습니다.
6. 수집 시각을 사건 발생 시각으로 바꾸어 적지 않습니다. 버퍼링·전송 지연은 별도로 기록합니다.

정렬된 로그가 곧 인과관계는 아닙니다

로그 검색 화면은 timestamp를 기준으로 기록을 정렬하지만, 수집기가 늦게 받은 이벤트도 원본 시각이 오래됐을 수 있습니다. 반대로 잘못된 timezone 설정으로 숫자만 빠르게 보이는 이벤트도 실제로는 뒤일 수 있습니다. 타임스탬프는 사건 순서를 세우는 증거 중 하나입니다. 공통 요청 식별자, 시스템 호출 결과, 메시지 흐름 등 서로 독립된 흔적이 맞는지 함께 검토합니다.

복습: 어떤 사건이 먼저였나요?

문제: 앱 이벤트는 09:03:00Z ±2초이고, 호스트 B 기록은 09:01:30Z ±90초입니다. 호스트 B 기록이 먼저 발생했다고 말할 수 있나요?

정답: 확정할 수 없습니다. B의 가능한 시각은 09:00:00–09:03:00이고 앱의 09:02:58–09:03:02 구간과 09:02:58–09:03:00에서 겹칩니다. 당시 시계 오차나 다른 인과 식별자를 추가로 확인합니다.