Fluentd: 출력 버퍼를 구성하는 것이 중요한 이유

오늘날에는 클러스터의 애플리케이션과 시스템 구성 요소 모두에 대한 로그를 저장하는 ELK 스택이 없는 Kubernetes 기반 프로젝트를 상상하는 것이 불가능합니다. 실제로는 Logstash 대신 Fluentd와 함께 EFK 스택을 사용합니다.

Fluentd는 점점 더 많은 인기를 얻고 있는 현대적인 범용 로그 수집기이며 Cloud Native Computing Foundation에 합류했습니다. 이것이 바로 Fluentd의 개발 벡터가 Kubernetes와 함께 사용하는 데 중점을 두는 이유입니다.

Logstash 대신 Fluentd를 사용한다는 사실이 소프트웨어 패키지의 일반적인 본질을 바꾸지는 않습니다. 그러나 Fluentd는 다재다능함으로 인한 고유한 뉘앙스가 특징입니다.

예를 들어, 로깅 강도가 높은 바쁜 프로젝트에서 EFK를 사용하기 시작했을 때 Kibana에서 일부 메시지가 여러 번 반복적으로 표시된다는 사실에 직면했습니다. 이번 포스팅에서는 이런 현상이 발생하는 이유와 해결 방법에 대해 알려드리겠습니다.

문서 복제 문제

우리 프로젝트에서 Fluentd는 DaemonSet(Kubernetes 클러스터의 각 노드에 있는 하나의 인스턴스에서 자동으로 시작됨)으로 배포되고 /var/log/containers에서 stdout 컨테이너 로그를 모니터링합니다. 수집 및 처리 후 JSON 문서 형식의 로그는 프로젝트 규모와 성능 및 내결함성에 대한 요구 사항에 따라 클러스터 또는 독립 실행형 형식으로 생성되어 ElasticSearch로 전송됩니다. Kibana는 그래픽 인터페이스로 사용됩니다.

출력 버퍼링 플러그인과 함께 Fluentd를 사용할 때 ElasticSearch의 일부 문서에 내용이 정확히 동일하고 식별자만 다른 상황이 발생했습니다. Nginx 로그를 예로 사용하여 이것이 메시지 반복인지 확인할 수 있습니다. 로그 파일에는 다음 메시지가 단일 복사본으로 존재합니다.

127.0.0.1 192.168.0.1 - [28/Feb/2013:12:00:00 +0900] "GET / HTTP/1.1" 200 777 "-" "Opera/12.0" -

그러나 ElasticSearch에는 이 메시지가 포함된 여러 문서가 있습니다.

{
  "_index": "test-custom-prod-example-2020.01.02",
  "_type": "_doc",
  "_id": "HgGl_nIBR8C-2_33RlQV",
  "_version": 1,
  "_score": 0,
  "_source": {
    "service": "test-custom-prod-example",
    "container_name": "nginx",
    "namespace": "test-prod",
    "@timestamp": "2020-01-14T05:29:47.599052886 00:00",
    "log": "127.0.0.1 192.168.0.1 - [28/Feb/2013:12:00:00  0900] "GET / HTTP/1.1" 200 777 "-" "Opera/12.0" -",
    "tag": "custom-log"
  }
}

{
  "_index": "test-custom-prod-example-2020.01.02",
  "_type": "_doc",
  "_id": "IgGm_nIBR8C-2_33e2ST",
  "_version": 1,
  "_score": 0,
  "_source": {
    "service": "test-custom-prod-example",
    "container_name": "nginx",
    "namespace": "test-prod",
    "@timestamp": "2020-01-14T05:29:47.599052886 00:00",
    "log": "127.0.0.1 192.168.0.1 - [28/Feb/2013:12:00:00  0900] "GET / HTTP/1.1" 200 777 "-" "Opera/12.0" -",
    "tag": "custom-log"
  }
}

또한 두 번 이상 반복될 수도 있습니다.

Fluentd 로그에서 이 문제를 해결하는 동안 다음 내용이 포함된 많은 경고를 볼 수 있습니다.

2020-01-16 01:46:46 +0000 [warn]: [test-prod] failed to flush the buffer. retry_time=4 next_retry_seconds=2020-01-16 01:46:53 +0000 chunk="59c37fc3fb320608692c352802b973ce" error_class=Fluent::Plugin::ElasticsearchOutput::RecoverableRequestFailure error="could not push logs to Elasticsearch cluster ({:host=>"elasticsearch", :port=>9200, :scheme=>"http", :user=>"elastic", :password=>"obfuscated"}): read timeout reached"

