Kubernetes 통합 가시성 자습서: 로그 모니터링 및 분석

By
Michael Hyatt

Kubernetes는 사실상의 컨테이너 오케스트레이션 기술, 그리고 클라우드 네이티브 이동에 필수적인 기술을 등장시켰습니다. 클라우드 네이티브는 소프트웨어 개발에 속도, 탄력성 및 민첩성을 더해 주지만, 수천 개(또는 수백만 개)의 컨테이너에 수백 개의 마이크로서비스가 제공되어 사용 후 삭제되는 일회용 포드로 실행되므로 복잡성이 증대됩니다. 그러한 복잡하고 분산된 과도 시스템을 모니터링하는 것은 어려운 일이며 동시에 매우 중요합니다. 다행히도, Elastic은 Kubernetes 환경에 통합 가시성을 쉽게 더할 수 있게 해줍니다. 

이 Kubernetes 통합 가시성 자습서 시리즈에서는 다음을 포함하여 Kubernetes에서 실행되는 애플리케이션의 모든 측면을 모니터링하는 방법을 살펴보겠습니다. 

이 자습서 끝 부분에 모든 통합 가시성 데이터를 Elastic Stack으로 전송하여 모니터링 및 분석을 수행하는 애플리케이션 작업의 예가 설명되어 있습니다.

Kubernetes를 위한 Elastic Observability를 선택하는 이유

통합 가시성은 ‘기둥’이 되는 3가지 데이터 요소, 즉 로그, 메트릭 및 애플리케이션 성능 모니터링(약어로 APM)에 의존합니다. 3-6개의 서로 다른 도구, 공급업체 및 기술을 조합하여 Kubernetes를 위한 "가장 좋은 종류의" 모니터링을 구성할 수 있도록 서로 다른 도구와 공급업체를 매핑하는 기사는 무척 많이 있습니다. 

겁내지 마세요. Elastic Observability는 로그, 메트릭 및 APM 데이터를 결합하여 하나의 도구를 사용해 통합된 가시성과 분석을 제공합니다. APM 데이터의 (머신 러닝이 탐지한) 사용자 대기 시간 이상 징후에 기반한 문제 해결을 시작하고, 특정 Kubernetes 포드의 메트릭으로 피벗하고, 해당 포드에서 생성된 로그를 살펴보고, 호스트 및 네트워크에서 발생하는 이벤트를 설명하는 메트릭 및 로그와 상호 연관시키세요. 동일한 사용자 인터페이스에 있는 동안 모두 가능합니다. 이제, 통합 가시성이 제대로 되는 것입니다! 

사용자의 측면에서는 간단하지만, 뒤에서는 많은 일들이 진행되고 있습니다. 그 이유는 대상이 계속 움직이기 때문입니다.

Kubernetes 로그가 대상을 이동

Kubernetes는 사용 가능한 호스트에 컨테이너를 배포하여 오케스트레이션을 수행합니다. 이것은 기본적으로 애플리케이션 구성 요소를 서로 다른 호스트에 배포하기 때문에, 구성 요소가 어디에 있게 될 것인지 미리 알 수 없습니다.

Kubernetes 포드 내에서 실행되는 컨테이너는 stdout 또는 stderr로 로그를 생성합니다. 이 로그들은 포드 ID의 이름을 딴 파일로서 Kublet에 알려진 위치에 작성됩니다. 로그를 생성한 구성 요소나 포드에 로그를 연결하려면 사용자는 현재 호스트에서 어떤 구성 요소 포드가 실행 중인지, 그 ID가 무엇인지 알아내야 합니다.

더 복잡한 문제는, Kubernetes가 애플리케이션을 확장하거나 축소하기로 결정할 수 있으며, 그 결과 애플리케이션 구성 요소를 나타내는 포드 수가 변경될 수 있다는 점입니다. 

다행히도 Filebeat는 움직이는 대상을 좋아합니다.

