Unix 타임스탬프로 UTC 장애 타임라인 만들기

문제 상황

분산 시스템의 장애 증거는 하나의 clock이나 단위를 공유하지 않는 경우가 많습니다. 애플리케이션은 epoch 초, 브라우저는 밀리초, 데이터베이스는 commit 마이크로초, tracing 수집기는 receive 나노초를 기록할 수 있습니다. created_at, sent_at, received_at, indexed_at은 같은 이벤트의 서로 다른 단계를 뜻하며, 서버 clock skew와 네트워크 지연이 겉으로 보이는 순서를 뒤집을 수도 있습니다. 모든 값을 읽기 쉬운 날짜로 바꾸는 것만으로는 부족합니다. 방어 가능한 타임라인은 정확한 epoch 값, 출처 시스템, 필드 의미, UTC 정규화, 정밀도, 불확실성을 함께 유지하고 기록된 순서와 입증된 인과관계를 구분해야 합니다. 로컬 시간은 사용자 증거를 설명할 때만 이름이 표시된 번역값으로 추가해야 합니다.

공식 출처와 표준

다음 공식 문서는 이 작업 흐름에서 다루는 형식과 보안 경계의 기준입니다. 도구별 실행 검증은 위에 별도로 기록합니다.

• RFC 3339: Date and Time on the Internet: Timestamps

  RFC Editor / IETF

이럴 때 사용하세요

• 장애가 애플리케이션 로그, 큐, 데이터베이스, API gateway, 브라우저 또는 모바일 증거에 걸쳐 있을 때
• 한 요청에 event, send, receive, commit, ingest 시각이 있고 이를 같은 필드처럼 취급하면 안 될 때
• 두 사건의 밀리초 날짜 표시는 같지만 마이크로초나 나노초 순서는 다를 때
• 사용자가 보고한 로컬 clock 시각을 UTC backend 증거와 일광 절약 시간 규칙에 맞춰야 할 때
• 추측한 순서를 사실처럼 쓰지 않고 불확실성을 포함한 티켓이나 사후 분석 표가 필요할 때

단계

1. 1단계

   장애 구간과 기준 사건 정하기

   배포, gateway 응답, 데이터베이스 transaction, monitoring alert처럼 알고 있는 UTC 기준 사건을 하나 고르세요. 덜 확실한 사건을 추가하기 전에 출처와 신뢰 수준을 기록하세요.

2. 2단계

   각 clock과 타임스탬프 의미 표시하기

   값마다 생산자를 적고 event 생성, client 전송, server 수신, database commit, queue ack, 이후 ingest 중 무엇을 의미하는지 기록하세요. 이 의미를 하나의 일반 time column으로 합치지 마세요.

3. 3단계

   출처별 단위 확인하기

   schema나 코드 문서에서 초, 밀리초, 마이크로초, 나노초를 확인하세요. 복사한 일부에 단위가 섞였으면 자동 판별 결과를 행마다 검토하고, 한 출처 묶음은 단위를 직접 선택하세요.

4. 4단계

   정확한 epoch를 남긴 채 UTC로 정규화하기

   한도 안의 발췌문을 변환하고 원본의 정확한 epoch 문자열 옆에 ISO UTC를 두세요. 여러 사건의 날짜 표시가 같은 .123Z라는 이유로 서브밀리초 자릿수를 버리지 마세요.

5. 5단계

   비교 가능한 clock 범위 안에서 정렬하기

   충분히 동기화된 하나의 clock이 만든 사건은 정확한 epoch로 정렬할 수 있습니다. 서로 다른 host라면 작은 차이에 의미를 부여하기 전에 NTP 상태, 알려진 drift, client clock 품질, network 지연을 기록하세요.

6. 6단계

   전송 및 protocol 증거 비교하기

   가능하면 HTTP Date, Age, cache, request ID, tracing header와 큐·데이터베이스 sequence 증거를 타임스탬프 옆에 두세요. 이 값은 제안한 순서를 지지하거나 반박할 수 있지만 타임스탬프를 인과관계 증명으로 만들지는 않습니다.

7. 7단계

   UTC 검토 뒤 사용자 시간으로 번역하기

   기술 타임라인은 UTC로 유지하세요. 스크린샷이나 문의 시각을 맞출 때 변환기에 표시된 브라우저 로컬 IANA 시간대를 별도 column으로 추가하고, 시간대 없는 로컬 clock 값은 쓰지 마세요.

예시

client sent_at=1704067200123 (밀리초)
gateway received_at=1704067200.128 (초)
database committed_at=1704067200132456 (마이크로초)
trace indexed_at=1704067200139000000 (나노초)

00:00:00.123000Z | client 전송 | client clock, skew 확인 필요
00:00:00.128000Z | gateway 수신 | server clock
00:00:00.132456Z | database commit | 정확한 마이크로초
00:00:00.139000Z | trace ingest | collector 시각
관찰 순서는 일관되지만 서로 다른 host의 타임스탬프만으로 인과관계를 입증할 수는 없습니다.

흔한 실수

자주 묻는 질문