쿠버네티스 실습: Prometheus + Grafana + Kiali + Jaeger로 완전한 Observability 구축하기

쿠버네티스 실습: Prometheus + Grafana + Kiali + Jaeger로 완전한 Observability 구축하기

앞선 글에서는 Istio를 활용한 서비스 메시(Service Mesh) 개념과 실습을 통해 트래픽 제어, mTLS 보안, Canary 배포 등을 경험했습니다.
이번 글에서는 운영 환경에서 꼭 필요한 Observability(가시성, 관찰성) 체계를 구축합니다.
즉, 클러스터 내부에서 발생하는 모든 지표(Metrics), 로그(Logs), 트레이싱(Tracing) 을 하나로 통합해 실시간으로 시각화하는 환경을 구성합니다.

---

1) Observability란?

**Observability(관찰성)**은 단순한 모니터링 이상의 개념입니다.

• Monitoring은 “무슨 일이 일어났는가?”를 보는 것
• Observability는 “왜 그런 일이 일어났는가?”를 이해하는 것

쿠버네티스 환경에서는 보통 아래 네 가지 구성으로 Observability를 완성합니다.

구성요소 역할

Prometheus	지표(Metrics) 수집 및 저장
Grafana	대시보드 시각화
Kiali	서비스 메시 트래픽 구조 시각화
Jaeger	트랜잭션 단위 분산 트레이싱

---

2) Istio Add-ons 설치

Istio에는 이 모든 도구가 애드온 형태로 기본 제공됩니다.

cd istio-1.*
kubectl apply -f samples/addons

설치 확인:

kubectl get pods -n istio-system

예상 출력:

NAME                                    READY   STATUS    AGE
prometheus-xxxxx                        1/1     Running   2m
grafana-xxxxx                           1/1     Running   2m
kiali-xxxxx                             1/1     Running   2m
jaeger-xxxxx                            1/1     Running   2m

---

3) Prometheus로 Metrics 수집

Prometheus는 쿠버네티스의 /metrics 엔드포인트를 자동으로 스크래핑합니다.

istioctl dashboard prometheus

→ 브라우저에서 PromQL 쿼리로 Pod, Deployment, Node 단위의 자원 사용량 확인 가능.

예시 쿼리:

sum(rate(container_cpu_usage_seconds_total{namespace="team-a"}[5m]))

→ team-a 네임스페이스의 CPU 사용률 추이 확인

---

4) Grafana로 시각화

Grafana 대시보드 접속:

istioctl dashboard grafana

추천 대시보드:

• Istio Mesh Dashboard
• Kubernetes / Compute Resources / Namespace (Pods)
• Workload Dashboard

→ 실시간으로 Pod, Service, Namespace 별 리소스와 네트워크 트래픽 모니터링 가능.

---

5) Kiali로 트래픽 구조 확인

반응형

istioctl dashboard kiali

Kiali에서는 서비스 간 트래픽 흐름, 에러율, 응답 시간, mTLS 상태 등을 시각적으로 확인할 수 있습니다.
특히 마이크로서비스 간 호출 구조를 실시간 그래프로 보여주기 때문에,
“어떤 서비스가 병목인지”, “어디서 에러가 발생하는지”를 한눈에 파악할 수 있습니다.

---

6) Jaeger로 분산 트레이싱

Jaeger는 개별 요청이 서비스 간을 어떻게 이동하는지 추적(Tracing)합니다.

istioctl dashboard jaeger

예시:

• NextJS → NestJS → PostgreSQL 요청 트레이스 확인
• 각 구간별 지연 시간(Latency), 오류 구간 파악
• 문제 구간만 골라 딥다이브 분석 가능

---

7) Helm 기반 통합 배포

앞서 만든 Helm Chart에 Observability Add-ons를 통합할 수도 있습니다.
values.yaml에 다음을 추가:

observability:
  prometheus: true
  grafana: true
  kiali: true
  jaeger: true

