API 로그에서 타임스탬프 추출하고 변환하기

문제 상황

API 추적 한 조각에는 created_at 초, 브라우저 이벤트 밀리초, 데이터베이스 마이크로초, tracing 필드 나노초가 이웃한 줄에 함께 있을 수 있습니다. 같은 조각에 상태 코드, 처리 시간, 요청 ID, 토큰, 사용자 정보도 섞입니다. 숫자만 따로 복사하면 필드와 줄 맥락을 잃어 결과를 검증하기 어렵고, 최근 값의 흔한 자릿수만 보고 단위를 추측하면 과거 값이나 앞에 0이 붙은 값을 잘못 분류할 수 있습니다. 쓸 만한 추출 절차는 입력 범위를 제한하고 비밀값을 지우며, 원본 맥락과 자동 판별 기준을 보여주고, 읽기 쉬운 밀리초 날짜에 모든 정밀도가 있다고 과장하지 않으면서 서브밀리초 값을 정확히 보존해야 합니다.

공식 출처와 표준

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

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

  RFC Editor / IETF

이럴 때 사용하세요

• 복사한 API 로그, 웹훅, 큐 이벤트, JSON 조각에 epoch처럼 보이는 값이 여러 개 있을 때
• 같은 디버깅 과정에서 서로 다른 생산자가 초, 밀리초, 마이크로초, 나노초를 사용할 때
• created_at, processed_at, received_at과 원본 줄 번호를 변환 결과에 붙여 둬야 할 때
• 12자리 과거 값처럼 최근 시점 자릿수 추정 대신 명시적 단위가 필요한 값이 있을 때
• 로그 본문을 변환 서버에 업로드하지 않고 비식별화된 보고서를 티켓에 남겨야 할 때

단계

1. 1단계

   필요한 최소 맥락만 복사하기

   각 값을 식별할 필드명, 이벤트 종류, 이웃한 몇 줄만 남기세요. 디버깅 도구에 넣기 전에 Authorization 헤더, 쿠키, 원본 JWT, 이메일 주소, 불필요한 사용자 정보를 제거하세요.

2. 2단계

   필드명과 줄 경계 보존하기

   숫자만 있는 목록으로 줄이지 마세요. created_at, duration_ms, sequence_id, received_at 같은 이름은 타임스탬프와 카운터를 구분하고 어떤 clock이 값을 만들었는지 설명하는 근거입니다.

3. 3단계

   원본 시스템의 단위 확인하기

   가능하면 API schema, 데이터베이스 column, tracing 문서, 생산자 코드를 확인하세요. 자동 모드는 정수부 9~11자리를 초, 12~14자리를 밀리초, 15~17자리를 마이크로초, 18자리 이상을 나노초로 보지만 이 휴리스틱은 원본 메타데이터가 아닙니다.

4. 4단계

   한도 안의 표본 변환하기

   UTF-8 기준 최대 200,000바이트, 200줄, 타임스탬프 후보 100개를 붙여넣으세요. 일반적인 여러 단위가 섞였을 때만 자동을 사용하고, 모든 후보가 문서화된 한 단위를 따르면 해당 단위를 직접 선택하세요.

5. 5단계

   단위와 정밀도 경고 읽기

   각 감지 단위와 건너뛴 줄을 확인하세요. 정확한 epoch 문자열은 마이크로초와 나노초를 보존하지만 ISO, UTC, 로컬 Date 표시는 밀리초에서 끝나며 나머지가 있으면 경고합니다.

6. 6단계

   UTC 결과를 원본에 연결해 기록하기

   유용한 각 행에 원본 필드명, 줄 번호, 선택하거나 감지한 단위, 정확한 epoch 값, ISO UTC 결과를 함께 보관하세요. 사용자 화면을 맞출 때만 브라우저 로컬 IANA 시간대를 사용하세요.

7. 7단계

   로그 밖의 기준 사건 하나로 검증하기

   알고 있는 배포, 데이터베이스 레코드, 서명된 이벤트, 서버 Date 헤더 중 하나를 변환 행과 비교하세요. 날짜가 그럴듯하다는 이유만으로 해당 숫자가 타임스탬프이거나 자동 판별 단위가 맞다고 확정할 수 없습니다.

예시

INFO created_at=1704067200 status=200
INFO updated_at=1704067200123 duration_ms=42
DEBUG processed_at=1704067200123456 request_id=req_demo
TRACE received_at=1704067200123456789 retries=3

1704067200 | 초 | 2024-01-01T00:00:00.000Z
1704067200123 | 밀리초 | 2024-01-01T00:00:00.123Z
1704067200123456 | 마이크로초 | 정확히 1704067200.123456초 | 날짜 표시는 .123Z
1704067200123456789 | 나노초 | 정확히 1704067200.123456789초 | 날짜 표시는 .123Z

흔한 실수

자주 묻는 질문