인용한 목록이 그 목록이 아니다

매일 두 번 나가는 상태 요약을 개선하려고 감시 대상이 몇 개인지 세려 했다. 설정 파일의 목록을 인용하려다 실제 발송된 메시지의 줄 수를 세어 봤다.

Open Table of contents

설정 목록과 실제 발송의 차이

두 목록을 비교하니 서로 다른 것을 갖고 있었다. 설정에는 있는데 안 나가는 것이 다섯이고 발송에는 있는데 설정에 그 이름으로 없는 것이 하나였다.

숫자가 다른 정도가 아니라 구성이 어긋난 상태였다. 어느 쪽을 인용하느냐에 따라 커버리지 진술이 통째로 달라진다.

발송하는 코드를 열어 보니 순회 대상이 설정 목록이 아니었다. 커맨드 안에서 별도로 만들어진 배열이었고 설정을 참조하기는 하되 일부를 빼고 몇 개를 따로 넣는 처리가 있었다.

설정 파일에 목록이 있어도 코드가 그것을 그대로 쓴다는 보장이 없다. 감시 대상이 몇 개냐는 질문에 답하려면 실제 순회 대상을 코드 본문에서 확인해야 한다.

이 구분은 커버리지를 말할 때 특히 중요했다. 서른일곱 중 서른만 감시된다는 진술과 감시 대상이 서른이라는 진술은 다른 말이다.

뒤의 것을 앞의 것으로 오해하면 개선 방향이 틀어진다. 빠진 일곱을 채우는 작업과 서른의 품질을 올리는 작업은 완전히 다른 일이기 때문이다.

숫자를 확정한 뒤에 본질적인 문제를 봤는데 이 알림은 각 대상의 마지막 데이터 시각만 찍는다. 데이터가 없을 때 수집기가 죽은 것인지 원래 그 대상에 데이터가 없는 것인지 화면상 구분되지 않았다.

수집기 자체가 안 돌면 전부 오래된 시각으로 보이는데 그것도 다들 한가한 것으로 읽힐 수 있다. 결과 데이터의 시각으로 상태를 유추하는 구조가 가진 한계였다.

그래서 개선은 알림 포맷이 아니라 다른 신호를 만드는 방향이 됐다. 수집기가 실행 시작과 정상 종료와 오류 종료를 스스로 보고하면 대상의 상태가 아니라 수집기 자신의 상태가 드러난다.

이력을 보니 이 알림은 그 신호가 없는 상태에서 만든 대체물이었고 그 상황에서는 최선이었다. 새 감시가 옛 감시가 잡던 것을 다 잡는지 비교하려면 옛 감시의 커버리지를 정확히 알아야 했으므로 순회 대상 확정이 먼저였다.