Beats를 통한 Docker 및 Kubernetes 힌트 기반 자동 검색

6.0부터 Beats에 새로운 기능을 추가하기 시작하여 support for container monitoring을 개선합니다. 우리는 새로운 기능을 최근에 소개했습니다. Docker 및 Kubernetes의 지원을 통한 Filebeat 및 Metricbeat 내 자동 검색입니다. 자동 검색은 Beats를 통해 동적으로 시작되는 일련의 구성 세트를 사용자가 원할 때 직접 정의할 수 있게 해 줍니다. 이 기능은 그 동적인 특성 때문에 컨테이너를 모니터링하는 데 특히 유용합니다.

컨테이너 모니터링의 문제점

기존 인프라에서는 일반적으로 새 호스트를 설정하고, 호스트에서 실행할 모든 서비스를 구성하고, 모니터링 에이전트를 구성하여 정기적으로 쿼리합니다. 구성 관리 도구는 작업에 도움이 되지만 그래도 여전히 정적인 상태입니다.

컨테이너 아키텍처에서는 모든 것이 움직이는 대상이 됩니다. 배포는 동적으로 이뤄지며, 확장, 축소, 소멸되고, 컨테이너는 한 노드에서 다른 노드로 오고 갑니다. 메트릭을 검색하는 고정된 IP가 없습니다.

추적을 수행하려면 특정한 도구가 필요합니다.

자동 검색

작동 방식을 살펴보겠습니다. 다음은 샘플 구성입니다.

metricbeat.autodiscover:
  providers:
   - type: docker
     templates:
       - condition.contains:
           docker.container.image: etcd
         config:
          - module: etcd
            metricsets: ["leader", "self", "store"]
            hosts: "${data.host}:2379"

output.elasticsearch:
  hosts: ["localhost:9200"]

docker 자동 검색 제공자를 사용하도록 Metricbeat를 구성하고 있습니다. 사용할 템플릿 목록을 트리거해야 하는 조건에 따라 정의할 수 있습니다. 이 경우, 조건은 etcd를 포함하는 컨테이너 이미지와 일치합니다(포함하다라는 표현은 이미지 필드에 name:tag 쌍이 있다는 의미임). etcd 컨테이너가 생성되면, Metricbeat는 etcd 모듈을 실행하여 모니터링하고 ${data.host} 변수를 컨테이너 IP 주소로 대체합니다.

이 모두가 어떻게 이뤄지는지 자세히 살펴보겠습니다.

1. 자동 검색 이벤트

Beats Autodiscover에는 여러 제공자를 위한 지원이 마련되어 있으며 현재는 Kubernetes와 Docker에 대해 이용할 수 있습니다. 제공자는 특정 플랫폼의 이벤트를 감시하는 방식을 구현합니다. 이벤트가 발생하고 나면 제공자는 자동 검색 이벤트를 생성하며, 여기에는 반응하는 데 필요한 모든 정보를 포함합니다.

2. 조건 일치

모든 이벤트를 프로세서와 동일한 구성 형식으로 조건 목록에 대해 점검합니다. 조건 하나가 이벤트와 일치하는 경우 제공된 구성 세트를 생성합니다.

3. 변수 확장

구성 템플릿에는 변수가 포함될 수 있으며, 이는 조건을 트리거한 이벤트의 실제 값으로 대체됩니다. 이러한 메커니즘은 IP 주소와 같이 컨테이너의 상태에 의존하는 동적 구성을 정의할 수 있게 해 줍니다. 하지만 라벨과 주석의 사용을 통해 더욱 복잡한 구성도 가능하게 합니다.

4. 구성 시작/중단

최종 구성이 생성되면 자동 검색 프로세스에 의해 실행됩니다. 유효한 구성은 Metricbeat와 Filebeat의 모듈과 Filebeat의 입력도 포함합니다.

시작 및 중단 이벤트가 존재하므로 자동 검색에 의해 실행되는 구성은 컨테이너가 이동하면 자동으로 중단됩니다. 이는 특별한 구성을 필요로 하지 않습니다.

