Monitoring on Kubernetes

개요

Observability는 시스템의 상태를 외부에서 파악할 수 있는 능력을 의미하며, 세 가지 핵심 신호(Pillar)로 구성됩니다.

Pillar	설명	특징	예시
Metric	시간에 따른 수치 데이터	집계된 데이터, 경량, 알림에 적합	CPU 사용률, 요청 수, 에러율
Log	개별 이벤트의 상세 기록	비정형/정형 텍스트, 디버깅에 적합	에러 스택트레이스, 요청 로그
Trace	분산 시스템에서 요청의 전체 경로	Span의 트리 구조, 병목 지점 파악에 적합	서비스 A → B → C 호출 흐름

세 가지를 조합하면: Metric이 이상을 감지하고, Trace가 어디서 발생했는지 보여주고, Log가 왜 발생했는지 알려줍니다.

Datadog vs Grafana Stack

모니터링 도구는 크게 두 가지 선택지가 있습니다.

• Datadog: 공식 문서가 매우 잘 되어 있고 쉬운 사용성과 강력한 편의성을 제공하지만 비쌉니다.
• Grafana Stack: 오픈소스와 Grafana Cloud 중 선택이 가능하고 기능은 Datadog에 뒤떨어지지 않지만 도입 난이도가 있습니다.

아래에서는 Grafana 스택(Prometheus, Loki, Tempo, Alloy)을 중심으로 정리합니다.

---

Metric: Prometheus & Thanos

설치

Prometheus는 kube-prometheus-stack으로 설치하는 것이 일반적입니다. 멀티 클러스터 환경에서는 각 클러스터에 Prometheus를 설치하고, Thanos로 중앙 집계합니다.

설치 시 주의사항

• Prometheus CRD가 매우 크기 때문에 Argo CD에서 동기화 문제가 발생할 수 있습니다. Server-side Apply를 적용하면 해결됩니다.
• Argo CD와 함께 사용할 때 CRD 설치 타이밍 문제가 있어 PreSync 등 사이클을 일부 리소스에 적용해야 할 수 있습니다.
• 클러스터 간 gRPC 통신이 필요할 때, Azure Application Gateway 등 HTTP/2를 지원하지 않는 LB가 있을 수 있습니다. 이 경우 NGINX Ingress Controller 등으로 우회합니다.
• Thanos의 Store Gateway 등 Object Storage에서 데이터를 불러오는 컴포넌트는 OOM이 발생하기 쉽습니다. 처리하는 데이터량에 비례하여 리소스를 설정해야 합니다.

메트릭 수집 확장

필요한 곳에서 Metric 기능을 활성화하고, ServiceMonitor를 사용하여 Prometheus에 추가합니다.

일반적으로 메트릭을 수집하는 대상:

• Ingress Controller (Ingress NGINX)
• Autoscaler (KEDA, HPA)
• GitOps 도구 (Argo CD, Flux)
• ML Serving (Triton Inference Server 등)
• 애플리케이션 커스텀 메트릭 (Prometheus Client 라이브러리 사용)

---

Log: Alloy + Loki

구성

로그 수집은 Alloy + Loki를 사용합니다.

• Alloy: 모든 클러스터에 DaemonSet으로 설치하여 로그를 수집하고 Loki에 전달합니다. 메타데이터 파싱도 가능하므로 Fluentd 등 추가 도구가 불필요합니다.
• Loki: 로그를 중앙에 모아 검색하고 분석합니다. 중앙 클러스터에 설치합니다.

설치 시 주의사항

1. Alloy
   • 모든 노드에 배포되어야 하므로 모든 Taint를 무시할 수 있도록 Toleration을 추가합니다.
   • alloy.configMap.config에서 로그 수집 Flow와 전처리를 설정합니다.
2. Loki
   • Object Storage(S3 등) 설정과 리소스 설정이 핵심입니다.
   • S3 Secret 설정은 Grafana Community 가이드를 참고합니다.

Alloy Flow

Alloy의 로그 수집 흐름은 다음과 같습니다. (Alloy를 Port-forward하여 해당 다이어그램을 확인할 수 있습니다.)

• discovery.kubernetes: Kubernetes 상에서 Pod를 탐색합니다.
  • nodeName을 통해 같은 노드에 있는 Pod만 필터링합니다.
• discovery.relabel: K8s 라벨 등을 기반으로 메타데이터를 재정의하고 Pod를 분류합니다.
• loki.source.kubernetes: 탐색한 Pod를 기반으로 로그를 수집합니다.
  • K8s API를 통해 로그를 수집하므로, nodeName 필터링 없이는 전체 노드의 로그가 중복 수집됩니다. CPU/MEM 낭비를 방지하려면 반드시 필터링이 필요합니다.
