Amazon EKS 모니터링 톺아보기: 첫 구성부터 운영까지

안녕하세요. 제조 비즈니스 테크놀로지부 소속 hongkii입니다.

EKS를 운영하기 시작하면 어떤 로그와 메트릭이 있는지, 운영하면서 무엇을 지켜봐야 하는지 감이 잡히지 않아 무엇부터 해야 할지 모르는 상태가 되기 쉽습니다. 관련 기능도 컨트롤 플레인 로그부터 Container Insights, Prometheus, Fluent Bit까지 다양한데, 서비스와 문서가 제각각 나뉘어 있어 전체 그림이 잘 그려지지 않습니다.

저도 실무에서 EKS를 운영하면서 Fluent Bit으로 컨테이너 로그를 CloudWatch Logs에 보내고, Prometheus와 Grafana로 메트릭을 보고 있는데요. 새 기능이 나올 때마다 "지금 구성과 겹치지는 않을까?", "우리도 켜야 할까?"를 문서에서 하나씩 찾아 맞춰 보게 되더라고요. 최근 1년 사이에는 Container Insights의 방식이 바뀌는 등 큰 변화도 많았고요.

그래서 2026년 10월 기준으로 EKS 모니터링의 전체 그림을 한번 정리해 보기로 했습니다. 처음 모니터링을 구성하는 분에게도, 이미 운영 중인 구성을 다시 점검하려는 분에게도 도움이 되면 좋겠습니다.

먼저 구성 예로 전체 모습을 훑어본 뒤, 다음 순서로 이야기해 보겠습니다.

1. 모니터링에서 다루는 데이터(시그널)의 종류와 흐름
2. 우리 환경에 지금 무엇이 필요한지, 상황별로 정리
3. 어떤 알람을 만들고, 울렸을 때 무엇을 볼지
4. 기능마다 알아 둘 사양과 주의점

설정 절차는 따로 다루지 않았습니다. 대신 기능마다 공식 문서를 링크해 두었으니, 직접 설정하실 때 참고하시면 좋겠습니다.

구성 예로 보는 전체 모습

본론에 들어가기 전에, 어떤 구성 요소의 데이터가 어디로 가는지 먼저 한 장으로 그려 봤습니다. 예시는 EC2 관리형 노드 그룹에서 서비스(프런트엔드와 백엔드 API)를 운영하고, 야간 배치만 Fargate에서 실행하는 클러스터입니다.

색이 있는 화살표가 데이터가 가는 길이고, 회색 가는 선은 모인 데이터를 꺼내 분석하거나 알람을 보내는 흐름입니다

처음 보는 용어가 많을 수 있는데, 다음 장부터 차례로 설명하니 지금은 "무엇이 어디로 데이터를 보내는지"만 잡아 두셔도 충분합니다. 번호마다 짧게 풀어 보면 이렇습니다.

그림에서 번호가 붙지 않은 세 가지는 모인 데이터를 꺼내 보는 쪽인데요, 각각 하는 일은 이렇습니다.

그림만으로는 보이지 않는 점도 몇 가지 있습니다.

• ③④⑤의 Fluent Bit과 CloudWatch 에이전트는 CloudWatch Observability 애드온을 설치하면 함께 들어갑니다. ⑤의 ADOT SDK를 Pod에 자동으로 넣는 것도 이 애드온입니다
• Fargate에서는 DaemonSet을 쓸 수 없기 때문에, 로그는 ⑥의 로그 라우터로 보냅니다
• etcd에 쌓이는 Kubernetes 이벤트는 기본 1시간만 보관됩니다. 오래 남기려면 ⑪처럼 클러스터 밖으로 모아야 합니다
• 그림에 메모로만 적은 cni-metrics-helper, ADOT Collector, Prometheus 직접 운영은 뒤쪽 해당 장에서 다룹니다

그렇다고 이 화살표를 처음부터 모두 갖출 필요는 없습니다. 어떤 상황에서 무엇이 필요한지는 뒤의 "우리 환경에는 무엇이 필요할까"에서 정리했습니다.

모니터링에서 다루는 4가지 시그널

모니터링으로 수집하는 데이터를 시그널이라고 부릅니다. EKS 베스트 프랙티스 가이드의 "관찰성" 페이지는 로그, 메트릭, 트레이스를 옵저버빌리티의 3가지 축으로 설명하는데요. EKS에서는 여기에 Kubernetes가 따로 남기는 이벤트까지 4가지로 나눠 두면, 뒤에 나오는 도구들이 각각 무엇을 맡는지 훨씬 잘 보입니다.

메트릭: 숫자로 보는 상태

메트릭은 어떤 값을 일정한 간격으로 측정해 시간 순서대로 쌓은 숫자입니다. Pod의 CPU 사용률, 노드의 메모리 사용량, API 서버가 받은 요청 수 같은 것이 여기에 해당합니다.

추세를 보거나 임계값을 넘었을 때 알람을 보내는 데 잘 맞습니다. 다만 "CPU 사용률이 언제부터 올라갔는지"는 메트릭으로 알 수 있어도, "왜 올라갔는지"까지는 알려 주지 않거든요. 원인은 로그나 이벤트에서 찾게 됩니다.

로그: 무슨 일이 있었는지에 대한 기록

로그는 애플리케이션이나 Kubernetes 컴포넌트가 남기는 메시지입니다. 애플리케이션의 에러 메시지, 컨테이너의 표준 출력, API 서버의 감사 로그가 모두 로그입니다.

에러의 원인을 파고들 때 가장 많이 들여다보는 데이터입니다. 대신 양이 쉽게 불어나서 저장과 검색에 비용이 들고, 전체적인 추세를 보는 데는 잘 맞지 않습니다.

트레이스: 요청이 지나간 경로

트레이스는 하나의 요청이 여러 서비스를 거쳐 가는 경로와, 각 구간에서 걸린 시간을 기록한 것입니다. 프런트엔드에서 API를 거쳐 데이터베이스까지 가는 요청 중 어느 구간이 느렸는지를 알 수 있습니다.

서비스가 여러 개로 나뉜 구성에서 느린 곳이나 에러가 난 곳을 찾을 때 특히 힘을 발휘합니다. 다만 애플리케이션에 트레이스를 내보내는 설정(계측)이 필요한데요, 뒤에서 소개할 Application Signals는 이 계측을 자동으로 넣어 줍니다.

Kubernetes 이벤트: 클러스터 안에서 일어난 일

Kubernetes 이벤트는 Kubernetes가 직접 남기는 기록입니다. EKS 문서에는 Pod 스케줄링, 이미지 가져오기, 헬스 체크 실패, 스케일링 같은 예가 나옵니다. "Pod를 배치할 노드가 없다", "컨테이너 이미지를 가져오지 못했다" 같은 정보가 이벤트로 남고, kubectl get events나 kubectl describe pod로 확인할 수 있습니다.

다만 로그와 달리 클러스터 안에 잠시 머무를 뿐이고, 기본값으로는 1시간이 지나면 사라집니다. 더 오래 남기려면 클러스터 밖으로 따로 모아야 합니다.

4가지를 한 표로 보면

실제로 장애를 쫓다 보면 시그널 하나만으로 끝나는 경우는 드뭅니다. 보통은 메트릭 알람으로 이상을 알아차리고, 이벤트와 로그로 무슨 일이 있었는지 확인한 뒤, 트레이스로 어느 서비스의 어느 처리에서 생긴 문제인지 좁혀 가게 됩니다.

데이터는 어떻게 흘러가나

어떤 시그널이든 "수집, 저장, 시각화와 알림"이라는 흐름을 거칩니다.

