测验：丢失、重复与迟到

수집기에 쌓인 로그에서 5분 동안 한 줄도 보이지 않는다. 이 사실만으로 말할 수 있는 것은?

• 그 5분 동안 요청이 없었다는 것 — 로그가 없으면 일도 없었던 것이다
• 안 왔는지 일이 없었는지 알 수 없다는 것 — 둘을 가르려면 발신 쪽 번호가 필요하다
• 수집기가 그 시간에 멈춰 있었다는 것 — 빈 구간은 수집기 장애의 신호다
• 그 구간의 로그가 다른 파일로 회전되었다는 것 — 파일 경계를 먼저 확인해야 한다

RFC 5424 는 syslog 의 전달 신뢰성을 어떻게 설명하는가?

• 전달 보증은 없지만 재전송 큐가 규격에 정의되어 있어 결국 모두 도착한다
• TCP 전송을 쓰면 규격이 전달을 보증하므로 유실을 고려할 필요가 없다
• 전달 보증 장치가 없어 메시지가 사라질 수 있고, 막히는 대신 의도적으로 버리되 그 사실을 알리는 편이 낫다고 적는다
• 수신자가 받지 못하면 발신자가 반드시 막혀야 한다고 규정해 유실을 원천 차단한다

프로세스가 재시작해 일련번호가 1부터 다시 시작했다. boot_id 없이 (host, seq) 로만 집계하면?

• 재시작 전후의 같은 번호가 중복으로 보이고, 재시작 뒤의 유실은 앞의 기록에 가려 안 보인다
• 번호가 겹치므로 집계 도구가 오류를 내고 멈춘다
• 재시작 뒤의 레코드가 전부 유실로 세어져 유실률이 크게 부풀려진다
• 시각 순서가 유지되므로 결과는 달라지지 않는다

OpenTelemetry 로그 데이터 모델이 Timestamp 와 ObservedTimestamp 를 따로 두는 이유는?

• 하나는 UTC 이고 다른 하나는 지역 시각이라 표기를 나눠야 하기 때문이다
• 원본 시계의 시각과 수집계가 관측한 시각이 다르고, 둘의 차이가 곧 도착 지연이기 때문이다
• Timestamp 는 필수이고 ObservedTimestamp 는 규격이 금지한 값을 담는 자리이기 때문이다
• 압축 효율을 높이려고 같은 값을 두 번 적어 두는 관행이기 때문이다

자정 직후에 센 어제의 오류 건수가, 사흘 뒤 같은 질의에서 더 크게 나왔다. 가장 그럴듯한 설명은?

• 집계 질의에 버그가 있어 실행 시점에 따라 다른 결과를 낸다
• 로그 회전이 일어나 같은 줄이 두 파일에 중복으로 남았다
• 보존 기간이 지나 옛 줄이 지워지면서 비율이 달라졌다
• 마감 시각 이후에 도착한 줄이 있었다 — 사건 시각은 어제인데 관측 시각이 오늘이다

at-least-once 수집기에서 온 로그의 중복을 접으려 한다. (host, boot_id, seq) 가 있는데도 내용의 해시로 접으면 어떤 문제가 생기는가?

• 해시 계산이 느려 60초 안에 끝나지 않는다
• 해시가 충돌하면 서로 다른 내용이 같은 줄로 보여 집계가 늘어난다
• JSON 키 순서가 달라지면 같은 줄이 다른 해시가 되어 중복이 남는다
• 내용이 똑같은 서로 다른 두 사건까지 한 건으로 접혀 실제 건수가 줄어든다