4주차 Study - EKS Observability

[AWS]/[EKS]

by scdo 2025. 3. 1. 22:12

EKS에서 Observability가 중요한 이유

모니터링은 CPU, 메모리 사용량 등의 정량적인 데이터를 기반으로 이상 여부를 감지하는 역할을 하지만 EKS 환경에서는 단순한 모니터링만으로는 시스템의 상태를 완전히 파악하기 어렵습니다.
Observability은 로그, 메트릭, 트레이스 데이터를 종합적으로 분석하여 장애 원인을 파악하고 성능 최적화를 가능하게 합니다.
예를 들어, API 응답 속도가 느려졌을 때 네트워크, 데이터베이스, 애플리케이션 코드 중 어디에서 문제가 발생했는지를 정확히 진단할 수 있습니다.
결국, EKS 환경에서 안정적인 운영과 신속한 장애 대응을 위해서는 모니터링뿐만 아니라 관측 가능성을 확보하는 것이 필수적입니다.

모니터링 vs Observability 비교 정리

구분	모니터링	Observability
정의	시스템의 상태를 특정 메트릭을 통해 감시	외부 출력 데이터로 시스템 상태 분석
목적	문제 발생 시 감지 및 경고	문제 원인 진단 및 시스템 최적화
데이터 소스	미리 정의된 메트릭(CPU, 메모리 등)	로그, 메트릭, 트레이스, 이벤트 등
시스템 유형	단순한 시스템(단일 서버, 작은 애플리케이션)	복잡한 분산 시스템(마이크로서비스, 컨테이너)
상호작용 방식	정적 경고(임계값 기반)	동적 쿼리 및 분석(질문 기반)

AWS 콘솔에서 EKS 리소스 및 정보 확인

AWS 콘솔에서는 EKS 클러스터의 다양한 Kubernetes 리소스를 쉽게 확인할 수 있습니다.
EKS 클러스터의 상태와 설정을 직관적으로 파악하고 관리할 수 있습니다.

워크로드: Pod, Deployment 등 애플리케이션 실행 상태 확인
클러스터: EKS 클러스터 정보(Kubernetes 버전, VPC 설정 등) 조회
서비스 및 네트워킹: 서비스, Ingress, 네트워크 정책 관리
구성 및 보안 암호: 환경 변수(ConfigMap), 보안 정보(Secret) 설정
스토리지: Persistent Volume(PV) 및 스토리지 클래스 관리
인증: IAM 사용자 및 역할을 통한 접근 제어
권한 부여: RBAC(Role-Based Access Control)로 접근 권한 설정
정책: 보안 및 네트워크 정책 설정
확장 프로그램: EKS 애드온(CoreDNS, VPC CNI 등) 관리

※ AWS 콘솔에서 EKS 리소스를 확인하려면 권한 설정이 필요합니다. 특히, IAM 사용자 또는 역할이 EKS 클러스터의 Kubernetes 리소스를 조회할 수 있도록 적절한 권한을 가져야 합니다. 아래 페이지를 참고하여 설정해주시기 바랍니다.
https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/view-kubernetes-resources.html#view-kubernetes-resources-permissions

Logging in EKS

Control Plane Logging

EKS의 컨트롤 플레인 로그는 Kubernetes 클러스터의 핵심 구성 요소에서 발생하는 로그를 수집하는 기능입니다.
기본적으로 컨트롤 플레인 로그는 비활성화 되어 있기 때문에 활성화해주어야 하며, 수집된 로그는 CloudWatch Logs에 저장되어 볼 수 있습니다.

AWS콘솔 > EKS > 관찰성 > 컨트롤 플레인 로그 > 로깅관리에서 원하는 로그를 활성화할 수 있습니다.

컨테이너(파드) Logging

# NGINX 웹서버 배포
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

# 파라미터 파일 생성
cat <<EOT > nginx-values.yaml
service:
  type: NodePort
  
networkPolicy:
  enabled: false
  
resourcesPreset: "nano"

ingress:
  enabled: true
  ingressClassName: alb
  hostname: nginx.$MyDomain
  pathType: Prefix
  path: /
  annotations: 
    alb.ingress.kubernetes.io/group.name: study
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP":80}]'
    alb.ingress.kubernetes.io/load-balancer-name: $CLUSTER_NAME-ingress-alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/success-codes: 200-399
    alb.ingress.kubernetes.io/target-type: ip
EOT

# 배포
helm install nginx bitnami/nginx --version 19.0.0 -f nginx-values.yaml

# 확인
kubectl get ingress,deploy,svc,ep nginx
kubectl describe deploy nginx # Resource - Limits/Requests 확인
kubectl get targetgroupbindings # ALB TG 확인

# 접속 주소 확인 및 접속
echo -e "Nginx WebServer URL = http://nginx.$MyDomain"
curl -s http://nginx.$MyDomain