이러한 경고는 ElasticSearch가 request_timeout 매개변수에 지정된 시간 내에 요청에 대한 응답을 반환할 수 없을 때 발생하며, 이로 인해 전달된 버퍼 조각을 지울 수 없습니다. 그 후 Fluentd는 버퍼 조각을 ElasticSearch로 다시 보내려고 시도하고 임의의 횟수만큼 시도한 후에 작업이 성공적으로 완료됩니다.

2020-01-16 01:47:05 +0000 [warn]: [test-prod] retry succeeded. chunk_id="59c37fc3fb320608692c352802b973ce" 
2020-01-16 01:47:05 +0000 [warn]: [test-prod] retry succeeded. chunk_id="59c37fad241ab300518b936e27200747" 
2020-01-16 01:47:05 +0000 [warn]: [test-dev] retry succeeded. chunk_id="59c37fc11f7ab707ca5de72a88321cc2" 
2020-01-16 01:47:05 +0000 [warn]: [test-dev] retry succeeded. chunk_id="59c37fb5adb70c06e649d8c108318c9b" 
2020-01-16 01:47:15 +0000 [warn]: [kube-system] retry succeeded. chunk_id="59c37f63a9046e6dff7e9987729be66f"

그러나 ElasticSearch는 전송된 각 버퍼 조각을 고유한 것으로 처리하고 인덱싱 중에 고유한 _id 필드 값을 할당합니다. 이것이 메시지 사본이 나타나는 방식입니다.

Kibana에서는 다음과 같이 보입니다.

솔루션

이 문제를 해결하기 위한 몇 가지 옵션이 있습니다. 그 중 하나는 각 문서에 대한 고유한 해시를 생성하기 위해 fluent-plugin-elasticsearch 플러그인에 내장된 메커니즘입니다. 이 메커니즘을 사용하면 ElasticSearch는 전달 단계에서 반복을 인식하고 문서 중복을 방지합니다. 그러나 이 문제 해결 방법은 조사에 어려움을 겪고 시간 제한이 부족하여 오류를 제거하지 못하므로 이 방법의 사용을 포기했습니다.

단기적인 네트워크 문제 또는 로깅 강도 증가 시 로그 손실을 방지하기 위해 Fluentd 출력에 버퍼링 플러그인을 사용합니다. 어떤 이유로 ElasticSearch가 문서를 인덱스에 즉시 쓸 수 없는 경우 해당 문서는 대기열에 추가되어 디스크에 저장됩니다. 따라서 우리의 경우 위에서 설명한 오류를 유발하는 문제의 원인을 제거하려면 Fluentd 출력 버퍼의 크기가 충분하고 버퍼링 매개 변수에 대한 올바른 값을 설정해야 합니다. 동시에 할당된 시간 내에 클리어되도록 관리합니다.

아래에 설명된 매개변수의 값은 서비스별로 로그에 메시지를 쓰는 강도, 디스크 시스템 성능, 네트워크 등 여러 요소에 따라 달라지므로 출력 플러그인에서 버퍼링을 사용하는 각 특정 사례마다 개별적이라는 점은 주목할 가치가 있습니다. 채널 로드 및 대역폭. 따라서 무작정 긴 검색을 피하고 개별 사례에 적합하면서도 중복되지 않는 버퍼 설정을 얻으려면 Fluentd가 작업 중에 로그에 기록하는 디버깅 정보를 사용하여 비교적 빠르게 올바른 값을 얻을 수 있습니다.

문제가 기록된 당시 구성은 다음과 같았습니다.

 <buffer>
        @type file
        path /var/log/fluentd-buffers/kubernetes.test.buffer
        flush_mode interval
        retry_type exponential_backoff
        flush_thread_count 2
        flush_interval 5s
        retry_forever
        retry_max_interval 30
        chunk_limit_size 8M
        queue_limit_length 8
        overflow_action block
      </buffer>

문제를 해결할 때 다음 매개변수의 값을 수동으로 선택했습니다.
Chunk_limit_size — 버퍼의 메시지가 분할되는 청크의 크기입니다.

• flash_interval — 버퍼가 지워진 후의 시간 간격입니다.
• queue_limit_length — 대기열의 최대 청크 수입니다.
• request_timeout은 Fluentd와 ElasticSearch 간의 연결이 설정되는 시간입니다.

총 버퍼 크기는 매개변수 queue_limit_length와 Chunk_limit_size를 곱하여 계산할 수 있습니다. 이는 "각각 주어진 크기를 갖는 대기열의 최대 청크 수"로 해석될 수 있습니다. 버퍼 크기가 충분하지 않으면 로그에 다음 경고가 표시됩니다.

2020-01-21 10:22:57 +0000 [warn]: [test-prod] failed to write data into buffer by buffer overflow action=:block