노드마다 실행되는 에이전트가 데이터를 수집해 저장소로 보내고, 대시보드에서 보거나 알람으로 알립니다. 컨트롤 플레인의 로그와 메트릭은 예외적으로 에이전트 없이 EKS가 직접 CloudWatch로 보냅니다.

다만 Kubernetes 이벤트는 이 흐름에서 빠져 있습니다. 수집과 저장 기능이 기본으로 제공되지 않아서, 장애가 지나간 뒤 원인을 찾으려고 하면 이미 사라져 있는 경우가 많거든요. 이 점은 꼭 기억해 두는 게 좋습니다.

우리 환경에는 무엇이 필요할까

여기서는 자주 마주치는 상황을 기준으로, 무엇을 켜고 어떤 알람을 설정하면 좋을지 정리했습니다. 상황은 제가 나눈 것이고, 각 기능의 사양과 권장 사항은 공식 문서를 근거로 했습니다. "우리 환경이 딱 이렇다" 싶은 항목부터 골라 읽으셔도 됩니다. 기능마다 자세한 내용은 뒤에서 다룹니다.

이제 막 EKS 운영을 시작했다

무엇부터 해야 할지 모르겠다면, 아래 4가지부터 갖춰 두는 건 어떨까요? 특히 앞의 두 가지는 에이전트나 애드온을 설치하지 않아도 되니 오늘 바로 시작할 수 있습니다.

로그 타입을 무엇부터 켤지 고민된다면 audit을 추천합니다. 누가 어떤 리소스를 바꿨는지 추적할 수 있고, 뒤에서 소개할 옵저버빌리티 대시보드의 분석 쿼리도 audit 로그를 바탕으로 동작하거든요. 다만 로그는 수집한 양만큼 요금이 나오니, 프로덕션이 아닌 클러스터라면 베스트 프랙티스 가이드에서도 권하듯 필요할 때만 켜 두는 편이 좋습니다.

장애가 지나간 뒤 원인을 끝까지 찾지 못한 적이 있다

새벽에 Pod가 재시작을 반복했지만, 아침에는 이미 정상으로 돌아와 있었다고 해 봅시다. 출근해서 kubectl get events를 실행해도, 기본 보관 기간인 1시간이 지난 이벤트는 남아 있지 않습니다.

한 번이라도 이런 일을 겪었다면, 다음 세 가지는 미리 갖춰 두는 게 좋습니다.

• Kubernetes 이벤트를 클러스터 밖으로 수집한다: Fluent Bit의 kubernetes_events 입력 플러그인으로 CloudWatch Logs 등에 보낼 수 있습니다
• 컨테이너 로그의 보관 기간을 정한다: CloudWatch Logs는 기본적으로 로그를 무기한 보관하므로, 필요한 기간만큼 보관 기간을 설정합니다
• audit 로그를 켜 둔다: 장애 직전에 누가 무엇을 바꿨는지 확인할 수 있습니다

서비스가 여러 개라 어디가 느린지 알 수 없다

"응답이 느리다"는 문의는 들어오는데, 프런트엔드, API, 백엔드 중 어디가 원인인지 알 수 없는 상황입니다. 이럴 때 필요한 것이 바로 트레이스입니다.

CloudWatch Observability 애드온의 Application Signals를 쓰면, Java, Python, Node.js, .NET 애플리케이션에 계측을 자동으로 넣어 서비스 간 의존 관계, 레이턴시, 에러율을 볼 수 있습니다. 서비스별 목표가 정해져 있다면 SLO로 정의해서 달성률을 추적해 보는 것도 좋습니다. SLO(Service Level Objective, 서비스 수준 목표)는 "요청의 99.9%가 성공한다", "요청의 99%가 300ms 안에 응답한다"처럼 서비스가 지켜야 할 목표를 정한 것입니다.

클러스터가 크고 컨트롤러나 오퍼레이터가 많다

kubectl 응답이 가끔 느리거나, 컨트롤러 로그에 처리 지연이 보이는 상황입니다. 원인이 애플리케이션이 아니라 컨트롤 플레인 쪽에 있을 수 있습니다.

AWS 블로그에서는 이런 증상의 원인으로 요청을 과도하게 보내는 컨트롤러나 워크로드를 꼽습니다. 이때 API 서버는 429(Too Many Requests)를 반환하는데, client-go가 자동으로 재시도하기 때문에 정작 원인이 된 워크로드의 로그에는 남지 않을 수 있습니다.

이런 클러스터라면 아래 메트릭으로 알람을 만들어 두는 게 좋습니다. 모두 AWS/EKS에 무료로 쌓이는 메트릭이라 부담도 없습니다.

• API 서버의 429 수(apiserver_request_total_429)
• API 응답의 P99 레이턴시(apiserver_request_duration_seconds_*_P99)
• admission webhook의 거부 수와 레이턴시
• etcd 사용량(etcd_mvcc_db_total_size_in_use_in_bytes)

알람이 울렸을 때 무엇을 볼지는 다음 장에서 정리합니다.

이미 Prometheus와 Grafana를 쓰고 있다

저도 Prometheus와 Grafana를 쓰고 있는데요, PromQL로 만든 대시보드나 알람 규칙이 이미 있다면 그 자산을 그대로 살리는 구성이 좋습니다. 선택지는 크게 3가지인데, 과금 기준과 맞는 상황은 뒤의 "도구 고르기"에서 비교했습니다.

어느 쪽이든 Kubernetes 1.28 이상에서는 API 서버뿐 아니라 kube-scheduler와 kube-controller-manager의 메트릭도 Prometheus 형식으로 수집할 수 있습니다.

간헐적인 타임아웃이 있거나 AZ 간 통신이 신경 쓰인다

애플리케이션에서 가끔 타임아웃이 나는데 원인이 보이지 않거나, 어떤 워크로드가 AZ를 넘어 데이터를 많이 주고받는지 알고 싶은 상황입니다.

Container Network Observability를 켜면 EKS 콘솔에서 서비스 맵과 플로우 테이블을 볼 수 있습니다. 데이터 전송량이 많은 통신이 어디인지, 재전송이나 재전송 타임아웃이 많은 통신이 어디인지 확인할 수 있습니다.

이미 쓰고 있는 도구가 있다

새로 켜는 기능이 기존 구성과 겹치지 않는지 먼저 확인하는 게 안전합니다. 특히 다음 3가지는 모르고 지나치기 쉽습니다.

• Fluent Bit을 직접 운영하고 있다: CloudWatch Observability 애드온은 기본적으로 자체 Fluent Bit으로 컨테이너 로그를 수집합니다. 그대로 켜면 같은 로그를 두 번 수집하게 됩니다
• Classic Container Insights를 쓰고 있다: OTel Container Insights를 켜기만 하면 로그와 메트릭이 기존 방식과 함께 전송됩니다. 마이그레이션이 끝나면 한쪽을 꺼야 요금이 중복되지 않습니다
• 다른 APM이나 OpenTelemetry로 계측하고 있다: 애드온 v5.0.0부터는 업그레이드만 해도 Application Signals가 자동으로 켜집니다. 기존 계측과 겹치지 않도록 업그레이드 전에 설정부터 확인해 두는 게 안전합니다

Fargate를 함께 쓰고 있다

Fargate에서는 DaemonSet을 쓸 수 없기 때문에 EC2 노드와 같은 방식이 통하지 않는 부분이 있습니다.

알람과 대응

알람은 만들어 두는 것만으로는 부족하고, "울렸을 때 무엇을 할지"까지 정해 두어야 의미가 있는데요. 그래서 여기서는 알람마다 어떤 상황에서 울리고, 울리면 어디를 보고 무엇을 하면 되는지 함께 정리했습니다. 임계값의 구체적인 숫자는 환경마다 다르니 정하는 방법만 적었습니다.

