36.5.3. fluentd

Fluentd는 노드 레이블 선택기에 따라 노드를 배포하는 DaemonSet으로 배포되며, 인벤토리 매개변수 openshift_logging_fluentd_nodeselector 로 지정할 수 있으며 기본값은 logging-infra-fluentd 입니다. OpenShift 클러스터 설치의 일부로 Fluentd 노드 선택기를 지속된 노드 레이블 목록에 추가하는 것이 좋습니다.

Fluentd는 시스템 로그 소스로 journald 를 사용합니다. 운영 체제, 컨테이너 런타임 및 OpenShift의 로그 메시지입니다.

사용 가능한 컨테이너 런타임은 로그 메시지의 소스를 식별하기 위한 최소한의 정보를 제공합니다. 로그 수집 및 로그 정규화는 Pod가 삭제되고 라벨 또는 주석과 같은 API 서버에서 추가 메타데이터를 검색할 수 없는 후에 발생할 수 있습니다.

로그 수집기가 로그를 완료하기 전에 지정된 이름과 네임스페이스가 있는 Pod를 삭제하면 로그 메시지를 유사한 이름의 Pod 및 네임스페이스와 구분할 수 없습니다. 이로 인해 로그를 인덱싱하고 포드를 배포한 사용자가 소유하지 않은 인덱스에 주석을 달 수 있습니다.

OpenShift Container Platform 3.9 이상을 설치하면 json-file 을 기본 로그 드라이버로 사용하지만 OpenShift Container Platform 3.7에서 업그레이드된 환경에서는 기존 journald 로그 드라이버 구성이 유지됩니다. json-file 로그 드라이버를 사용하는 것이 좋습니다. 기존 로그 드라이버 구성을 json-file 로 변경하려면 집계된 로깅 드라이버 변경 에서 참조하십시오.

Fluentd 로그 보기

로그를 보는 방법은 LOGGING_FILE_PATH 설정에 따라 다릅니다.

Fluentd 로그 위치 구성

Fluentd는 기본적으로 /var/log/fluentd/fluentd.log 또는 LOGGING_FILE_PATH 환경 변수를 기반으로 지정된 파일에 로그를 작성합니다.

Fluentd 로그의 기본 출력 위치를 변경하려면 기본 인벤토리 파일에서 LOGGING_FILE_PATH 매개변수를 사용합니다. 특정 파일을 지정하거나 Fluentd 기본 위치를 사용할 수 있습니다.

LOGGING_FILE_PATH=console 1
LOGGING_FILE_PATH=<path-to-log/fluentd.log> 2

이러한 매개변수를 변경한 후 로깅 설치 프로그램 플레이북을 다시 실행합니다.

$ cd /usr/share/ansible/openshift-ansible
$ ansible-playbook [-i </path/to/inventory>] \
    playbooks/openshift-logging/config.yml

Fluentd 로그 순환 구성

현재 Fluentd 로그 파일이 지정된 크기에 도달하면 OpenShift Container Platform의 이름이 fluentd.log 로그 파일의 이름을 자동으로 변경하여 새 로깅 데이터를 수집할 수 있습니다. 로그 회전은 기본적으로 활성화되어 있습니다.

다음 예에서는 최대 로그 크기가 1Mb이고 로그 4개를 유지해야 하는 클러스터의 로그를 보여줍니다. fluentd.log 가 1Mb에 도달하면 OpenShift Container Platform은 현재 fluentd.log.4 를 삭제하고 각 Fluentd 로그의 이름을 차례로 변경하고 새 fluentd.log 를 생성합니다.

fluentd.log     0b
fluentd.log.1  1Mb
fluentd.log.2  1Mb
fluentd.log.3  1Mb
fluentd.log.4  1Mb

Fluentd 로그 파일의 크기와 환경 변수를 사용하여 OpenShift Container Platform이 유지되는 이름 변경 파일 수를 제어할 수 있습니다.

예를 들면 다음과 같습니다.

$ oc set env ds/logging-fluentd LOGGING_FILE_AGE=30 LOGGING_FILE_SIZE=1024000"

LOGGING_FILE_PATH=console 을 설정하여 로그 회전을 끕니다. 이로 인해 Fluentd는 Fluentd 기본 위치인 /var/log/fluentd/fluentd.log에 로그를 작성합니다. 여기에서 oc logs -f <pod_name> 명령을 사용하여 검색할 수 있습니다.

