AWS EKS - Observability - Logging in EKS

CloudNet@ 팀의 AWS EKS Workshop Study 2기 - 4주차
# EKS Workshop 참고

 

※ Observability

• 클러스터와 애플리케이션의 상태 및 동작을 이해하고 추적할 수 있는 능력
• 모니터링, 로깅, 경고 및 추적과 같은 다양한 도구 및 기술을 통해 구현
• Observability를 통해 운영자는 시스템의 건강 상태를 파악하고 문제를 식별하며, 이를 해결하기 위한 조치

1. Monitoring(모니터링):
   • 클러스터 및 애플리케이션의 상태와 성능을 실시간으로 추적하고 관찰
   • AWS CloudWatch 및 Prometheus를 사용하여 EKS 클러스터의 메트릭을 수집하고 모니터링
2. Logging(로깅):
   • 애플리케이션 및 시스템에서 발생하는 로그를 수집하고 분석하여 문제를 식별
   • CloudWatch Logs 및 Fluentd와 같은 도구를 사용하여 EKS 클러스터의 로그를 수집하고 저장
3. Alerting(경고):
   • 정의된 임계값을 초과하는 경우 운영자에게 경고를 발송하여 잠재적인 문제를 신속하게 파악하고 조치
   • AWS CloudWatch 경보 및 Prometheus 경보 규칙을 설정하여 이러한 경고를 구성
4. Tracing(추적):
   • 애플리케이션의 요청 경로와 실행 경로를 추적하여 복잡한 시스템에서 문제를 식별
   • AWS X-Ray와 같은 서비스를 사용하여 애플리케이션의 추적 데이터를 수집하고 시각화
5. Distributed Tracing(분산 추적):
   • 여러 마이크로서비스 간의 통신을 추적하여 전체 시스템의 동작을 이해
   • Jaeger나 Zipkin과 같은 오픈 소스 도구 또는 AWS X-Ray와 같은 서비스를 사용하여 분산 추적을 수행

Observability 도구와 기술을 통해 AWS EKS에서 클러스터와 애플리케이션을 신속하게 모니터링하고 분석하여 성능을 최적화하고 문제를 신속하게 해결

---

💠 Control plane logs

• Amazon EKS 컨트롤 플레인 로깅은 감사 및 진단 로그를 Amazon EKS 컨트롤 플레인에서 계정의 CloudWatch Logs로 직접 제공
• 로그는 CloudWatch의 각 Amazon EKS 클러스터에 대한 로그 스트림으로 그룹으로 전송
• AWS 관리 콘솔, AWS CLI(버전 1.16.139 이상) 또는 Amazon EKS API를 사용하여 클러스터별로 각 로그 유형을 활성화 또는 비활성화
• Amazon EKS 컨트롤 플레인 로깅을 사용하는 경우, 실행하는 각 클러스터에 대한 표준 Amazon EKS 요금과 클러스터에서 CloudWatch Logs로 전송되는 모든 로그에 대한 표준 CloudWatch Logs 데이터 수집 및 저장 비용이 청구
• 클러스터 제어 플레인 로그 유형.
  • Kubernetes API server component logs (api)
  • Audit (audit) 
  • Authenticator (authenticator)
  • Controller manager (controllerManager)
  • Scheduler (scheduler)

✅ 실습

• EKS 컨트롤 플레인 로그 활성화는 EKS API를 통해 클러스터별로 수행

• Condole 확인

• CloudWatch 로그 콘솔에서 로그 확인
  • /aws/eks/ 필터링하고 로그를 확인할 클러스터를 선택

• 그룹에 여러 개의 로그 스트림이 표시
  • 로그 스트림 중 하나를 선택하면 EKS 제어 플레인에서 CloudWatch Logs로 전송되는 항목 확인

💠 CloudWatch Log Insights 

• CloudWatch 로그 인사이트를 사용하면 CloudWatch 로그에서 로그 데이터를 대화형으로 검색하고 분석
• 쿼리를 수행하여 운영 문제에 보다 효율적이고 효과적으로 대응
• 문제가 발생하면 CloudWatch 로그 인사이트를 사용하여 잠재적인 원인을 파악하고 배포된 수정 사항을 검증

✅ 실습

• CloudWatch Log Insights를 사용하여 EKS 제어 플레인 로그를 쿼리
• 콘솔에서 CloudWatch Log Insights로 이동합니다.

 

• 사용자 에이전트(UserAgent)별 요청 횟수를 계산하고 가장 많이 사용된 사용자 에이전트를 내림차순으로 정렬하는 쿼리  

 

1. fields userAgent, requestURI, @timestamp, @message:
   • 반환할 필드를 지정하는 부분
   • 사용자 에이전트(UserAgent), 요청 URI(requestURI), 타임스탬프(@timestamp), 및 로그 메시지(@message)를 선택
