SigNoz 알람 구성

요약

SUMMARY

SigNoz에서 감지한 이상을 Teams 웹훅으로 받도록 알람을 구성했다. 잡아둔 시나리오는 세 가지 — 파드가 반복 재시작(CrashLoopBackOff)할 때, CPU·메모리·GPU가 임계치를 넘을 때(경고/위험 2단), 그리고 관측 시스템 자체(otel-collector·SigNoz)가 죽었을 때다. 마지막 하나가 핵심인데, 관측이 멈추면 다른 알람도 안 오기 때문이다.

알람을 짤 때 제일 신경 쓴 건 “알람이 안 오는 게 정상인지, 관측이 죽어서 안 오는 건지”를 구분하는 것이었다.

1. 전달 채널: Teams 웹훅

알람은 Teams 웹훅으로 보낸다. SigNoz의 알림 채널(Alert Channel)에 Teams의 incoming webhook URL을 등록하면, 트리거된 알람이 그 채널로 카드 메시지로 온다. 운영 인원이 이미 Teams를 쓰고 있어서 별도 알림 도구를 새로 붙이지 않고 붙였다.

2. 알람 시나리오

2-1. 파드 CrashLoopBackOff

파드가 반복적으로 재시작하면 알람을 보낸다. SigNoz에서 k8s.pod.status.phase가 Failed로 떨어지거나 restart count가 임계치를 넘으면 트리거한다. 한 번 죽는 건 흔하니 일정 시간 창에서 재시작 횟수를 기준으로 잡아, 일시적 재기동에 과민 반응하지 않게 했다.

2-2. 리소스 사용 임계치 초과

CPU·메모리·GPU 사용량이 임계치를 넘으면 알람을 보낸다. 경고(warning)와 위험(critical) 2단으로 나눠, 여유가 줄어드는 단계에선 경고만, 실제로 넘치면 위험 알람을 띄운다. 그래야 “이미 터진 뒤”가 아니라 “터지기 전”에 손댈 수 있다.

• CPU — 파드 request 대비 사용률
• 메모리 — 파드 limit 대비 사용률
• GPU — GPU 메모리 사용률(nvidia 지표 기준)

2-3. 로그·메트릭 수집 불가

otel-collector가 수집을 멈추거나 SigNoz 자체가 unhealthy가 되면 알람을 보낸다. 이건 관측 시스템이 죽은 경우를 대비한 것이다. 관측이 멈추면 위 두 알람도 같이 침묵하기 때문에, “알람이 안 온다 = 평온하다”가 거짓이 될 수 있다. 그래서 수집 파이프라인의 생존 자체를 별도 알람으로 감시한다.

NOTE

otel-collector는 DaemonSet으로 노드마다 하나씩 떠 있다(Otel pipeline 참고). collector 파드가 unhealthy가 되면 그 노드의 메트릭만 끊기고 다른 노드는 정상이다. 그래서 수집 불가 알람은 “노드 하나의 collector 문제”인지 “SigNoz 게이트웨이·백엔드 전체 문제”인지 구분해서 잡는 게 좋다. 전자는 노드 단위 조치, 후자는 관측 스택 전체 장애다.

참고

• Otel pipeline
• SigNoz infra monitoring 에서 메모리가 높게 뜨는 증상
• SigNoz — Alerts