用实测数据读 cAdvisor 与 node exporter

목표

이 사이트를 돌리는 7노드 클러스터에서 뜬 실측 지표로 cAdvisor·node exporter 의 숫자를 읽습니다. 끝나면 컨테이너 CPU·메모리·throttle 지표를 보고 "이게 많은 건가" 에 근거를 갖고 답할 수 있습니다.

왜 중요한가

PromQL 문법을 다 알아도, 지표가 무엇을 센 것인지 모르면 숫자를 해석할 수 없습니다. 누적 카운터의 크기는 오래 산 컨테이너가 항상 이기고, working set 과 usage 는 다른 것을 세며, CPU 한도는 cAdvisor 가 아니라 kube-state-metrics 가 알려 줍니다. 이 셋을 모르면 대시보드는 예쁘지만 판정은 매번 틀립니다. 여기서 만지는 자료는 실제 클러스터의 것이라 값이 깔끔하지 않습니다 — throttle 은 0.19% 이고, 한도가 없는 컨테이너에는 지표가 아예 없습니다. 현장이 그렇습니다.

자료에 대해

• 창은 고정된 3시간입니다. lab-realdata 로 확인하세요.
• 질의는 promq-at "<PromQL>" 로 던집니다. 이 도우미가 창 안의 고정된 시각으로 묻습니다. 그냥 promq 를 쓰면 지금 시각이라 결과가 빕니다.
• 익스포터 노출 형식 원문은 /opt/lab/realdata/expo/ 에 있습니다.
• 출처·채집 시각·손본 내용은 /opt/lab/realdata/README.md 에 적혀 있습니다. 내부 IP 와 호스트 이름은 지우지 않았습니다 — 이 사이트의 실제 클러스터입니다.

단계

1. lab-realdata 로 창을 확인하고, monitoring 네임스페이스에서 container_cpu_usage_seconds_total 을 내보내는 파드가 몇 개인지 세는 쿼리를 /root/pca-exporters/01-count.promql 에 씁니다(계열 수가 아니라 파드 수입니다).
2. monitoring 의 prometheus 컨테이너가 지금 몇 코어를 쓰는지 내는 쿼리를 /root/pca-exporters/02-cpu-rate.promql 에 씁니다.
3. CFS throttle 비율(throttled_periods / periods, 윈도 [1h])의 최댓값을 내는 쿼리를 /root/pca-exporters/03-throttle.promql 에, 그 비율이 가장 높은 컨테이너 이름을 /root/pca-exporters/03-throttle.txt 에 한 줄로 씁니다.
4. monitoring 의 grafana 컨테이너에서 container_memory_usage_bytes 와 container_memory_working_set_bytes 의 차이를 내는 쿼리를 /root/pca-exporters/04-inactive.promql 에, 그 차이와 같은 값을 내는 지표 이름을 /root/pca-exporters/04-inactive.txt 에 씁니다.
5. ai 네임스페이스 tts 컨테이너의 QoS 클래스를 id 라벨에서 읽어 /root/pca-exporters/05-qos.txt 에 한 줄로 씁니다.
6. /opt/lab/realdata/expo/cadvisor-nuc1.txt 에는 있는데 프로메테우스에는 없는 지표 이름을 세 개 이상 찾아 /root/pca-exporters/06-dropped.txt 에 한 줄에 하나씩 씁니다.
7. ai 네임스페이스에서 CPU 한도 대비 사용률이 가장 높은 값을 내는 쿼리를 /root/pca-exporters/07-limit-join.promql 에 씁니다.
8. 192.168.219.120:9100 노드의 CPU 사용률(0~1)을 내는 쿼리를 /root/pca-exporters/08-node-cpu.promql 에 씁니다.
9. 같은 노드의 MemAvailable 과 MemFree 차이를 내는 쿼리를 /root/pca-exporters/09-mem-available.promql 에 씁니다.

참고