무료 컨트롤 플레인 메트릭으로 만드는 알람

Kubernetes 1.28 이상 클러스터라면 AWS/EKS 네임스페이스에 컨트롤 플레인 메트릭이 이미 무료로 쌓이고 있습니다. 아무것도 설치하지 않아도 되니, 알람은 여기서부터 만드는 게 가장 빠릅니다.

"통계" 열은 사용자 가이드의 메트릭 표에 나와 있는 유효한 통계(Valid statistics)입니다. P99 메트릭은 이미 P99로 집계된 값이라 Average를, etcd 사용량은 Maximum을 씁니다. 통계를 잘못 고르면 알람이 의도대로 울리지 않으니, 만들 때 한 번 더 확인해 두는 게 좋습니다.

AWS/EKS 메트릭은 클러스터의 모든 API 서버를 합친 값입니다. EKS는 API 서버를 2대 이상 운영하는데, 특정 API 서버만 느려지는 상황을 구분해서 보려면 Prometheus 형식의 메트릭을 API 서버별로 봐야 합니다. 베스트 프랙티스 가이드에서도 짚듯이, 이때 여러 API 서버의 값을 평균 내면 느려진 서버가 묻혀 버리니 주의가 필요합니다.

알람을 만들기 전에 메트릭의 디멘션을 확인해 두면 설정 실수를 줄일 수 있습니다.

aws cloudwatch list-metrics \
  --namespace AWS/EKS \
  --metric-name etcd_mvcc_db_total_size_in_use_in_bytes

임계값을 정하기 어렵다면 몇 주 동안 평소 값을 지켜본 뒤 정하거나, CloudWatch의 이상 탐지를 쓰는 방법도 있습니다.

429가 늘었다

API 서버가 동시에 처리할 수 있는 요청 수(API Priority and Fairness의 시트)가 바닥나서 요청을 거절하고 있는 상태입니다. 앞에서 말했듯 원인은 요청을 과도하게 보내는 컨트롤러나 워크로드인 경우가 많습니다.

• 먼저 볼 곳: EKS 콘솔의 옵저버빌리티 대시보드에는 audit 로그를 분석하는 CloudWatch Logs Insights 쿼리가 준비되어 있고, 그중 하나가 요청이 제한된 클라이언트(throttled clients)를 찾는 쿼리입니다. 여기서 userAgent를 보면 어느 컨트롤러가 원인인지 좁힐 수 있습니다. audit 로그가 켜져 있어야 합니다
• 대응: 원인이 된 클라이언트가 같은 리소스를 반복해서 LIST하고 있다면, WATCH로 변경을 받도록 고치는 것이 기본입니다. WATCH는 Kubernetes에서 변경을 받는 가장 확장성 있는 방법입니다
• 주의: APF의 큐 깊이를 늘려서 버티려는 경우가 있는데, 큐를 너무 깊게 하면 오히려 레이턴시가 늘어납니다(베스트 프랙티스 가이드)

API 응답이 느리다

베스트 프랙티스 가이드에 따르면 API 레이턴시가 1초 미만이면 컨트롤 플레인이 요청을 제때 처리하고 있다고 봐도 됩니다. API 서버의 타임아웃은 기본 60초라서, 그보다 훨씬 앞에서 알람이 울리도록 정해 둡니다. 기준을 정하기 어렵다면 upstream Kubernetes의 SLO가 참고가 됩니다.

• 먼저 볼 곳: admission webhook의 레이턴시(apiserver_admission_webhook_admission_duration_seconds_*_P99)와 429가 함께 늘었는지 확인합니다. 옵저버빌리티 대시보드에는 느린 요청(slow requests)을 찾는 쿼리도 있습니다
• 대응: webhook이 원인이라면 다음 항목을 참고합니다. 429가 함께 늘었다면 앞의 항목과 같은 방법으로 원인 클라이언트를 찾습니다

admission webhook이 요청을 거부하거나 느리다

admission webhook은 리소스를 만들거나 바꿀 때마다 호출됩니다. 설정이 잘못되면 클러스터의 중요한 작업까지 막을 수 있습니다.

• 먼저 볼 곳: 거부 수(apiserver_admission_webhook_rejection_count)와 레이턴시 메트릭. 옵저버빌리티 대시보드에는 문제가 있는 webhook(broken webhooks)을 찾는 쿼리도 있습니다
• 대응: 모든 리소스에 걸리는 "catch-all" webhook은 피하는 게 좋습니다. 그럴 수 없다면 webhook이 응답하지 않아도 클러스터의 중요한 작업이 멈추지 않도록 fail open으로 두고, 타임아웃을 30초보다 짧게 잡습니다(베스트 프랙티스 가이드)

etcd 사용량이 늘고 있다

etcd 사용량이 데이터베이스 쿼터를 넘으면 etcd가 쓰기를 받지 않게 되어 클러스터가 읽기 전용이 됩니다. Pod 생성도 Deployment 스케일도 거부되는 상태이므로 미리 알아차려야 하는 값입니다. EKS의 etcd 데이터베이스 상한은 8GB입니다. 임계값은 대응할 시간을 남길 수 있도록, 예를 들어 상한의 80% 정도로 잡는 건 어떨까요? 80%라는 숫자는 제 기준입니다.

• 먼저 볼 곳: 어떤 객체가 공간을 많이 차지하는지 객체 수를 확인합니다. AWS 블로그에 나온 명령은 이렇습니다

kubectl get --raw=/metrics | grep apiserver_storage_objects | awk '$2>100' | sort -g -k 2

• 대응: 필요 없는 객체를 정리합니다. 베스트 프랙티스 가이드는 Deployment의 revisionHistoryLimit를 낮춰 오래된 ReplicaSet이 쌓이지 않게 하는 방법을 예로 듭니다. 배치 작업이나 CronJob이 많아 이벤트가 대량으로 쌓이는 클러스터라면, 이벤트 보관 기간(eventTtl)을 짧게 하는 것도 방법입니다
• 이미 읽기 전용이 되었다면: EKS에는 자동 복구 워크플로가 있으므로 15분 정도 기다려 봅니다. 그래도 풀리지 않으면 필요 없는 객체를 20% 이상 지워야 합니다(AWS 블로그). 객체를 줄일 수 없을 만큼 데이터가 필요하다면 더 큰 쿼터를 쓸 수 있는 Amazon EKS Provisioned Control Plane도 선택지입니다

스케줄되지 못한 Pod가 쌓인다

노드 자원이 부족하거나, Pod의 배치 조건을 만족하는 노드가 없는 상태입니다.

• 먼저 볼 곳: kubectl describe pod의 이벤트에 나오는 FailedScheduling 메시지를 확인합니다. "Insufficient memory"처럼 자원 부족인지, affinity나 taint 조건 때문인지가 여기서 갈립니다
• 대응: AWS re:Post에 메시지별 해결 방법이 정리되어 있는데, Pod의 리소스 요청을 실제 사용량에 맞추거나, 더 큰 노드를 추가하거나, 배치 조건을 완화하는 식입니다. 이벤트는 1시간 뒤 사라지므로 시간이 지난 뒤라면 scheduler 로그에서 확인합니다

5XX가 늘었다

API 서버 쪽에서 에러가 나고 있는 상태입니다. 컨트롤 플레인 로그의 api 로그와, 앞에서 소개한 webhook 관련 메트릭을 함께 확인합니다.

로그에서 알람 만들기

메트릭에 없는 정보는 CloudWatch Logs의 메트릭 필터로 숫자로 바꾼 뒤 알람을 만듭니다. 예를 들어 audit 로그에서 지원 종료 예정인 API를 쓰는 요청을 세거나, scheduler 로그에서 스케줄 실패를 세는 식입니다. 컨트롤 플레인 로깅이 켜져 있어야 합니다.

