블라인드 스팟 모니터링에 지쳐서, 이를 찾아내는 무언가를 만들었습니다

Source: Dev.to

문제 정의

우리는 코드 품질, 보안, 테스트 커버리지를 위한 자동 검사를 가지고 있지만, 모니터링에 대해서는 그냥 괜찮을 거라 기대합니다.

작년에는 제가 온콜을 맡고 있을 때 중요한 서비스가 다운되었습니다. 알림이 3개월 전 유지보수 기간 동안 비활성화돼 있었기 때문에 페이지가 오기까지 시간이 걸렸습니다. 아무도 다시 활성화하지 않았고, 아무도 눈치채지 못했습니다.

사후 분석 후 PagerDuty와 Datadog 설정을 파헤쳐 보니 다음과 같은 문제를 발견했습니다:

• 퇴사한 사람에게 연결된 에스컬레이션 정책.
• 알림 규칙이 전혀 없는 경우(메트릭은 수집되지만 알림이 전혀 발생하지 않음).
• 어떤 정책에도 참조되지 않은 알림 채널.
• 모두가 무시하도록 배운 “데이터 없음” 상태에 영구히 머물러 있는 대시보드 패널.

우리는 대시보드도 있었고, 모니터링도 있었으며, 알림도 있었지만, 무엇을 놓치고 있는지 알 방법이 없었습니다.

해결 방안 개요

저는 모니터링 스택(PagerDuty, Datadog, Grafana, Sentry, New Relic 등)에 연결해 갭 분석을 수행하는 도구를 만들었습니다. “서비스가 정상 가동 중인가?” 라고 묻는 대신 다음을 묻습니다:

• 서비스에 실제로 알림이 설정되어 있나요?
• 그 알림이 유용한 대상에 라우팅되고 있나요?

시스템은 각 도구의 API를 통해 설정을 가져와 다음을 확인합니다:

• 에스컬레이션 정책이 없는 서비스.
• 알림 채널이 지정되지 않은 알림 규칙.
• 30일 이상 데이터를 받지 못한 모니터.
• 알림이 비활성화된 예약 검색.

각 이슈에는 심각도(critical / warning / info)와 AI가 생성한 구체적인 해결 방안이 할당됩니다. 또한 도구는 알림 커버리지, 알림 라우팅, 대시보드 상태 등 여러 차원에서 점수를 매겨, 한 눈에 가장 큰 격차를 확인할 수 있게 합니다.

AI‑구동 권고사항

AI는 우선순위가 매겨진 해결 단계와 Incident Autopilot을 생성합니다. 증상이 설명될 때(예: “checkout이 느리다”) 해당 증상이 미치는 서비스 범위를 매핑하고, 현재 온콜 담당자를 식별하며, 조사 플레이북을 자동으로 작성합니다.

PR/MR 스캐너

최근 추가된 기능으로 GitHub/GitLab 웹훅과 연동됩니다. PR에 새로운 API 엔드포인트나 데이터베이스 연결이 추가되면 스캐너가 이를 감지하고, 병합 전에 추가해야 할 모니터를 제안합니다.

열린 질문

• 문제가 충분히 고통스러운가? 제가 대화한 대부분의 팀은 모니터링에 격차가 있음을 알고 있지만, 제3자 도구를 연결해 감사를 수행할지, 아니면 위험을 그냥 감수할지 고민합니다.
• 스크립트 vs. 플랫폼: “스크립트 하나면 충분하다”는 의견도 있습니다. PagerDuty 에스컬레이션 정책용 스크립트는 만들 수 있지만, Datadog 모니터, Grafana 알림 규칙, Sentry 프로젝트 설정 등을 모두 관리하려면 곧 유지보수 악몽이 됩니다.
• 보안 우려: 시스템은 모니터링 도구에 대한 읽기 전용 API 토큰을 필요로 합니다. 토큰은 저장 시 암호화되며 평문으로 보관되지 않지만, 신뢰 장벽은 여전히 존재합니다.

시도해 보고 싶다면, 라이브 데모(계정 필요 없음)는 여기에서 확인할 수 있습니다. Enter Demo를 클릭하고 합성 데이터를 탐색해 보세요.

모니터링 커버리지 격차를 겪어본 분들의 이야기를 듣고 싶습니다. 현재 어떻게 대응하고 계신가요? 단순히 트라이벌 지식과 기대에 의존하고 있나요?