Prometheus·Grafana로 상태와 이상 징후 읽기

01개념과 구성 요소

• Pull 수집Prometheus가 exporter의 /metrics 같은 endpoint를 주기적으로 요청한다.
• 시계열Metric 이름과 label 집합이 시계열을 구분하고 sample은 시각과 값을 가진다.
• 활용TSDB에 저장한 값을 PromQL로 계산하며 경보 규칙·Alertmanager·Grafana는 다른 처리 역할을 맡는다.

02메트릭 수집부터 경보 전달까지

1. 표본 노출Exporter가 counter·gauge 등 정의된 의미의 측정값을 HTTP 응답으로 제공한다.
2. 주기적 ScrapePrometheus가 scrape_interval에 따라 요청하고 성공·실패를 up과 관련 지표로 기록한다.
3. 시계열 저장Label 집합별 sample을 저장한다. 대상이 사라져 표본이 없는 상태와 값 0은 다르다.
4. 규칙 평가evaluation_interval에 따라 PromQL 식을 평가한다. Counter는 reset을 고려한 rate 뒤에 목적별 집계를 적용한다.
5. 경보 상태 변화조건이 지속되어 for 요건을 충족하면 pending에서 firing으로 이어질 수 있다.
6. 통지 라우팅Alertmanager가 grouping·중복 억제·silence·수신자 routing을 적용한다. 한 통지가 원시 사건 한 건과 같지는 않다.

03Exporter→Scrape→TSDB→PromQL

• 수집·저장Prometheus는 대상의 메트릭 endpoint에 주기적으로 요청하는 pull 수집 구조를 기본으로 한다. Node Exporter는 호스트의 CPU·메모리·파일시스템 등 지표를 HTTP 응답으로 제공하고 Prometheus는 sample을 시계열에 저장한다.
• GrafanaGrafana는 저장된 값을 질의·시각화하는 별도 구성요소이며 exporter나 TSDB를 대신하지 않는다.
• 실습 버전수업 자료의 Prometheus 2.51.0과 Node Exporter 1.7.0·1.8.2는 당시 버전 예이다. 지원 지표와 설정은 실제 버전·OS·exporter 구성에 따라 달라질 수 있다.

04Metric 이름과 Label이 시계열을 결정한다

• 시계열 식별하나의 시계열은 metric 이름과 label 집합으로 구분된다. 같은 node_cpu_seconds_total도 instance·cpu·mode가 다르면 다른 시계열이다.
• Sample·Job·Instancesample은 시간과 값이다. job은 수집 구성의 묶음, instance는 기본적으로 target 식별에 쓰이는 label이며 relabeling에 따라 달라질 수 있다.
• 카디널리티사용자 ID·전체 URL·요청 ID를 무제한 label로 넣으면 시계열 수가 급격히 커진다. 문자열이 짧아도 조합 수가 많으면 메모리와 저장 비용이 증가한다.
• Label 설계로그의 모든 필드를 metric label로 옮기는 방식이 적합하지 않은 이유다.

# TYPE training_requests_total counter
training_requests_total{result="success"} 120
training_requests_total{result="failure"} 7
# TYPE training_queue_depth gauge
training_queue_depth 3

가상 endpoint의 텍스트 표현 예입니다. counter와 gauge의 의미가 다릅니다.

05scrape와 evaluation 간격의 차이

• 수집·평가 주기scrape_interval은 대상에서 새 sample을 수집하는 주기이고 evaluation_interval은 기록·경보 규칙을 평가하는 주기다. 수집이 15초이고 평가가 30초이면 모든 수집 순간마다 새 경보 판정이 실행되는 것은 아니다.
• Timeoutscrape_timeout은 요청을 기다리는 한도이며 긴 응답은 실패 sample을 만들 수 있다.
• 자기 감시Prometheus 자신의 9090 job과 Node Exporter 9100 job은 수집 대상이 다르므로 분리한다. exporter를 추가하면서 자기 감시 job을 지우면 Prometheus 자체의 상태 지표를 잃는다.
• Localhost 구성아래는 같은 호스트의 교육용 구성 조각이며 컨테이너가 분리되면 localhost의 의미도 달라진다.

global:
  scrape_interval: 15s
  evaluation_interval: 30s
scrape_configs:
  - job_name: prometheus
    static_configs:
      - targets: ["localhost:9090"]
  - job_name: node
    static_configs:
      - targets: ["localhost:9100"]

원리를 설명하는 가상 학습 예시입니다.

06Counter를 rate로 읽는 이유

• CounterCounter는 누적량이며 프로세스 재시작 등으로 reset될 수 있다. 현재값 1000은 현재 초당 1000이라는 뜻이 아니다.
• Rate·Resetrate(counter[5m])는 구간의 증가 추세를 초당 값으로 계산하며 reset을 고려한다. 여러 시계열을 먼저 합쳐 버리면 개별 reset의 의미가 흐려질 수 있어 각 시계열의 rate를 구한 뒤 목적에 맞게 집계한다.
• GaugeGauge는 현재 queue 깊이·온도처럼 오르내리는 값이다. 이미 비율인 값에 다시 rate를 적용하면 원래 질문과 달라질 수 있다.
• Sample 조건interval 안에 충분한 sample이 있어야 하고 scrape 간격·누락·짧은 구간 선택은 그래프의 안정성에 영향을 준다.

10CPU·메모리·네트워크 식의 단위

