PathFinder

경제적 독립을 위한 정보 공유 사이트

EKS LOG 관리와 운영

EKS Log 관리에 대한 방법을 알아봅니다.

  • 수집 : Fluentd 컨테이너를 데몬셋으로 동작시킨 후 파드의 로그를 CloudWatch Logs에 전송
  • 저장 : CloudWatch Logs에 로그를 저장하도록 설정
  • 모니터링 : 메트릭 디렉토리를 설정하고 CloudWatch 사용자 메트릭을 생성하여 그 메트릭의 결보를 생성함.
  • 시각화 : CloudWatch의 Logs Insights를 사용하여 대상 로그를 분석하고 CloudWatch의 대시보드를 시각화

원래 애플리케이션 로그는 어디에 저장해야 할까요?

  • 표준 출력으로 구성하는 것을 추천합니다.
  • kubectl logs <파드 이름> 명령으로 파드가 표준 출력한 정보를 참조할 수 있습니다.

EKS LOG 수집

  • CloudWatch Logs 서비스는 애플리케이션이 출력한 로그를 수집하는 구조입니다.
  • 일반적으로 EC2에 CloudWatch 에이전트를 설치하고 수집 대상 로그 파일을 설정하면 AWS 로그 저장 공간으로 전송 가능합니다.
  • EKS도 위 방법이 가능하지만 데몬셋으로 플루언트디 컨테이너를 동작시켜 파드 각각의 표준 출력한 로그를 확인, CloudWatch Logs로 수집, 관리하는 방법입니다.

데이터 노드의 IAM 역할에 정책 추가

  • EKS에서 배포한 데몬셋에서 CloudWatch Logs에 로그를 전송하려면 데이터 플레인에 연결된 IAM 역할에 IAM 정책을 연결해야 합니다.
  1. EKS 클러스터 데이터 노드에 해당하는 EC2 ‘인스턴스 ID’ 중 하나를 선택 → 상세 정보 중에 ‘IAM 역할’ 아래의 링크 클릭합니다.
  2. ‘요약’ 페이지에서 <정책 연결> 버튼을 클릭합니다.
  3. ‘정책 이름’ 목록 → ‘CloudWatchAgentServerPolicy’ 선택 → <정책 연결> 클릭합니다.

CloudWatch용 네임스페이스 생성

#네임스페이스 생성용 매니페스트 다운로드
curl -0 <https://s3.amazonaws.com/cloudwatch-agent-k8s-yaml/> \\
> kubernetesmonitorsing/cloudwatch-namespace.yaml

# 네임스페이스 생성
kubectl apply -f cloudwatch-namespace.yaml
namespace/amazon-Cloudwatch created

플루언트디 컨테이너를 데몬셋으로 동작시키기

  1. 플루언트디 컨테이너를 설치할 매니페스트 다운로드
  2. 플루언트디 컨테이너를 데몬셋으로 동작시킴
# 플루언트디 컨테이너에서 사용할 컨피그맵 생성
kubectl create configmap cluster-info \\
--from-literal=cluster.name=eks-work-cluster \\
--from-literal=logs.region=ap-north-east-2 -n amazon-cloudwatch

# 플루언트디 컨테이너를 설치할 매니페스트 다운로드
curl -0 <https://raw.githubsercontent.com/aws-samples/> \\
amazon-clouldwatchcontainer-insights/latest/k8s-deployment-manifest-templates/ \\
deployment-mode/daemonset/container-insights-monitoring/fluentd/fluentd.yaml

# 플로언트디 컨테이너를 데몬셋으로 동작시킴
kubectl apply -f fluentd.yaml
  • CloudWatch Logs에 아래와 같은 로그 그룹 생성
    • /aws/containerinsights/eks-work-cluster/application
    • /aws/containerinsights/eks-work-cluster/host
    • /aws/containerinsights/eks-work-cluster/dataplane

로그 저장

  • CloudWatch Logs로 전송된 로그는 기간 제한 없이 저장, 로그 용량에 따라 과금이 발생. 용도에 맞게 저장 기간을 설정해서 사용.
  • 목표 : 로그 저장 기간 설정(비용 감소)

CloudWatch Logs에서 보관 기간 설정

  1. CloudWatch Logs에서는 로그 그룹 단위로 로그 저장 기간 설정
  2. application, host, dataplane 단위로 설정 가능
  3. 각각의 application 단위로 설정은 불가능

로그 모니터링

CloudWatch 경보를 사용한 통지

  • 메트릭 필터에서 에러 대상 로그를 추출 → 그것을 CloudWatch 메트릭으로 등록 → 메트릭 경보를 생성하면 통지를 보낼 수 있음.
  1. 메트릭 필터 조건을 ‘ERROR’로 설정하고 출력 횟수를 메트릭에 등록
  2. 출력 횟수 메트릭 통보 생성(예를 들어 5분간 1회 이상 발생하면 통지 등)
  • ‘어떤 애플리케이션에서 발생한 에러인지’에 대해 미리 추출 조건을 포함시켜야 함.
  • 메트릭 필터를 설정하면 CloudWatch 사용자 메트릭이 증가하여 그만큼 비용이 발생함.

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

  • batch-app 에러 검색
    • CloudWatch 페이지 왼쪽 메뉴 ‘로그 그룹’ 선택 → /aws/containerinsights/eks-work-cluster/application 클릭
    • 로그 스트림 목록이 표시된 페이지 → <Search log group> 버튼 클릭
    # 이벤트 검색 조건 예 # '애플리케이션 로그 AND 애플리케이션 이름이 backend-app AND "WARN"이나 # "error"가 포함된다'라는 조건 { $.log != "[*" &&.kubernetes.container_name = "backend-app" && ( $.log = "*WARN*" || $.log = "*error*" ) }

로그의 시각화와 분석

  • CloudWatch Logs Insights
    • CloudWatch ‘로그 그룹’ 목록 페이지 → 원하는 그룹 선택 → 왼쪽 위 <Logs Insights에서 보기> 버튼 클릭

액세스 로그 확인

  • ‘어느 정도의 접속이 있었는지’, ‘어떤 애플리케이션에서 얼마만큼의 에러가 발생하고 있는지’ 등
  • 쿼리를 사용해 위와 같은 정보를 수집할 수 있음.
# 예제 애플리케이션에 어느 정도의 접속이 있었는지 확인
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 kubenetes.container_name as APP
| filter ( log not like /^\\[/ and (log like /WARN/ or log like /error/) )

쿼리 결과를 대시보드에 저장

  • 수집할 정보를 매번 하나씩 쿼리로 입력하는 것은 비효율적임. 여러 쿼리 결과를 대시보드에 저장해두면 전체적인 상황을 파악할 수 있음.
  • 쿼리 실행 결과 페이지 → <대시보드에 추가> 버튼 클릭

이상으로 로그 운영 방식에 대해 알아보았습니다.

Back to top