#로그 확인
kubectl stern deploy/nginx
#혹은
kubectl logs deploy/nginx -f

EKS에서 컨테이너 로그 관리 개요

컨테이너 로그를 효율적으로 관리하려면 표준 출력(stdout)과 표준 에러(stderr)를 활용하는 것이 권장됩니다.
이렇게 하면 Pod 내부에 직접 접속하지 않아도 kubectl logs 명령어로 애플리케이션 로그를 쉽게 조회할 수 있습니다.

# 로그 실시간 확인
kubectl stern deploy/nginx
#혹은
kubectl logs deploy/nginx -f

#파드 내부에 직접 접속하지 않아도 로그 확인 가능

일부 애플리케이션(Nginx 등)은 기본적으로 로그를 특정 파일 경로에 저장합니다.
이를 표준 출력(stdout)과 표준 에러(stderr)로 리디렉션하면, 로그가 자동으로 Docker/Kubernetes 로그 시스템으로 전달됩니다.

# Nginx 컨테이너 내부에서 로그 파일 위치 확인
kubectl exec -it deploy/nginx -- ls -l /opt/bitnami/nginx/logs/

추가로 Docker 컨테이너에서는 다음과 같이 설정하여 로그를 표준 출력으로 리디렉션할 수 있습니다.

RUN ln -sf /dev/stdout /opt/bitnami/nginx/logs/access.log
RUN ln -sf /dev/stderr /opt/bitnami/nginx/logs/error.log

이 설정을 적용하면 Nginx 로그가 Docker/Kubernetes 로그 시스템으로 자동 전송됩니다.

단, 종료된 파드의 로그는 kubectl logs로 조회할 수 없습니다. 이 문제를 해결하려면 FluentBit 또는 FlunetD 같은 로그 수집기를 사용하여 CloudWatch, S3 등에 로그를 저장해야 합니다.

참고: https://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/Container-Insights-setup-logs-FluentBit.html#Container-Insights-FluentBit-setup

Amazon CloudWatch & Fluent Bit의 컨테이너 인사이트 지표

CloudWatch Container Observability는 컨테이너 환경에서 메트릭(Metrics)과 로그(Logs)를 수집하여 AWS CloudWatch에서 모니터링할 수 있도록 해주는 기능입니다. 이를 위해 두 가지 주요 요소가 사용됩니다.

EKS 환경에서 CloudWatch Agent와 Fluent Bit을 통한 로그 및 메트릭 수집, 출처 - https://aws.amazon.com/ko/blogs/containers/fluent-bit-integration-in-cloudwatch-container-insights-for-eks/

CloudWatch Agent 파드 (CW Agent)
Kubernetes 클러스터의 각 노드(Node)에 DaemonSet으로 배포되며, CPU 사용량, 메모리 사용량, 네트워크 트래픽 등의 메트릭(Metrics) 을 수집합니다.
수집한 메트릭을 CloudWatch에 전송하여 모니터링할 수 있도록 합니다.

Fluent Bit 파드
Fluent Bit은 경량 로그 수집 도구로, 각 노드(Node)에 DaemonSet으로 배포되며, 노드와 파드(Pod)에서 생성된 로그(Logs)를 수집하여 CloudWatch Logs로 전송합니다.
이를 통해 애플리케이션과 시스템 로그를 분석하고 문제를 파악할 수 있습니다.

로그 수집

수집하는 로그는 다음과 같습니다.

① 애플리케이션 로그

CloudWatch Logs 그룹: /aws/containerinsights/<Cluster_Name>/application
로그 소스: /var/log/containers
설명: 클러스터 내 각 컨테이너 및 파드에서 발생하는 로그

# 애플리케이션 로그 위치 확인 예제
for node in $N1 $N2 $N3; do echo ">>>>> $node <<<<<"; ssh ec2-user@$node sudo tree /var/log/ -L 1; echo; done
for node in $N1 $N2 $N3; do echo ">>>>> $node <<<<<"; ssh ec2-user@$node sudo ls -la /var/log/; echo; done

② 호스트(노드) 로그

CloudWatch Logs 그룹: /aws/containerinsights/<Cluster_Name>/host
로그 소스: /var/log/dmesg, /var/log/secure, /var/log/messages
설명: EKS 노드(호스트)에서 발생하는 시스템 로그

# host 로그 위치 확인 예제
for node in $N1 $N2 $N3; do echo ">>>>> $node <<<<<"; ssh ec2-user@$node sudo tree /var/log/ -L 1; echo; done
for node in $N1 $N2 $N3; do echo ">>>>> $node <<<<<"; ssh ec2-user@$node sudo ls -la /var/log/; echo; done

③ 데이터 플레인 로그

