쿠버네티스 로그와 모니터링 개념 정리: 운영에서 왜 중요한가

쿠버네티스에서 로그와 모니터링은 왜 더 중요할까

HPA까지 설정했다면,
이제부터는 “문제가 생겼을 때 어떻게 알아차릴 것인가”가 가장 중요한 질문이 된다.

쿠버네티스 환경에서는 단순히 서버에 접속해서 로그를 보는 방식이 잘 통하지 않는다.

• Pod는 수시로 생성되고 사라진다
• 문제가 발생한 Pod가 이미 사라졌을 수도 있다
• 노드 단위가 아니라 서비스 단위로 상황을 봐야 한다

그래서 쿠버네티스에서는
로그(Log) 와 모니터링(Monitoring) 을 별도의 영역으로 명확히 나눠서 다룬다.

---

로그와 모니터링은 다르다

먼저 이 두 개념을 구분하는 게 중요하다.

로그는 “무슨 일이 있었는지”,
모니터링은 “지금 상태가 어떤지”를 보여준다.

로그(Log)

• 애플리케이션이 남긴 텍스트 기록
• 에러 원인, 요청 흐름 추적
• 문제 발생 이후 분석에 주로 사용

모니터링(Monitoring)

• CPU, 메모리, 요청 수 같은 수치
• 시스템의 현재 상태와 추세
• 문제를 사전에 감지하는 용도

쿠버네티스에서는
이 둘을 함께 설계하지 않으면 운영이 상당히 불안정해진다.

---

쿠버네티스에서 로그가 사라지는 이유

가장 먼저 부딪히는 문제는 이것이다.

• Pod가 재시작되면서 로그가 사라진다
• Node가 내려가면 로그도 함께 사라진다

이는 쿠버네티스의 구조적 특성 때문이다.

• 로그는 기본적으로 컨테이너 표준 출력(stdout) 에 남는다
• 컨테이너가 사라지면 로그도 함께 사라진다

즉, 로그를 외부로 모으지 않으면
장애 원인을 추적할 방법이 없다.

---

쿠버네티스 로그 수집의 기본 구조

일반적인 로그 흐름은 다음과 같다.

1. 컨테이너가 stdout으로 로그 출력
2. Node에서 로그 파일로 기록
3. 로그 수집 에이전트가 이를 읽음
4. 중앙 로그 저장소로 전송

여기서 핵심은
모든 Pod의 로그를 한 곳으로 모은다는 점이다.

---

DaemonSet이 로그 수집에 쓰이는 이유

로그 수집 에이전트는 보통 DaemonSet으로 배포된다.

이유는 단순하다.

• 모든 Node에서 로그를 수집해야 한다
• Node가 늘어나면 자동으로 따라가야 한다

앞에서 다룬 DaemonSet의 성격과 정확히 맞아떨어진다.

실제로 써보면
“아, 그래서 이게 DaemonSet이었구나” 하고 이해되는 지점이다.

---

모니터링은 무엇을 봐야 할까

모니터링에서 가장 먼저 봐야 할 것은
인프라 → 워크로드 → 애플리케이션 순서다.

인프라 레벨

• Node CPU / 메모리 사용량
• 디스크, 네트워크 상태

워크로드 레벨

• Pod 수 변화
• 재시작 횟수
• OOMKilled 여부

애플리케이션 레벨

• 요청 수
• 응답 시간
• 에러 비율

이 중 하나라도 빠지면
문제의 원인을 정확히 짚기 어렵다.

---

메트릭 서버의 역할

HPA 글에서 잠깐 언급했지만,
쿠버네티스에서 메트릭의 출발점은 메트릭 서버다.

• Pod, Node의 리소스 사용량 수집
• HPA의 기본 데이터 소스

⚠️ 메트릭 서버는 장기 보관용이 아니다.
실무에서는 보통 별도의 모니터링 스택과 함께 사용한다.

---

실제로 운영해보면 느끼는 포인트

쿠버네티스 환경에서 로그와 모니터링을 구축하면서
자주 느끼는 점은 다음과 같다.

• “문제가 생긴 뒤” 로그를 보려고 하면 늦다
• 알람 기준이 없으면 모니터링은 의미가 없다
• 처음부터 완벽하게 설계하기는 어렵다

그래서 보통은

• 최소한의 로그 수집
• 핵심 메트릭 위주 모니터링
• 점진적 확장

이런 방식으로 접근하게 된다.

---

로그와 모니터링을 도입할 때의 기준

모든 것을 다 수집하려고 하면 오히려 피로도가 커진다.

다음 기준이 도움이 된다.

• 장애 원인 분석에 필요한가
• 알람으로 연결할 수 있는가
• 지금 서비스 규모에 필요한가

“수집할 수 있느냐”보다
“지금 필요한가”를 먼저 판단하는 게 중요하다.

---

정리하며

이번 글에서는 쿠버네티스 환경에서
로그와 모니터링이 왜 중요한지,
그리고 기본적인 구조를 살펴봤다.

• 로그는 사라지기 때문에 반드시 중앙 수집이 필요하다
• 모니터링은 장애를 사전에 감지하기 위한 수단이다
• DaemonSet은 로그 수집에 매우 잘 맞는다

다음 글에서는
실무에서 가장 많이 겪는 주제인
쿠버네티스 트러블슈팅,
특히 Pod가 뜨지 않을 때 확인 순서를 중심으로 정리해볼 예정이다.