포드 로그를 수집하려면 Kubernetes 클러스터에서 DaemonSet로 실행되는 Filebeat만 있으면 됩니다. Filebeat는 로컬 Kubelet API와 통신하고, 현재 호스트에서 실행 중인 포드 목록을 가져오며, 포드가 생성 중인 로그를 수집하도록 구성할 수 있습니다. 이러한 로그에는 포드 ID, 컨테이너 이름, 컨테이너 라벨 및 주석 등과 같은 모든 관련 Kubernetes 메타데이터로 주석이 달려 있습니다. 

Filebeat는 이러한 주석을 사용하여 포드에서 실행 중인 구성 요소의 종류를 알아내고 처리 중인 로그에 적용할 로깅 모듈을 결정할 수 있습니다. 이제 됐습니다! Filebeat를 이용해 Kubernetes 로그를 수집하는 것은 아주 쉽습니다. 자, 이제 시작해 보려고 하는데, 시작하기 전에 알아두실 사항이 하나 있습니다. 짧지만 중요한 것입니다.

시작하기 전에: 다음 자습서는 Kubernetes 환경 설정을 사용하는 것을 전제로 하고 있습니다. 나머지 활동을 실행할 수 있도록 데모 어플리케이션으로 단일 노드 Minikube 환경을 설정하는 과정을 단계별로 안내하는 보충 블로그를 만들었습니다.

Filebeat를 사용하여 Kubernetes 로그 수집

우리는 Elastic Cloud의 Elasticsearch Service를 사용하게 됩니다. 그러나 여기서 설명하는 모든 것은 자체적으로 관리하든 아니면 Elastic Cloud Enterprise(ECE)나 Kubernetes의 Elastic Cloud(ECK)와 같은 오케스트레이션 시스템을 사용하든, 자체 인프라에 배포된 Elastic 클러스터와 함께 작동할 수 있습니다. 본 자습서의 코드는 GitHub 리포지토리 http://github.com/michaelhyatt/k8s-o11y-workshop에서 확인할 수 있습니다.

Filebeat를 DaemonSet로 배포

Kubernetes 호스트당 하나의 Filebeat 인스턴스만 배포해야 합니다. Filebeat는 일단 배포되면 kubelet API를 통해 호스트와 통신하여 실행 중인 포드, 모든 메타데이터 주석, 로그 파일의 위치 등에 대한 정보를 검색합니다.

DaemonSet의 배포 구성은 $HOME/k8s-o11y-workshop/filebeat/filebeat.yml 파일에 정의되어 있습니다. Filebeat 구성을 나타내는 배포 설명자 부분을 좀더 자세히 살펴봅시다.

이 파트는 가능한 전체 필드 수를 기본값 1000에서 5000으로 증가시킵니다. Kubernetes 배포는 스키마 필드가 기본값 1000을 초과하게 될 수 있는 다수의 라벨과 주석을 도입할 수 있습니다.

setup.template.settings:
  index.mapping.total_fields.limit: 5000

자동 검색 메커니즘에 대한 설정은 Filebeat가 Kubernetes 자동 검색을 사용하고 주석에서 작동하는 힌트 기반 자동 검색에 의존하도록 지시합니다.

filebeat.autodiscover:
 providers:
   - type: kubernetes
     host: ${NODE_NAME}
     hints.enabled: true

다음 세션은 이 Filebeat 인스턴스가 캡처한 모든 로그에 적용할 프로세서 체인을 정의합니다. 첫째, Docker, Kubernetes, 호스트, 클라우드 서비스 제공자로부터 오는 메타데이터로 이벤트를 보강합니다. 그 다음, 선행 프로세서에서 생성된 일부 메타데이터 필드와 내용을 기준으로 메시지를 걸러내는 drop_event섹션이 있습니다. 이는 로그를 계속 지배하는 소음이 많은 이벤트 유형이 있을 때 유용합니다. 일치 조건을 구성하기 위해 논리적으로 and 또는 or가 어떻게 사용되고 있는지 주목해 보세요.