$ oc set env ds/fluentd LOGGING_FILE_PATH=console

MERGE_JSON_LOG를 사용하여 로그의 JSON 구문 분석 비활성화

기본적으로 Fluentd는 로그 메시지가 JSON 형식인지 확인하고 메시지를 Elasticsearch에 게시된 JSON 페이로드 문서에 병합합니다.

JSON 구문 분석을 사용할 때 다음과 같은 결과가 나타날 수 있습니다.

이러한 문제 일부를 완화하는 방법에 대한 자세한 내용은 로그 수집기에서 로그를 정규화하는 방법을 참조하십시오.

이러한 문제를 방지하거나 로그에서 JSON을 구문 분석할 필요가 없는 경우 JSON 구문 분석을 비활성화할 수 있습니다.

JSON 구문 분석을 비활성화하려면 다음을 수행합니다.

로그 수집기에서 로그를 정규화하는 방법 구성

클러스터 로깅은 데이터베이스 스키마와 같은 특정 데이터 모델을 사용하여 로그 레코드와 해당 메타데이터를 로깅 저장소에 저장합니다. 데이터에는 몇 가지 제한 사항이 있습니다.

이러한 요구 사항으로 인해 다양한 하위 시스템에서 수집된 로그 데이터로 충돌과 불일치가 발생할 수 있습니다.

예를 들어 MERGE_JSON_LOG 기능(MERGE_JSON_LOG=true) 기능을 사용하는 경우 애플리케이션이 JSON에 출력을 기록하고 Elasticsearch에서 데이터를 자동으로 구문 분석하여 인덱싱하도록 하는 것이 매우 유용할 수 있습니다. 그러나 이로 인해 다음과 같은 여러 문제가 발생합니다.

다음 표에서 Fluentd 로그 수집기 데몬 세트를 편집하고 환경 변수를 설정하여 클러스터 로깅이 서로 다른 소스에서 필드를 처리하는 방법을 구성할 수 있습니다.

정의되지 않은 빈 필드 처리를 구성하려면 logging-fluentd daemonset를 편집합니다.

MERGE_JSON_LOG 및 CDM_UNDEFINED_TO_STRING 설정

MERGE_JSON_LOG 및 CDM_ UNDEFINED_TO_STRING 환경 변수를 true로 설정하면 Elasticsearch 400 오류가 발생할 수 있습니다. MERGE_JSON_LOG=true 인 경우 로그 수집기는 문자열 이외의 데이터 유형에 필드를 추가합니다. CDM_UNDEFINED_TO_STRING=true 를 설정하면 Fluentd가 해당 필드를 문자열 값으로 추가하려고 시도하여 Elasticsearch 400 오류가 발생합니다. 다음 날 인덱스가 롤오버될 때 오류가 지워집니다.

Fluentd가 다음 날의 로그에 대한 인덱스를 롤오버하면 완전히 새 인덱스가 생성됩니다. 필드 정의가 업데이트되고 400 오류가 발생하지 않습니다.

스키마 위반, 손상된 데이터 등 하드 오류가 있는 레코드는 재시도할 수 없습니다. 로그 수집기는 오류 처리를 위해 레코드를 전송합니다. Fluentd 구성에 <label @ERROR> 섹션을 추가하는 경우 마지막 <label> 으로 필요에 따라 이러한 레코드를 처리할 수 있습니다.

예를 들면 다음과 같습니다.

data:
  fluent.conf:

....

    <label @ERROR>
      <match **>
        @type file
        path /var/log/fluent/dlq
        time_slice_format %Y%m%d
        time_slice_wait 10m
        time_format %Y%m%dT%H%M%S%z
        compress gzip
      </match>
    </label>

이 섹션에서는 Elasticsearch 배달 못 한 큐(DLQ) 파일에 오류 레코드를 작성합니다. 파일 출력에 대한 자세한 내용은 fluentd 문서를 참조하십시오.

그런 다음 파일을 편집하여 레코드를 수동으로 정리하고 Elasticsearch /_bulk 인덱스 API와 함께 사용하도록 파일을 편집하고 cURL을 사용하여 해당 레코드를 추가할 수 있습니다. Elasticsearch 대량 API에 대한 자세한 내용은 Elasticsearch 설명서를 참조하십시오.

