Prometheus: Up & Running, 2nd Edition

19장. 알림 관리자

이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: [e-mail]

18장에서는 Prometheus에서 알림 규칙을 정의하여 알림 관리자에게 알림을 전송하는 방법을 살펴보았습니다. 모든 Prometheus 서버의 모든 알림을 수신하여 이메일, 채팅 메시지, 페이지 등의 알림으로 변환하는 것은 알림 관리자의 책임입니다. 2장에서는 알림 관리자 사용에 대해 간략하게 소개했지만, 이 장에서는 알림 관리자의 모든 기능을 구성하고 사용하는 방법을 배웁니다.

알림 파이프라인

알림 관리자는 일대일 방식으로 무작정 알림으로 전환하는 것 이상의 기능을 제공합니다. 이상적인 세계에서는 각 프로덕션 인시던트에 대해 정확히 하나의 알림을 받을 수 있습니다. 이것은 무리한 요구이지만, Alertmanager는 알림이 알림으로 처리되는 방식에 대한 제어 가능한 파이프라인을 제공함으로써 이러한 목표를 달성하기 위해 노력합니다. 레이블이 Prometheus 자체의 핵심인 것처럼, 레이블도 Alertmanager의 핵심입니다:

억제

증상 기반 알림을 사용하는 경우에도 서비스가 있는 데이터센터에 장애가 발생했지만 트래픽이 전혀 수신되지 않는 경우 서비스에 대한 알림을 방지하는 등 더 심각한 다른 알림이 발생하면 일부 알림에 대한 알림을 방지하고 싶을 때가 있습니다. 이것이 바로 억제의 역할입니다.

침묵

이미 문제에 대해 알고 있거나 유지보수를 위해 서비스를 중단하고 있는 경우에는 대기 중인 담당자에게 호출할 필요가 없습니다. 무음을 사용하면 특정 알림을 잠시 동안 무시할 수 있으며, 알림 관리자의 웹 인터페이스를 통해 추가할 수 있습니다.

라우팅

조직당 하나의 Alertmanager를 실행하는 것이 좋지만 모든 알림이 한 곳으로 가는 것은 바람직하지 않습니다. 팀마다 알림이 다른 곳으로 전달되기를 원할 수도 있고, 한 팀 내에서도 프로덕션 환경과 개발 환경에 대한 알림이 다르게 처리되기를 원할 수도 있습니다. 라우팅 트리를 사용하여 이를 구성할 수 있습니다.

그룹화

이제 경로로 이동하는 팀에 대한 생산 알림( )을 받을 수 있습니다. 실패한 랙의 각 머신에 대해 개별 알림을 받으려면¹ 에 대해 개별 알림을 받는 것은 스팸이 될 수 있으므로 Alertmanager 그룹 알림을 통해 랙당 하나의 알림, 데이터센터당 하나의 알림 또는 연결할 수 없는 머신에 대해 전 세계적으로 하나의 알림만 받을 수 있습니다.

스로틀링 및 반복

머신 랙이 다운되어 발생하는 알림 그룹이 있는데 랙에 있는 머신 중 하나에 대한 알림이 이미 알림을 보낸 후에 들어온다고 가정해 보세요. 한 그룹에서 새 알림이 들어올 때마다 알림 관리자가 새 알림을 보낸다면 그룹화의 목적이 무색해집니다. 대신 알림 관리자가 특정 그룹에 대한 알림을 스로틀링하여 스팸을 받지 않도록 합니다.

이상적인 세계에서는 모든 알림이 즉시 처리되지만, 현실에서는 대기 담당자나 다른 시스템이 문제를 놓칠 수 있습니다. 알림 ...