• CPU 시간 비율node_cpu_seconds_total의 mode=idle을 rate로 변환하면 각 CPU가 구간 동안 쉬었던 시간 비율에 해당한다. instance별 평균을 1에서 빼고 100을 곱하면 idle 이외 시간의 비율이다.
• 집계 범위이 값은 특정 앱의 CPU 사용률이 아니라 호스트 전체의 집계다.
• 메모리메모리 식은 MemAvailable을 사용하므로 단순 free보다 재사용 가능한 메모리를 반영한다. OS와 exporter에 따라 지표 지원이 달라질 수 있다.
• 네트워크 단위네트워크 receive bytes counter의 rate는 초당 바이트이며 비트/초 표시에 맞추려면 8배 단위를 명시해야 한다. loopback·가상 인터페이스를 포함할지도 분석 목적에 따라 달라진다.

(1 - avg by (instance) (
  rate(node_cpu_seconds_total{mode="idle"}[5m])
)) * 100

(1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100

rate(node_network_receive_bytes_total[5m])

원리를 설명하는 가상 학습 예시입니다.

11UP과 애플리케이션 정상은 다르다

• Upup=1은 해당 scrape가 성공했다는 뜻이고 up=0은 실패했다는 뜻이다. HTTP 서버가 /metrics에 정상 응답하더라도 실제 업무 DB 연결이 실패할 수 있다.
• 대상 부재반대로 exporter만 중단되면 업무가 정상이어도 up=0이 된다. 최근 대상이 discovery에서 사라져 시계열 자체가 없는 상황도 0과 구분해야 한다.
• Targets 오류Targets에는 endpoint·최근 scrape·duration·error가 보인다. no route to host는 라우팅뿐 아니라 방화벽 reject 등으로도 발생할 수 있어 exporter 중단으로 즉시 단정하지 않는다.
• 실패 단계Connection refused, timeout, HTTP 401/403/404, TLS 검증 오류는 서로 다른 단계의 실패이다.

수업 원본 자료

수집 성공과 실패를 Targets에서 구분하기

원본 크기로 보기 ↗

이 자료에서 읽어낼 것

1. node_exporter_client는 0/1 up이며 해당 endpoint에 대한 수집이 실패했습니다. node_exporter_ubuntu의 1/1 up과 비교해 실패 범위를 분리합니다.
2. DOWN 행의 Error에 no route to host가 표시됩니다. 해당 시점의 연결 실패 단서이며 실제 경로, 연결 대상, 방화벽의 거부 응답 등 원인을 추가 확인해야 합니다.
3. Last Scrape는 최근 수집 시점과의 시간, Scrape Duration은 수집 소요 시간입니다. 애플리케이션 요청의 응답 시간과 같은 지표가 아닙니다.
4. UP은 수집 대상의 메트릭을 가져왔다는 상태입니다. 로그인이나 주문 같은 실제 사용자 기능까지 정상이라는 보장은 아니므로 별도의 기능 점검과 연결합니다.

Prometheus 공식 문서: 수집 대상과 up 지표 ↗

12Prometheus 서버 관점과 Grafana 서버 관점

• Prometheus 경로메트릭 요청은 Prometheus 서버가 수행한다. 사용자 브라우저에서 exporter 주소가 열린다고 같은 경로가 Prometheus에도 있다는 뜻은 아니다.
• Grafana 경로Grafana data source 검사 역시 Grafana 서버·컨테이너에서 Prometheus로의 요청이다. 두 단계에서 localhost가 각각 가리키는 대상이 다르다.
• 빈 패널UP인데 패널이 비어 있다면 collector가 해당 metric을 내보내는지, label 필터·job 변수·조회 기간·단위가 맞는지 확인할 수 있다. Community dashboard는 특정 지표와 변수를 가정하므로 모든 환경에서 패널이 자동으로 채워지는 것은 아니다.

13경보 상태와 Alertmanager

• Pending·FiringPrometheus가 경보 식을 평가하고 조건이 지속되면 pending에서 firing으로 이어질 수 있다. for 기간은 순간적인 흔들림을 줄이는 조건이지만 실제 장애 통보도 그만큼 늦출 수 있다.
• Absent 처리수집 대상 누락과 값 0을 구분하지 못한 식은 원래 감시하려던 장애에서 아무 경보도 만들지 않을 수 있다.
• AlertmanagerAlertmanager는 전달받은 경보의 grouping·중복 억제·silence·수신자 routing을 담당한다. 통지 한 건이 원시 이벤트 한 건과 같은 수량은 아니다.
• 경보 전달 추적경보가 발생하지 않는 문제를 수집 식·규칙 평가·Alertmanager 전달·routing·수신 단계로 분해한다.

14WAL·Head·Block과 보존

• Head·WAL·Block최근 sample은 head 영역과 WAL 등 저장 구조에서 관리되고 시간이 지나면 block으로 정리된다. 보존 기간, scrape 간격, 활성 시계열 수와 label 조합이 필요한 저장량에 영향을 준다.
• 파일 관리실행 중인 데이터 파일을 임의로 삭제하는 것은 안전한 보존 정책 적용과 다르다.
• 그래프 상태그래프의 값 0·sample 없음·조회 범위 밖·label 조건 불일치는 서로 다른 상태다. 지표를 조회할 수 있는 상태와 지표가 질문에 맞는 의미를 가진 상태를 분리해야 모니터링 화면을 장애 원인 설명에 사용할 수 있다.