로그 비교: 여러 로그 파일을 타임스탬프로 정렬해 차이 분석

하나의 요청이 세 서비스를 거치다가 문제가 생기면, 진실은 세 개의 로그 파일에 흩어져 있습니다. 하나씩 읽으면 타임스탬프를 머릿속에 기억한 채 편집기 사이를 오가야 하고, 매번 흐름을 놓치게 됩니다. Log Compare는 반대 방식을 취합니다. 관련 파일을 모두 한 번에 열면 뷰어가 공통 타임라인에 맞춰 정렬하므로, 한 로그를 스크롤하면 다른 로그도 같은 순간으로 이동합니다. 핵심 상호작용은 타임스탬프 잠금 스크롤입니다. 각 파일은 브라우저에서 파싱되고 모든 줄의 타임스탬프가 인덱싱됩니다. 기본 로그를 이동하면 다른 창은 그 시점 또는 그 이전의 가장 가까운 줄을 따라갑니다. 이는 엔지니어가 모니터 두 대와 많은 인내심으로 수동으로 하던 기법을 자동화한 것입니다. 머신 간 시계 오차는 숨겨지지 않고 그대로 보이며, 그 자체가 진단 정보입니다. 데이터베이스 로그가 원인이 된 요청보다 먼저 이벤트가 발생했다고 주장한다면 NTP 설정에 관한 중요한 사실을 알게 된 것입니다. 필터는 대규모에서도 정렬을 유용하게 만듭니다. 장황한 서비스는 초당 수천 줄을 출력할 수 있지만, 파일별 키워드 또는 정규식 필터로 각 창을 오류 코드, 요청 ID, 사용자 ID처럼 필요한 줄만 남길 수 있습니다. 정렬은 여전히 전체 타임라인을 기준으로 작동합니다. 모든 창에 요청 ID 필터를 결합하면 분산 추적을 처음부터 끝까지 읽을 수 있는 형태로 바꿀 수 있습니다. 모든 작업은 로컬에서 이루어집니다. 파일은 브라우저의 File API로 읽히며 컴퓨터를 떠나지 않습니다. 로그에 고객 데이터, 토큰 또는 임의의 온라인 도구에 붙여 넣어서는 안 되는 내부 호스트 이름이 들어 있을 때 중요합니다. 따라서 실제 크기 제한은 업로드 한도가 아니라 RAM입니다. 일반적인 용도는 다섯 서비스의 로그에서 혼란스러웠던 1분을 재구성하는 사후 분석, 장애 환경 로그와 정상 환경 로그를 비교하여 동작이 갈라지는 지점을 찾는 일, 클라이언트·게이트웨이·백엔드 전체에서 하나의 요청 ID를 추적하는 일, 그리고 수정이 오류 메시지뿐 아니라 이벤트 순서를 바꾸었는지 확인하는 일입니다. 뷰어는 오픈 소스이므로 사용자 지정 타임스탬프 형식에 맞게 파싱 규칙을 확장할 수 있습니다.