processors:
  - add_cloud_metadata:
  - add_host_metadata:
  - add_docker_metadata:
  - add_kubernetes_metadata:
  - drop_event:
      when:
        or:
        - contains:
            message: "OpenAPI AggregationController: Processing item k8s_internal_local_delegation_chain"
        - and:
          - equals:
              kubernetes.container.name: "metricbeat"
          - contains:
              message: "INFO"
          - contains:
              message: "Non-zero metrics in the last"
        - and:
          - equals:
              kubernetes.container.name: "packetbeat"
          - contains:
              message: "INFO"
          - contains:
              message: "Non-zero metrics in the last"
        - contains:
            message: "get services heapster"
        - contains:
            kubernetes.container.name: "kube-addon-manager"
        - contains:
            kubernetes.container.name: "dashboard-metrics-scraper"

Filebeat 모듈 및 주석을 사용한 자동 검색

위에서 자동 검색이 어떻게 stdout/stderr에 적절한 모듈을 적용하여 모듈별 형식으로 구문 분석하는지를 보았습니다. Filebeat 설명서에서 자동 검색에 대해 자세히 알아보세요.

이제, 우리의 샘플 애플리케이션의 다른 구성 요소들이 어떻게 Kubernetes 힌트 기반 자동 검색과 함께 작동하도록 구성되어 있는지 알아보겠습니다.

NGINX 예제

다음은 $HOME/k8s-o11y-workshop/nginx/nginx.yml의 코드 조각으로 Filebeat가 이 포드의 로그를 NGINX 로그로 처리하도록 지시하며 여기서 stdout는 액세스 로그를 나타내고 stderr는 오류 로그를 나타냅니다.

annotations:
  co.elastic.logs/module: nginx
  co.elastic.logs/fileset.stdout: access
  co.elastic.logs/fileset.stderr: error

다중 행 애플리케이션 로그 처리 

힌트 기반 자동 검색의 또 다른 예로는 Filebeat를 구성하여 petclinic 다중 행 로그 항목을 단일 로그 이벤트로 처리하도록 하는 것입니다. 이것은 단일 이벤트를 나타내는 Java 스택 추적과 같이 구성 요소가 다중 행 메시지를 기록할 때 유용하지만, 기본적으로 행 끝에 의해 구분된 행당 단일 이벤트로 처리됩니다.

다음은 힌트 기반 자동 검색을 사용하여 Filebeat가 이해한 다중 행 이벤트 처리 구성을 나타내는 $HOME/k8s-o11y-workshop/petclinic/petclinic.yml의 코드 조각입니다.

annotations:
  co.elastic.logs/multiline.pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2}'
  co.elastic.logs/multiline.negate: "true"
  co.elastic.logs/multiline.match: "after"

Filebeat 설명서에서 다중 행 이벤트 처리에 대해 자세히 알아보세요.

Elastic Stack의 Kubernetes 로그 분석

로그가 Elasticsearch로 수집되었으니, 이제 로그들을 잘 활용할 때입니다.

Kibana의 Logs 앱 사용

Kibana의 Logs 앱은 Elastic Stack에 수집된 모든 로그를 검색, 필터링 및 추적할 수 있게 해줍니다. 다른 서버로 ssh를 해야 하는 대신, 디렉토리로 cd를 하고 개별 파일을 추적해야 하는 대신, 모든 로그는 Logs 앱에서 하나의 도구로 이용할 수 있습니다. 

  • 키워드 또는 일반 텍스트 검색을 사용하여 필터링 로그를 확인합니다.
  • 시간 선택기 또는 측면의 시간 표시 막대 보기를 사용하여 시간을 앞뒤로 이동할 수 있습니다. 
  • tail -f 스타일로 앞에서 로그가 업데이트되는 것만 보려면 스트리밍 버튼을 클릭하고 강조 표시를 사용하여 원하는 중요한 정보를 강조 표시하세요.

Kibana의 Logs 앱에서 Filebeat 항목 검색

