4.1 Scrape와 Target

Prometheus는 등록된 target 목록을 기준으로 exporter를 scrape합니다. Static target은 lab에 적합하고, instance가 자주 바뀌는 Kubernetes에서는 service discovery나 ServiceMonitor를 사용합니다.

Static configuration

scrape_configs:
  - job_name: postgres
    scrape_interval: 15s
    scrape_timeout: 10s
    static_configs:
      - targets:
          - db-a-exporter.internal:9187
          - db-b-exporter.internal:9187
        labels:
          environment: prod
          cluster: orders

scrape_interval보다 scrape_timeout을 짧게 둡니다. 한 번의 수집이 다음 주기까지 겹치지 않게 하고, exporter와 database에 느린 connection이 쌓이는 것을 막습니다.

Target label 정규화

기본 instance는 scrape 주소입니다. Exporter 주소와 실제 database 정체성이 다르면 relabeling으로 읽기 쉬운 label을 만듭니다.

relabel_configs:
  - source_labels: [__address__]
    regex: db-a-exporter\.internal:9187
    target_label: instance
    replacement: db-a:5432

Label은 dashboard 편의를 넘어 alert routing과 장기 비교의 key가 됩니다. Host 교체 때도 같은 cluster 이름을 유지하고, 실제 instance는 별도 label로 남기는 방식을 고려합니다.

Kubernetes ServiceMonitor

Prometheus Operator 환경에서는 ServiceMonitor가 scrape 설정을 선언합니다.

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: postgres-exporter
  namespace: monitoring
spec:
  namespaceSelector:
    matchNames: [database]
  selector:
    matchLabels:
      app: postgres-exporter
  endpoints:
    - port: metrics
      path: /metrics
      interval: 30s
      scrapeTimeout: 10s

ServiceMonitor가 존재해도 Prometheus custom resource의 serviceMonitorSelector가 이를 선택하지 않으면 target에 들어오지 않습니다. 문제를 볼 때는 Service, Endpoints, ServiceMonitor, Prometheus selector 순서로 확인합니다.

up과 scrape 내부 metric

Prometheus는 target마다 자체 metric을 만듭니다.

up{job="postgres"}
scrape_duration_seconds{job="postgres"}
scrape_samples_scraped{job="postgres"}
scrape_samples_post_metric_relabeling{job="postgres"}

scrape_duration_seconds가 timeout에 가까워지면 collector query나 database 응답이 느린 상태입니다. 새 collector를 활성화한 전후의 duration과 sample 수를 비교하면 비용을 수치로 확인할 수 있습니다.

Metric relabeling

불필요한 series는 저장 전에 제거합니다. 다만 drop 규칙은 데이터 손실이므로 사용 query와 alert를 먼저 검색합니다.

metric_relabel_configs:
  - source_labels: [__name__]
    regex: 'go_.*'
    action: drop

Exporter process metric을 모두 지우면 memory leak이나 GC 문제를 진단할 증거도 사라집니다. 저장 비용과 진단 가치 사이에서 결정합니다.

Target 장애 진단 순서

1. Prometheus /targets의 Last Error 확인
2. Prometheus host 또는 Pod에서 exporter URL 호출
3. Exporter log와 pg_up 확인
4. Exporter에서 PostgreSQL DNS/TCP/TLS/인증 확인
5. Collector query 시간과 database lock 확인

Prometheus server에서 접근 가능한 경로와 로컬 노트북에서 접근 가능한 경로는 다를 수 있습니다. 반드시 scrape 주체의 network 위치에서 확인합니다.

참고: Prometheus configuration, Prometheus Operator ServiceMonitor