Devtools 개요

핵심 질문

• metric은 application에서 Prometheus까지 어떻게 노출·수집·저장되는가?
• PromQL은 어떤 time-series question에 답하고, Grafana는 그 결과를 어떻게 탐색하게 하는가?
• Alertmanager는 언제 alert delivery와 routing을 담당하는가?

읽기 경로

1. Prometheus
2. Prometheus Exporter
3. PromQL
4. Grafana
5. Loki
6. Alertmanager
7. 장애 자동 대응의 안전장치

Build·delivery 경로

1. Docker Platform
2. Docker Build Cache Design
3. GitHub Actions Workflow

메트릭·로그·경보의 흐름

• 아래 그림은 Prometheus, Loki, Alertmanager의 역할을 연결한다. 화살표는 라벨에 적힌 요청·설정·전달의 방향이며, 요청의 응답 데이터까지 함께 표시하지 않는다.
• 로그 수집기는 현재 Wiki의 Promtail 사례를 표시한다. webhook을 받은 뒤의 검증과 실행 정책은 장애 자동 대응의 안전장치에서 읽는다.

flowchart LR
    T[Application / host / target]
    E[Exporter or instrumented app]
    P[Prometheus]
    G[Grafana]
    R[Alert rule]
    M[Alertmanager]
    C[Receiver]
    T -->|메트릭 노출| E
    P -->|메트릭 scrape 요청| E
    G -->|PromQL 조회 요청| P
    G -->|LogQL 조회 요청| L[Loki]
    T -->|로그 읽기 대상| A[Promtail]
    A -->|로그 push| L
    R -->|평가 규칙 설정| P
    P -->|규칙 평가로 생성한 경보 전달| M
    M -->|그룹화와 라우팅 뒤 알림 전달| C
    C -->|조치 요청 검증과 실행 정책 적용| GR[Guarded Alert Remediation]

현재 범위

• 현재 source는 Prometheus monitoring stack과 Docker·GitHub Actions의 build/delivery boundary를 함께 다룬다.
• Prometheus, Alertmanager, Grafana의 공식 문서를 함께 확인해 configuration, alert lifecycle, datasource/variable 모델을 보강했다.
• Docker는 client-daemon, image/container, volume/network lifecycle까지, GitHub Actions는 event-triggered workflow·job·step·runner model까지 다룬다.
• Dockerfile detail, build-cache rule, Compose syntax, reusable workflow·secret forwarding recipe는 추가 official source가 생길 때 확장한다.
• blackbox_exporter는 target의 /metrics를 전달하는 exporter가 아니라 target을 probe하고 probe 결과를 노출하는 예외적 흐름이다.