알람 대신 자동 복구에 맡기기

모든 이상을 사람이 알림을 받고 대응할 필요는 없습니다. 노드 이상처럼 자동으로 고쳐지는 편이 나은 영역도 있거든요. 노드 모니터링 에이전트와 노드 자동 복구를 켜 두면, ContainerRuntimeReady나 NetworkingReady 같은 상태가 비정상이 된 노드를 EKS가 교체합니다. 버전 업그레이드 전 점검도 클러스터 인사이트가 24시간마다 실행해 줍니다.

애플리케이션의 알람

레이턴시나 에러율은 Application Signals의 SLO로 정의하면 달성률과 에러 버짓으로 추적할 수 있습니다. SLO도 요금이 드는 시그널로 계산되므로, 꼭 필요한 것부터 만드는 게 좋습니다.

문제가 생겼을 때 어디를 볼까

알람이 울렸거나 사용자 문의가 들어왔을 때 어디서부터 볼지, 이 글의 내용을 바탕으로 제가 정리한 표입니다. 장애 대응 중에 펼쳐 보는 용도로 쓰시면 좋습니다.

도구 고르기

메트릭을 어디에 모을지는 과금 기준과 운영 방식을 함께 놓고 보면 판단하기 쉽습니다. 금액은 바뀔 수 있으니 과금 기준만 정리했습니다.

어느 쪽을 고르든 요금에 가장 크게 영향을 주는 것은 로그 수집량입니다. 줄이는 방법은 베스트 프랙티스 가이드의 비용 최적화 장에 잘 나와 있는데, 요약하면 이렇습니다.

• 필요한 로그만 수집한다. 프로덕션이 아닌 환경에서는 필요할 때만 로그 타입을 켠다
• 로그 보관 기간을 설정한다
• 오래 보관할 로그는 S3로 보낸다
• 출력하는 로그를 중요도가 높은 것으로 줄이고, 필터로 필요 없는 로그를 걸러 낸다

https://docs.aws.amazon.com/ko_kr/eks/latest/best-practices/cost-opt-observability.html

컨트롤 플레인의 로그와 메트릭

여기서부터는 앞에서 나온 기능의 사양과 주의점을 기능마다 정리합니다. 필요한 부분만 골라 읽으셔도 괜찮습니다.

컨트롤 플레인은 AWS가 관리하지만, 로그와 메트릭은 사용자가 가져와서 볼 수 있습니다. 데이터마다 가는 곳이 달라서, 먼저 그림으로 보면 이해가 빠릅니다.

번호는 처음 본 구성도의 번호와 같습니다

컨트롤 플레인 로깅

API 서버 문제를 조사하거나 누가 무엇을 바꿨는지 추적할 때 필요합니다. 로그 타입은 5가지입니다.

기본값으로는 어떤 로그도 CloudWatch Logs로 보내지 않으므로, 필요한 로그 타입을 골라 켭니다. 로그는 /aws/eks/<클러스터명>/cluster 로그 그룹에 저장됩니다. 다음은 공식 문서의 예시로, 5가지를 모두 켜는 명령입니다.

aws eks update-cluster-config \
    --region region-code \
    --name my-cluster \
    --logging '{"clusterLogging":[{"types":["api","audit","authenticator","controllerManager","scheduler"],"enabled":true}]}'

https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/control-plane-logs.html

요금은 사용자 가이드에 따르면 CloudWatch Logs의 표준 수집 요금과 저장 요금입니다. 참고로 EKS 로그는 2023년 9월 5일부터 CloudWatch Logs의 Vended Logs로 분류되어, 볼륨 할인 요금이 적용됩니다(베스트 프랙티스 가이드).

로그 스트림과 로그의 모습

로그 그룹 안에는 로그 타입별로 로그 스트림이 나뉘어 있습니다.

데이터가 늘면 로그 스트림의 이름이 바뀌면서 새 스트림이 생깁니다. 같은 로그 타입의 스트림이 여러 개라면 마지막 이벤트 시간이 가장 최근인 스트림을 보면 됩니다.

authenticator 로그에는 IAM 역할을 Kubernetes 사용자에 연결한 기록이 다음처럼 남습니다. 처음 보면 당황할 수 있는데, 사용자 가이드에 따르면 정상적으로 남는 기록입니다. eks:node-manager는 EKS가 관리형 노드 그룹과 Fargate를 위해 쓰는 내부 서비스 역할입니다.

level=info msg="mapping IAM role" groups="[]" role="arn:aws:iam::111122223333:role/XXXXXXXXXXXXXXXXXX-NodeManagerRole-XXXXXXXX" username="eks:node-manager"

audit 로그는 JSON 형식입니다. 다음은 베스트 프랙티스 가이드에 실린, 지원 종료 예정인 API 사용이 감지된 예시를 보기 좋게 정리한 것입니다.

{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "level": "Request",
  "auditID": "8f7883c6-b3d5-42d7-967a-1121c6f22f01",
  "stage": "ResponseComplete",
  "requestURI": "/apis/policy/v1beta1/podsecuritypolicies?allowWatchBookmarks=true&resourceVersion=4131&timeout=9m19s&timeoutSeconds=559&watch=true",
  "verb": "watch",
  "user": {
    "username": "system:apiserver",
    "uid": "8aabfade-da52-47da-83b4-46b16cab30fa",
    "groups": ["system:masters"]
  },
  "sourceIPs": ["::1"],
  "userAgent": "kube-apiserver/v1.24.16 (linux/amd64) kubernetes/af930c1",
  "objectRef": {
    "resource": "podsecuritypolicies",
    "apiGroup": "policy",
    "apiVersion": "v1beta1"
  },
  "responseStatus": { "metadata": {}, "code": 200 },
  "requestReceivedTimestamp": "2023-10-04T12:36:11.849075Z",
  "stageTimestamp": "2023-10-04T12:45:30.850483Z",
  "annotations": {
    "authorization.k8s.io/decision": "allow",
    "authorization.k8s.io/reason": "",
    "k8s.io/deprecated": "true",
    "k8s.io/removed-release": "1.25"
  }
}

감사 로그에서 주로 보게 되는 필드는 이 정도입니다.

annotations의 "k8s.io/deprecated": "true"로 필터링하면, 지원 종료 예정인 API를 아직 쓰고 있는 클라이언트를 찾을 수 있습니다.

fields @message | filter `annotations.k8s.io/deprecated`="true"

https://docs.aws.amazon.com/ko_kr/eks/latest/best-practices/cluster-upgrades.html

scheduler 로그는 이벤트가 사라진 뒤에도 스케줄 실패를 추적하는 데 쓸 수 있습니다. 다음 쿼리로 스케줄되지 못한 Pod를 Pod와 에러별로 셀 수 있습니다. 베스트 프랙티스 가이드의 쿼리를 바탕으로 하되, 원문에 빠져 있던 stats를 보충했습니다.

fields timestamp, pod, err, @message
| filter @logStream like "scheduler"
| filter @message like "Unable to schedule pod"
| parse @message /^.(?<date>\d{4})\s+(?<timestamp>\d+:\d+:\d+\.\d+)\s+\S*\s+\S+\]\s\"(.*?)\"\s+pod=(?<pod>\"(.*?)\")\s+err=(?<err>\"(.*?)\")/
| stats count(*) as count by pod, err
| sort count desc

베스트 프랙티스 가이드의 예에서는 이 쿼리로, 스토리지 PVC를 쓸 수 없어 Pod가 배포되지 않았다는 에러를 찾아냅니다.

https://docs.aws.amazon.com/ko_kr/eks/latest/best-practices/control_plane_monitoring.html

컨트롤 플레인 메트릭