여러 줄 Docker 로그에 참여

Docker 로그 부분 조각에서 전체 로그 레코드를 재구성하도록 Fluentd를 구성할 수 있습니다. 이 기능을 활성화하면 Fluentd는 여러 줄의 Docker 로그를 읽고 재구축하며 누락된 데이터가 없는 Elasticsearch에 로그를 하나의 레코드로 저장합니다.

그러나 이 기능을 사용하면 성능 저하가 발생할 수 있으므로 기능은 기본적으로 꺼져 수동으로 활성화해야 합니다.

다음 Fluentd 환경 변수는 여러 줄의 Docker 로그를 처리하도록 클러스터 로깅을 구성합니다.

다음 명령을 사용하여 사용 중인 로그 드라이버를 확인할 수 있습니다.

$ docker info | grep -i log

다음 중 하나는 출력입니다.

Logging Driver: json-file

Logging Driver: journald

여러 줄의 Docker 로그 처리를 활성화하려면 다음을 수행합니다.

외부 로그 집계기로 로그를 보내도록 Fluentd 구성

secure-forward 플러그인을 사용하여 기본 Elasticsearch 외에도 로그 사본을 외부 로그 집계기로 전송하도록 Fluentd를 구성할 수 있습니다. 여기에서 로컬 호스팅 Fluentd가 처리한 후 로그 레코드를 추가로 처리할 수 있습니다.

로깅 배포는 외부 집계기를 구성하기 위해 Fluentd 구성 맵에 secure-forward.conf 섹션을 제공합니다.

<store>
@type secure_forward
self_hostname pod-${HOSTNAME}
shared_key thisisasharedkey
secure yes
enable_strict_verification yes
ca_cert_path /etc/fluent/keys/your_ca_cert
ca_private_key_path /etc/fluent/keys/your_private_key
ca_private_key_passphrase passphrase
<server>
  host ose1.example.com
  port 24284
</server>
<server>
  host ose2.example.com
  port 24284
  standby
</server>
<server>
  host ose3.example.com
  port 24284
  standby
</server>
</store>

이 작업은 oc edit 명령을 사용하여 업데이트할 수 있습니다.

$ oc edit configmap/logging-fluentd

secure-forward.conf 에서 사용할 인증서는 Fluentd Pod에 마운트된 기존 보안에 추가할 수 있습니다. your_ca_cert 및 your_private_key 값은 configmap/logging-fluentd 의 secure-forward.conf 에 지정된 값과 일치해야 합니다.

$ oc patch secrets/logging-fluentd --type=json \
  --patch "[{'op':'add','path':'/data/your_ca_cert','value':'$(base64 -w 0 /path/to/your_ca_cert.pem)'}]"
$ oc patch secrets/logging-fluentd --type=json \
  --patch "[{'op':'add','path':'/data/your_private_key','value':'$(base64 -w 0 /path/to/your_private_key.pem)'}]"

외부 집계기를 구성할 때 Fluentd에서 메시지를 안전하게 수락할 수 있어야 합니다.

외부 집계기가 또 다른 Fluentd 서버인 경우 fluent-plugin-secure-forward 플러그인이 설치되어 있어야 하며 입력 플러그인을 사용해야 합니다.

<source>
  @type secure_forward

  self_hostname ${HOSTNAME}
  bind 0.0.0.0
  port 24284

  shared_key thisisasharedkey

  secure yes
  cert_path        /path/for/certificate/cert.pem
  private_key_path /path/for/certificate/key.pem
  private_key_passphrase secret_foo_bar_baz
</source>

fluent-plugin-secure-forward 리포지토리에서 fluent-plugin-secure-forward 플러그인을 설정하는 방법에 대한 추가 설명을 확인할 수 있습니다.

Fluentd에서 API 서버로 연결 수 감소

MUX 는 Secure Forward listener 서비스입니다.

Fluentd의 제한 로그

특히 상세한 프로젝트의 경우 관리자는 처리하기 전에 Fluentd에서 로그를 읽는 비율을 제한할 수 있습니다.

제한해야 하는 프로젝트를 Fluentd에 알리려면 배포 후 ConfigMap에서 스로틀 구성을 편집합니다.

$ oc edit configmap/logging-fluentd

