AlertDelivery: Grafana 알림을 네임스페이스별로 나누다 (SRE 밋업 3회)

같은 밋업의 모니터링 발표에서 연결된 시스템으로 소개한 알림의 상세 동작을 다룹니다. 담당자 정보의 출처는 katalog 발표이며, 이후 알림 관련 작업은 옵저버빌리티 에이전트 발표로 이어집니다.

주요 구간

• 02:02 Grafana 알림 동작 방식: 상태, Evaluate Every와 For
• 06:39 Grafana 알림의 한계 다섯 가지
• 12:14 AlertDelivery의 목표와 데이터 흐름
• 13:51 완성된 Slack 알림 메시지
• 16:25 알림별 정책, 스누즈, 웹 UI
• 18:29 효용과 남은 과제

Grafana 레거시 알림의 한계

당근은 한국 클러스터에만 네임스페이스가 200개 넘게 있어 알림도 많았습니다. 서비스·트래픽 대시보드를 Grafana로 만들고, 필요한 지표에 패널 알림을 설정해 Slack으로 보냈습니다. 사용하던 레거시 알림은 v10부터 지원이 끊기는 기능입니다. 발표에서는 한계를 다섯 가지로 꼽습니다.

• 조건을 넘은 모든 시계열이 한 메시지에 묶여 옴
• 네임스페이스별 상태 확인이 불가능. 하나가 정상으로 돌아와도 다른 쪽에 문제가 남으면 패널이 계속 알림 상태여서 복구 메시지를 받지 못함. 특정 네임스페이스를 끄려고 쿼리에서 제외하면 이력 추적이 어렵고 방치되기도 함
• 메시지를 꾸밀 수 없어 값이 길게 나열되고 읽기 어려움
• 리마인더 간격을 채널 단위로만 설정할 수 있어 알림별 조정이 불가능. 이슈가 지속되면 Slack 채널이 계속 시끄러움
• 담당자 정보가 없어 SRE가 직접 찾아 멘션해야 함. Kontrol 배포 프로젝트에는 정보가 남지만 ArgoCD 배포 프로젝트는 커밋 로그를 확인해야 했고, 신규 입사자는 대응하기 어려웠음

AlertDelivery의 전달 방식과 정책

당근은 한 메시지에 한 네임스페이스만 담기, 가독성 개선, 알림별 제어, 담당자 정보와 필요에 따른 멘션, 전체 상태를 보여 주는 웹 UI를 다섯 가지 목표로 잡았습니다. 이를 위해 만든 AlertDelivery는 Grafana 웹훅에서 필요한 필드를 추려 알림 데이터로 만들고 DB에 저장하는 서비스입니다.

알림별 정책은 코드로 관리합니다. 5xx 알림에서 503은 멘션하지 않되 응답 플래그가 UC이거나 메트릭 값이 1000 이상이면 멘션하고, 값이 1200을 넘으면 SRE 팀 전체를 태그합니다. 크론잡 실패와 경고 로그 급증 알림에는 팀 정보만 넣고 멘션하지 않으며, 리마인더 횟수 임계값도 알림마다 따로 둡니다.

완성된 Slack 메시지의 제목에는 네임스페이스와 알림 종류가 들어갑니다. 메트릭 레이블, Kontrol 프로젝트 링크, katalog API에서 가져온 담당 팀과 Slack 그룹, 서비스와 로그 대시보드 링크(알림 전후 10분 창)도 담깁니다. 정해진 횟수 이상 울리면 담당자를 멘션하고, 담당 Slack 그룹이 없으면 설정 링크를 안내합니다. 알림은 스레드에서 바로 끌 수 있으며, 스누즈를 누가 언제까지 설정했는지는 웹에서 확인할 수 있습니다.

알림량과 대응의 변화

• 개발자가 SRE를 거치지 않고 알림을 받아 처리하고, 배포 중인 알림도 직접 끌 수 있게 됨
• 발표자는 임계값과 리마인더를 따로 조정해 전체 알림 양이 크게 줄고 대응이 빨라졌다고 설명
• 모든 알림 이력을 저장해 웹 UI에서 네임스페이스별 이력과 전체 현황을 확인하고, 스누즈된 알림은 매시간 리포트로 상기

남은 과제와 마이그레이션

발표자는 지금도 다소 시끄러운 알림이 남아 있어 알림별 시간·조건·정책을 더 구체화해 중요도를 높여야 한다고 말합니다. Grafana 쿼리를 다듬어 필요한 정보만 담고 인프라 상황 변화에 유연하게 대응하며, 개발팀별 리포트를 보내는 작업도 남은 과제입니다. 발표자는 레거시 알림 기반인 이 시스템의 알림을 다음 Grafana 업그레이드 때 모두 마이그레이션할 예정이라고 밝혔습니다.