Filebeat와 Metricbeat를 사용하여 Elastic의 방식으로 Kubernetes 모니터링하기

저의 이전 블로그 포스팅에서는 Kubernetes를 모니터링하기 위해 Elastic Stack과 함께 Prometheus와 Fluentd를 사용하는 방법을 보여드렸습니다. 조직에서 이미 오픈 소스 기반 모니터링 도구를 사용하고 있는 경우, 이 옵션이 좋습니다. 그러나 Kubernetes 모니터링이 처음이거나 Elastic Observability를 최대한 활용하고 싶으시다면, 더 쉽고 포괄적인 방법이 있습니다. 이 블로그에서는, Elastic의 방식으로 Kubernetes를 모니터링하는 방법에 대해 알아보겠습니다. 바로 Filebeat와 Metricbeat를 사용하는 것입니다.

Filebeat와 Metricbeat 사용하기

알고 계시듯이, Beats는 데이터 전송/수집 전용 무료 개방형 플랫폼입니다. Beats를 사용하면, 수백 또는 수천 대의 시스템에서 Logstash 또는 Elasticsearch로 데이터를 전송할 수 있습니다.

Filebeat는 경량 로그 수집기로 알려져 있으며, 컨테이너화된 아키텍처도 지원합니다. Filebeat를 Docker, Kubernetes 및 클라우드 환경에 배포하여 모든 로그 스트림을 수집하고, 컨테이너, 포드, 노드, 가상 환경 및 호스트와 같은 메타데이터를 가져와 해당 로그 이벤트와 자동으로 연관시킬 수 있습니다. Metricbeat는 Filebeat와 마찬가지로 컨테이너화된 환경도 지원하는 경량 메트릭 수집기입니다. Kubernetes 환경에서, 컨테이너는 이용 가능한 작업자 노드에서 동적으로 포드로 배포됩니다. 이 "동적"이 핵심이며, Filebeat와 Metricbeat에는 자동 검색(Autodiscover)이라는 편리한 기능이 있습니다. 컨테이너에서 애플리케이션을 실행하면, 해당 애플리케이션이 모니터링 시스템을 위한 움직이는 대상이 됩니다. Filebeat와 Metricbeat의 Kubernetes 자동 검색 제공자는 Kubernetes 노드, 포드 및 서비스의 시작, 업데이트, 중지를 모니터링합니다. Filebeat나 Metricbeat가 이러한 이벤트를 탐지하면, 각 이벤트에 적합한 메타데이터를 사용할 수 있게 됩니다. 또한, 시작된 Kubernetes 포드의 주석에 따라 대상 로그와 메트릭에 적절한 설정을 적용합니다. 힌트 기반 자동 검색은 Beats를 통한 Docker 및 Kubernetes 힌트 기반 자동 검색에 대한 이전 블로그 포스팅에 자세히 설명되어 있습니다.

모니터링 아키텍처

이전 블로그에서처럼, Cloud-Voting-App이라고 하는 단순한 다중 컨테이너 애플리케이션을 Kubernetes 클러스터에 배포하고 해당 애플리케이션을 포함한 Kubernetes 환경을 모니터링할 것입니다. 이번에는, Filebeat를 사용하여 로그를 수집하고, Metricbeat를 사용하여 메트릭을 수집하며, 이를 Elasticsearch에 직접 수집하고, Kibana를 사용하여 모니터링하는 절차에 대해 설명하겠습니다. 또한 Elastic APM을 사용하여 Prometheus 사용자 정의 메트릭을 얻는 방법에 대해서도 다루려고 합니다. 개요 아키텍처는 아래 그림에 나와 있습니다. 또한, 이 튜토리얼의 코드는 제 GitHub 리포지토리에서 제공됩니다. 전체 절차는 이를 참조하시기 바랍니다.

각 단계를 살펴봅시다!

Filebeat를 DaemonSet로 배포하기

Kubernetes 노드당 하나의 Filebeat 인스턴스만 배포해야 합니다. DaemonSet의 매니페스트는 이미 elastic/filebeat-kubernetes.yaml 파일에 정의되어 있지만, 관련 설정을 살펴보도록 하겠습니다.