CloudWatch Logs 그룹: /aws/containerinsights/<Cluster_Name>/dataplane
로그 소스: /var/log/journal (kubelet.service, kubeproxy.service, docker.service 관련)
설명: 쿠버네티스 데이터 플레인(Kubelet, Kube-Proxy, 컨테이너 런타임) 관련 로그

# 데이터플레인 로그 위치 확인 예제
for node in $N1 $N2 $N3; do echo ">>>>> $node <<<<<"; ssh ec2-user@$node sudo tree /var/log/journal -L 1; echo; done

CloudWatch Agent와 Fluent Bit을 DaemonSet으로 배포하면, 클러스터 내 모든 노드에서 메트릭과 로그를 빠짐없이 수집할 수 있습니다.

로그 저장 (CloudWatch Logs)
수집된 로그는 CloudWatch Logs 그룹에 저장됩니다.
로그 그룹별 보존 기간을 설정 가능하여, 필요에 따라 데이터 보관 전략을 조정할 수 있습니다.

로그 분석 및 시각화
CloudWatch Logs Insights를 사용하여 특정 조건의 로그를 조회하고 분석할 수 있습니다.
CloudWatch Container Insights는 컨테이너형 애플리케이션과 마이크로서비스의 모니터링, 문제 해결(트러블슈팅), 알람 기능을 제공하는 완전 관리형(AWS 관리) 서비스로 CloudWatch 대시보드를 활용하면, 로그 데이터를 시각화하여 보다 직관적으로 모니터링할 수 있습니다.

아래 페이지를 통해 클러스터의 메트릭 값을 수집하기 위해 CloudWatch Agent를 설치하여, CloudWatch Logs에 로그를 보내기 위해ㅔ Fluent Bit을 DaemonSet 형태로 설치할 수 있습니다.
https://catalog.us-east-1.prod.workshops.aws/workshops/9c0aa9ab-90a9-44a6-abe1-8dff360ae428/ko-KR/90-monitoring/100-build-insight

CloudWatch Container Observability

CloudWatch Container Observability는 Amazon EKS 및 ECS와 같은 컨테이너 환경에서 애플리케이션의 상태를 모니터링하고 문제를 진단할 수 있도록 지원하는 AWS의 통합 모니터링 솔루션입니다. 이 기능을 통해 컨테이너의 CPU, 메모리, 네트워크 사용량 등의 메트릭을 자동으로 수집하고, 애플리케이션 및 시스템 로그를 분석하며, 서비스 간 요청 흐름을 추적하여 성능 병목을 파악할 수 있습니다.

설치

#IRSA 설정
eksctl create iamserviceaccount --name cloudwatch-agent --namespace amazon-cloudwatch --cluster $CLUSTER_NAME --role-name $CLUSTER_NAME-cloudwatch-agent-role --attach-policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy --role-only --approve

#addon 배포
aws eks create-addon --addon-name amazon-cloudwatch-observability --cluster-name myeks --service-account-role-arn arn:aws:iam::<IAM User Account ID직접 입력>:role/myeks-cloudwatch-agent-role

#addon 확인
aws eks list-addons --cluster-name myeks --output table

# 설치 확인
kubectl get crd | grep -i cloudwatch
kubectl get-all -n amazon-cloudwatch
kubectl get ds,pod,cm,sa,amazoncloudwatchagent -n amazon-cloudwatch
kubectl describe clusterrole cloudwatch-agent-role amazon-cloudwatch-observability-manager-role    # 클러스터롤 확인
kubectl describe clusterrolebindings cloudwatch-agent-role-binding amazon-cloudwatch-observability-manager-rolebinding  # 클러스터롤 바인딩 확인
kubectl -n amazon-cloudwatch logs -l app.kubernetes.io/component=amazon-cloudwatch-agent -f # 파드 로그 확인
kubectl -n amazon-cloudwatch logs -l k8s-app=fluent-bit -f    # 파드 로그 확인

# cloudwatch-agent 설정 확인
kubectl describe cm cloudwatch-agent -n amazon-cloudwatch
kubectl get cm cloudwatch-agent -n amazon-cloudwatch -o jsonpath="{.data.cwagentconfig\.json}" | jq

# CloudWatch Agent DaemonSet 설정 확인
## Volumes에 HostPath를 확인
kubectl describe -n amazon-cloudwatch ds cloudwatch-agent

참고: docker.sock을 Pod에 마운트하면 Pod 내부에서 호스트의 Docker 데몬을 직접 조작할 수 있어 보안에 취약합니다. 공격자가 Docker CLI를 실행하면 호스트에서 컨테이너를 생성하거나, 시스템을 장악하는 컨테이너 탈출(Container Escape)이 가능합니다. 이를 방지하려면 docker.sock 마운트를 금지하거나, 부득이한 경우 ReadOnly로 설정하고 RBAC 및 보안 정책을 적용해야 합니다.

