로그 관리와 운영

들어가며:

어떤 애플리케이션이든 장애가 발생하면 추적하기 위한 정보로 다양한 로그를 사용

EKS에서 효율적으로 수집, 저장, 모니터링, 시각화하는 방법에 대해 설명하도록 하겠습니다.

 

수집: fluentd 컨테이너를 데몬셋으로 동작시키고 파드의 로그를 CloudWatch Logs에 전송합니다.

저장: CloudWatch Logs에 로그를 저장하도록 설정합니다.

모니터링: Metric 디렉토리를 설정하고 CloudWatch 사용자 Metric을 생성하여 그 메트릭의 경보를 생성합니다.

시각화: CloudWatch의 Logs Insights를 사용하여 대상 로그를 분석하고 CloudWatch의 대시보드로 시각화 합니다.

 

 

이 포스팅은 클라우드 네이티브를 위한 쿠버네티스 실전 프로젝트를 참고하였습니다.

클라우드 네이티브를 위한 쿠버네티스 실전 프로젝트 - YES24

 

---

 

원래 애플리케이션 로그는 어디에 저장해야 하는가?

기존 서버에서 app을 배포하는 경우 app이 출력하는 로그는 배포된 서버의 특정 디렉토리에 로그 파일로 출력해서 저장

 

하지만, k8s에서 동작하는 app은 개념이 다름.

(노드 스케줄링에 맞게 파드가 배치되기 때문에 호스트가 변경될 가능성이 있음.)

 

 

 

kubectl logs <파드 이름>으로 파드가 표준 출력한 정보를 참조할 수 있음.

kubectl logs -l app=backend-app과 같이 레이블을 지정해서 특정 레이블에 있는 모든 파드의 로그를 참조할 수도 있음.

 

파드 안의 모든 정보를 표준 출력으로 스트림하여 쌓아 수집하는 좋음.

(표준 출력이라 명시적으로 애플리케이션이 출력한 내용 이외의 로그도 포함될 가능성이 있음)

 

 

 

---

로그 수집 방법

 

AWS에서는 애플리케이션이 출력한 로그를 수집하는 구조로 CloudWatch Logs 라는 서비스를 제공

EC2 에서 CloudWatch 에이전트를 설치하고 수집 대상 로그 파일을 설정하면 AWS 로그 저장 공간으로 전송할 수 있음.

 

 

EKS에서도 같은 방법으로 구현할 수 있지만

데몬셋으로 fluentd 컨테이너를 동작시켜 파드 각각이 표준 출력한 로그를 확인하고 CloudWatch Logs로 수집, 관리하는 방법을 소개

 

 

---

fluentd 로그 수집 데몬셋 실습

Step 1. IAM 역할 부여

AWS EC2 서비스에서 데이터 노드(?)로 사용하는 인스턴스 2개 중 아무거나 1개 클릭

 

 

 

인스턴스 상세 정보에서 IAM 역할 링크 클릭

 

 

IAM 페이지로 넘어온 뒤 정책 연결 클릭

 

 

 

 

Step2. CloudWatch용 네임스페이스 생성

EKS 클러스터에 CloudWatch용 네임스페이스 생성

 

Step3. 플루언트디 컨테이너 데몬셋으로 동작

플루언트디 컨테이너는 클러스터 이름과 리전 이름을 컨피그맵에서 참조하는 방식으로 먼저 다음 명령으로 컨피그맵을 생성

 

fluentd.yaml 는 해당 링크 참고.

플루언트디 컨테이너를 배포

 

 

Step4. 정상 배포 확인

위에 배포가 정상적으로 되었다면 다음과 같은 로그 그룹이 생성되어 있음.

• /aws/containerinsights/eks-work-cluster/application
• /aws/containerinsights/eks-work-cluster/host
• /aws/containerinsights/eks-work-cluster/dataplane

CloudWatch Logs로 전송된 로그는 기본적으로 기간 제한이 없이 저장.

저장되는 로그 용량에 따라 과금 발생.

따라서, 용도에 맞게 저장 기간을 설정하는 것이 중요.

 

---

로그 모니터링 방법

01. CloudWatch 경보를 사용한 통지

Metric 필터에서 에러 대상 로그를 추출하고 그것을 CloudWatch 메트릭으로 등록해 메트릭 경보를 생성하면 통지를 보낼 수 있음.

메트릭 필터를 설정하면 CloudWatch 사용자 메트릭이 증가하여 그만큼 비용이 발생

 

02. CloudWatch Logs 이벤트 검색을 이용한 디버그

통지를 받은 운영자가 에러를 특정 짓기 위해 직접 찾는 방법.

 

 

{ $.log != "{*" && $.kubernetes.container_name = "backend-app" && ( $.log = "*WARN*" || $.log = "*error*")}

 

 

03. 로그의 시각화와 분석

수집한 로그에서 에러를 추출하고 통지하는 것은 문제가 생겼을 때 실시간 대응이 가능하게끔 도와주는 것.

반면 시각화와 분석은 로그 내용을 기반으로 다양한 패턴을 파악하여 장애 방지 및 개발 방향성을 얻는 것이 목적.

 

# 예제 애플리케이션에 어느 정도의 접속이 있었는지 확인

stats count(*) as ACCESS_COUNT
| filter ( kubernetes.container_name = "backend-app")
| filter ( log not like /^\[/ and (log like /Health GET API called./ or log like / REGION GET ALL API/ or log like /LOCATION LIST BY REGION ID API/ ))

 

# 어떤 애플리케이션에서 얼마만큼의 에러가 발생하고 있는지 확인

stats count(*) as ERROR_COUNT by kubernetes.container_name as APP | filter ( log not like /^\[/ and (log like /WARN/ or log like /error/) )