throttle-config.yaml 키 형식은 프로젝트 이름과 각 노드에서 로그를 읽는 원하는 속도가 포함된 YAML 파일입니다. 기본값은 노드당 한 번에 1000행입니다. 예를 들면 다음과 같습니다.

project-name:
  read_lines_limit: 50

second-project-name:
  read_lines_limit: 100

logging:
  read_lines_limit: 500

test-project:
  read_lines_limit: 10

.operations:
  read_lines_limit: 100

Fluentd를 변경하려면 구성을 변경하고 Fluentd Pod를 다시 시작하여 변경 사항을 적용합니다. Elasticsearch를 변경하려면 먼저 Fluentd를 축소한 다음 Elasticsearch를 0으로 축소해야 합니다. 변경을 수행한 후 Elasticsearch를 먼저 스케일링한 다음 Fluentd를 원래 설정으로 다시 조정합니다.

Elasticsearch를 0으로 확장하려면 다음을 수행합니다.

$ oc scale --replicas=0 dc/<ELASTICSEARCH_DC>

daemonset 구성에서 nodeSelector를 0과 일치하도록 변경합니다.

$ oc get ds logging-fluentd -o yaml |grep -A 1 Selector
     nodeSelector:
       logging-infra-fluentd: "true"

$ oc patch ds logging-fluentd -p '{"spec":{"template":{"spec":{"nodeSelector":{"nonexistlabel":"true"}}}}}'

$ oc get ds logging-fluentd -o yaml |grep -A 1 Selector
     nodeSelector:
       "nonexistlabel: "true"

Elasticsearch를 0에서 백업합니다.

$ oc scale --replicas=# dc/<ELASTICSEARCH_DC>

daemonset 구성의 nodeSelector를 logging-infra-fluentd: "true"로 다시 변경합니다.

oc patch 명령을 사용하여 daemonset nodeSelector를 수정합니다.

oc patch ds logging-fluentd -p '{"spec":{"template":{"spec":{"nodeSelector":{"logging-infra-fluentd":"true"}}}}}'

버퍼 Chunk 제한 튜닝

Fluentd 로거가 많은 로그를 유지할 수 없는 경우 메모리 사용량을 줄이고 데이터 손실을 방지하기 위해 파일 버퍼링으로 전환해야 합니다.

Fluentd buffer_chunk_limit 는 기본값 8m 이 있는 환경 변수 BUFFER_SIZE_LIMIT 로 결정됩니다. 출력당 파일 버퍼 크기는 기본값이 256Mi 인 환경 변수 FILE_BUFFER_LIMIT 로 결정됩니다. 영구 볼륨 크기는 FILE_BUFFER_LIMIT 보다 커야 합니다.

Fluentd 및 Mux Pod에서 영구 볼륨 /var/lib/fluentd 는 PVC 또는 hostmount에서 준비해야 합니다(예:). 그런 다음 해당 영역은 파일 버퍼에 사용됩니다.

buffer_type 및 buffer_path 는 다음과 같이 Fluentd 구성 파일에 구성됩니다.

$ egrep "buffer_type|buffer_path" *.conf
output-es-config.conf:
  buffer_type file
  buffer_path `/var/lib/fluentd/buffer-output-es-config`
output-es-ops-config.conf:
  buffer_type file
  buffer_path `/var/lib/fluentd/buffer-output-es-ops-config`
filter-pre-mux-client.conf:
  buffer_type file
  buffer_path `/var/lib/fluentd/buffer-mux-client`

Fluentd buffer_queue_limit 는 variable BUFFER_QUEUE_LIMIT 의 값입니다. 이 값은 기본적으로 32 입니다.

환경 변수 BUFFER_QUEUE_LIMIT 은 (FILE_BUFFER_LIMIT / (number_of_outputs * BUFFER_SIZE_LIMIT) 로 계산됩니다.

BUFFER_QUE_LIMIT 변수에 기본 값 세트가 있는 경우:

buffer_queue_limit 값은 32 가 됩니다. buffer_queue_limit 를 변경하려면 FILE_BUFFER_LIMIT 값을 변경해야 합니다.

이 공식에서 number_of_outputs 는 모든 로그 가 단일 리소스에 전송되고 추가 리소스마다 1 씩 증가합니다. 예를 들어 number_of_outputs 값은 다음과 같습니다.