일곱 달 요청과 한 달치 로그

올해 초부터 이 오류가 몇 번 났는지 뽑아 달라는 요청을 받았다. 로그를 뒤졌더니 석 달 전 것부터 아예 없었다.

Open Table of contents

없는 것이 아니라 지워진 것

두 군데를 확인했다. 컨테이너 로그 설정은 파일 크기와 개수에 상한이 있어서 실질 보존 기간이 하루 반쯤이었다.

검색 엔진 인덱스는 정리 작업이 서른 날이 지난 것을 지우고 있었다. 둘 다 정상 동작이고 무한히 쌓으면 디스크가 차므로 정책 자체는 맞았다.

문제는 그 정책을 조사 시작 전에 아무도 확인하지 않았다는 점이었다. 이후로 로그를 뒤지기 전에 그 기간이 남아 있는지를 가장 오래된 기록의 시각으로 먼저 본다.

두 번째는 남아 있는 기간이 온전한지다. 세 번째는 그 로그가 그 내용을 담고 있는지인데 로그 수준이 낮게 잡혀 있었거나 필드가 나중에 추가됐으면 그 이전 기록에는 아예 없다.

남아 있어도 중간이 비어 있을 수 있어서 날짜별 건수를 세어 본다. 디스크가 찼거나 수집이 멈췄던 구간이 그렇게 드러난다.

건수가 0인 날은 오류가 없었던 날일 수도 있고 기록이 없는 날일 수도 있다. 이 둘을 구분하지 않으면 통계가 통째로 틀리고 그것도 조용히 틀린다.

이번 건은 석 달 전 이후만 확인할 수 있었으므로 확인 가능 기간과 그 기간의 건수와 이전 기간의 확인 불가를 나눠 적었다. 그 이전에는 없었다고 쓰지 않았다.

없는 것과 확인할 수 없는 것은 다르고 앞의 것은 사실이지만 뒤의 것은 관측의 한계다. 대신 다른 소스를 찾아보니 애플리케이션이 데이터베이스에 남긴 실패 기록에 일 년치가 있었고 결국 그것으로 요청한 답을 냈다.

이런 조사가 반복될 것을 알았으니 보존 정책도 손봤다. 컨테이너 로그는 실시간 확인용이고 수집기가 검색 엔진으로 보내고 있으므로 그대로 뒀다.

인덱스 보존은 전체 로그와 오류만 뽑은 인덱스로 나눠서 뒤쪽을 훨씬 길게 뒀다. 전체를 오래 보관하면 비용이 감당이 안 되지만 오류만 뽑으면 양이 수십 분의 일이므로 얼마나 오래가 아니라 무엇을 얼마나 오래로 나누니 답이 나왔다.