Kubernetes 1.28 이상 클러스터에서는 컨트롤 플레인 메트릭이 CloudWatch의 AWS/EKS 네임스페이스로 1분 간격, 무료로 전송됩니다. 알람과 조사에 자주 쓰는 메트릭을 골라 보면 이렇습니다.

https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/cloudwatch.html

Prometheus 형식으로도 가져올 수 있습니다. 1.28 이상에서는 API 서버에 더해 kube-scheduler와 kube-controller-manager의 메트릭도 공개됩니다.

# API 서버
kubectl get --raw /metrics

# kube-scheduler
kubectl get --raw "/apis/metrics.eks.amazonaws.com/v1/ksh/container/metrics"

# kube-controller-manager
kubectl get --raw "/apis/metrics.eks.amazonaws.com/v1/kcm/container/metrics"

Prometheus 등으로 수집한다면, 수집하는 쪽에 다음 권한이 필요합니다.

- apiGroups: ["metrics.eks.amazonaws.com"]
  resources: ["kcm/metrics", "ksh/metrics"]
  verbs: ["get"]

https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/view-raw-metrics.html

옵저버빌리티 대시보드

EKS 콘솔의 클러스터 화면에 있는 "관찰성" 탭에서 컨트롤 플레인 상태를 한눈에 볼 수 있습니다. 컨트롤 플레인 모니터링에는 다음 3가지가 있습니다.

• 메트릭 그래프(Kubernetes 1.28 이상)
• audit 로그를 분석하는 CloudWatch Logs Insights 쿼리 목록. 요청이 많은 클라이언트, 느린 요청, 요청이 제한된 클라이언트, 문제가 있는 webhook 등을 찾을 수 있습니다. 컨트롤 플레인 로깅이 켜져 있어야 하고, 쿼리 요금이 듭니다
• CloudWatch의 컨트롤 플레인 로그로 가는 링크

https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/observability-dashboard.html

클러스터 인사이트

버전 업그레이드를 앞두고 있거나 업그레이드 후 롤백을 검토할 때 쓰는 기능입니다. 클러스터의 설정과 업그레이드 준비 상태를 EKS가 점검해 주며, 3가지 종류가 있습니다.

인사이트는 24시간마다 자동으로 갱신되고, 2025년 8월부터는 aws eks start-insights-refresh로 바로 갱신할 수도 있습니다. 옵저버빌리티 대시보드 문서에는 설정 인사이트를 수동으로 갱신할 수 없다는 설명이 아직 남아 있지만, 클러스터 인사이트 문서에는 수동 갱신 방법이 나와 있습니다.

https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/cluster-insights.html

롤백 준비 상태 인사이트는 제가 직접 확인해 본 글이 있어 함께 남겨 둡니다.

https://dev.classmethod.jp/articles/eks-version-rollback-terraform/

노드 상태 감시와 자동 복구

노드 모니터링 에이전트

노드의 커널, 네트워크, 스토리지, 컨테이너 런타임에 생긴 문제를 잡아내는 에이전트입니다. eks-node-monitoring-agent 애드온은 DaemonSet으로 각 노드의 로그를 읽고, 문제를 다음 두 가지로 나눠 기록합니다.

• 교체나 재부팅 같은 복구가 필요한 문제: NodeCondition으로 기록
• 일시적인 문제나 최적이 아닌 노드 설정: Kubernetes 이벤트로 기록. 이벤트로는 자동 복구가 이루어지지 않습니다

https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/node-health-nma.html

에이전트가 추가하는 NodeCondition은 AcceleratedHardwareReady, ContainerRuntimeReady, KernelReady, NetworkingReady, StorageReady의 5가지입니다. Fargate와 Windows에서는 쓸 수 없습니다.

https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/node-health.html

노드 자동 복구

노드에 이상이 생기면 사람이 손대기 전에 EKS가 노드를 교체하거나 재부팅해 주는 기능입니다. 관리형 노드 그룹과 Karpenter에서 쓸 수 있고, 조건별 기본 동작은 이렇습니다.

켜기 전에 확인해 둘 부분입니다.

• 에이전트가 없으면 자동 복구는 kubelet의 Ready 조건, 수동으로 삭제된 노드 오브젝트, 클러스터 참가에 실패한 관리형 노드 그룹 인스턴스에만 반응합니다. 위 표의 조건 대부분은 에이전트가 있어야 감지됩니다
• Reboot는 관리형 노드 그룹에서만 쓸 수 있습니다
• 관리형 노드 그룹에서는 노드가 5대를 넘고 그중 20%를 넘는 노드가 비정상이면 새 복구를 시작하지 않습니다(진행 중인 복구는 계속됩니다). ARC 존 시프트 중에도 마찬가지입니다
• 2025년 9월부터 관리형 노드 그룹에서는 비정상 노드 수의 임계값(maxUnhealthyNodeThresholdCount 또는 maxUnhealthyNodeThresholdPercentage), 동시에 복구할 노드 수(maxParallelNodesRepairedCount 또는 maxParallelNodesRepairedPercentage), 조건별 동작(nodeRepairConfigOverrides)을 설정할 수 있습니다

https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/node-repair.html

노드의 CPU나 메모리 사용량 자체는 Container Insights나 node-exporter로 봅니다.

컨테이너 로그 수집(EC2와 Fargate)

EC2 노드에서는 Fluent Bit을 DaemonSet으로 각 노드에서 실행합니다. Fargate에서는 DaemonSet을 쓸 수 없기 때문에 AWS가 관리하는 로그 라우터를 씁니다.

EC2 노드

Fluent Bit을 설치하는 방법은 2가지입니다.

1. CloudWatch Observability 애드온(amazon-cloudwatch-observability)을 쓴다. 기본적으로 Fluent Bit으로 모든 Pod의 컨테이너 로그를 수집한다
2. AWS 공식 이미지 aws-for-fluent-bit을 직접 DaemonSet으로 배포한다

애드온을 쓰면 로그 그룹이 4개 만들어지는데, performance는 CloudWatch 에이전트가, 나머지 3개는 Fluent Bit이 보냅니다.

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

OTel Container Insights를 켰을 때의 로그

OTel Container Insights를 켜면 OpenTelemetry Collector의 로그 파이프라인으로도 로그가 전송됩니다. 그런데 여기에는 함정이 두 개 있습니다.

첫째, 로그를 보내는 로그 그룹이 문서와 구현에서 다르게 적혀 있습니다. 켠 뒤에는 실제로 만들어진 로그 그룹을 확인하는 게 안전합니다.

둘째, 로그와 메트릭이 중복될 수 있습니다. 다른 설정을 기본값으로 둔 채 otelContainerInsights.enabled만 true로 바꾸면, 로그는 Fluent Bit과 OTel 양쪽으로, 메트릭은 Classic과 OTel 양쪽으로 전송됩니다.

Fluent Bit을 이미 직접 운영하고 있다면, 애드온의 Fluent Bit은 다음 설정으로 끌 수 있습니다.

{ "containerLogs": { "enabled": false } }

https://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Observability-EKS-addon.html

다만 이 설정으로 어디까지 꺼지는지는 문서와 구현의 말이 다릅니다. OTel Container Insights를 켰다면 otelContainerInsights.logs.enabled도 함께 확인하는 게 좋습니다.

aws-for-fluent-bit을 직접 운영한다면

이미지 버전은 직접 관리해야 합니다. 지금은 Amazon Linux 2023 기반의 3.x와 Amazon Linux 2 기반의 2.x가 함께 릴리스되고 있으며, 장기 지원 대상은 3.x입니다. 그런데 작성 시점에 stable 태그는 2.x를 가리키고 있습니다. 그래서 README에서도 권하듯, stable이나 latest 대신 바뀌지 않는 버전 태그를 지정해 두는 게 안전합니다.