2. | filter @logStream ~= "kube-apiserver-audit":
   • 로그 스트림 필터링을 수행하는 부분
   • 로그 스트림 이름에 "kube-apiserver-audit"가 포함된 로그만 필터링하여 해당 로그만을 분석
3. | stats count(userAgent) as count by userAgent:
   • 사용자 에이전트별로 요청 횟수를 계산하는 부분
   • count(userAgent)는 각 사용자 에이전트의 등장 횟수를 세는 것을 의미하며, as count를 사용하여 이를 count라는 이름으로 별칭을 지정
   • by userAgent는 사용자 에이전트별로 결과를 그룹화하는 것을 의미
4. | sort count desc:
   • 결과를 요청 횟수(count)에 따라 내림차순으로 정렬
   • 가장 많이 사용된 사용자 에이전트가 상단에 나열

 

• 인사이트 콘솔에서 EKS 클러스터의 로그 그룹을 선택합니다:

• 쿼리를 콘솔에 복사하고 쿼리 실행을 누르면 결과가 반환
  • 어떤 컴포넌트가 API 서버에 요청을 보내는지 이해하는 데 매우 유용

💠 Pod logging

• 쿠버네티스 로깅 아키텍처는 세 가지 레벨을 정의
  • Basic level logging
    • kubectl을 사용하여 파드 로그를 수집하는 기능
  • Node level logging
    • 컨테이너 엔진은 애플리케이션의 stdout 과 stderr 에서 로그를 캡처하여 로그 파일에 기록
  • Cluster level logging
    • 노드 수준 로깅을 기반으로 구축되며, 로그 캡처 에이전트가 각 노드에서 실행
    • 에이전트는 로컬 파일 시스템에서 로그를 수집하여 Elasticsearch 또는 CloudWatch와 같은 중앙화된 로깅 대상으로 전송
    • 에이전트는 두 가지 유형의 로그를 수집
      
      • 노드에서 컨테이너 엔진이 캡처한 컨테이너 로그.
      • 시스템 로그.
• Kubernetes는 컨테이너 런타임이 로그를 로컬 파일시스템에 JSON 형식으로 저장하도록 구성
• 컨테이너 런타임은 Docker와 마찬가지로 컨테이너의 stdout 및 stderr 스트림을 로깅 드라이버로 리디렉션
• Kubernetes에서 컨테이너 로그는 노드의 /var/log/pods/*.log에 기록
• Kubelet과 컨테이너 런타임은 자체 로그를 /var/logs 또는 시스템드가 있는 운영 체제의 경우 journald에 기록
• Fluentd와 같은 클러스터 전체 로그 수집기 시스템이 노드에서 이러한 로그 파일을 추적하고 보존을 위해 로그를 전송
• 로그 수집기 시스템은 일반적으로 작업자 노드에서 데몬셋으로 실행됩니다.

✅ 실습

※ Fluent Bit

• 파드에서 실행되는 쿠버네티스 클러스터 구성 요소의 경우, 기본 로깅 메커니즘을 우회하여 /var/log 디렉터리 내의 파일에 기록한다.
• 노드 수준 로깅 에이전트를 각 노드에 데몬셋으로 배포하여 파드 수준 로깅을 구현할 수 있습니다(예: Fluent Bit).
• Fluent Bit는 경량 로그 프로세서이자 전달자로, 다양한 소스에서 데이터와 로그를 수집하고 필터를 사용하여 보강한 후 CloudWatch, Kinesis Data Firehose, Kinesis Data Streams 및 Amazon OpenSearch Service와 같은 여러 대상에 전송
• AWS는 CloudWatch Logs와 Kinesis Data Firehose용 플러그인이 포함된 Fluent Bit 이미지를 제공

---

• Fluent Bit에 대해 생성된 리소스의 유효성을 검사

• aws-for-fluent-bit에 대한 컨피그맵은 각 노드에서 /var/log/containers/*.log 디렉터리에 있는 파일의 내용을 CloudWatch 로그 그룹 /eks-workshop/worker-fluentbit-log로 스트리밍하도록 구성

• 각 노드에 배포된 Fluent Bit 에이전트가 Amazon CloudWatch Logs로 전달한 Kubernetes 포드 로그를 확인하는 방법
• 배포된 애플리케이션 구성 요소는 각 노드의 /var/log/containers/*.log 경로에 저장되는 stdout에 로그를 기록
• 플루언트 비트를 활성화한 이후 새로운 로그가 작성되도록 UI 구성 요소의 파드를 재활용

• kubectl 로그를 직접 사용하여 UI 컴포넌트가 로그를 생성하고 있는지 확인

• fluentbit-cloudwatch로 필터링하여 Fluent Bit에서 생성한 로그 그룹 확인

• /aws/eks/fluentbit-cloudwatch/workload/ui를 선택하여 각각 개별 포드에 해당하는 로그 스트림 확인

• 로그 항목 중 하나를 확장하여 전체 JSON 페이로드를 확인