指標が実際に流れるPrometheus

이 실습은 진짜 Prometheus 에서 돕니다

VM 안에 Prometheus · Alertmanager · node-exporter 가 실제로 떠 있습니다. node-exporter 가 진짜 지표를 내므로 PromQL 이 진짜 데이터를 다루고, 규칙은 실제로 평가되며, 알림은 실제로 발화해 Alertmanager 까지 갑니다.

PCA 과정의 다른 실습이 도는 가짜 클러스터에는 Prometheus 자체가 없습니다. 쿼리를 글로 쓰는 연습까지가 전부였습니다.

kube-prometheus-stack 을 쓰지 않습니다. 오퍼레이터가 설정을 대신 써 주면 prometheus.yml 을 만질 일이 없는데, PCA 가 묻는 것이 정확히 그 파일이기 때문입니다.

처음 뜨는 데 3분쯤 걸립니다.

준비된 것

Prometheus     http://127.0.0.1:30090   설정은 /etc/prometheus/prometheus.yml
Alertmanager   http://127.0.0.1:30093
규칙           /etc/prometheus/rules/rules.yml
대상           node-exporter(데몬셋) · demo-app · Prometheus 자신
질의 도구      promq 'up'

목표

스크레이프 설정부터 알림이 Alertmanager 에 도달하기까지 전 경로를 직접 연결합니다.

왜 중요한가

Prometheus 를 다루면서 가장 자주 막히는 자리는 문법이 아닙니다.

• 설정을 고쳤는데 반영이 안 됩니다. ConfigMap 볼륨은 kubelet 이 주기적으로 동기화해서 즉시 바뀌지 않습니다(약 60초). 전파 전에 reload 를 치면 옛 설정을 다시 읽고, reload 는 200 을 돌려줍니다.
• 알림이 안 옵니다. 규칙은 발화했는데 alerting.alertmanagers 를 안 적어 보낼 곳이 없는 경우가 흔합니다.
• up == 0 알림이 안 걸립니다. 대상이 사라지면 up 시계열 자체가 없어집니다. up == 0 은 대상이 있는데 응답하지 않을 때만 참입니다.

마지막이 특히 값집니다. "서비스가 죽으면 알림이 오겠지" 라고 믿었는데, 파드가 통째로 사라지는 배포 사고에서는 아무 알림도 오지 않습니다.

단계

1. 지금 무엇을 긁고 있는지 확인해 /root/pca/targets.txt 에 담으세요.
2. kubernetes_sd_configs 로 파드를 자동으로 찾게 하고 결과를 /root/pca/sd.txt 에 담으세요.
3. relabel_configs 로 애노테이션이 붙은 것만 남기고 app 라벨을 만들어 /root/pca/relabel.txt 에 담으세요.
4. PromQL 을 써 /root/pca/promql.txt 에 담으세요. instant=, range=, rate_result= 세 줄이 필요합니다.
5. 레코딩 룰을 하나 만들어(이름은 level:metric:operation 관례) 결과가 실제로 나오는 것을 /root/pca/recording.txt 에 담으세요.
6. 알림 규칙을 만들고 대상을 실제로 고장 내 firing 까지 가는 것을 /root/pca/alert.txt 에 담으세요. for 절도 씁니다.
7. Prometheus 가 Alertmanager 로 보내게 하고 실제로 도착한 것을 /root/pca/am.txt 에 담으세요.
8. /root/pca/report.md 에 up_targets=, alert_fired=yes, recording_rule= 세 줄과 설명을 쓰세요.

참고

• 질의는 promq 'up' 으로 합니다. 결과는 JSON 이라 | jq 로 걸러 보세요.
• 설정 파일을 고친 뒤에는 curl -XPOST http://127.0.0.1:30090/-/reload 를 치세요. 파드가 그 디렉터리를 hostPath 로 그대로 보므로 고치는 즉시 반영됩니다.
• reload 가 200 이 아니면 설정이 문법상 틀린 것입니다. 이때는 옛 설정이 그대로 살아 있어 서비스가 죽지는 않습니다.
• 대상 상태는 curl -s $P/api/v1/targets | jq 로 봅니다. droppedTargets 에는 릴레이블링에서 걸러진 것이 들어 있습니다.
• 6번에서 up == 0 을 만들려면 대상이 있으면서 응답하지 않아야 합니다. 아무도 듣지 않는 포트를 static_configs 로 가리키는 것이 가장 확실합니다.
• 흔한 실수 1: 파드를 지워 up == 0 을 만들려는 것. 대상이 목록에서 사라져 시계열 자체가 없어집니다. 그런 경우는 absent() 로 잡아야 합니다.
• 흔한 실수 2: 레코딩 룰 이름에 콜론을 안 쓰는 것. 규칙이 만든 지표와 원본 지표를 이름만 보고 구분할 수 없게 됩니다.

지금 무엇을 긁고 있나

지금 무엇을 긁고 있는지 확인해 /root/pca/targets.txt 에 담으세요.

/api/v1/targets 와 현재 prometheus.yml 을 함께 보세요.

대상을 손으로 적지 않는다

kubernetes_sd_configs 로 파드를 자동으로 찾게 하고 결과를 /root/pca/sd.txt 에 담으세요.

kubernetes_sd_configs 의 role: pod 를 쓰면 파드가 뜨고 질 때마다 목록이 따라옵니다.

무엇을 남기고 무엇을 버릴까

relabel_configs 로 애노테이션이 붙은 것만 남기고 app 라벨을 만들어 /root/pca/relabel.txt 에 담으세요.

__meta_ 로 시작하는 라벨은 릴레이블링 전에만 존재합니다. keep 으로 거르고 target_label 로 새 라벨을 만드세요.

진짜 데이터로 질의한다

PromQL 을 써 /root/pca/promql.txt 에 담으세요. instant=, range=, rate_result= 세 줄이 필요합니다.

instant=, range=, rate_result= 세 줄이 필요합니다. 카운터에는 rate() 를 씁니다.

미리 계산해 둔다

레코딩 룰을 하나 만들어(이름은 level:metric:operation 관례) 결과가 실제로 나오는 것을 /root/pca/recording.txt 에 담으세요.

이름은 level:metric:operation 관례를 따르세요. 콜론이 들어가야 원본 지표와 구분됩니다.

알림을 실제로 발화시킨다

알림 규칙을 만들고 대상을 실제로 고장 내 firing 까지 가는 것을 /root/pca/alert.txt 에 담으세요. for 절도 씁니다.

up == 0 은 대상이 있는데 응답하지 않을 때만 참입니다. 파드를 지우면 시계열 자체가 사라집니다.

알림이 갈 곳이 있어야 한다

Prometheus 가 Alertmanager 로 보내게 하고 실제로 도착한 것을 /root/pca/am.txt 에 담으세요.

alerting.alertmanagers 를 안 적으면 규칙이 발화해도 아무 데도 가지 않습니다.

무엇을 배웠나

/root/pca/report.md 에 up_targets=, alert_fired=yes, recording_rule= 세 줄과 설명을 쓰세요.

up_targets=, alert_fired=yes, recording_rule= 세 줄과 설명을 쓰세요.