https://github.com/aws/aws-for-fluent-bit

CloudWatch Logs로 보낼 때는 C로 구현된 cloudwatch_logs 플러그인을 씁니다. Go로 구현된 예전 cloudwatch 플러그인을 대체하는 플러그인입니다.

https://docs.fluentbit.io/manual/data-pipeline/outputs/cloudwatch

참고로 Container Insights의 로그 전송 수단으로서 Fluentd 지원은 2025년 2월 10일에 끝났습니다. 기존 Fluentd 구성은 계속 동작합니다.

https://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/Container-Insights-EKS-logs.html

Fluent Bit에서 CloudWatch Logs로 전송할 때 생기는 broken connection 에러를 조사한 글도 썼습니다. EC2의 DaemonSet과 Fargate의 로그 라우터를 함께 쓰는 환경에서의 사례입니다.

https://dev.classmethod.jp/articles/fluent-bit-cloudwatch-logs-broken-connection/

Fargate

Fargate에는 Fluent Bit 기반의 로그 라우터가 내장되어 있어서, 사이드카로 Fluent Bit을 따로 실행할 필요가 없습니다. 설정은 ConfigMap 하나로 합니다.

• aws-observability 네임스페이스를 만들고 aws-observability: enabled 라벨을 붙인다
• 이 네임스페이스에 aws-logging ConfigMap을 만든다
• ConfigMap에는 [FILTER], [OUTPUT], [PARSER]만 쓸 수 있고, [SERVICE]와 [INPUT]은 AWS가 관리한다
• ConfigMap은 5,300자까지 쓸 수 있다
• ConfigMap을 바꾸면 새로 만들어지는 Pod에만 반영된다

로그는 CloudWatch Logs, Amazon Data Firehose, Kinesis Data Streams, Amazon OpenSearch Service로 보낼 수 있습니다. S3 등으로 보내려면 Firehose를 거칩니다. 보낼 곳에 맞는 권한은 Fargate의 Pod 실행 역할에 붙이며, 대상별 IAM 정책 예시는 공식 문서에서 확인할 수 있습니다.

https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/fargate-logging.html

로그가 나오지 않으면 Pod의 어노테이션과 이벤트를 확인합니다. ConfigMap을 찾지 못하면 다음과 같이 표시됩니다.

Annotations:          CapacityProvisioned: 0.25vCPU 0.5GB
                      Logging: LoggingDisabled: LOGGING_CONFIGMAP_NOT_FOUND

Events:
  Type     Reason           Age        From                 Message
  ----     ------           ----       ----                 -------
  Warning  LoggingDisabled  <unknown>  fargate-scheduler    Disabled logging because aws-logging configmap was not found. configmap "aws-logging" not found

ConfigMap은 읽혔는데 출력이 이상하다면, ConfigMap에 flb_log_cw: "true"를 지정해 로그 라우터 자체의 프로세스 로그를 CloudWatch Logs로 보낼 수 있습니다. 로그 그룹은 <클러스터명>-fluent-bit-logs입니다. 수집과 저장 요금이 추가로 들기 때문에 원인을 찾은 뒤에는 "false"로 되돌려 두는 게 좋습니다.

로그 라우터용 메모리는 50MB, 로그가 아주 많다면 100MB 정도를 잡아 두면 됩니다(사용자 가이드). 라우터의 [INPUT] 설정은 AWS가 고정해서 관리하며, 메모리 버퍼 상한과 태그를 여기서 확인할 수 있습니다.

