"Fluent Bit 문서/쿠버네티스"의 두 판 사이의 차이

12번째 줄: 12번째 줄:


==개념==
==개념==
Before getting started it is important to understand how Fluent Bit will be deployed. Kubernetes manages a cluster of nodes, so our log agent tool will need to run on every node to collect logs from every POD, hence Fluent Bit is deployed as a DaemonSet (a POD that runs on every node of the cluster).
시작하기 전에 Fluent Bit가 어떻게 배포되는지 이해하는 것이 중요합니다. Kubernetes는 노드 클러스터를 관리하므로, 로그 에이전트 도구는 모든 POD에서 로그를 수집하기 위해 모든 노드에서 실행되어야 하므로 Fluent Bit는 DaemonSet(클러스터의 모든 노드에서 실행되는 POD)로 배포됩니다.


When Fluent Bit runs, it will read, parse and filter the logs of every POD and will enrich each entry with the following information (metadata):
Fluent Bit가 실행되면 모든 POD의 로그를 읽고 구문 분석하고 필터링하며 다음 정보(메타데이터)로 각 항목을 강화합니다.
* 파드 이름
* 파드 ID
* 컨테이너 이름
* 컨테이너 ID
* 레이블
* 애노테이션


* Pod Name
이 정보를 얻기 위해, kubernetes라는 빌트인 필터 플러그인은 Kubernetes API 서버와 통신하여 pod_id, labels, annotations과 같은 관련 정보를 조회하고, pod_name, container_id, container_name과 같은 기타 필드는 로컬에서 로그 파일 이름으로부터 조회됩니다. 이 모든 것이 자동으로 처리되므로 설정 측면에서 개입이 필요하지 않습니다.
* Pod ID
* Container Name
* Container ID
* Labels
* Annotations