• promq-at "count(up)" 처럼 따옴표 안에 쿼리를 넣습니다. 파일에 쓴 쿼리는 promq-at "$(cat <파일>)" 로 던져 보세요.
• 흔한 실수 1: 결과가 비면 쿼리가 아니라 시각을 의심하세요. promq 는 지금 시각으로 묻고, 실측 자료는 과거의 고정된 창에만 있습니다.
• 흔한 실수 2: 라벨 집합이 다른 두 지표를 그냥 나누거나 빼면 결과가 빕니다. on(...) 으로 맞추거나 같은 라벨로 좁히세요.

적재된 실측 자료 확인하고 파드 수 세기

lab-realdata 가 질의할 수 있는 시각의 창을 알려 줍니다. 질의는 promq-at 으로 던지세요 — 지금 시각으로 던지면 창 밖이라 빈 결과가 옵니다. count() 를 그냥 쓰면 계열 수, 즉 컨테이너 수가 나옵니다. 파드 하나에 컨테이너가 여럿일 수 있으니 pod 로 먼저 묶은 뒤 세야 파드 수가 됩니다.

누적 카운터의 기울기 재기

container_cpu_usage_seconds_total 은 태어난 뒤 쓴 CPU 초를 계속 더한 값입니다. 지금 몇 코어를 쓰는지는 rate 로 기울기를 재야 나옵니다. 창 안이면 윈도는 [5m]~[30m] 아무거나 좋습니다. 네임스페이스 전체가 아니라 prometheus 컨테이너 하나로 좁히세요.

throttle 비율로 한도 초과 판정하기

throttled_periods 는 개수라서 그 값만으로는 심각한지 알 수 없습니다. 같은 윈도의 periods 로 나눠 비율을 내세요. 가장 높은 컨테이너는 topk(1, ...) 로 찾고, 결과의 container 라벨을 읽습니다. 한도가 없는 컨테이너에는 이 지표가 아예 없습니다.

usage 와 working set 의 차이가 무엇인지 확인하기

두 지표를 같은 라벨로 좁혀 빼면 됩니다. 라벨 집합이 다르면 뺄셈 결과가 비어 버립니다. 그 차이와 똑같은 값을 내는 지표가 따로 있습니다 — promq-at 으로 grafana 컨테이너의 container_memory_ 로 시작하는 지표들을 훑어보세요.

cgroup 경로에서 QoS 클래스 읽기

container_cpu_usage_seconds_total 의 id 라벨이 cgroup 경로 그대로입니다. kubepods-besteffort · kubepods-burstable 마디를 찾으세요. Guaranteed 파드는 그 마디가 아예 없습니다. ai 네임스페이스의 tts 컨테이너를 보면 됩니다.

원문에는 있는데 프로메테우스에는 없는 지표 찾기

/opt/lab/realdata/expo/cadvisor-nuc1.txt 가 kubelet 이 실제로 내보낸 원문입니다. 거기 있는 지표 이름을 promq-at 으로 하나씩 던져 보세요. 결과가 비는 것이 스택의 metric_relabel 이 버린 지표입니다. 세 개 이상 찾아 적으세요.

kube-state-metrics 와 이어 붙여 한도 대비 사용률 내기

한도는 cAdvisor 쪽에 없으니 kube_pod_container_resource_limits 에서 가져옵니다. 두 지표는 라벨 집합이 달라서 그냥 나누면 결과가 빕니다. 양쪽을 sum by (pod,container) 로 같은 라벨까지 줄이거나 on(pod,container) 로 맞추세요. resource="cpu" 로 좁히는 것을 잊지 마세요 — 메모리 한도까지 섞이면 값이 무의미해집니다.

모드별 누적 시간에서 노드 CPU 사용률 내기

node_cpu_seconds_total 은 코어 하나 × 모드 하나마다 계열 하나입니다. idle 모드의 rate 를 코어 수로 평균 내고 1 에서 빼면 0~1 사이 사용률이 됩니다. sum 을 쓰면 코어 수만큼 커집니다. 노드는 192.168.219.120:9100 입니다.

MemFree 와 MemAvailable 의 차이 재기

두 지표를 같은 instance 로 좁혀 빼면 됩니다. 이 차이가 '지금은 캐시가 쓰고 있지만 필요하면 내어 줄 수 있는 메모리' 입니다. 노드는 앞 단계와 같은 192.168.219.120:9100 입니다.