전체 큰 그림

• Datacenter cluster (노드/애플리케이션이 실제로 뛰는 곳)에서 메트릭을 최대한 “가까운 곳”에서 긁어모아(pull) Prometheus Agent가 임시 버퍼(WAL)로 안전하게 잡아둔 뒤, LMV cluster의 중앙 Prometheus로**remote write(푸시)**한다 →
• Grafana가 그 Prometheus를 데이터 소스로 삼아 대시보드/탐색 → Prometheus가 룰 평가 후 Alertmanager로 알림.
• 원거리(클러스터 간)에서는 “중앙에서 당겨오기(scrape across networks)”보다 **에이전트가 원격으로 밀어넣기(remote write)**가 신뢰성과 장애 가시성 측면에서 유리
  • Prometheus 커뮤니티가 권장하는 흐름

Node Exporter (Datacenter cluster)

• 각 노드의 OS/하드웨어 지표(CPU, 메모리, 디스크, 네트워크 등)를 /metrics로 노출하는 경량 익스포터
  • 애초에 노드 리소스 지표라 “노드 바로 옆”에서 수집해야 정확하고 안정적
• 일반적으로 포트 9100, node_ 접두 메트릭을 제공.
• 배치 원칙
  • DaemonSet으로 전 노드에 배포
  • 보안·성능상 Node Exporter는 외부 노출 불필요(동일 클러스터 내 Prometheus Agent만 접근)

• “스크래퍼 전용” Prometheus
• 질의/저장/알림/룰 평가 기능은 비활성화하고, 스크랩+원격 전송에 최적화된 모드
• 로컬 TSDB 대신 WAL 버퍼만 유지해 네트워크 끊김 시 잠깐 버텨주고 회복되면 중앙에 재전송. 같은 설정/SD를 쓰되, 목적이 수집·전송에 집중된 경량 프로세스
  • 원래 Prometheus(일반 모드)의 구조
    • TSDB(Time Series Database)
      • Prometheus는 수집한 메트릭을 자기 로컬 디스크에 데이터베이스 형식으로 장기간 저장해요.
        • 시계열(time series) 데이터를 디스크 블록 단위로 계속 쌓아둠.
        • 이걸 기반으로 PromQL 쿼리, 대시보드 조회, 알림 룰 평가를 실행할 수 있음
        • 즉, “메트릭을 저장 + 질의 + 알림” 까지 다 하는 풀옵션 모드.
    • WAL(Write Ahead Log)
      • TSDB에 데이터를 넣기 전에, 잠깐씩 버퍼처럼 로그 파일에 임시 저장하는 곳.
        • 예: Prometheus가 샘플을 수집 → 먼저 WAL 파일에 씀 → 일정 시간이 지나면 TSDB 블록으로 확정 저장.
        • 이렇게 해야 Prometheus가 갑자기 꺼져도 최근 수집한 데이터를 복구할 수 있음.
  • Prometheus Agent 모드
    • WAL까지만 유지
      • 샘플을 잠깐 WAL에 모아두고, 네트워크가 가능할 때 원격 Prometheus로 전송(remote write).
      • 전송 성공하면 WAL에서 지워버리고, 자기 로컬엔 오래 안 남김.
        • “보내기 전 대기실” 같은 공간
    • WAL을 써야 하는 이유
      • PVC로 WAL 디렉토리를 영속화하면:
        • Pod 재시작 후에도 WAL에 있던 데이터가 남아있음 → 다시 읽어서 remote write 재전송 가능.
        • 네트워크 단절이나 Pod 장애에도 데이터 유실 최소화
      • 우리 프로젝트에서 부하 테스트 등을 수행하면 Pod가 죽을 수 있음
        • Pod가 죽는 순간 WAL 파일이 같이 날아감.
        • 그 직전에 모아두던 메트릭은 중앙 Prometheus로 전송되지 못하고 유실됨.
        • 대시보드에서 “데이터 구멍”이 생김
• 왜 바로 프로메테우스로 가지 않나?
  • 클러스터 경계를 건너 스크랩하지 말라는 권고
    • 네트워크 단절/지연이 “타깃 문제인지 네트워크 문제인지” 구분을 흐리게 한다. 로컬에서 pull→중앙에 push가 더 투명
• 교차 클러스터 전송 방식
  • remote write로 LMV의 중앙 Prometheus에 HTTP POST로 샘플을 전송(배칭·백오프·재시도 로직 포함)
• 라벨링
  • 에이전트 쪽에 external_labels로 cluster="datacenter" 같은 식별자를 붙여두면, 중앙에서 대시보드/알림 라우팅이 쉬워진다(클러스터별/노드풀별 필터링)

• 장기 저장(TSDB), 질의(PromQL), 녹화 룰(Recording rules), 알림 룰(Alerting rules) 의 단일 진실의 원천
• Grafana는 이 인스턴스를 단일 데이터 소스로 본다
• LoadBalancer로 외부와 통신
  • prometheus agent가 원격으로 푸시하려면 LMV 쪽 prometheus가 수신을 외부에서 접근 가능하게 열어야 함
  • 온프레 K8s라면 MetalLB 같은 L2 LB로 서비스에 고정 IP를 주는 패턴이 일반적. Prometheus는 원격 쓰기 수신 엔드포인트(/api/v1/write) 를 제공하며, 현대 버전은 --web.enable-remote-write-receiver 플래그로 활성화
• 보관·성능 설계
  • 보존 기간(예: 15~30일)과 디스크 용량을 중앙 Prometheus에서 결정
  • 고가용성이 필요하면 중앙을 2대 구성해 양쪽에 remote write(팬아웃) 하되, 그 경우엔 Thanos/Mimir 같은 쿼리 집계가 필요해 운영 복잡도가 오른다(초기엔 단일 인스턴스 권장)

• 중앙 Prometheus를 단일 데이터 소스로 연결해 대시보드/탐색/애드혹 분석.
• Grafana는 Prometheus용 데이터 소스 플러그인을 표준으로 제공

• Prometheus가 평가한 알림을 받아 중복 제거, 그룹핑, 라우팅 후 최종 수신자(Slack, 이메일, PagerDuty, 웹훅 등)로 전달