매일 두 번 텔레그램으로 나가는 지갑 노드 상태 요약을 개선하려고 감시 대상이 몇 개인지 세려 했다. application.yml 의 nodes 목록을 인용하려다 실제 발송된 메시지의 줄 수를 세어 봤다.
Table of contents
Open Table of contents
증상 — 설정 목록과 실제 발송의 차이
diff 로 두 목록을 비교하니 서로 다른 것을 갖고 있었다. application.yml 에는 있는데 안 나가는 노드가 다섯이고 발송에는 있는데 설정에 그 이름으로 없는 것이 하나였다.
숫자가 다른 정도가 아니라 구성이 어긋난 상태였다. 어느 쪽을 인용하느냐에 따라 커버리지 진술이 통째로 달라진다.
원인 — 순회 대상은 잡 본문에 있었다
두 가지 방법이 있었다. 발송 주체를 추측해 설정 쪽을 고치는 것과, 메시지의 출력 문구로 grep -rn '노드 상태 요약' 해서 발송 코드를 찾는 것이다. 뒤쪽을 골랐다. 이유는 같은 문구를 내는 잡이 둘 이상일 수 있어서다. 대신 문구가 바뀌어 있으면 못 찾는 것을 감수했다.
NodeSummaryJob 을 열어 보니 순회 대상이 설정 목록이 아니었다. 잡 안에서 별도로 만들어진 배열이었고 설정을 참조하기는 하되 BSV 등 일부를 빼고 ETH 의 토큰 몇 개를 따로 넣는 처리가 있었다. 감시 대상이 몇 개냐는 질문에 답하려면 실제 순회 대상을 코드 본문에서 확인해야 한다.
판단 기준 — 커버리지를 논할 때의 진술
이 구분은 커버리지를 말할 때 특히 중요했다. 서른일곱 중 서른만 감시된다는 진술과 감시 대상이 서른이라는 진술은 다른 말이다.
뒤의 것을 앞의 것으로 오해하면 개선 방향이 틀어진다. 빠진 일곱을 채우는 작업과 서른의 품질을 올리는 작업은 완전히 다른 일이기 때문이다.
결과 시각만 보는 감시의 한계
숫자를 확정한 뒤에 본질적인 문제를 봤는데 이 알림은 각 노드의 last_block_at 마지막 블록 수신 시각만 찍는다. 시각이 오래됐을 때 수집기가 죽은 것인지 원래 그 체인이 느린 것인지 화면상 구분되지 않았다.
수집기 자체가 안 돌면 전부 오래된 시각으로 보이는데 그것도 다들 한가한 것으로 읽힐 수 있다. 결과 데이터의 시각으로 상태를 유추하는 구조가 가진 한계였다.
조치 — 수집기 자신의 보고 신호
그래서 개선은 알림 포맷이 아니라 다른 신호를 만드는 방향이 됐다. 수집기가 실행 시작과 정상 종료와 오류 종료를 worker_heartbeats 에 스스로 보고하면 노드의 상태가 아니라 수집기 자신의 상태가 드러난다.
git log 를 보니 이 알림은 그 신호가 없는 상태에서 만든 대체물이었고 그 상황에서는 최선이었다. 새 감시가 옛 감시가 잡던 것을 다 잡는지 비교하려면 옛 감시의 커버리지를 정확히 알아야 했으므로 순회 대상 확정이 먼저였다.
정리
application.yml의 목록이 실제 순회 대상이라는 보장이 없다- 코드가 그 목록을 그대로 쓰는지
NodeSummaryJob본문에서 확인한다 - 커버리지를 논할 때 어느 목록을 인용했는지가 결론을 가른다
- 서른일곱 중 서른이라는 진술과 서른이라는 진술은 다른 말이다
last_block_at결과 시각만 보는 감시는 고장과 정상을 못 가른다- 개선은 포맷이 아니라
worker_heartbeats같은 수집기 자신의 보고 신호를 만드는 것이다 - 기존 감시는 새 감시의 비교 대상이므로 커버리지를 확정한다
- 발송 주체를 모르면 추측하지 말고 출력 문구로
grep한다