# Fluent Bit 로그 INPUT/FILTER/OUT 설정 확인
## 설정 부분 구성 : application-log.conf , dataplane-log.conf , fluent-bit.conf , host-log.conf , parsers.conf
kubectl describe cm fluent-bit-config -n amazon-cloudwatch

Fluent Bit 파드가 Volumes의 HostPath를 통해 수집하는 데이터

# Volumes에 HostPath를 확인
kubectl describe -n amazon-cloudwatch ds fluent-bit

# /var/log 디렉터리의 전체 파일 및 폴더 구조를 확인
ssh ec2-user@$N1 sudo tree /var/log
ssh ec2-user@$N2 sudo tree /var/log
ssh ec2-user@$N3 sudo tree /var/log

AWS 콘솔 확인

로그 그룹: CloudWatch > 로그 그룹

Container Insights: CloudWatch > Insights > Container Insights

로그 확인

Apache Bench로 부하 발생시켜 로그 확인해보기

# EC2 서버
yum install -y httpd
ab -c 500 -n 30000 http://nginx.$MyDomain/

CloudWatch > 로그 그룹 > application 로그 그룹 선택 > 로그 스트림 "nginx" 필터링

CloudWatch Logs Insights에서 EKS 클러스터의 애플리케이션 오류, Kubelet 로그, 노드 CPU 사용량, 파드 재시작 횟수, 실행 중인 Pod 수, 노드 장애 횟수, 컨테이너 CPU 사용량 등을 분석하여 운영 상태를 모니터링하고 문제를 진단하는 쿼리 모음

# Application log errors by container name : 컨테이너 이름별 애플리케이션 로그 오류
# 로그 그룹 선택 : /aws/containerinsights/<CLUSTER_NAME>/application
stats count() as error_count by kubernetes.container_name 
| filter stream="stderr" 
| sort error_count desc

# All Kubelet errors/warning logs for for a given EKS worker node
# 로그 그룹 선택 : /aws/containerinsights/<CLUSTER_NAME>/dataplane
fields @timestamp, @message, ec2_instance_id
| filter  message =~ /.*(E|W)[0-9]{4}.*/ and ec2_instance_id="<YOUR INSTANCE ID>"
| sort @timestamp desc

# Kubelet errors/warning count per EKS worker node in the cluster
# 로그 그룹 선택 : /aws/containerinsights/<CLUSTER_NAME>/dataplane
fields @timestamp, @message, ec2_instance_id
| filter   message =~ /.*(E|W)[0-9]{4}.*/
| stats count(*) as error_count by ec2_instance_id

# performance 로그 그룹
# 로그 그룹 선택 : /aws/containerinsights/<CLUSTER_NAME>/performance
# 노드별 평균 CPU 사용률
STATS avg(node_cpu_utilization) as avg_node_cpu_utilization by NodeName
| SORT avg_node_cpu_utilization DESC

# 파드별 재시작(restart) 카운트
STATS avg(number_of_container_restarts) as avg_number_of_container_restarts by PodName
| SORT avg_number_of_container_restarts DESC

# 요청된 Pod와 실행 중인 Pod 간 비교
fields @timestamp, @message 
| sort @timestamp desc 
| filter Type="Pod" 
| stats min(pod_number_of_containers) as requested, min(pod_number_of_running_containers) as running, ceil(avg(pod_number_of_containers-pod_number_of_running_containers)) as pods_missing by kubernetes.pod_name 
| sort pods_missing desc

# 클러스터 노드 실패 횟수
stats avg(cluster_failed_node_count) as CountOfNodeFailures 
| filter Type="Cluster" 
| sort @timestamp desc

# 파드별 CPU 사용량
stats pct(container_cpu_usage_total, 50) as CPUPercMedian by kubernetes.container_name 
| filter Type="Container"
| sort CPUPercMedian desc

Prometheus

Prometheus는 Kubernetes 및 애플리케이션 모니터링을 위한 오픈소스 도구로, 메트릭 데이터를 수집하고 저장하며, 이를 기반으로 경고(Alerts)를 설정할 수 있습니다.

Prometheus Operator는 Kubernetes에서 Prometheus를 쉽게 배포하고 관리할 수 있도록 해주는 Controller입니다.
Kubernetes에서 Prometheus를 설치하려면 수많은 설정 파일을 관리해야 하는데, Prometheus Operator를 사용하면 간단한 CRD(Custom Resource Definition)만으로 설치 및 설정이 가능합니다.

Prometheus Architecture, 출처 - https://prometheus.io/docs/introduction/overview/

Prometheus 주요 구성 요소

