ㅁ 모니터링 기본
메트릭
- 특정 기간에 측정한 일련의 숫자
로그
- 시스템을 탐색적으로 분석하기 위해 사용
블랙박스 모니터링
- 애플리케이션 외부에 초점을 두어 CPU, MEMORY, STORAGE등의 시스템 컴포넌트를 모니터링한다. 이것은 인프라 수준의 모니터링에 유용하지만 애플리케이션이 어떻게 동작하는지 파악하거나 현상을 이해하기는 힘들다.
화이트박스 모니터링
- 화이트박스 모니터링은 애플리케이션 상태에 초점을 둔다. 예를 들면 전체 HTTP 요청, 500 오류 수, Request Latency 등.
ㅁ 모니터링 패턴
USE 패턴.
- U(Utilization): 사용률
- S(Saturation): 포화도
- E(Error): 오류율
RED 패턴
- R(Request): 요청
- E(Error): 오류율
- D(Duration): 소요 시간
위의 기준은로 구글은 4 가지 황금 신호(frou golden signals)을 관리한다.
- Latency: 요청을 처리하는데 걸리는 시간
- Traffic: 시스템에 존재하는 요청의 양
- Error Rate: 요청 실패율
- Saturation: 서비스의 사용률
으 관리한다.
ㅁ 쿠버네티스 메트릭 개요
- 컨트롤 플레인 컴포넌트: API 서버, etcd, 스케줄러, 컨트롤러 관리자
- 워커노드 컴포넌트: kubelete, 컨테이너 런타임, kube-proxy, kube-dns, Pod
ㅇ cAdvisor
컨테이너 어드바이저 또는 cAdvisor는 오픈 소스 프로젝트로 노드에서 실행 중인 컨테이너의 리소스와 메트릭을 수집한다. cAdvisor는 쿠버네티스 kubelet에 내장되어 클러스터의 모든 노드에서 실행된다.
리눅스 cgroup 트리를 통해 메모리와 CPU 메트릭을 수집한다. cgroups는 CPU, Disk IO, Netowork IO 리소스를 고립시킬 수 있는 리눅스 커널 기능으로 리눅스 커널에 내장된 statfs를 이용해 디스크 메트릭을 수집한다.
ㅇ 메트릭 서버
지원이 종료된 힙스터(heapster) 대신에 쿠버네티스 메트릭 서버와 API를 사용한다. 쿠버네티스 메트릭 서버와 API를 두 가지 측면에서 이해할 수 있다.
첫번째, 리소스 메트릭 API의 표준 구현체가 메트릭 서버이다. 메트릭 서버는 CPU와 메모리 같은 리소스 메트릭을 수집한다. kubelet API로부터 수집하여 메모리에 저장한다. 이 메트릭은 스케줄러, HPA(Horizontal Pod Autoscaler), VPA(Vertical Pod Autoscaler)에서 사용된다.
두번째, 사용자 정의 메트릭 API를 이용해 모니터링 시스템에서 임의의 메트릭을 수집할 수 있다. 모니터링 솔루션은 사용자 정의 어댑터를 구축해 리소스 메트릭을 확장할 수 있다.
프로메테우스를 예로 들자면, 사용자 정의 메트릭 어댑터를 통해 사용자 정의 메트릭 기반의 HPA를 이용할 수 있다. Queue 크기 등의 메트릭을 가져올 수 있어서 쿠버네티스 외부의 메트릭 기반으로 확장할 수 있다.
ㅇ kube-state-metrics
kube-state-metrics는 쿠버네티스에 저장된 오브젝트를 모니터링할 수 있는 쿠버네티스 추가 기능이다. cAdvisor와 메트릭 서버는 리소스 사용량에 대한 자세한 메트릭을 제공하지만 kube-state-metrics는 클러스터에 배포된 쿠버네티스 오브젝트의 상태를 파악하는 것에 중점을 둔 기능이다.
kube-state-metrics가 해결해 줄수 있는 항목은 다음과 같다.
* Pod
- 클러스터에 몇개의 Pod가 배포되었는가?
- 대기 중인 Pod는 몇개인가?
- Pod 요청을 처리할 수 있을 만큼의 충분한 Resource가 있나.
* Deployment
- 의도한 상태에서 수행 중인 Pod는 몇개 인가
- 몇 개의 Replica가 가용한가?
- 어떤 Deployment가 업데이트되나.
* Node
- Worker Node의 상태는 어떠한가?
- Cluster에서 할당할 수 있는 CPU 코어는 몇개인가?
- 스케줄되지 않는 노드가 있나?
* Job
- Job이 언제 시작되었나
- Job이 언제 완료되었나
- 몇개의 Job이 실패했나
보다 자세한 사항은 https://github.com/kubernetes/kube-state-metrics/tree/master/docs
ㅁ 모니터링할 메트릭
쿠버네티스에서 모니터링할 때는 다음과 같은 계층적 방식을 취해야 한다.
- 물리 혹은 가상의 노드
- 클러스터 컴포넌트
- 클러스터 추가 기능
- 최종 사용자 애플리케이션
이러한 계층적 모니터링 방식으로 신호를 간단하고 정확하게 판단할 수 있다. 예를 들어 Pod가 대기 상태에 진입하면 노드의 리소스 양을 먼저 파악하고 문제가 없으면 클러스터 수준의 컴포넌트를 살펴본다.
다음은 시스템에서 살펴볼 메트릭이다.
* Node
- CPU 사용률
- Memory 사용률
- Network 사용률
- Disk 사용률
* 클러스터 컴포넌트
- etcd 레이턴시
* 클러스터 추가 기능
- 클러스터 오토스케일러
- 인그레스 컨트롤러
* 애플리케이션
- 컨테이너 메모리 사용률과 포화도
- 컨테이너 CPU 사용률
- 컨테이너 네트워크 사용률과 오류율
- 애플리케이션 프레임워크 특정 메트릭
ㅁ 일반 모니터링 도구
ㅇ 프로메테우스
프로메테우스는 시스템 모니터링과 Alert Tookit 오픈 소스로 초창기에는 사운드 클라우드(SoundCloud)에서 개발했다.
ㅇ InfluxDB
InfluxDB는 높은 쓰기와 질의(Query) 부하를 처리하도록 설계된 시계열 데이터베이스이다. TICK(Telegraf, InfluxDB, Chronograf, Kapacitor의 줄임말) 스택의 필수 컴포턴트로 대량 타임스탬프 데이터와 관련하여 다양하게 활용될 수 있는 스토리지이다.
ㅇ DataDog
클라우드 규모의 애플리케이션을 위한 SaaS 기반 모니터링 서 비스로 데이터 분석 플랫폼을 통해 서버, 데이터베이스, 도구, 서비스를 모니터링 할 수 있다.
ㅇ Sysdig
시스딕 모니터는 컨테이너 네이티브 앱을 위한 도커와 쿠버네티스 모니터링을 제공하는 상용 도구이다. 쿠버네티스와 직접 통합되어 프로메테우스 메트릭을 수집하고 연동하고 질의할 수 있다.
ㅁ 클라우드 공급자 도구
ㅇ GCP 스택드라이버
모니터링과 로깅 서비스를 관리하고, GKE 클러스터에 맞춘 대시보드 인터페이스가 있다. 이를 통해 클라우드 애플리케이션의 성능과 업타임, 전반적인 상태를 볼 수 있다.
ㅇ 마이크로소프트 Azure Monitor
Azure Monitor는 쿠버네티스의 메트릭 API를 통해서 컨트롤러, 노드, 컨테이너의 메모리와 프로세서 메트릭을 수집해서 보여주며 컨테이너 로그도 수집한다.
쿠버네티스 클러스터에서 모니터링을 활성화하면 메트릭과 로그가 자동으로 리눅스용 로그 애널리틱스의 컨테이너화 버전을 통해 수집된다.
ㅇ AWS Container Insights
AWS Container Application과 마이크로서비스의 메트릭과 로그를 수집, 집계, 요약할 수 있다. 또한 컨테이너 재시작 실패와 같은 진단 정보를 제공한다.
ㅁ 쿠버네티스 로그 개요
ㅇ 로그 보관 주기: 30일 ~ 45일
장기간에 걸쳐 나타나는 문제를 조사하기에 충분하고, 로그를 저장하는데 필요한 리소스 양도 줄일 수 있다.
규정 때문에 기간을 늘려야 한다면 저비용 리소스에 로그를 보관한다.
ㅇ 로그를 수집해야 할 컴포넌트 목록
* 노드 로그
* 쿠버네티스 컨트롤 플레인 로그
- API 서버 : /var/log/kube-APIserver.log
- 컨트롤러 매니저 : /var/log/kube-controller-manager.log
- 스케줄러 : /var/log/kube-scheduler.log
* 쿠버네티스 감사(Audit) 로그
* 애플리케이션 컨테이너 로그
ㅁ 로깅 도구
ㅇ EFK(ElasticSearch, FluentD, Kibana)/ELK (ElasticSearch, Logstash, Kibana)스택
ㅇ 데이터독
ㅇ Sumo Logic
ㅇ Systdig
ㅇ 클라우드 공급자 서비스 (GCP Stackdriver, Azure Monitor, Amazon CloudWatch)