올해 초부터 노드 전송 오류가 몇 번 났는지 뽑아 달라는 요청을 받았다. Kibana 에서 로그를 뒤졌더니 석 달 전 것부터 아예 없었다.
Table of contents
Open Table of contents
원인 — 없는 것이 아니라 지워진 것
두 군데를 확인했다. Docker 공식 문서대로 json-file 드라이버의 max-size 와 max-file 이 로그 회전을 정하는데 10m 과 3 으로 잡혀 있어서 컨테이너 로그의 실질 보존 기간이 하루 반쯤이었다.
Elasticsearch 인덱스는 ILM 정책이 서른 날이 지난 것을 지우고 있었다. 둘 다 정상 동작이고 무한히 쌓으면 디스크가 차므로 정책 자체는 맞았다.
판단 기준 — 조사 전에 확인하는 세 가지
문제는 그 정책을 조사 시작 전에 아무도 확인하지 않았다는 점이었다. 이후로 로그를 뒤지기 전에 그 기간이 남아 있는지를 min(@timestamp) 가장 오래된 기록의 시각으로 먼저 본다.
두 번째는 남아 있는 기간이 온전한지다. 세 번째는 그 로그가 그 내용을 담고 있는지인데 logback 수준이 WARN 으로 잡혀 있었거나 필드가 나중에 추가됐으면 그 이전 기록에는 아예 없다.
건수 0이 뜻하는 두 가지
남아 있어도 중간이 비어 있을 수 있어서 날짜별 건수를 date_histogram 으로 세어 본다. 디스크가 찼거나 Filebeat 가 멈췄던 구간이 그렇게 드러난다.
건수가 0인 날은 오류가 없었던 날일 수도 있고 기록이 없는 날일 수도 있다. 이 둘을 구분하지 않으면 통계가 통째로 틀리고 그것도 조용히 틀린다.
조치 — 확인 불가를 결론으로 적는다
이번 건은 석 달 전 이후만 확인할 수 있었으므로 확인 가능 기간과 그 기간의 건수와 이전 기간의 확인 불가를 나눠 적었다. 그 이전에는 없었다고 쓰지 않았다.
없는 것과 확인할 수 없는 것은 다르고 앞의 것은 사실이지만 뒤의 것은 관측의 한계다. 대신 다른 소스를 찾아보니 WithdrawWorker 가 MariaDB 의 job_failures 에 남긴 실패 기록에 일 년치가 있었고 결국 그것으로 요청한 답을 냈다.
무엇을 얼마나 오래
이런 조사가 반복될 것을 알았으니 보존 정책도 손봤다. 두 가지 방법이 있었다. logs-* 인덱스 전체의 보존을 일 년으로 늘리는 것과, 전체 로그와 ERROR 만 뽑은 errors-* 인덱스로 나눠서 뒤쪽만 훨씬 길게 두는 것이다. 뒤쪽을 골랐다. 이유는 전체를 오래 보관하면 스토리지 비용이 감당이 안 되지만 오류만 뽑으면 양이 수십 분의 일이라서다. 대신 Logstash 파이프라인에 분기 하나가 더 생기는 것을 감수했다.
컨테이너 로그는 실시간 확인용이고 Filebeat 가 Elasticsearch 로 보내고 있으므로 그대로 뒀다. 얼마나 오래가 아니라 무엇을 얼마나 오래로 나누니 답이 나왔다.
정리
- 보존 정책이 조사 가능한 범위를 정한다
- 없는 기간은 조회로 만들어지지 않는다
- 조사 전에 가장 오래된 기록의 시각을 먼저 확인한다
- 남아 있어도 중간이 비어 있을 수 있다
- 건수 0은 없었던 날이 아니라 기록이 없는 날일 수 있다
- 확인할 수 없으면 확인 불가로 적고 없었다고 쓰지 않는다
- 로그가 유일한 소스가 아니므로
job_failures같은 다른 기록을 함께 찾는다 - 보존은 얼마나 오래가 아니라
errors-*처럼 무엇을 얼마나 오래로 나눈다