주문 서비스의 오류 비율이 잠깐 올라갔다가 회복했습니다. 이후 같은 문제가 몇 분 동안 계속됩니다. 지속된 문제를 알림으로 받고 싶다면 조건과 대기 시간을 함께 정해야 합니다. 이 글에서는 Prometheus가 조건을 판단하는 과정과 Alertmanager가 알림을 묶는 과정을 살펴봅니다.
조건을 판단하는 시각
Alert는 확인이 필요한 상태를 표현하는 기록입니다. Prometheus는 정해진 간격마다 Alerting rule, 즉 상태를 판단하는 규칙을 평가합니다. for는 조건이 계속 참으로 유지되어야 하는 시간입니다. 조건이 처음 참으로 평가되면 Pending이라는 대기 상태에 들어갑니다. 이후 매 평가에서 조건이 이어지고 지정 시간이 지나면 Firing, 즉 알림 조건이 지속되어 발생한 상태가 됩니다. 이 동작은 Alerting rules 문서를 기준으로 설명합니다.
다음과 같이 가정해 보겠습니다. 오류 비율이 5%를 넘으면 조건이 참이고, 대기 시간은 2분입니다. 평가는 1분마다 수행합니다. 0분에 처음 참이면 대기를 시작합니다. 1분에도 참이면 대기를 이어갑니다. 2분에도 참이면 처음부터 2분이 지났으므로 발생 상태가 됩니다. 대기 중 조건이 거짓으로 평가되면 지속 시간 계산을 다시 시작해야 합니다.
| 평가 시각 | 조건 | 상태 |
|---|---|---|
| 0분 | 참 | Pending 시작 |
| 1분 | 참 | Pending 유지 |
| 2분 | 참 | Firing |
| 3분 | 거짓 | Inactive |
Prometheus: 조건이 2분 이어졌는지 판단
↓ 발생한 Alert 전달
Alertmanager: checkout 서비스별 Grouping
↓ 묶은 알림 전달
수신처표에서 2분은 조건을 처음 확인한 뒤 이어진 시간입니다. Prometheus는 매분 평가한 값을 따라 상태를 바꿉니다. 두 평가 사이에 값이 어떻게 움직였는지는 추가 기록이 있어야 알 수 있습니다. 실제 첫 알림의 도착 시각은 평가 간격과 알림 전달 설정까지 함께 확인해야 합니다.
알림을 전달하는 단계
Alertmanager는 Prometheus에서 보낸 Alert를 받아 중복을 정리하고, 묶고, 지정한 수신처로 전달합니다. Grouping은 설정에서 선택한 Label, 즉 Alert에 붙은 이름과 값으로 묶는 기능입니다. 예를 들어 서비스 이름으로 묶으면 주문 서비스의 여러 실행 단위에서 발생한 Alert를 한 알림에 정리할 수 있습니다. 이 역할은 Alertmanager 문서에서 확인할 수 있습니다.
for는 Prometheus의 상태 판단에 쓰입니다. Grouping은 전달할 알림의 구성을 정합니다. 두 설정은 각 단계에서 다른 일을 담당합니다. 실제 전달에는 묶음을 기다리는 시간과 수신처 설정까지 함께 확인해야 합니다.
가상의 주문 서비스가 세 곳에서 실행된다고 생각해 보겠습니다. 같은 문제가 각 실행 단위에서 조건을 만족하면 발생한 Alert도 세 개가 됩니다. 서비스 이름으로 묶도록 설정했다면 같은 묶음에 들어갈 수 있습니다. 전달받은 사람은 그 묶음에서 영향을 받은 실행 단위를 함께 확인합니다. 어떤 항목을 묶음의 기준으로 선택할지는 조사할 때 필요한 범위에 따라 정합니다.
대기 시간을 정할 때는 문제가 어느 정도 이어졌을 때 알림을 받을지 먼저 적어 보세요. 여기에 평가 간격을 표시하고, 조건이 시작한 시각과 첫 메시지가 도착한 시각을 따로 기록합니다. 그러면 상태 판단에 걸린 시간과 전달에 걸린 시간을 따라갈 수 있습니다.
예제: 조건이 이어진 시간 계산하기
started = None
for minute, active in enumerate([True, True, True, False]):
if active:
if started is None:
started = minute
state = "firing" if minute - started >= 2 else "pending"
else:
started = None
state = "inactive"
print(minute, state)예제의 상태 변화는 다음과 같습니다.
0 pending
1 pending
2 firing
3 inactive처음 참인 시각을 저장하고 현재 시각과의 차이를 계산합니다. 3분에는 조건이 거짓이라 시작 시각을 지웁니다. 이 예제는 하나의 Alert를 매분 평가한다고 가정합니다. 조건이 끝난 뒤에도 Firing 상태를 유지하는 시간을 정하는 keep_firing_for 설정은 생략했습니다.
확인 문제와 정답
for: 2m에서 1분까지 조건이 이어지면 상태는 무엇인가요?- 알림을 서비스별로 묶는 역할은 어느 도구가 담당하나요?
- 모델 입력을
[True, False, True, True, True]로 바꾸면 언제 Firing이 되나요?
정답: 1은 Pending입니다. 2는 Alertmanager입니다. 3은 4분입니다. 1분에 조건이 끊겨 시작 시각이 지워집니다. 2분에 대기를 새로 시작하고, 4분에 2분이 경과합니다.
대기 시간을 3분으로 바꾸면 조건이 이어져야 하는 시간도 달라집니다. 평가 시각마다 상태를 따라가며 확인할 수 있습니다. Prometheus Counter에서 초당 요청 수 읽기와 연결하면 오류 비율을 계산할 숫자와 알림 조건을 함께 정할 수 있습니다.