자동 검색을 사용할 때 활용하기 좋은, 추가된 특징 한 가지는 자동 검색을 통해 도출되는 모든 이벤트가 Docker 또는 Kubernetes 메타데이터를 통해 자동으로 강화되어 adddockermetadata나 addkubernetesmetadata 프로세서를 사용할 필요가 없다는 것입니다. 이 메타데이터는 로그와 메트릭을 탐색할 때 필터링하고 실제로 중요한 것에 집중할 수 있게 해 주어 도움이 됩니다.

힌트 도입

6.3 릴리스에서는 힌트를 사용하여 컨테이너를 모니터링하는 방식을 정의할 수 있습니다. 기존에는 새로 배포된 애플리케이션의 모니터링을 구성하려면 Beats 설정 파일을 업데이트해야 했습니다.

힌트 기반 자동 검색은 모니터링 설정 컨트롤을 중앙 위치가 아니라 애플리케이션 컨테이너와 가까운 곳에 두어 순서를 전환합니다. 이는 앱을 구축하고 배포하는 팀이 모니터링 방식을 정의하는 책임과 관련하여 역량을 강화한다는 의미입니다.

이러한 구성은 Kubernetes 컨테이너 로그에 대한 힌트 기반 자동 검색을 가능하게 합니다(일례로, 이러한 변화는 당사의 reference Kubernetes manifest for filebeat에서 이뤄질 수 있음).

filebeat.autodiscover:
  providers:
    - type: kubernetes
      hints.enabled: true

그렇습니다. Kubernetes Pod 주석이나 Docker 라벨을 사용하여 Filebeat 및 Metricbeat에게 컨테이너 로그를 처리하는 방법을 전달할 수 있습니다. 예를 들면, Java 애플리케이션을 Pod에서 실행하고 있는 경우 다음과 같은 주석을 추가할 수 있습니다.

annotations:
  co.elastic.logs/multiline.pattern: '^\['
  co.elastic.logs/multiline.negate: 'true'
  co.elastic.logs/multiline.match: after

Pod가 시작되면 Filebeat는 주석을 처리하고 여러 선으로 된 패턴이 있는 로그를 읽기 시작하며, Java 스택의 흔적을 함께 두는 것을 고려합니다. 이용 가능한 힌트의 전체 목록은 설명서를 확인하실 수 있습니다.

또한 모듈을 사용하여 로그를 정형 데이터로 처리할 수도 있습니다. 예를 들어 NGINX 서버를 실행하고 있는 경우, 이 주석을 추가하면 모든 로그가 처리되어 방문에 대한 통찰력을 얻을 수 있습니다.

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

보시다시피, 로그 출력의 각 스트림은 다양한 파일셋으로 매핑되어 있습니다. 또한 co.elastic.logs/fileset으로 정의하면 모든 스트림을 단일 파일셋으로 매핑할 수도 있습니다.

Metricbeat를 사용할 때 힌트를 이용할 수도 있으며, 이는 Metricbeat를 가져오는 동일한 NGINX 인스턴스를 구성하는 방식이 될 것입니다. 보시다시피, 여기서는 변수 확장도 사용할 수 있습니다. ${data.host}는 컨테이너의 IP 주소를 가져오는 데 사용됩니다.

annotations:
  co.elastic.metrics/module: nginx
  co.elastic.metrics/metricsets: stubstatus
  co.elastic.metrics/hosts: '${data.host}:80'
  co.elastic.metrics/period: 10s

Filebeat와 Metricbeat를 모두 실행하는 경우, 두 가지 힌트 세트를 함께 사용할 수 있다는 점을 염두에 두십시오.

결론

힌트 기반 자동 검색은 사용자의 모니터링 설정 구성을 모니터링하려는 애플리케이션에 알맞게 이동시킵니다. 이렇게 하면 멀티테넌트 시나리오에서 팀에게 적합한 도구를 제공합니다. 또한 지침의 단순한 모음을 제공하며, 단순하고 요점잡힌 경험을 할 수 있도록 합니다.

우리는 사용자가 자동 검색을 통해 할 수 있는 일의 겉핥기를 했을 뿐입니다. 귀하의 의견을 듣고 어떻게 활용하고 계신지 자세히 알고 싶습니다! 당사의 Beats forum에 꼭 방문하셔서 어떻게 이용하고 계신지 알려주세요.