• loki.process: 로그를 파싱하고 메타데이터를 추가합니다.
• loki.write: 로그를 Loki에 전달합니다.

자세한 설정은 Alloy Components Reference를 참고합니다.

Loki Keywords

• Gossip Ring: memberlist 기반 노드 간 상태 전파 프로토콜. Consul/etcd 대신 Grafana 스택(Loki, Mimir, Tempo)에서 권장합니다.
• Replication Factor: 각 로그 스트림을 몇 개의 ingester에 복제할지 결정합니다.
• TSDB Index: Loki 2.8+부터 권장되는 인덱스 방식. (기존은 BoltDB Shipper)
• Structured Metadata: Loki 3.0에서 기본 활성화. Cardinality 부담 없이 추가 메타데이터 저장/검색이 가능합니다.
• OTLP Native Ingestion: Loki 3.0+부터 /otlp/v1/logs 엔드포인트로 OpenTelemetry 로그를 직접 수집할 수 있습니다.

---

Trace: Tempo

Tempo란

Grafana Tempo는 대용량 분산 트레이싱 백엔드입니다. 핵심 특징은 인덱싱 없이 Object Storage(S3, GCS, Azure Blob)에 직접 저장한다는 것입니다. 이로 인해 운영이 단순하고 비용이 낮습니다.

아키텍처

     ┌──────────────┐
     │  Application │  (OTLP, Jaeger, Zipkin)
     └──────┬───────┘
            ▼
     ┌──────────────┐    TraceID 해싱
     │ Distributor  │──────────────────┐
     └──────────────┘                  ▼
                               ┌──────────────┐
                               │   Ingester   │  WAL에 임시 저장
                               └──────┬───────┘
                                      ▼
                               ┌──────────────┐
                               │Object Storage│  S3, GCS 등
                               └──────┬───────┘
                                      ▼
     ┌──────────────┐         ┌──────────────┐
     │Query Frontend│────────▶│   Querier    │  블록 병렬 검색
     └──────────────┘         └──────────────┘
            ▲
     ┌──────────────┐
     │  Compactor   │  블록 병합, 검색 공간 최적화
     └──────────────┘

• Distributor: 여러 포맷(OTLP, Jaeger, Zipkin)의 span을 수신하고 TraceID 해싱으로 Ingester에 라우팅합니다.
• Ingester: span 데이터를 WAL에 임시 저장 후 Object Storage에 flush합니다.
• Querier: Object Storage에서 블록을 병렬로 검색합니다. Query Frontend가 요청을 분할하여 여러 Querier에 분배합니다.
• Compactor: 블록을 병합하여 검색 성능을 최적화합니다.

TraceQL

Tempo는 PromQL, LogQL에 이어 TraceQL이라는 전용 쿼리 언어를 제공합니다.

// 500ms 이상 걸린 HTTP GET 요청의 trace 검색
{ span.http.method = "GET" && span.http.status_code >= 500 && duration > 500ms }

DevOps 팁

1. Sampling 전략: 모든 trace를 저장하면 비용이 급증합니다.
   • Head Sampling: 요청 시작 시점에 샘플링 여부 결정. 구현이 단순하지만 에러 trace를 놓칠 수 있습니다.
   • Tail Sampling: 요청 완료 후 결과를 보고 샘플링. 에러나 느린 요청을 확실히 잡지만 메모리를 더 사용합니다.
   • OpenTelemetry Collector나 Alloy에서 tail sampling을 설정할 수 있습니다.
2. Span 크기 제한: max_attribute_bytes 기본값은 2048입니다. 큰 attribute를 보내는 서비스가 있으면 OOM의 원인이 됩니다.
3. Alloy 연동: Alloy는 로그뿐 아니라 OTLP로 trace도 수집하여 Tempo에 전송할 수 있습니다. 로그와 트레이스를 하나의 agent로 처리할 수 있습니다.
4. Metrics Generator: Tempo가 trace 데이터로부터 RED 메트릭(Rate, Error, Duration)을 자동 생성하여 Prometheus에 전달할 수 있습니다. 별도의 계측 없이 서비스 수준 메트릭을 얻을 수 있습니다.
5. Trace-Log 연결: 로그에 traceID를 포함시키면 Grafana에서 로그 → trace, trace → 로그 간 이동이 가능합니다. 장애 분석 속도가 크게 향상됩니다.

---

UI: Grafana

kube-prometheus-stack에서 Grafana를 활성화하여 사용합니다. Loki와 Tempo가 중앙화되어 있다면 Grafana도 1곳에만 설치하면 됩니다.

대시보드는 Grafana Dashboards에서 커뮤니티 대시보드를 가져와 수정하는 것이 효율적입니다.