알림

알림 (Alerting)

알림을 어떻게 설계하느냐에 따라 모니터링의 가치가 완전히 달라져요. 이 문서는 프로메테우스에서 알림 규칙을 만들 때 따라야 할 실무 모범 사례(practices)를 정리한 거예요. 핵심 메시지는 간단해요. 알림을 단순하게 유지하고, 근본 원인보다 증상(symptom)에 알림을 걸고, 원인을 짚을 수 있는 좋은 콘솔을 갖추고, 할 일이 없는 페이지는 만들지 말라는 거죠.

Rob Ewaschuk이 Google에서 겪은 경험을 바탕으로 쓴 My Philosophy on Alerting을 함께 읽어 보는 걸 강력히 권장해요. 이 페이지는 그 철학을 프로메테우스 실무에 어떻게 적용할지 알려 주는 거예요.

출처: 문서

본문

Rob Ewaschuk이 Google에서 관찰한 내용을 바탕으로 한 My Philosophy on Alerting을 읽어 볼 것을 권장해요.

요약하면: 알림을 단순하게 유지하고, 증상에 알림을 걸며, 원인을 정확히 짚을 수 있는 좋은 콘솔을 갖추고, 할 일이 없는 곳에 페이지를 만들지 마세요.

이름 짓기 (Naming)

알림 규칙 이름에는 엄격한 제한이 없어요. 알림 이름은 다른 라벨 값과 마찬가지로 임의 개수의 Unicode 문자를 포함할 수 있거든요. 하지만 커뮤니티는 알림 이름에 Camel Case를 사용하는 쪽으로 의견을 모았어요.

무엇에 알림을 걸까 (What to alert on)

가능한 한 적은 수의 알림을 목표로 하세요. 그 고통을 일으킬 수 있는 모든 방법을 잡으려 하기보다는, 최종 사용자의 고통과 연결되는 증상에 알림을 거는 거예요. 알림은 관련 콘솔에 연결되고 어느 컴포넌트가 문제인지 파악하기 쉬워야 해요.

작은 변동(blips)을 흡수할 수 있도록 알림에 여유(slack)를 두세요.

온라인 서빙 시스템 (Online serving systems)

보통 스택에서 가능한 한 높은 위치에서 높은 지연시간(latency)과 오류율에 알림을 걸어요.

스택의 한 지점에서만 지연시간에 대해 페이지를 보내세요. 하위 레벨 컴포넌트가 느리더라도 전체 사용자 지연시간이 괜찮다면 페이지를 보낼 필요가 없어요.

오류율에 대해서는 사용자가 보는 오류에 페이지를 보내세요. 스택 더 아래쪽에 그런 실패를 일으킬 오류가 있다고 해도 그것에 따로 페이지를 보낼 필요는 없어요. 다만 일부 실패가 사용자에게 보이지 않지만 사람의 개입이 필요할 만큼 심각하다면(예: 많은 돈을 잃고 있다면), 그것에 페이지를 보내도록 추가하세요.

요청 유형마다 특성이 다르거나, 트래픽이 적은 요청 유형의 문제가 트래픽이 많은 요청에 묻혀 버린다면, 서로 다른 유형의 요청에 대한 알림이 필요할 수 있어요.

오프라인 처리 (Offline processing)

오프라인 처리 시스템에서 핵심 메트릭은 데이터가 시스템을 통과하는 데 걸리는 시간이에요. 사용자 영향이 생길 만큼 높아지면 페이지를 보내세요.

배치 잡 (Batch jobs)

배치 잡이 최근에 충분히 성공하지 않았고 이것이 사용자에게 보이는 문제를 일으킨다면 배치 잡에 페이지를 보내는 것이 합리적이에요.

이것은 일반적으로 배치 잡을 최소 2번 전체 실행할 시간이어야 해요. 4시간마다 실행되고 1시간이 걸리는 잡이라면 10시간이 합리적인 임계값이 될 거예요. 단 한 번의 실행 실패를 견딜 수 없다면 잡을 더 자주 실행하세요. 단일 실패가 사람의 개입을 요구해서는 안 되거든요.

용량 (Capacity)

즉각적인 사용자 영향을 일으키는 문제는 아니지만, 용량에 가까워지면 가까운 미래의 장애를 피하기 위해 종종 사람의 개입이 필요해요.

메타모니터링 (Metamonitoring)

모니터링이 작동한다는 확신을 갖는 것이 중요해요. 따라서 Prometheus 서버, Alertmanager, PushGateway, 그리고 기타 모니터링 인프라가 사용 가능하고 올바르게 실행되고 있는지 확인하는 알림을 두세요.

언제나 그렇듯, 근본 원인이 아니라 증상에 알림을 거는 것이 가능하다면 노이즈를 줄이는 데 도움이 돼요. 예를 들어 PushGateway에서 Prometheus로, Alertmanager로, 이메일로 가는 알림이 제대로 도달하는지 확인하는 블랙박스 테스트가 각각에 대한 개별 알림보다 더 나아요.

Prometheus의 화이트박스 모니터링을 외부 블랙박스 모니터링으로 보완하면 다른 방법으로는 보이지 않는 문제를 잡을 수 있고, 내부 시스템이 완전히 실패했을 때의 폴백 역할도 해요.

더 알아보기 (Learn more)