이는 할당된 시간 내에 버퍼를 지울 시간이 없으며, 전체 버퍼에 들어가는 데이터가 차단되어 로그의 일부가 손실된다는 의미입니다.

큐에 있는 각 청크의 크기를 늘리거나 큐에 있을 수 있는 청크 수를 늘리는 두 가지 방법으로 버퍼를 늘릴 수 있습니다.

청크 크기(chunk_limit_size)를 32MB 이상으로 설정하면 들어오는 패킷이 너무 크기 때문에 ElasticSeacrh는 이를 허용하지 않습니다. 따라서 버퍼를 더 늘려야 한다면 최대 큐 길이인 queue_limit_length를 늘리는 것이 좋습니다.

버퍼 오버플로가 멈추고 시간 초과 부족 메시지만 남으면 request_timeout 매개변수를 늘리기 시작할 수 있습니다. 그러나 값을 20초 이상으로 설정하면 Fluentd 로그에 다음 경고가 표시되기 시작합니다.

2020-01-21 09:55:33 +0000 [warn]: [test-dev] buffer flush took longer time than slow_flush_log_threshold: elapsed_time=20.85753920301795 slow_flush_log_threshold=20.0 plugin_id="postgresql-dev" 

이 메시지는 시스템 작동에 어떠한 영향도 미치지 않으며 버퍼 플러시 시간이 Slow_flush_log_threshold 매개변수에 설정된 것보다 오래 걸렸음을 의미합니다. 이는 디버깅 정보이며 request_timeout 매개변수의 값을 선택할 때 사용됩니다.

일반화된 선택 알고리즘은 다음과 같습니다.

1. request_timeout을 필요한 것(수백 초)보다 큰 값으로 설정하십시오. 설정하는 동안 이 매개변수를 올바르게 설정하기 위한 주요 기준은 시간 초과 부족에 대한 경고가 사라지는 것입니다.
2. Slow_flush_log_threshold 임계값 초과에 대한 메시지를 기다립니다. elapsed_time 필드의 경고 텍스트는 버퍼가 지워진 실시간 시간을 표시합니다.
3. request_timeout을 관찰 기간 동안 얻은 최대 elapsed_time 값보다 큰 값으로 설정하십시오. request_timeout 값은 elapsed_time + 50%로 계산됩니다.
4. 로그에서 긴 버퍼 플러시에 대한 경고를 제거하려면 Slow_flush_log_threshold 값을 올리면 됩니다. 이 값은 elapsed_time + 25%로 계산됩니다.

앞에서 언급한 것처럼 이러한 매개변수의 최종 값은 각 경우에 대해 개별적으로 얻어집니다. 위의 알고리즘을 따르면 반복되는 메시지로 이어지는 오류를 제거할 수 있습니다.

아래 표는 위에서 설명한 매개변수 값을 선택하는 과정에서 메시지 중복으로 이어지는 일일 오류 수가 어떻게 변하는지 보여줍니다.

노드-1
노드-2
노드-3
노드-4

전 후
전 후
전 후
전 후

버퍼를 플러시하지 못했습니다.
1749/2
694/2
47/0
1121/2

재시도 성공
410/2
205/1
24/0
241/2

프로젝트가 성장하고 그에 따라 로그 수가 증가함에 따라 결과 설정의 관련성이 사라질 수 있다는 점도 주목할 가치가 있습니다. 시간 초과가 충분하지 않다는 주요 징후는 Fluentd 로그에 긴 버퍼 플러시에 대한 메시지가 반환되는 것입니다. 즉, Slow_flush_log_threshold 임계값을 초과하는 것입니다. 이 시점부터는 request_timeout 매개변수를 초과하기 전까지 약간의 여유가 있으므로 이러한 메시지에 적시에 응답하고 위에서 설명한 최적의 설정을 선택하는 과정을 반복해야 합니다.

결론

Fluentd 출력 버퍼를 미세 조정하는 것은 EFK 스택 구성의 주요 단계 중 하나이며, 작동 안정성과 인덱스에서 문서의 올바른 배치를 결정합니다. 설명된 구성 알고리즘을 기반으로 모든 로그가 반복이나 손실 없이 올바른 순서로 ElasticSearch 인덱스에 기록된다는 것을 확신할 수 있습니다.

블로그에서 다른 기사도 읽어보세요.

• Go와 Zabbix 5.0이 친구가 되었습니다
• 다운타임 없이 Kubernetes 클러스터 업그레이드
• Kubernetes: 시스템 리소스 관리를 설정하는 것이 왜 그렇게 중요한가요?
• Docker 이미지를 축소하는 세 가지 간단한 트릭
• 다수의 이기종 웹 프로젝트 백업

출처 : habr.com