templates/observability.yaml

{{- if .Values.observability.prometheus }}
apiVersion: v1
kind: ConfigMap
metadata:
  name: prometheus-config
data:
  prometheus.yml: |
    scrape_configs:
      - job_name: 'kubernetes-pods'
        kubernetes_sd_configs:
        - role: pod
{{- end }}

→ CI/CD 파이프라인에서 자동 설치 가능하게 구성.

---

8) 실무 팁 — 관찰성 최적화 전략

항목 권장 설정 설명

Prometheus 데이터 보존 기간	7~14일	너무 길면 성능 저하
Grafana 알림 채널	Slack / PagerDuty	알람 자동화
Jaeger 샘플링 비율	0.1~0.3	트래픽 과부하 방지
Kiali 사용자 인증	Keycloak / OIDC 연동	접근 제어 강화

---

9) 정리

• Prometheus, Grafana, Kiali, Jaeger를 이용해 쿠버네티스 전반의 가시성 확보
• Metrics / Logs / Tracing이 통합된 완전한 Observability 환경 완성
• Istio와 결합하면 보안, 트래픽 제어, 모니터링이 하나의 네트워크 계층에서 관리 가능

다음 글에서는 이 Observability 환경을 바탕으로,
**실제 운영 수준의 모니터링 알람 체계(자동 알림, SLA 감시, 장애 알림 Slack 연동)**를 구축하는 실습을 진행하겠습니다.

---

 

쿠버네티스,Observability,Prometheus,Grafana,Kiali,Jaeger,서비스메시,모니터링,DevOps,K8s실습

 

---

쿠버네티스 실습: Prometheus + Grafana + Kiali + Jaeger로 완전한 Observability 구축하기

앞선 글에서 Istio 기반 서비스 메시를 구축하며 트래픽 제어, 보안, Canary 배포 등을 실습했습니다.
이번 글에서는 Metrics, Logs, Tracing을 통합해 관찰 가능성(Observability) 체계를 완성하는 과정을 실습합니다.

즉, 마이크로서비스 환경 전반에서 무슨 일이 일어나는지 / 왜 그런 현상이 생겼는지 분석할 수 있는 구조를 만드는 것이 목표입니다.

---

1) Observability 개념 정리 & Istio 역할

• Monitoring: 시스템이 무엇을 하고 있는지(지표)
• Logging: 시스템이 무슨 일을 했는지(이벤트 / 로그)
• Tracing: 요청 흐름이 어떻게 이어지는지(분산 트레이스)
• Observability는 이 모두를 합쳐 “왜 이런 현상이 일어났는가”를 해석 가능한 상태를 뜻합니다

Istio는 기본적으로 네트워크 계층의 telemetry를 자동 생성해 줍니다.
Envoy 사이드카가 트래픽을 감시하고, 서비스 간 요청 메트릭 및 트레이스를 생성합니다. (Istio)

• Proxy 수준 메트릭, 서비스 수준 메트릭, 제어면(Control Plane) 메트릭이 포함됨 (Istio)
• 트레이스는 요청 간 경로, 지연 시간(latency), 오류 지점 등을 보여줌

이에 Prometheus, Grafana, Kiali, Jaeger 등을 조합하여 완전한 모니터링/관찰성 환경을 구성할 수 있습니다.

---

2) Istio Observability Add-ons 설치

Istio 설치 후, samples/addons 디렉터리에 Prometheus, Grafana, Jaeger, Kiali 등이 포함된 매니페스트가 제공됩니다.

kubectl apply -f istio-1.* / samples/addons
kubectl get pods -n istio-system

이렇게 하면 Istio 구동 시 기본적으로 Observability 구성 요소들이 같이 설치됩니다. (Istio)

단, 이 방식은 개발/테스트용 데모 환경에는 적합하지만, 운영 환경에서는 리소스 설정, 저장소, 보안 설정 등을 별도로 다듬어야 합니다.

설치 후 외부 접근 설정