To obtain this information, a built-in filter plugin called kubernetes talks to the Kubernetes API Server to retrieve relevant information such as the pod_id, labels and annotations, other fields such as pod_name, container_id and container_name are retrieved locally from the log file names. All of this is handled automatically, no intervention is required from a configuration aspect.
{{인용문|Kubernetes 필터 플러그인은 전적으로, [https://github.com/jimmidyson Jimmi Dyson]이 작성한 [https://github.com/fabric8io/fluent-plugin-kubernetes_metadata_filter Fluentd Kubernetes Metadata Filter]에서 영감을 받았습니다.}}
 
Our Kubernetes Filter plugin is fully inspired by the Fluentd Kubernetes Metadata Filter written by Jimmi Dyson.


==설치==
==설치==

2024년 4월 15일 (월) 14:21 판

1 개요

Kubernetes
쿠버네티스

Kubernetes 프로덕션급 로그 처리기

Fluentbit kube logging.png

Fluent Bit 는 Kubernetes를 완벽하게 지원하는 가볍고 확장가능한 로그 처리기입니다.

  • 파일 시스템 또는 Systemd/Journald에서 Kubernetes 컨테이너 로그를 처리합니다.
  • Kubernetes 메타데이터로 로그를 강화(enrich)하세요.
  • Elasticsearch, InfluxDB, HTTP와 같은 서드파티 스토리지 서비스로 로그를 중앙화하세요.

2 개념

시작하기 전에 Fluent Bit가 어떻게 배포되는지 이해하는 것이 중요합니다. Kubernetes는 노드 클러스터를 관리하므로, 로그 에이전트 도구는 모든 POD에서 로그를 수집하기 위해 모든 노드에서 실행되어야 하므로 Fluent Bit는 DaemonSet(클러스터의 모든 노드에서 실행되는 POD)로 배포됩니다.

Fluent Bit가 실행되면 모든 POD의 로그를 읽고 구문 분석하고 필터링하며 다음 정보(메타데이터)로 각 항목을 강화합니다.

  • 파드 이름
  • 파드 ID
  • 컨테이너 이름
  • 컨테이너 ID
  • 레이블
  • 애노테이션

이 정보를 얻기 위해, kubernetes라는 빌트인 필터 플러그인은 Kubernetes API 서버와 통신하여 pod_id, labels, annotations과 같은 관련 정보를 조회하고, pod_name, container_id, container_name과 같은 기타 필드는 로컬에서 로그 파일 이름으로부터 조회됩니다. 이 모든 것이 자동으로 처리되므로 설정 측면에서 개입이 필요하지 않습니다.

Kubernetes 필터 플러그인은 전적으로, Jimmi Dyson이 작성한 Fluentd Kubernetes Metadata Filter에서 영감을 받았습니다.

3 설치

Fluent Bit should be deployed as a DaemonSet, so on that way it will be available on every node of your Kubernetes cluster.

The recommended way to deploy Fluent Bit is with the official Helm Chart: https://github.com/fluent/helm-charts

3.1 OpenShift 참고사항

If you are using Red Hat OpenShift you will also need to set up security context constraints (SCC):

$ kubectl create -f https://raw.githubusercontent.com/fluent/fluent-bit-kubernetes-logging/master/fluent-bit-openshift-security-context-constraints.yaml

3.2 헬름 차트로 설치

Helm is a package manager for Kubernetes and allows you to quickly deploy application packages into your running cluster. Fluent Bit is distributed via a helm chart found in the Fluent Helm Charts repo: https://github.com/fluent/helm-charts.

To add the Fluent Helm Charts repo use the following command

helm repo add fluent https://fluent.github.io/helm-charts To validate that the repo was added you can run helm search repo fluent to ensure the charts were added. The default chart can then be installed by running the following

helm upgrade --install fluent-bit fluent/fluent-bit

3.3 기본값

The default chart values include configuration to read container logs, with Docker parsing, systemd logs apply Kubernetes metadata enrichment and finally output to an Elasticsearch cluster. You can modify the values file included https://github.com/fluent/helm-charts/blob/master/charts/fluent-bit/values.yaml to specify additional outputs, health checks, monitoring endpoints, or other configuration options.

4 세부사항

The default configuration of Fluent Bit makes sure of the following:

Consume all containers logs from the running Node.

The Tail input plugin will not append more than 5MB into the engine until they are flushed to the Elasticsearch backend. This limit aims to provide a workaround for backpressure scenarios.

The Kubernetes filter will enrich the logs with Kubernetes metadata, specifically labels and annotations. The filter only goes to the API Server when it cannot find the cached info, otherwise it uses the cache.

The default backend in the configuration is Elasticsearch set by the Elasticsearch Output Plugin. It uses the Logstash format to ingest the logs. If you need a different Index and Type, please refer to the plugin option and do your own adjustments.

There is an option called Retry_Limit set to False, that means if Fluent Bit cannot flush the records to Elasticsearch it will re-try indefinitely until it succeed.

5 컨테이너 런타임 인터페이스(CRI) 파서

Fluent Bit by default assumes that logs are formatted by the Docker interface standard. However, when using CRI you can run into issues with malformed JSON if you do not modify the parser used. Fluent Bit includes a CRI log parser that can be used instead. An example of the parser is seen below:

# CRI Parser
[PARSER]
    # http://rubular.com/r/tjUt3Awgg4
    Name cri
    Format regex
    Regex ^(?<time>[^ ]+) (?<stream>stdout|stderr) (?<logtag>[^ ]*) (?<message>.*)$
    Time_Key    time
    Time_Format %Y-%m-%dT%H:%M:%S.%L%z

To use this parser change the Input section for your configuration from docker to cri

[INPUT]
    Name tail
    Path /var/log/containers/*.log
    Parser cri
    Tag kube.*
    Mem_Buf_Limit 5MB
    Skip_Long_Lines On

6 윈도우 배포

v1.5.0부터 Fluent Bit는 Windows 파드에 대한 배포를 지원합니다.

6.1 로그 파일 개요

Fluent Bit를 Kubernetes에 배포할 때, 관심 있게 봐야 할 로그 파일 세 가지가 있습니다.

C:\k\kubelet.err.log

  • 호스트에서 실행되는 kubelet 데몬의 오류 로그 파일입니다.
  • 향후 트러블슈팅(배포 실패 디버깅 등)을 위해 이 파일을 보관할 필요가 있습니다.

C:\var\log\containers\<pod>_<namespace>_<container>-<docker>.log

  • 이것은 감시(watch)해야 할 메인 로그 파일입니다. 이 파일을 따르도록 Fluent Bit를 설정합니다.
  • 이는 파일 이름에 일부 추가 메타데이터가 포함된, C:\ProgramData\ 내의 Docker 로그 파일에 대한 심볼릭 링크입니다 .

C:\ProgramData\Docker\containers\<docker>\<docker>.log

  • Docker에서 생성한 로그 파일입니다.
  • 일반적으로 이 파일에서 직접 읽지는 않지만 Fluent Bit에서 이 파일이 표시되는지 확인해야 합니다.

일반적으로 배포 yaml에는 다음 볼륨 구성이 포함됩니다.

spec:
  containers:
  - name: fluent-bit
    image: my-repo/fluent-bit:1.8.4
    volumeMounts:
    - mountPath: C:\k
      name: k
    - mountPath: C:\var\log
      name: varlog
    - mountPath: C:\ProgramData
      name: progdata
  volumes:
  - name: k
    hostPath:
      path: C:\k
  - name: varlog
    hostPath:
      path: C:\var\log
  - name: progdata
    hostPath:
      path: C:\ProgramData

6.2 Fluent Bit 설정

위에서 설명한 기본 볼륨 설정을 가정하여, 다음 설정을 적용하면 로깅을 시작할 수 있습니다. 여기(등록 필요)에서 설정을 시각화할 수 있습니다.

fluent-bit.conf: |
    [SERVICE]
      Parsers_File      C:\\fluent-bit\\parsers.conf

    [INPUT]
      Name              tail
      Tag               kube.*
      Path              C:\\var\\log\\containers\\*.log
      Parser            docker
      DB                C:\\fluent-bit\\tail_docker.db
      Mem_Buf_Limit     7MB
      Refresh_Interval  10

    [INPUT]
      Name              tail
      Tag               kubelet.err
      Path              C:\\k\\kubelet.err.log
      DB                C:\\fluent-bit\\tail_kubelet.db

    [FILTER]
      Name              kubernetes
      Match             kube.*
      Kube_URL          https://kubernetes.default.svc.cluster.local:443

    [OUTPUT]
      Name  stdout
      Match *

parsers.conf: |
    [PARSER]
        Name         docker
        Format       json
        Time_Key     time
        Time_Format  %Y-%m-%dT%H:%M:%S.%L
        Time_Keep    On

6.3 윈도우 파드의 불안정한 네트워크 완화

Windows 파드는 부팅 직후 작동하는 DNS가 부족한 경우가 많습니다(#78479). 이 이슈를 완화하기 위해 filter_kubernetes는, 네트워크가 시작될 때까지 기다리는 빌트인 메커니즘을 제공합니다.

  • DNS_Retries - 네트워크가 작동하기 시작할 때까지 N번 재시도 (6)
  • DNS_Wait_Time - 네트워크 상태 확인 간격 (30)

기본적으로, Fluent Bit는 3분(30초 x 6회)동안 기다립니다. 충분하지 않은 경우 다음과 같이 설정을 조정하십시오.

[filter]
    Name kubernetes
    ...
    DNS_Retries 10
    DNS_Wait_Time 30

7 참고

문서 댓글 ({{ doc_comments.length }})
{{ comment.name }} {{ comment.created | snstime }}