즉시 사용 가능한 Kibana 시각화

우리가 filebeat-setup 작업을 실행할 때, 여러 가지 다른 것들과 함께 Kibana에서 즉시 사용 가능한 대시보드 세트가 미리 생성되었습니다. 샘플 petclinic 애플리케이션이 최종적으로 배포되면 즉시 사용 가능한 MySQL, NGINX용 Filebeat 대시보드로 이동하여 Filebit 모듈이 로그를 캡처할 뿐만 아니라 구성 요소가 기록하는 메트릭도 캡처하는 것을 확인할 수 있습니다. 이러한 시각화를 사용하려면 예제 애플리케이션의 MySQL 및 NGINX 구성 요소를 실행해야 합니다.

Kibana의 즉시 사용 가능한 NGINX 대시보드

Kibana의 즉시 사용 가능한 MySQL 대시보드

머신 러닝 및 로깅 이상 징후 탐지 

Elastic Stack은  7.5 버전부터 애플리케이션 구성 요소의 로그 속도에서 이상 징후를 탐지할 수 있습니다. 이것은 다음과 같은 것을 탐지하는 데 사용될 수 있습니다.

  • 새 애플리케이션 또는 로그 소스가 방금 온보드됨
  • 프로모션(또는 공격!)으로 인해 로깅 작업이 갑자기 증가함
  • 아마도 에이전트 또는 수집 파이프라인 오작동으로 인해 로그 전달이 갑자기 중지됨

Logs 앱에 바로 로그 속도 이상 징후 기능을 도입하여 운영자가 위의 질문에 대한 즉각적인 답변을 얻을 수 있도록 하였습니다. Logs 앱에서 클릭 한 번으로 활성화하세요.

머신 러닝의 로그 데이터 이상 징후 탐지

로그 항목 분류와 함께 알려지지 않은 알 수 없음 탐지

로그와 관련된 머신 러닝의 또 다른 유용한 적용 분야는 이전에는 관찰되지 않았던 새로운 로그 유형 항목을 탐지하는 것입니다. 매우 높은 수준에서 머신 러닝은 타임스탬프, 숫자 값 등과 같은 로그 항목에서 모든 숫자 및 변수 부분을 제거하고 남은 부분을 캡처하여 로그 항목의 고정 부분을 분류합니다. 그런 다음, 버킷으로 그룹화하려고 시도하고 이전에는 볼 수 없었던 로그 항목을 나타내는 이상 징후로 보이는 새 버킷을 계속 플래그합니다.

로그 메시지 분류

즉시 사용 가능한 머신 러닝 작업 — NGINX

우리가 filebeat-setup 작업을 실행할 때, 즉시 사용 가능한 머신 러닝 작업이 미리 생성되었습니다. 활성화되면, Filebeat에서 수집된 NGINX stdout 및 stderr 데이터에서 이상 징후 탐지를 시작할 수 있습니다.

NGINX 로그에 머신 러닝 적용

NGINX 로그에서 이상 징후 탐지

요약

이 파트에서는 Filebeat 및 해당 모듈을 사용하여 Elastic Stack에 Kubernetes 로그를 수집했습니다. Elastic Cloud의 Elasticsearch Service 무료 체험판에 등록하거나 Elastic Stack을 다운로드하고 직접 호스팅하여 오늘 시스템 및 인프라 모니터링을 시작할 수 있습니다. 일단 실행되면, Elastic Uptime으로 호스트의 가용성을 모니터링하고 Elastic APM으로 호스트에서 실행 중인 애플리케이션을 계측하세요. 시스템에서 새 메트릭 클러스터와 완벽하게 통합된, 완전한 통합 가시성을 갖추는 작업을 계속 진행하세요. 어려운 상황에 부딪히거나 질문이 있으시면, 토론 포럼으로 오세요. 저희는 언제나 도와드리기 위해 기다리고 있습니다.

다음 단계: 성능 및 상태 메트릭 수집