기본적으로 Grafana, Prometheus 등의 Add-on은 클러스터 내에서만 접근 가능한 서비스로 구성됩니다.
만약 외부(브라우저 등)에서도 접근 가능하게 하려면 Istio Gateway + VirtualService 또는 Ingress 등을 활용해 노출해야 합니다. (Istio)

예를 들어 Grafana 노출 예시는 Istio 문서의 “Remotely Accessing Telemetry Addons”에 잘 설명되어 있습니다. (Istio)

---

3) Prometheus: 지표 수집 및 쿼리

• Prometheus는 기본적으로 samples/addons 설치 시 활성화되며, Istio가 노출하는 메트릭을 스크래핑합니다. (Istio)
• PromQL 쿼리로 서비스별 CPU 사용률, 요청률, 오류율 등을 조회할 수 있습니다.
  예:
• sum(rate(istio_requests_total{destination_service="your-service",reporter="destination"}[5m]))
• Grafana와 Kiali는 Prometheus의 데이터를 시각화하거나 활용합니다.

---

4) Grafana: 대시보드 시각화

• Istio 애드온 설치 시 Grafana도 함께 설치되며, 기본적으로 Istio의 지표 대시보드를 포함하고 있습니다. (Istio)
• istioctl dashboard grafana 명령어로 접속할 수 있습니다.
• 추천 대시보드 예:
  • Istio Mesh Dashboard
  • Kubernetes / Compute Resources / Namespace (Pods)
  • Workload Dashboard
  • 서비스별 Latency, Error Rate, Traffic 등

---

5) Kiali: 서비스 메시 시각화 및 관찰

• Kiali는 Istio 서비스 메시의 통신 구조, 트래픽 흐름 및 상태를 시각화하는 툴입니다. (Istio)
• Kiali는 Prometheus가 반드시 있어야 동작합니다. 즉 Prometheus가 없으면 Topology 정보를 못 만듭니다. (kiali.io)
• Jaeger (Tracing)와의 통합도 지원하며, 트레이싱 엔드포인트로 바로 이동 가능하게 연결됩니다. (Istio)
• Kiali 설치 예:또는 Helm 또는 커스텀 방식으로 설치 가능함. (kiali.io)
• kubectl apply -f samples/addons/kiali.yaml

---

6) Jaeger: 분산 트레이싱

• Istio 애드온에 포함된 Jaeger는 요청의 흐름을 트레이싱하여, 어떤 서비스 간 호출이 지연됐는지, 어느 부분에서 오류가 났는지 분석할 수 있게 합니다.
• istioctl dashboard jaeger로 Jaeger UI를 열 수 있습니다.
• 기본 샘플 구성에서는 샘플링 비율이 낮게 설정되어 있어, 일정량의 요청을 보내야 트레이스가 보입니다. Istio 공식 문서에서는 기본 샘플링 비율이 1% 정도 설정되는 경우를 예로 들고 있으며, 100개의 요청 정도 보내야 트레이스가 보인다고 안내합니다. (Istio)

---

7) 통합 구성 팁 & 고려사항

항목 유의 및 팁

리소스 부담	Observability 스택 구성요소들은 리소스를 꽤 소모합니다. CPU/메모리 여유가 충분해야 합니다.
저장소 설정	Prometheus, Jaeger 등의 데이터를 장기간 보존하려면 Persistent Volume 구성 필요
보안 접근 통제	Grafana, Kiali, Jaeger 등을 외부 노출할 경우 인증/권한 설정 또는 mTLS/HTTPS 적용 필요
샘플링 비율 조정	트레이스가 너무 많으면 비용이 커지므로 적절한 샘플링 비율 설정 필요
모니터링 기준 (Golden Signals)	Latency, Traffic, Error, Saturation 지표 위주로 대시보드 구성
외부 노출 방법	Ingress 또는 Gateway + VirtualService를 통해 외부 접근 경로 구성 필요 (Istio)

---