[서론]
이제 관측 해야지. 사실 관측 설치는 하는 거 보다 어떻게 할지 확인하는 게 더 어려울 것 같다.
우선 전반적으로 알아보자.
[4.1 관측 가능성이란]
관측 가능성의 3요소
metrics : 숫자
logs: 텍스트
traces: 흐름
이걸 추출하기 위해
메트릭 모니터링 : 프로메테우스 + 그라파나
로그 모니터링 : Loki + Fluent Bit
이걸 4장에서 진행할 것이다.
트레이스는 8장에서 진행한다고 한다.
[4.2 메트릭 모니터링: 프로메테우스 + 그라파나]
Prometheus가 하는일
- pull 기반 수집으로 30초마다 각 pod의 /metrics endpoint 조회
- PromQL 시계열 데이터를 쿼리하는 전용 언어
- ServiceMonitor CRD : 어떤 서비스를 스크랩할 지 정의
Grafana가 하는 일
- Prometheus 데이터 시각적 대시보드로 표시
- Loki나 Tempo도 사용 가능
kube-state-metrics -> 쿠버네티스 API의 오브젝트 상태 가져옴 (Pod의 객수, Pod이 CrashLoopBackOff다)
node-exporter -> VM의 수준 정보 수집 (CPU 사용률, 메모리 사용량 등)
DaemonSet은 모든 노드에 한개씩 띄어줌.
비교하기
| 도구 | 특징 | 장점 | 단점 | 적합도 |
| Prometheus + Grafana | 오픈소스, Pull 기반 메트릭 수집, PromQL 지원 | 무료, Kubernetes 표준, 거대한 생태계 | 자체 운영 필요, 기본 구성만으로는 장기 저장에 한계 | ★★★ |
| Datadog | SaaS, 에이전트 기반 통합 모니터링 | 설정 간편, 통합 대시보드, APM 지원 | 유료, 호스트 증가 시 비용 예측 어려움 | ★★ |
| CloudWatch | AWS 네이티브 모니터링 서비스 | AWS 서비스 통합, 별도 인프라 관리 불필요 | GKE 환경에서 사용 불편, 커스텀 메트릭 비용 부담 | ★ |
| Google Cloud Monitoring | GCP 네이티브 모니터링 서비스 | GKE 통합, 무료 사용량 제공, 관리 부담 적음 | 커스텀 대시보드 제약, 모니터링 스택 학습 목적에는 부족 | ★★ |
설치하기
1. brew install helm
2. yaml 파일 만들기
prometheus:
prometheusSpec:
resources:
requests:
cpu: 100m
memory: 256Mi
limits:
memory: 512Mi
retention: 6h
storageSpec: {}
grafana:
resources:
requests:
cpu: 50m
memory: 128Mi
limits:
memory: 256Mi
persistence:
enabled: false
alertmanager:
alertmanagerSpec:
resources:
requests:
cpu: 25m
memory: 64Mi
limits:
memory: 128Mi
prometheusOperator:
resources:
requests:
cpu: 25m
memory: 64Mi
limits:
memory: 128Mi
kube-state-metrics:
resources:
requests:
cpu: 10m
memory: 32Mi
limits:
memory: 64Mi
nodeExporter:
resources:
requests:
cpu: 10m
memory: 16Mi
limits:
memory: 32Mi3. 실행하고 pod 상태 확인하기
kubectl --context gke-sysnet4admin_book_gitaiops -n monitoring get pods -o wide
promehtus의 각 pod 설명하기
StatfulSet은 Pod에 고정 이름이 붙음.
`monitoring` 네임스페이스에 뜬 7개 Pod은 kube-prometheus-stack Helm 차트가 한 번에 설치한 컴포넌트들입니다.
1. `alertmanager-kube-prometheus-kube-prome-alertmanager-0` (2/2) — Alertmanager. Prometheus가 감지한 알림(경고 규칙 트리거)을 받아 중복 제거·그룹핑·라우팅하는 역할. 2/2인 이유는 alertmanager 컨테이너 + config-reloader 사이드카가 함께 뜨기 때문.
2. `kube-prometheus-grafana-xxxxx` (3/3) — Grafana 본체. 대시보드로 메트릭을 시각화. 3/3인 이유는 grafana 메인 컨테이너 외에 `grafana-sc-dashboard`(ConfigMap으로 정의된 대시보드를 자동 로드하는 사이드카), `grafana-sc-datasources`(데이터소스 자동 등록 사이드카) 2개가 함께 뜨기 때문.
3. **`kube-prometheus-kube-prome-operator-xxxxx`** (1/1) — Prometheus Operator. Prometheus, Alertmanager, ServiceMonitor, PrometheusRule 같은 CRD를 감시하다가 실제 StatefulSet/설정을 자동으로 만들어주는 컨트롤러. 나머지 컴포넌트들의 "관리자" 역할.
4. **`kube-prometheus-kube-state-metrics-xxxxx`** (1/1) — kube-state-metrics. Kubernetes API 서버에서 Pod 개수, Deployment replica 상태, 재시작 횟수 같은 "오브젝트 상태"를 Prometheus가 읽을 수 있는 메트릭 형태로 변환해주는 역할.
5~6. **`kube-prometheus-prometheus-node-exporter-xlmh6`, `-zltpj`** (1/1 각각) — node-exporter. 노드(호스트 머신) 자체의 CPU/메모리/디스크/네트워크 사용량을 수집. DaemonSet이라 노드마다 1개씩 뜨는 게 정상이고, 지금 노드가 2개(e2-medium ×2)라서 2개가 보이는 것.
7. **`prometheus-kube-prometheus-kube-prome-prometheus-0`** (2/2) — Prometheus 서버 본체. 실제로 메트릭을 수집(scrape)·저장하고 PromQL 쿼리를 처리하는 핵심 컴포넌트. 2/2인 이유는 prometheus 컨테이너 + config-reloader 사이드카(설정 변경 시 재시작 없이 리로드) 조합.
즉 "수집(node-exporter, kube-state-metrics) → 저장/쿼리(Prometheus) → 알림(Alertmanager) → 시각화(Grafana)"를 Operator가 조율하는 구조이고, 컨테이너 수가 2~3개인 Pod들은 사이드카(설정 리로더, 대시보드 로더) 때문입니다.
그라파나에서 접속하기
kubectl을 통해서 로컬에 접속가능하게 포트포워딩 하기
kubectl port-forward svc/kube-prometheus-grafana -n monitoring 3000:80 &
쿠버네티스는 기본적으로 20개 이상의 대시보드를 만들어낸다.
프로메테우스 메트릭 확인하기
port-foward로 확인해버렷
kubectl --context gke-sysnet4admin_book_gitaiops -n monitoring port-forward svc/kube-prometheus-kube-prome-prometheus 9090
[4.3 로그수집: Fluent Bit + Loki ]
Fluent Bit이 하는 일
- Daemonset으로 모든 노드에 1개씩 배포
- 해당 노드의 모든 컨테이너 로그를 자동 수집
- 수집한 로그를 Loki에 전송
Loki가 하는일
- 로그를 라벨 기반으로 저장
- LogQL 쿼리 언어
- Grafana에서 바로 조회 가능
풀리퀘스트 인덱싱 : 모든 단어에 색인하는 방식 (elastice search -> 검색속도 빠른 대신 메모리 많이 씀)
라벨 기반 인덱싱 : 메타데이터만 인덱싱 (Loki -> 메모리 적게 소모하는 대신 검색 속도 느림)
비교하기
| 도구 | 특징 | 장점 | 단점 | 적합도 |
| Loki + Fluent Bit | 라벨 기반 인덱싱, Grafana 통합 | 경량 운영 가능낮은 인프라 비용Grafana 네이티브 연동 | 복잡한 풀텍스트 검색 성능이 상대적으로 낮음 | ★★★ |
| ELK Stack | Elasticsearch, Logstash, Kibana 조합 | 강력한 풀텍스트 검색성숙한 생태계다양한 분석 기능 | 높은 메모리 요구량구축 및 운영 복잡도 증가 | ★ |
| CloudWatch Logs | AWS 네이티브 로그 관리 서비스 | 별도 인프라 관리 불필요AWS 서비스와 높은 통합성 | GKE 환경과의 통합이 불편함AWS 종속성 발생 | ★ |
| Google Cloud Logging | GCP 네이티브 로그 관리 서비스 | GKE 로그 자동 수집운영 부담이 낮음무료 사용량 제공 | 복잡한 커스텀 쿼리에 제약Grafana 연동성이 상대적으로 낮음 | ★★ |
설치하기
yaml 파일 만들기
deploymentMode: SingleBinary
loki:
useTestSchema: true
auth_enabled: false
commonConfig:
replication_factor: 1
storage:
type: filesystem
bucketNames:
chunks: chunks
ruler: ruler
admin: admin
singleBinary:
replicas: 1
resources:
requests:
cpu: 10m
memory: 128Mi
limits:
memory: 256Mi
persistence:
enabled: false
read:
replicas: 0
write:
replicas: 0
backend:
replicas: 0
gateway:
enabled: false
test:
enabled: false
lokiCanary:
enabled: false
monitoring:
selfMonitoring:
enabled: false
serviceMonitor:
enabled: false[4.4 알림 설정: PrometheusRule]
PrometheusRule + AlertManager
- Yaml 파일로 관리
- 알림 규칙도 코드로 관리
- 프로덕션에서 많이 쓰이는 패턴
- ArogCD에 자동 반영, 코드로 관리 됨
실무에서 많이 쓰는 규칙
1. Pod 재시작 과다 (CrashLoopBackOff) — kube_pod_container_status_restarts_total이 짧은 시간(예: 5분) 내 임계치 이상 증가하면 알림. 배포 직후 문제를 가장 빨리 잡아낸다. (지금 프로젝트에 이미 있는 pod-restart-alert.yaml이 이 유형)
2. 높은 에러율 (HTTP 5xx / 에러 응답 비율) — 전체 요청 대비 5xx 비율이 일정 % 이상이면 알림. 장애를 사용자 체감 전에 감지하는 핵심 알림.
3. 리소스 임계치 초과 (CPU/메모리 과사용) — Pod/노드의 CPU·메모리 사용률이 요청(request)이나 제한(limit) 대비 일정 비율(예: 90%) 이상 지속되면 알림. OOMKilled 예방용.
4. 디스크/PVC 용량 부족 — PersistentVolume 사용률이 임계치(예: 85%) 이상이면 알림. 로그나 DB 볼륨이 꽉 차서 서비스가 죽는 걸 사전에 막는다.
비교하기
| 도구 | 특징 | 장점 | 단점 | 적합도 |
| PrometheusRule + Alertmanager | Prometheus 스택 네이티브 | GitOps 호환(CRD), 강력한 라우팅·그루핑, 실무 표준 | YAML 작성 필요, Alertmanager 라우팅 학습 필요 | ★★★ |
| Grafana Alerting | Grafana 내장 알림 | UI로 빠르게 시작 가능, 다양한 알림 채널 지원 | UI 기반 설정은 GitOps와 어긋날 수 있음, 대규모 운영에서 Alertmanager보다 제약 | ★★ |
| PagerDuty / OpsGenie | 전문 인시던트 관리 도구 | 에스컬레이션, 온콜 스케줄, 모바일 앱 지원 | 유료, 학습 환경에서는 과도한 구성 | ★ |
| Cloud Monitoring Alert | GCP 네이티브 알림 | GCP 콘솔 통합, SMS 알림 지원 | Prometheus 메트릭 연동을 위한 별도 설정 필요 | ★ |
알림 규칙 만들기
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
name: pod-restart-alert
namespace: monitoring
labels:
release: kube-prometheus
spec:
groups:
- name: notiflex-alerts
rules:
- alert: PodRestartTooMany
expr: increase(kube_pod_container_status_restarts_total{namespace="notiflex"}[5m]) > 2
for: 1m
labels:
severity: warning
annotations:
summary: "Pod {{ $labels.pod }} 재시작 과다"
description: "5분 내 {{ $value }}회 재시작"알림 확인하기
근데 어디로 가는거지? 프로메테우스에서 지정한게 grafana alert rules에 나온다.
[potato의 후기!]
만드는 거 자체가 중요하다기 보다, 이걸 어떻게 확인하고 검증할건지가 모니터링에서 더 중요한 것 같다.
ai와 이 책과 함께 일단 빨리 훑어보자. 그리고 그 다음에 필요한 부분을 더 중요하게 확인해보자.
그리고 잘못된 사항이나 질문사항 있으시면 질문 남겨주세요. 답변 드리겠습니다~ 감사합니다~
[참고자료]
[] :