구성 요소	설명
Prometheus Server	메트릭 데이터를 주기적으로 수집(scrape)하고, 시계열(time-series) 데이터로 저장
Client Libraries	애플리케이션에서 직접 메트릭을 노출할 수 있도록 지원하는 라이브러리 (예: Go, Java, Python, Ruby 등)
Push Gateway	수명이 짧은(Short-lived) Job(배치 작업)이 Prometheus에 데이터를 푸시할 수 있도록 지원
Explorters	외부 서비스(예: HAProxy, MySQL, Redis, Node Exporter 등)의 메트릭을 Prometheus가 읽을 수 있도록 변환
Alertmanager	Prometheus에서 감지한 이상 징후를 기반으로 Slack, Email, PagerDuty 등으로 알림 전송
Support Tools	Grafana(시각화), Thanos(장기 데이터 저장), Kubernetes Operator(운영 자동화) 등 다양한 지원 도구

Metrics

메트릭(Metric)은 CPU 사용량, 응답 시간, 활성 연결 수처럼 시간에 따라 변화하는 수치 데이터를 측정하는 개념입니다.
시계열(Time Series)이란, 이러한 데이터를 시간 흐름에 따라 기록하는 방식을 의미합니다.
예를 들어, 웹 서버는 요청 처리 시간을, 데이터베이스는 활성 연결 수나 실행 중인 쿼리 수를 측정할 수 있습니다.
즉, 측정 대상은 애플리케이션의 특성에 따라 달라집니다.

Prometheus 설치 - EC2 서버

# 최신 버전 다운로드
wget https://github.com/prometheus/prometheus/releases/download/v3.2.0/prometheus-3.2.0.linux-amd64.tar.gz

# 압축 해제
tar -xvf prometheus-3.2.0.linux-amd64.tar.gz
cd prometheus-3.2.0.linux-amd64
ls -l

# 수동 설치 및 설정 파일 구성
mv prometheus /usr/local/bin/
mv promtool /usr/local/bin/
mkdir -p /etc/prometheus /var/lib/prometheus
mv prometheus.yml /etc/prometheus/
cat /etc/prometheus/prometheus.yml

# 사용자 및 권한 설정
useradd --no-create-home --shell /sbin/nologin prometheus
chown -R prometheus:prometheus /etc/prometheus /var/lib/prometheus
chown prometheus:prometheus /usr/local/bin/prometheus /usr/local/bin/promtool

# Prometheus를 systemd 서비스로 등록(재부팅시 자동으로 시작)
tee /etc/systemd/system/prometheus.service > /dev/null <<EOF
[Unit]
Description=Prometheus
Wants=network-online.target
After=network-online.target

[Service]
User=prometheus
Group=prometheus
Type=simple
ExecStart=/usr/local/bin/prometheus \
  --config.file=/etc/prometheus/prometheus.yml \
  --storage.tsdb.path=/var/lib/prometheus \
  --web.listen-address=0.0.0.0:9090

[Install]
WantedBy=multi-user.target
EOF

# Prometheus 데몬 실행
systemctl daemon-reload
systemctl enable --now prometheus
systemctl status prometheus
ss -tnlp

# 확인
curl localhost:9090/metrics
echo -e "http://$(curl -s ipinfo.io/ip):9090"

Node_exporter 설치

# Node Exporter 최신 버전 다운로드 및 수동 설치
cd ~
wget https://github.com/prometheus/node_exporter/releases/download/v1.9.0/node_exporter-1.9.0.linux-amd64.tar.gz
tar xvfz node_exporter-1.9.0.linux-amd64.tar.gz
cd node_exporter-1.9.0.linux-amd64
cp node_exporter /usr/local/bin/

# Node Exporter 사용자 및 권한 설정
groupadd -f node_exporter
useradd -g node_exporter --no-create-home --shell /sbin/nologin node_exporter
chown node_exporter:node_exporter /usr/local/bin/node_exporter

# Node Exporter를 systemd 서비스로 등록(재부팅시 자동으로 시작)
tee /etc/systemd/system/node_exporter.service > /dev/null <<EOF
[Unit]
Description=Node Exporter
Documentation=https://prometheus.io/docs/guides/node-exporter/
Wants=network-online.target
After=network-online.target

[Service]
User=node_exporter
Group=node_exporter
Type=simple
Restart=on-failure
ExecStart=/usr/local/bin/node_exporter \
  --web.listen-address=:9200

[Install]
WantedBy=multi-user.target
EOF

# 데몬 실행
systemctl daemon-reload
systemctl enable --now node_exporter
systemctl status node_exporter
ss -tnlp

# 확인
curl localhost:9200/metrics

Prometheus 설정에 수집 대상 target (node_exporter) 추가

# prometheus.yml 수정
cat << EOF >> /etc/prometheus/prometheus.yml

  - job_name: 'node_exporter'
    static_configs:
      - targets: ["127.0.0.1:9200"]
        labels:
          alias: 'myec2'
EOF

# prometheus 데몬 재기동
systemctl restart prometheus.service
systemctl status prometheus

Prometheus 웹에서 target 확인 및 node 로 시작되는 메트릭 쿼리 해보기