먼저, Kubernetes 자동 검색 제공자를 사용하여 로그를 처리하기 위한 애플리케이션 포드 주석 설정을 구성합니다. 보시다시피, 자동 검색 설정은 filebeat.autodiscover 섹션에 정의되어 있습니다. 힌트를 활성화하고 컨테이너 로그의 기본 경로를 설정했습니다. Filebeat를 위한 자동 검색 구성에 대한 자세한 내용은 Filebeat 설명서를 참조하세요.

...
    # 힌트 기반 자동 검색을 활성화하려면, `filebeat.inputs` 구성을 제거하고 이 주석 처리를 해제하세요.
    filebeat.autodiscover:
      providers:
        - type: kubernetes
          node: ${NODE_NAME}
          hints.enabled: true
          hints.default_config:
            type: container
            paths:
              - /kr/var/log/containers/*${data.kubernetes.container.id}.log
...

위의 내용 이외에는, 기본적으로 Elasticsearch 클러스터에 대한 자격 증명과 URL을 추가하기만 하면 됩니다.

...
     containers:
      - name: filebeat
        image: docker.elastic.co/beats/filebeat:7.13.0
        args: [
          "-c", "/kr/etc/filebeat.yml",
          "-e",
        ]
        env:
        - name: ELASTICSEARCH_HOST
          value: elasticsearch
        - name: ELASTICSEARCH_PORT
          value: "9200"
        - name: ELASTICSEARCH_USERNAME
          value: elastic
        - name: ELASTICSEARCH_PASSWORD
          value: changeme
        - name: ELASTIC_CLOUD_ID
          value:
        - name: ELASTIC_CLOUD_AUTH
          value:
...

kube-state-metrics 배포하기

kube-state-metrics는 Kubernetes에 저장된 개체를 모니터링하는 Kubernetes 애드온입니다. kube-state-metrics는 Kubernetes 클러스터에 배포된 Kubernetes 개체의 상태를 식별하는 데 중점을 두고 있습니다. 예를 들어, 특정 시점에 클러스터에 배포되는 포드 수, 클러스터에서 할당할 수 있는 CPU 코어 수, 실패한 작업 수 등이 있습니다. 기본적으로 Kubernetes 클러스터에는 kube-state-metrics가 배포되지 않으므로, 이를 자체적으로 배포해야 합니다. kube-state-metrics의 샘플 매니페스트는 examples/standard 아래에 있으니, 참고하시기 바랍니다. kube-state-metrics에 대한 자세한 내용은 이 GitHub 리포지토리를 참조하세요.

Metricbeat를 DaemonSet로 배포하기

Filebeat와 유사하게, Kubernetes 노드당 하나의 Metricbeat 인스턴스만 배포해야 합니다. DaemonSet의 매니페스트는 elastic/metricbeat-kubernetes.yaml 파일에 이미 정의되어 있지만, Filebeat보다 약간 더 까다롭습니다. 주요 설정을 살펴보겠습니다.

자동 검색을 위한 설정은 metricbeat.autodiscover 섹션에 정의되어 있습니다. 첫 번째 - type: kubernetes 설정은 전체 Kubernetes 클러스터에 대한 것입니다. 여기서는, Metricbeat의 Kubernetes 모듈을 사용하여 전체 Kubernetes 클러스터에 대한 메트릭을 구성합니다. 첫 번째 - module: kubernetes 구성은 위에서 언급한 kube-state-metrics에서 얻은 메트릭을 설정합니다. 두 번째 - module: kubernetes 구성은 Kubernetes API를 노출하는 Kubernetes 컨트롤 플레인의 핵심인 Kubernetes API 서버(kube-apiserver)를 모니터링하기 위한 구성입니다. Metricbeat의 Kubernetes 모듈에 대한 자세한 내용은 Metricbeat 설명서를 참조하세요.

metricbeat.autodiscover:
  providers:
    - type: kubernetes
      scope: cluster
      node: ${NODE_NAME}
      unique: true
      templates:
        - config:
            - module: kubernetes
              hosts: ["kube-state-metrics:8080"]
              period: 10s
              add_metadata: true
              metricsets:
                - state_node
                - state_deployment
                - state_daemonset
                - state_replicaset
                - state_pod
                - state_container
                - state_cronjob
                - state_resourcequota
                - state_statefulset
                - state_service
            - module: kubernetes
              metricsets:
                - apiserver
              hosts: ["https://${KUBERNETES_SERVICE_HOST}:${KUBERNETES_SERVICE_PORT}"]
              bearer_token_file: /kr/var/run/secrets/kubernetes.io/serviceaccount/token
              ssl.certificate_authorities:
                - /kr/var/run/secrets/kubernetes.io/serviceaccount/ca.crt
              period: 30s

또한, 애플리케이션 포드 주석 설정을 사용하여 메트릭을 처리할 수 있도록 Kubernetes 자동 검색 제공자를 활용하여 힌트를 정의합니다. Metricbeat 자동 검색 구성에 대한 자세한 내용은 Metricbeat 설명서를 참조하세요.

    # 힌트 기반 자동 검색을 활성화하려면 이 주석 처리를 해제하세요.
    - type: kubernetes
      node: ${NODE_NAME}
      hints.enabled: true

다음 ConfigMap 설정은 Metricbeat의 Kubernetes 모듈의 기본 메트릭 세트인 node/system/pod/container/volume에 대한 것입니다. 이러한 메트릭은 각 노드의 kubelet 엔드포인트에서 가져옵니다.

kubernetes.yml: |-
  - module: kubernetes
    metricsets:
      - node
      - system
      - pod
      - container
      - volume
    period: 10s
    host: ${NODE_NAME}
    hosts: ["https://${NODE_NAME}:10250"]
    bearer_token_file: /kr/var/run/secrets/kubernetes.io/serviceaccount/token
    ssl.verification_mode: "none"

그리고 Filebeat와 마찬가지로, Elasticsearch 클러스터에 대한 자격 증명과 URL을 추가하기만 하면 됩니다.

애플리케이션 배포하기

이전 블로그에서와 마찬가지로, Cloud-Voting-App을 배포하겠습니다. 애플리케이션 인터페이스는 Python/Flask를 사용하여 구축되었습니다. 데이터 구성 요소는 Redis를 사용합니다. Prometheus 사용자 정의 메트릭을 노출하기 위해 애플리케이션이 Prometheus Python 클라이언트로 계측되었다는 것을 기억하세요. 이번에는 Prometheus가 없음에도 불구하고 어떻게 Prometheus 사용자 정의 메트릭을 수집할까요? 7.12부터는, Elastic APM Agent를 사용하여 사용자 정의 Prometheus 메트릭을 얻을 수 있습니다!

먼저, 애플리케이션이 ElasticAPM을 가져오고 환경 변수는 Elastic APM Agent 설정에 사용됩니다. SERVICE_NAME은 애플리케이션을 식별하기 위한 임의의 문자 스트링이고, ENVIRONMENT는 애플리케이션 환경을 식별하기 위한 임의 의 문자 스트링이며, SECRET_TOKEN과 SERVER_URL은 APM 서버와의 통신을 위한 스트링입니다. 마지막 PROMETHEUS_METRICS는 prometheus_client에서 메트릭을 가져올지 여부를 나타내는 매개 변수입니다.

from elasticapm.contrib.flask import ElasticAPM
...
app = Flask(__name__)
...
# Elastic APM 구성
app.config['ELASTIC_APM'] = {
# 필요한 서비스 이름 설정. 허용되는 문자:
# a-z, A-Z, 0-9, -, _, 공백
'SERVICE_NAME': os.environ['SERVICE_NAME'],
#
# APM 서버에 토큰이 필요한 경우 사용
'SECRET_TOKEN': os.environ['SECRET_TOKEN'],
#
# 사용자 정의 APM 서버 URL 설정(기본값: http://localhost:8200)
'SERVER_URL': os.environ['SERVER_URL'],
#
# 환경 설정
'ENVIRONMENT': os.environ['ENVIRONMENT'],
#
# prometheus_metrics 설정
'PROMETHEUS_METRICS': os.environ['PROMETHEUS_METRICS'],
}
apm = ElasticAPM(app)

다음은 Cloud-Voting-App을 Kubernetes 클러스터에 배포하기 위한 매니페스트입니다. 해당 파일은 elastic/cloud-vote-all-in-one-redis-aks.yaml에 있습니다. 가장 먼저, 사용자 인터페이스 cloud-vote-front에 대해, 컨테이너 사양에서 위에서 언급한 APM 에이전트에 필요한 변수가 환경 변수로 설정됩니다. 여기에서는, 포드별 주석이 지정되지 않으므로, 로그와 메트릭이 모두 기본 설정을 사용하여 얻어집니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cloud-vote-front
spec:
  replicas: 1
  selector:
    matchLabels:
      app: cloud-vote-front
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  minReadySeconds: 5
  template:
    metadata:
      labels:
        app: cloud-vote-front
    spec:
      nodeSelector:
        "beta.kubernetes.io/os": linux
      containers:
      - name: cloud-vote-front
        image: your image name
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 250m
          limits:
            cpu: 500m
        env:
        - name: REDIS
          value: "cloud-vote-back"
        - name: SERVICE_NAME
          value: "cloud-voting"
        - name: SECRET_TOKEN
          value: "APM Server secret token"
        - name: SERVER_URL
          value: "APM Server URL"
        - name: ENVIRONMENT
          value: "Production"
        - name: PROMETHEUS_METRICS
          value: "True"

반면, 백엔드인 cloud-vote-redis는 포드 annotations를 사용해 로그의 경우 Filebeat redis 모듈을 활성화하고 메트릭의 경우 Metricbeat redis 모듈을 활성화하여 필요한 설정을 적용합니다. cloute-vote-front는 기본 설정을 사용하여 Beats의 로그와 메트릭을 수집하지만, cloud-vote-back은 Beats의 redis 모듈을 사용하여 로그와 메트릭을 수집합니다. 또한 Beats 매니페스트 대신 애플리케이션 매니페스트에서 로그와 메트릭을 수집하는 방법을 구성하여, 개발 팀과 Observability 플랫폼 팀 간의 책임을 분리할 수 있습니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cloud-vote-back
spec:
  replicas: 1
  selector:
    matchLabels:
      app: cloud-vote-back
  template:
    metadata:
      labels:
        app: cloud-vote-back
      annotations:
        co.elastic.logs/enabled: "true"
        co.elastic.logs/module: redis
        co.elastic.logs/fileset.stdout: log
        co.elastic.metrics/enabled: "true"
        co.elastic.metrics/module: redis
        co.elastic.metrics/hosts: "${data.host}:6379"
    spec:
      nodeSelector:
        "beta.kubernetes.io/os": linux
      containers:
      - name: cloud-vote-back
        image: redis
        ports:
        - containerPort: 6379
          name: redis

Kibana에 액세스하기

이제 필요한 모든 구성 요소를 배포했습니다. Cloud-Voting-App으로 몇 번 투표한 다음 Kibana에 액세스해 보겠습니다.

Observability 개요

가장 먼저, Kibana에서 Elastic Observability를 열면, 아무 작업도 수행하지 않고 Filebeat의 로그 입력의 로그 속도와 Metricbeat의 메트릭 입력 요약이 표시됩니다. 이 결과는 Filebeat와 Metricbeat가 기본적으로 ECS 형식의 데이터를 수집한다는 사실에서 기인합니다.

로그

Filebeat에서 수집한 로그는 filebeat-* 인덱스에 저장됩니다. Kibana의 Logs 앱을 사용하여 Elasticsearch에서 수집된 모든 로그를 검색, 필터링 및 추적할 수 있습니다. 특정 스트링을 강조 표시할 수도 있습니다. 예를 들어, 아래 예제에서는 cloud-vote-front를 강조 표시했습니다.

메트릭

Metricbeat에서 수집한 메트릭은 metricbeat-* 인덱스에 저장됩니다. Kibana의 Metrics 앱은 Elasticsearch에서 수집한 메트릭을 이해하기 쉽고 직관적으로 볼 수 있는 방법을 제공합니다. 아래에 나와 있는 것과 같이, Kubernetes Pods 보기를 사용하여 Kubernetes 노드와 포드를 매핑하고 각 리소스의 사용량을 보여줍니다.

또한 특정 포드를 클릭하여 컨텍스트를 유지하면서 포드 로그 또는 APM 추적과 같은 다른 앱으로 이동할 수도 있습니다. 화면에서 View details for kubernetes.pod.uid a47d81b1-02d7-481a-91d4-1db9fe82d7a7이 표시되는 것을 눈여겨 보세요.

그런 다음 Kubernetes Pod logs를 클릭하여 이 포드의 로그로 이동할 수 있습니다. Logs 앱의 검색 창이 이미 kubernetes.pod.uid: a47d81b1-02d7-481a-91d4-1db9fe82d7a7로 채워져 있다는 것을 알아차리셨나요? 이러한 방식으로 컨텍스트를 유지함으로써, Kibana는 앱에서 앱으로 원활하게 전환하여 정확한 결과를 즉시 반환할 수 있습니다.

그럼 Prometheus 사용자 정의 메트릭은 어떻게 되었을까요? Prometheus Python 클라이언트가 보유한 사용자 정의 메트릭은 Elastic APM Agent를 통해 apm-*이라는 인덱스에 기록됩니다. Kibana Discover를 확인하시면, 이것이 prometheus.metrics.cloud_votes 필드에 수집되어 있음을 알 수 있습니다. POST 요청의 변수는 labels.vote로 저장됩니다. Elastic APM Python 에이전트를 사용한 Prometheus 사용자 정의 메트릭 수집에 대한 자세한 내용은 APM 설명서를 참조하세요.

다음과 같이 Kibana Lens를 통해 apm-* 인덱스를 쉽게 시각화할 수 있습니다.

미리 정의된 대시보드

Redis를 사용하는 cloud-vote-back 포드의 경우, Filebeat와 Metricbeat 양쪽 모두에 대해 redis 모듈을 활성화했습니다. 이렇게 하면 즉시 사용할 수 있는 관련 대시보드가 미리 생성됩니다. 추가 설정 없이 즉시 Redis 로그와 메트릭을 시각화할 수 있습니다.

또한, Metricbeat의 Kubernetes 모듈 덕분에, Kubernetes 대시보드도 사용할 준비가 되어 있습니다.

요약

이 블로그에서는, Filebeat와 Metricbeat를 사용하여 Kubernetes 모니터링을 위한 로그와 메트릭으로 Elastic Stack을 채울 수 있는 보다 Elastic다운 방법을 소개했습니다. 또한 Elastic APM Agent를 사용하여 Prometheus 사용자 정의 메트릭을 얻는 방법에 대해서도 알아보았습니다. 지금 바로 Elastic Cloud 무료 체험판, 에 등록하거나 Elastic Stack을 다운로드하고 직접 호스팅하여 Kubernetes 환경 모니터링을 시작하실 수 있습니다. Elastic Observability를 사용하면 보다 효율적이고 효과적인 모니터링이 가능합니다. 또한 Elastic 머신 러닝 및 Kibana 경보와 통합되어 고도로 자동화되고 실행 가능하며 포괄적인 통합 가시성을 구축할 수 있습니다. 어려운 상황에 부딪히거나 질문이 있으시면, 토론 포럼으로 오세요. 저희는 언제나 도와드리기 위해 기다리고 있습니다.

향후 후속 블로그 포스팅에서, Kubernetes 모니터링을 위해 Elastic을 사용하는 더 많은 방법을 소개해 드릴 예정이니 눈여겨 봐주시기 바랍니다.