[INPUT]
    Name tail
    Buffer_Max_Size 66KB
    DB /var/log/flb_kube.db
    Mem_Buf_Limit 45MB
    Path /var/log/containers/*.log
    Read_From_Head On
    Refresh_Interval 10
    Rotate_Wait 30
    Skip_Long_Lines On
    Tag kube.*

EC2와 달리 로그 라우터의 Fluent Bit 버전은 AWS가 관리합니다. 대신 쓸 수 있는 플러그인은 정해져 있습니다.

Fargate Pod의 메트릭은 ADOT Collector로 Container Insights에 보낼 수 있습니다.

https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/monitoring-fargate-usage.html

Fargate의 로그 설정을 처음부터 따라 해 보고 싶다면 아래 글이 도움이 됩니다.

https://dev.classmethod.jp/articles/eksonfagate-cloudwatchlogs-builtinfluentbit/

Kubernetes 이벤트의 보관과 수집

이벤트가 어디서 만들어져 언제 사라지는지, 밖으로 모으려면 어떤 경로가 필요한지부터 그림으로 보겠습니다.

보관 기간: eventTtl

kube-apiserver는 일정 시간이 지난 이벤트를 삭제하며, upstream의 기본값은 1시간입니다(--event-ttl).

EKS에서는 2026년 8월 12일부터 Kubernetes 1.31 이상 클러스터에서 이 보관 기간을 바꿀 수 있습니다. 고급 Kubernetes 컨트롤 플레인 구성의 eventTtl입니다.

• 설정할 수 있는 범위는 10분에서 60분이고, 기본값은 60분입니다. 즉 기본값보다 짧게만 할 수 있습니다
• 바꾼 값은 새로 만들어지는 이벤트에만 적용됩니다
• 추가 요금은 없습니다

기본값과 설정 범위는 aws eks describe-cluster-versions로도 볼 수 있고, 문서도 이 API의 결과를 기준으로 삼으라고 합니다. 1.35에서 실행해 보면 이렇게 나옵니다.

"eventTtl": {"defaultValue": "60m", "constraints": {"min": "10m", "max": "60m"}}

https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/control-plane-configuration.html

문서는 배치 작업이나 CronJob이 많아 이벤트가 대량으로 쌓이고, 이벤트를 외부 시스템에 따로 보관하는 경우에 보관 기간을 줄이라고 권합니다. 거꾸로 말하면, 1시간보다 전의 이벤트를 보려면 클러스터 밖으로 수집하는 방법이 필요합니다. 노드 모니터링 에이전트가 남기는 이벤트도 Kubernetes 이벤트라서 같은 보관 기간이 적용됩니다.

클러스터 밖으로 수집하기: Fluent Bit의 kubernetes_events

Fluent Bit에는 API 서버에서 Kubernetes 이벤트를 가져오는 입력 플러그인 kubernetes_events가 있습니다. 가져온 이벤트는 로그로 다뤄지므로, 컨테이너 로그처럼 CloudWatch Logs 등으로 보낼 수 있습니다.

https://docs.fluentbit.io/manual/data-pipeline/inputs/kubernetes-events

다만 aws-for-fluent-bit의 버전 라인에 따라 쓸 수 있는지가 다릅니다. 3.x에는 이 플러그인이 포함되어 있지만, 2.x에 들어 있는 Fluent Bit 1.9.10에는 플러그인 자체가 없습니다. 앞에서 말했듯 작성 시점에 stable 태그는 2.x를 가리키므로, 이 플러그인을 쓰려면 3.x의 버전 태그를 지정해야 합니다.

Fargate의 로그 라우터는 [INPUT]을 AWS가 관리하므로 이 방법을 쓸 수 없습니다.

CloudWatch Container Insights

OTel 방식과 Classic 방식

Pod와 컨테이너의 메트릭, 컨테이너 로그를 한꺼번에 모아 주는 기능입니다. 지금은 2가지 방식이 있는데, 둘 다 같은 amazon-cloudwatch-observability 애드온을 쓰고 애드온의 버전과 설정만 다릅니다.

https://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/container-insights-eks-otel.html

https://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/container-insights-eks-classic.html

OTel 방식에는 node-exporter와 kube-state-metrics가 포함되어 있어, cAdvisor와 API 서버의 메트릭까지 함께 수집합니다. 메트릭 이름이 원래 이름 그대로라서, 기존 PromQL 대시보드나 커뮤니티 문서를 참고하기도 쉽습니다.

켜는 데 필요한 IAM 역할이나 Pod Identity 설정 같은 준비 사항은 퀵스타트를 따라가면 됩니다.

https://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/container-insights-eks-otel-quickstart.html

Classic에서 마이그레이션할 때

애드온 v6.2.0부터는 Classic과 OTel을 동시에 켤 수 있습니다. 마이그레이션 전에 새 메트릭을 확인하는 데 쓰는 방법으로, 공식 문서에 다음 예시가 있습니다.

aws eks update-addon \
  --cluster-name my-cluster \
  --addon-name amazon-cloudwatch-observability \
  --configuration-values '{"containerInsights":{"enabled":true},"otelContainerInsights":{"enabled":true}}'

containerInsights.enabled의 기본값이 true이기 때문에, otelContainerInsights.enabled만 지정해도 결과는 같습니다. OTel만 쓰려면 공식 문서대로 Classic을 명시적으로 꺼야 합니다.

aws eks update-addon \
  --cluster-name my-cluster \
  --addon-name amazon-cloudwatch-observability \
  --configuration-values '{"containerInsights":{"enabled":false},"otelContainerInsights":{"enabled":true}}'

로그도 중복되기 때문에(앞의 "OTel Container Insights를 켰을 때의 로그" 참고) 병행 기간은 짧게 잡는 게 좋습니다.

요금

• OTel Container Insights의 GB당 단가는 CloudWatch의 일반 OTel 메트릭 단가와 별도로 정해져 있습니다
• PromQL을 API나 알람에서 쓰면 스캔한 샘플 수만큼 쿼리 요금이 듭니다. 콘솔(대시보드 포함)에서 실행하는 쿼리는 무료입니다
• 컨테이너 로그에는 메트릭과 별도로 CloudWatch Logs 요금(수집과 저장)이 듭니다

금액은 바뀔 수 있으므로 요금 페이지에서 확인하는 게 좋습니다. 작성 시점에는 한국어판 요금 페이지에 OTel Container Insights 요금이 아직 없어서, 아래는 영어판입니다.

https://aws.amazon.com/cloudwatch/pricing/

OTel Container Insights는 2026년 4월 2일에 프리뷰로 시작해, 2026년 6월 23일에 정식 출시되었습니다. UAE, 바레인, 텔아비브 리전에서는 쓸 수 없습니다.

Prometheus와 Grafana

수집 방법 3가지

3가지 모두 같은 /metrics 엔드포인트에서 메트릭을 가져오지만, 저장하는 곳과 보는 도구가 다릅니다. 관리형 컬렉터는 이미 있는 엔드포인트에서 가져오기만 하므로, kube-state-metrics나 node-exporter의 메트릭이 필요하면 이것들을 클러스터에 따로 설치해 둡니다. kube-prometheus-stack에는 둘 다 포함되어 있습니다.

Amazon Managed Service for Prometheus(AMP)의 관리형 컬렉터

에이전트를 설치하지 않고, AWS가 관리하는 스크래퍼가 클러스터의 메트릭을 수집해 AMP 워크스페이스에 저장합니다. API 서버뿐 아니라 1.28 이상에서는 kube-scheduler와 kube-controller-manager의 메트릭도 수집할 수 있습니다.

• EKS 콘솔의 "관찰성" 탭에서 스크래퍼를 추가하거나, aws amp create-scraper로 만듭니다
• 클러스터의 엔드포인트 액세스에 프라이빗 액세스가 포함되어 있어야 합니다
• 인증 모드가 API 또는 API_AND_CONFIG_MAP이면 액세스 엔트리로 권한을 주는 방법이 가장 간단합니다. aws-auth ConfigMap도 계속 쓸 수 있습니다
• 2025년 1월부터 다른 계정의 워크스페이스에도 저장할 수 있습니다
• 클러스터를 삭제할 때 스크래퍼를 함께 삭제하지 않으면 요금이 계속 나갑니다(EKS 사용자 가이드)

https://docs.aws.amazon.com/ko_kr/prometheus/latest/userguide/AMP-collector-how-to.html

https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/prometheus.html

AMP의 요금은 수집한 샘플 수, 저장량, 쿼리로 처리한 샘플 수, 컬렉터의 가동 시간과 수집한 샘플 수로 정해집니다.

https://aws.amazon.com/ko/prometheus/pricing/

CloudWatch managed Prometheus collector

2026년 7월 31일에 출시된 기능입니다. AMP와 같은 aws amp create-scraper 명령에서 보낼 곳을 CloudWatch로 지정합니다. 요금은 시간당 요금과 CloudWatch의 OTel 메트릭 수집 요금입니다.

https://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/managed-prometheus-collectors-eks-setup.html

기능 소개와 실습을 함께 담은 글도 있습니다. 실습 대상은 EC2의 node_exporter입니다.

https://dev.classmethod.jp/articles/cloudwatch-managed-prometheus-collector/

직접 운영(kube-prometheus-stack 등)

Helm 차트 kube-prometheus-stack을 쓰면 Prometheus Operator, Prometheus, Alertmanager에 더해 kube-state-metrics, node-exporter, Grafana까지 한 번에 설치됩니다.

• kube-state-metrics는 API 서버에서 정보를 받아 Deployment나 Pod 같은 오브젝트의 상태를 메트릭으로 만듭니다
• node-exporter는 하드웨어와 OS의 메트릭을 공개합니다

자유도가 가장 높은 대신, Prometheus의 스토리지와 가용성까지 직접 관리해야 합니다.

https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack

시각화: Grafana

Amazon Managed Grafana에서는 AMP와 CloudWatch를 기본 제공 데이터 소스로 쓸 수 있습니다. 요금은 워크스페이스별 활성 사용자 수로 정해지며, Editor와 Viewer의 단가가 다르고, 워크스페이스마다 최소 1명분의 Editor 요금이 듭니다.

https://docs.aws.amazon.com/ko_kr/grafana/latest/userguide/AMG-data-sources-builtin.html

https://aws.amazon.com/ko/grafana/pricing/

직접 운영한다면 kube-prometheus-stack에 포함된 Grafana를 쓸 수 있습니다.

트레이스와 Application Signals

트레이스는 애플리케이션에 계측을 넣고, 에이전트로 수집해 AWS X-Ray에 저장한 뒤 확인합니다. EKS에서는 계측과 수집을 CloudWatch Observability 애드온에 한꺼번에 맡기는 방법(Application Signals)과, OpenTelemetry SDK와 Collector를 직접 구성하는 방법이 있습니다.

Application Signals

애플리케이션의 레이턴시, 에러율, 서비스 간 의존 관계(Application Map), SLO를 보는 기능입니다.

• CloudWatch Observability 애드온 v5.0.0(2026년 2월)부터 새로 설치하든 업그레이드하든 자동으로 켜집니다
• 자동 계측 대상 언어는 Java, Python, Node.js, .NET입니다
• kube-system과 amazon-cloudwatch 네임스페이스는 기본적으로 대상에서 빠집니다
• 요금은 받은 요청과 보낸 요청의 수, SLO(SLI 기간마다 시그널 2개)로 계산한 시그널 수로 정해집니다. 트랜잭션 검색을 켜면 수집한 데이터량(GB) 기준의 요금 체계가 됩니다

https://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Observability-EKS-addon.html

X-Ray SDK와 데몬은 유지 관리 모드로 전환

이제부터 계측을 넣는다면 이 변화부터 확인해 두는 게 좋습니다. X-Ray SDK와 데몬은 2026년 2월 25일에 유지 관리 모드로 들어갔습니다. 앞으로는 보안 수정만 릴리스되고 새 기능은 추가되지 않습니다.

https://docs.aws.amazon.com/ko_kr/xray/latest/devguide/xray-sdk-daemon-timeline.html

AWS가 권하는 대안은 계측에는 OpenTelemetry SDK나 ADOT, 수집에는 CloudWatch 에이전트나 OpenTelemetry Collector입니다. OpenTelemetry로 바꿔도 CloudWatch 콘솔의 트레이스와 트레이스 맵은 그대로 쓸 수 있고, X-Ray API로 트레이스를 가져올 수도 있습니다. CloudWatch 에이전트로 트레이스를 수집하려면 v1.300025.0 이상이 필요합니다.

https://docs.aws.amazon.com/ko_kr/xray/latest/devguide/xray-sdk-migration.html

이미 X-Ray SDK로 계측한 애플리케이션이라면 이 마이그레이션 가이드에서 Java, Python, Node.js, .NET, Go, Ruby별 절차를 확인할 수 있습니다. Application Signals의 자동 계측도 OpenTelemetry 기반이므로, 자동 계측으로 충분하다면 Application Signals로 옮기는 건 어떨까요?

직접 구성할 때: ADOT

ADOT(AWS Distro for OpenTelemetry)의 애드온 adot은 지금도 제공되고 있으며, 사용하려면 cert-manager가 필요합니다.

다만 EKS 애드온 목록에서 Container Insights와 Application Signals용으로 올라와 있는 것은 CloudWatch Observability 애드온입니다. ADOT은 Fargate Pod의 메트릭 수집처럼 OpenTelemetry Collector를 직접 구성하고 싶을 때의 선택지입니다.

https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/workloads-add-ons-available-eks.html

Pod 간 통신(Container Network Observability)

Pod 사이 통신이 느리거나 AZ를 넘는 트래픽이 궁금할 때 볼 기능입니다. 2025년 11월에 발표된 EKS의 Container Network Observability는 CloudWatch Network Flow Monitor를 기반으로 다음 3가지를 제공합니다.

• 성능 메트릭
• 서비스 맵
• 플로우 테이블(재전송, 재전송 타임아웃, 데이터 전송량)

애드온 이름은 aws-network-flow-monitoring-agent입니다. EKS 콘솔에서 켜면 필요한 NFM 리소스(Scope와 Monitor)가 자동으로 만들어집니다. Terraform 같은 IaC로 구성한다면, 필요한 조건과 에이전트의 IAM 권한을 아래 문서에서 미리 확인해 두는 게 좋습니다.

https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/network-observability.html

에이전트는 DaemonSet으로 각 노드에서 실행되며, 데이터 전송량이 많은 상위 500개 플로우를 30초마다 수집합니다. Pod 정보까지 붙이려면 Pod가 호스트의 네트워크 네임스페이스가 아니라 자체 네트워크 네임스페이스에서 실행되어야 합니다.

VPC CNI의 IP 주소 할당 상황은 cni-metrics-helper로 CloudWatch에 보낼 수 있습니다. EKS 사용자 가이드의 전용 페이지는 없어졌기 때문에 GitHub를 참고하는 게 좋습니다.

https://github.com/aws/amazon-vpc-cni-k8s/tree/master/cmd/cni-metrics-helper

위협 탐지(GuardDuty)

모니터링과는 목적이 다르지만, EKS의 위협 탐지에는 GuardDuty를 씁니다.

• EKS Protection: EKS의 감사 로그를 분석합니다. GuardDuty가 자체 스트림으로 감사 로그를 가져오기 때문에, 컨트롤 플레인 로깅을 켤 필요는 없습니다
• Runtime Monitoring: aws-guardduty-agent 애드온으로 노드에서 일어나는 동작을 모니터링합니다. EC2 노드는 지원하지만 EKS on Fargate는 지원하지 않습니다

https://docs.aws.amazon.com/ko_kr/guardduty/latest/ug/kubernetes-protection.html

https://docs.aws.amazon.com/ko_kr/guardduty/latest/ug/runtime-monitoring.html

예전 EKS Runtime Monitoring을 아직 쓰고 있다면, 지금의 Runtime Monitoring으로 옮기는 절차는 아래 문서를 따라가면 됩니다.

https://docs.aws.amazon.com/ko_kr/guardduty/latest/ug/migrating-from-eksrunmon-to-runtime-monitoring.html

최근 1년의 주요 변경

예전부터 EKS를 운영해 온 분이라면 다음 변경을 확인해 두는 게 좋습니다.

• Container Insights가 OpenTelemetry 기반 방식(권장)과 Classic(유지 관리 모드)으로 나뉘었습니다(2026년 6월)
• CloudWatch managed Prometheus collector가 출시되었습니다(2026년 7월)
• CloudWatch Observability 애드온 v5.0.0부터 Application Signals가 기본으로 켜집니다(2026년 2월)
• X-Ray SDK와 데몬이 유지 관리 모드로 전환되었습니다(2026년 2월)
• EKS에서 Kubernetes 이벤트의 보관 기간(eventTtl)을 설정할 수 있게 되었습니다(2026년 8월)
• Amazon DevOps Guru의 지원 종료가 발표되었습니다(2026년 9월). 2026년 10월 29일 이후로는 신규 고객이 사용을 시작할 수 없고, AWS가 제시한 대안은 CloudWatch와 Amazon DevOps Agent입니다

마치며

정리하면서 다시 느낀 건, EKS 모니터링은 기능이 많아 보여도 4가지 시그널과 "수집, 저장, 시각화와 알림"의 흐름으로 나눠 보면 각 도구의 역할이 꽤 깔끔하게 정리된다는 점입니다. 그다음에는 모든 기능을 켜기보다, 우리 환경이 지금 어떤 상황인지에 맞춰 필요한 것부터 갖추는 게 현실적이라고 생각합니다.

아직 아무것도 갖추지 않았다면, 에이전트나 애드온 없이 시작할 수 있는 컨트롤 플레인 로깅과 무료 메트릭 알람부터 시작해 보는 건 어떨까요? 알람을 만들 때는 울렸을 때 어디를 볼지도 함께 정해 두면, 실제로 문제가 생겼을 때 훨씬 빨리 움직일 수 있습니다.

모니터링의 사고방식을 더 체계적으로 알고 싶다면 AWS 권장 가이드 "Amazon EKS 관찰성 간소화 모범 사례"(2025년 4월 공개, 2026년 3월 로깅 장 갱신)를 함께 읽어 보는 것을 추천합니다. 로깅, 모니터링, 트레이싱, 알림의 4장으로 구성되어 있습니다.

https://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/amazon-eks-observability-best-practices/introduction.html

이 글에서는 시그널의 종류와 흐름부터 상황별로 필요한 구성, 알람과 대응, 기능마다 알아 둘 점까지 EKS 모니터링 전체를 정리해 보았습니다. 저도 정리하는 과정에서 운영 중인 구성을 다시 돌아보게 되었는데요. 처음 모니터링을 구성하는 분께는 어디서부터 시작할지 정하는 데, 이미 운영 중인 분께는 지금 구성에서 빠진 부분을 점검하는 데 도움이 되면 좋겠습니다.

참고 자료

• EKS 제어 플레인(EKS 베스트 프랙티스 가이드)
• Kubernetes 컨트롤 플레인(EKS 베스트 프랙티스 가이드, 확장성)
• Amazon CloudWatch로 로그 전송(OTel Container Insights)
• Enhanced Container Insights(Classic)에서 OTel 컨테이너 인사이트로 마이그레이션
• 로그 클래스(CloudWatch Logs)
• aws-observability/helm-charts
• aws/eks-node-monitoring-agent