rate(node_cpu_seconds_total{mode="system"}[1m])
node_filesystem_avail_bytes
rate(node_network_receive_bytes_total[1m])

Prometheus Stack 설치

Prometheus Stack은 모니터링에 필요한 여러 요소를 하나의 Helm 차트로 제공하는 통합 솔루션입니다.
이를 통해 Prometheus(메트릭 수집), Grafana(데이터 시각화), Alertmanager(이벤트 및 경고 관리) 등의 필수 구성 요소를 손쉽게 설치하고 운영할 수 있습니다.

Grafana를 활용하여 수집된 데이터를 시각화하고 대시보드를 생성할 수 있으며, Alertmanager를 통해 경고 임계값을 설정하고 Slack, Email 등으로 알림을 보낼 수 있습니다.

# repo 추가
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts

# 파라미터 파일 생성
cat <<EOT > monitor-values.yaml
prometheus:
  prometheusSpec:
    scrapeInterval: "15s"
    evaluationInterval: "15s"
    podMonitorSelectorNilUsesHelmValues: false
    serviceMonitorSelectorNilUsesHelmValues: false
    retention: 5d
    retentionSize: "10GiB"
    storageSpec:
      volumeClaimTemplate:
        spec:
          storageClassName: gp3
          accessModes: ["ReadWriteOnce"]
          resources:
            requests:
              storage: 30Gi

  ingress:
    enabled: true
    ingressClassName: alb
    hosts: 
      - prometheus.$MyDomain
    paths: 
      - /*
    annotations:
      alb.ingress.kubernetes.io/scheme: internet-facing
      alb.ingress.kubernetes.io/target-type: ip
      alb.ingress.kubernetes.io/listen-ports: '[{"HTTP":80}]'
      alb.ingress.kubernetes.io/success-codes: 200-399
      alb.ingress.kubernetes.io/load-balancer-name: myeks-ingress-alb
      alb.ingress.kubernetes.io/group.name: study

grafana:
  defaultDashboardsTimezone: Asia/Seoul
  adminPassword: prom-operator

  ingress:
    enabled: true
    ingressClassName: alb
    hosts: 
      - grafana.$MyDomain
    paths: 
      - /*
    annotations:
      alb.ingress.kubernetes.io/scheme: internet-facing
      alb.ingress.kubernetes.io/target-type: ip
      alb.ingress.kubernetes.io/listen-ports: '[{"HTTP":80}]'
      alb.ingress.kubernetes.io/success-codes: 200-399
      alb.ingress.kubernetes.io/load-balancer-name: myeks-ingress-alb
      alb.ingress.kubernetes.io/group.name: study

  persistence:
    enabled: true
    type: sts
    storageClassName: "gp3"
    accessModes:
      - ReadWriteOnce
    size: 20Gi

alertmanager:
  enabled: false
defaultRules:
  create: false
kubeControllerManager:
  enabled: false
kubeEtcd:
  enabled: false
kubeScheduler:
  enabled: false
prometheus-windows-exporter:
  prometheus:
    monitor:
      enabled: false
EOT

# 배포
helm install kube-prometheus-stack prometheus-community/kube-prometheus-stack --version 69.3.1 -f monitor-values.yaml --create-namespace --namespace monitoring

# 확인
## alertmanager-0 : 사전에 정의한 정책 기반(예: 노드 다운, 파드 Pending 등)으로 시스템 경고 메시지를 생성 후 경보 채널(슬랙 등)로 전송
## grafana-0 : 프로메테우스는 메트릭 정보를 저장하는 용도로 사용하며, 그라파나로 시각화 처리
## prometheus-0 : 모니터링 대상이 되는 파드는 ‘exporter’라는 별도의 사이드카 형식의 파드에서 모니터링 메트릭을 노출, pull 방식으로 가져와 내부의 시계열 데이터베이스에 저장
## node-exporter : 노드익스포터는 물리 노드에 대한 자원 사용량(네트워크, 스토리지 등 전체) 정보를 메트릭 형태로 변경하여 노출
## operator : 시스템 경고 메시지 정책(prometheus rule), 애플리케이션 모니터링 대상 추가 등의 작업을 편리하게 할수 있게 CRD 지원
## kube-state-metrics : 쿠버네티스의 클러스터의 상태(kube-state)를 메트릭으로 변환하는 파드
helm list -n monitoring
kubectl get sts,ds,deploy,pod,svc,ep,ingress,pvc,pv -n monitoring
kubectl get-all -n monitoring
kubectl get prometheus,servicemonitors -n monitoring
kubectl get crd | grep monitoring
kubectl df-pv

# 프로메테우스 버전 확인
kubectl exec -it sts/prometheus-kube-prometheus-stack-prometheus -n monitoring -c prometheus -- prometheus --version

# 프로메테우스 웹 접속
echo -e "http://prometheus.$MyDomain"
# macOS
open "http://prometheus.$MyDomain"

# 웹 상단 주요 메뉴 설명
1. 쿼리(Query) : 프로메테우스 자체 검색 언어 PromQL을 이용하여 메트릭 정보를 조회 -> 단순한 그래프 형태 조회
2. 경고(Alerts) : 사전에 정의한 시스템 경고 정책(Prometheus Rules)에 대한 상황
3. 상태(Status) : 경고 메시지 정책(Rules), 모니터링 대상(Targets) 등 다양한 프로메테우스 설정 내역을 확인 > 버전 정보

1. Status → Runtime & Build Information 클릭
 - Storage retention : 5d or 10GiB → 메트릭 저장 기간이 5일 경과 혹은 10GiB 이상 시 오래된 것부터 삭제 ⇒ helm 파라미터에서 수정 가능

2. Status → Command-Line Flags 클릭
 -- log.level : info
 -- storage.tsdb.retention.size : 10GiB
 -- storage.tsdb.retention.time : 5d

3. Status → Configuration
global:
  scrape_interval: 15s     # 메트릭 가져오는(scrape) 주기
  scrape_timeout: 10s      # 메트릭 가져오는(scrape) 타임아웃
  evaluation_interval: 15s # alert 보낼지 말지 판단하는 주기
...
- job_name: serviceMonitor/monitoring/kube-prometheus-stack-prometheus-node-exporter/0
  scrape_interval: 30s
  scrape_timeout: 10s
  metrics_path: /metrics
  scheme: http
  ...
  relabel_configs:
  - source_labels: [job]
    separator: ;
    target_label: __tmp_prometheus_job_name
    replacement: $1
    action: replace
  - source_labels: [__meta_kubernetes_service_label_app_kubernetes_io_instance, __meta_kubernetes_service_labelpresent_app_kubernetes_io_instance]
    separator: ;
    regex: (kube-prometheus-stack);true
    replacement: $1
    action: keep
  - source_labels: [__meta_kubernetes_service_label_app_kubernetes_io_name, __meta_kubernetes_service_labelpresent_app_kubernetes_io_name]
    separator: ;
    regex: (prometheus-node-exporter);true
    replacement: $1
    action: keep
  ...
kubernetes_sd_configs:    # 서비스 디스커버리(SD) 방식을 이용하고, 파드의 엔드포인트 List 자동 반영
  - role: endpoints       # 서비스에 연결된 엔드포인트(Pod IP + Port) 탐색
    kubeconfig_file: ""   # Prometheus가 실행 중인 환경의 기본 kubeconfig 사용
    follow_redirects: true # 엔드포인트를 변경할 경우 이를 따라감
    enable_http2: true
    namespaces:
      own_namespace: false # 자신이 실행 중인 네임스페이스가 아닌 곳에서도 탐색 가능
      names:
      - monitoring        # 서비스 엔드포인트가 속한 네임 스페이스 이름을 지정 : monitoring 네임스페이스에 있는 서비스만 타겟팅, 서비스 네임스페이스가 속한 포트 번호를 구분하여 메트릭 정보를 가져옴
...


- job_name: podMonitor/kube-system/aws-cni-metrics/0
  honor_timestamps: true
  ...
  relabel_configs:
  - source_labels: [job] 
    separator: ;
    target_label: __tmp_prometheus_job_name
    replacement: $1
    action: replace # job 라벨 값을 __tmp_prometheus_job_name에 저장
  - source_labels: [__meta_kubernetes_pod_label_k8s_app, __meta_kubernetes_pod_labelpresent_k8s_app]
    separator: ;
    regex: (aws-node);true
    replacement: $1
    action: keep    # Pod의 k8s_app 라벨 값이 aws-node인 경우만 유지
  ...
kubernetes_sd_configs:
- role: pod               # 클러스터 내 모든 개별 Pod 탐색
  kubeconfig_file: ""
  follow_redirects: true
  enable_http2: true
  namespaces:
    own_namespace: false
    names:
    - kube-system
...

4. Status → Target health
# 해당 스택은 ‘노드-익스포터’, cAdvisor, 쿠버네티스 전반적인 현황 이외에 다양한 메트릭을 포함

5. Status → Service Discovery
# 모든 endpoint 로 도달 가능 시 자동 발견!, 도달 규칙은 설정Configuration 파일에 정의
# 예) serviceMonitor/monitoring/kube-prometheus-stack-apiserver/0 경우 해당 __address__="192.168.1.254:443" 도달 가능 시 자동 발견됨

1. Use local time : 출력 시간을 로컬 타임으로 변경
2. Enable query history : PromQL 쿼리 히스토리 활성화
3. Enable autocomplete : 자동 완성 기능 활성화
4. Enable highlighting : 하이라이팅 기능 활성화
5. Enable linter : 문법 오류 감지, 자동 코스 스타일 체크

Grafana

Grafana는 데이터를 시각적으로 표현하는 대시보드 도구로, Prometheus, Loki, Elasticsearch, MySQL 등 다양한 데이터 소스에서 정보를 가져와 그래프와 차트로 시각화할 수 있습니다.
쉽게 말해, 수많은 로그와 메트릭 데이터를 한눈에 보기 쉽도록 정리하는 강력한 모니터링 도구로 Prometheus와 함께 사용하면 서버 상태, 애플리케이션 성능, 네트워크 트래픽 등을 실시간으로 모니터링할 수 있습니다.

참고: Prometheus Stack으로 grafana 설치

# 그라파나 버전 확인
kubectl exec -it -n monitoring sts/kube-prometheus-stack-grafana -- grafana cli --version

# ingress 확인
kubectl get ingress -n monitoring kube-prometheus-stack-grafana
kubectl describe ingress -n monitoring kube-prometheus-stack-grafana

# 그라파나 웹 접속
echo -e "http://grafana.$MyDomain"
# macOS
open "http://grafana.$MyDomain"

1. Search dashboards : 대시보드 검색
2. Starred : 즐겨찾기 대시보드
3. Dashboards : 대시보드 전체 목록 확인
4. Explore : 쿼리 언어 PromQL를 이용해 메트릭 정보를 그래프 형태로 탐색
5. Alerting : 경고, 에러 발생 시 사용자에게 경고를 전달
6. Connections : 설정, 예) 데이터 소스 설정 등

7. Administartor : 사용자, 조직, 플러그인 등 설정

Grafana는 시각화 도구로, 데이터를 직접 저장하지 않고 외부 데이터 소스를 활용하여 시각적으로 표현합니다.
현재 실습 환경에서는 Prometheus를 데이터 소스로 사용하여 모니터링 데이터를 시각화하고 있습니다.

Connections → Your connections에서, 스택을 사용할 경우 Prometheus가 자동으로 데이터 소스로 추가되며, 서비스 주소를 확인할 수 있습니다.

# 서비스 주소 확인
kubectl get svc,ep -n monitoring kube-prometheus-stack-prometheus

공식 대시보드 가져오기

1. 1 Kubernetes All-in-one Cluster Monitoring KR 대시보드 가져오기

Dashboards > New > Import > 17900 입력 후 Load > 데이터소스(Prometheus) 선택 > Import

2. AWS CNI Metrics 대시보드 가져오기

Dashboards > New > Import > 16032입력 후 Load > 데이터소스(Prometheus) 선택 > Import

대시보드 데이터값 수정

패널에서 Edit > 쿼리 수정 > Run queries > 상단 Save 후 Apply

# CPU 점유율에 대한 쿼리

# 수정 전
sum by (instance) (irate(node_cpu_seconds_total{mode!~"guest.*|idle|iowait", node="$node"}[5m]))

# 수정 후
sum by (instance) (irate(node_cpu_seconds_total{mode!~"guest.*|idle|iowait", instance="$instance"}[5m]))

메모리, 디스크에 대한 데이터도 수정

# 수정 : 메모리 점유율
(node_memory_MemTotal_bytes{instance="$instance"}-node_memory_MemAvailable_bytes{instance="$instance"})/node_memory_MemTotal_bytes{instance="$instance"}

# 수정 : 디스크 사용률
sum(node_filesystem_size_bytes{instance="$instance"} - node_filesystem_avail_bytes{instance="$instance"}) by (instance) / sum(node_filesystem_size_bytes{instance="$instance"}) by (instance)

이 외에도 운영 환경에 맞춰 필요한 대시보드와 패널을 직접 구성하고 유지 관리할 수 있습니다. 기본 제공되는 대시보드를 활용하는 것뿐만 아니라, 서비스 및 인프라 특성에 맞는 맞춤형 대시보드를 생성하여 실시간 모니터링을 최적화할 수 있으며, 운영 중 발생하는 이슈를 신속하게 감지하고 대응할 수 있도록 주요 지표(예: CPU, 메모리, 네트워크 사용량, 애플리케이션 응답 시간 등)에 대한 경고(Alert) 설정도 함께 관리할 수 있습니다.

'[AWS] > [EKS]' 카테고리의 다른 글

6주차 - EKS Security (0)	2025.03.16
5주차 Study - Autoscaling (0)	2025.03.09
3주차 Study - EKS Storage, Managed Node Groups (0)	2025.02.21
2주차 Study - EKS Networking (2) (0)	2025.02.15
2주차 Study - EKS Networking (1) (1)	2025.02.15

scdo 님의 블로그

고정 헤더 영역

메뉴 레이어

메뉴 리스트

검색 레이어

검색 영역

상세 컨텐츠

본문 제목

본문