컨테이너가 실행 중이라는 사실만으로 서비스 상태를 판단할 수 없습니다. 장애를 진단할 때는 먼저 읽기 전용 명령으로 현재 값을 확인하고, 같은 지표를 시계열로 수집해 지속 여부를 판정합니다. 이 글은 새 실측치를 만들지 않고, 이미 확인된 측정값과 PromQL·Grafana 설정 기준만으로 지표를 해석하는 순서를 정리합니다.
한 시점의 실제 측정값
2026년 9월 13일 KST에 실행 중인 컨테이너 한 개의 리소스 사용량을 측정했습니다. docker stats --no-stream 결과는 CPU 0.08%, 메모리 178.9MiB / 15.39GiB, 네트워크 수신·송신 671MB / 31.3MB였습니다. docker inspect의 재시작 횟수는 0이었고 healthcheck는 구성되지 않았습니다.
docker stats --no-stream
curl -sS http://<prometheus-host>:<port>/-/ready
이 값은 단일 시점 표본이므로 정상 범위를 증명하지 않습니다. CPU 0.08%가 낮아 보여도 요청이 없던 시점일 수 있고, 누적 Network I/O만으로 현재 트래픽 급증을 판정할 수도 없습니다. 메모리 사용량과 limit, 재시작 횟수를 함께 기록하고 이전 값과 비교해야 합니다.
cAdvisor에서 Prometheus target까지 확인합니다
cAdvisor는 컨테이너 CPU·메모리·네트워크 계열 지표를 노출하고 Prometheus는 scrape_configs에 등록된 target을 주기적으로 수집합니다. 먼저 cAdvisor의 /metrics가 응답하는지 확인하고 Prometheus의 Targets 화면에서 해당 job이 UP인지 확인합니다. target이 DOWN이면 Grafana 패널보다 주소, 네트워크, metrics 경로, scrape 오류부터 점검합니다.
수집 순서는 cAdvisor /metrics → Prometheus target UP → PromQL 결과 존재 → Grafana 패널과 알림입니다. 앞 단계가 비어 있으면 다음 단계의 빈 그래프를 정상으로 해석하지 않습니다.
PromQL 문법과 결과를 분리해 판정합니다
CPU 사용률 예시는 sum by (name) (rate(container_cpu_usage_seconds_total{name!=""}[5m])) * 100입니다. 메모리 비율은 container_memory_working_set_bytes{name!=""} / container_spec_memory_limit_bytes{name!=""} * 100으로 확인합니다. 두 식은 Prometheus 3.6.0의 promtool check rules로 문법 검사를 통과했습니다. 실제 시계열 결과는 각 운영 환경의 cAdvisor·Prometheus 스택에서 직접 확인해야 합니다.
CPU는 5분 평균이 평소 범위에 있고 처리 지연이 없다면 관찰을 계속합니다. 평소 기준을 넘는 상태가 10분 이상 지속되거나 메모리 비율이 계속 상승하면 조사 대상으로 전환합니다. 메모리 limit이 0이거나 지표가 없으면 백분율을 계산하지 않고 Compose 제한 설정과 exporter 라벨부터 확인합니다. 재시작 횟수가 증가하면 같은 시각의 종료 코드와 애플리케이션 로그를 대조합니다.
Grafana 알림을 조사 절차와 연결합니다
Grafana 패널은 PromQL 결과의 추세를 보여주고, 알림 규칙은 쿼리·임계값·평가 간격·지속 시간을 함께 정의합니다. 한 번의 급등으로 바로 알리지 않고 예를 들어 1분마다 평가하면서 10분 지속 조건을 둡니다. 알림에는 대상 라벨, 발생 시각, 현재값, 대시보드 링크를 넣어 같은 시각대의 docker inspect와 로그를 확인할 수 있게 합니다.
공식 기준은 Docker stats, Prometheus 설정, PromQL 기본, Grafana alert rule 문서에서 확인할 수 있습니다.