Как заставить Fluentd быстрее отправлять логи в Elasticsearch? - PullRequest
Новая
       8

Как заставить Fluentd быстрее отправлять логи в Elasticsearch?

0 голосов
/ 03 октября 2019

Я установил несколько док-контейнеров, в которых контейнер fluentd отправляет журналы в формате JSON в контейнер Elasticsearch (который, в свою очередь, читается Kibana). Я настроил fluentd для получения журналов через UDP, так как наши приложения регистрируют, отправляя UDP-сообщения. Это работает, но по какой-то причине происходит большая задержка, и текучие журналы достигают ES только через 5 минут.

Моя конфигурация fluentd: 

<system>
  log_level debug
</system>

<source>
  @type udp
  @label @udp_stream
  tag ma.udp_events
  <parse>
    @type json
    time_key $.log.@timestamp
    keep_time_key true
  </parse>
  port 20001
  bind 0.0.0.0
  message_length_limit 1MB
  source_hostname_key client_host
  source_address_key  client_addr
</source>

<label @udp_stream>
  <match **>
    @type copy
    <store>
      @type elasticsearch
      host elastic
      port 9200
      index_name logs.${app_environment}.${app_category}.${app_area}.${app_name}
      include_tag_key true
      reload_connections true
      reconnect_on_error false
      reload_on_failure false
      <buffer tag, app_environment, app_category, app_area, app_name>
        flush_at_shutdown true
        flush_mode immediate
        flush_thread_count 8
        flush_thread_interval 1
        flush_thread_burst_interval 1
        retry_forever true
        retry_type exponential_backoff
        retry_max_interval 30
        retry_wait 1
        chunk_limit_size 1K
        queue_limit_length 8
      </buffer>
    </store>
  </match>
</label>

Помимо этих настроек, есть тот же источник для TCP и еще один источник для tail. Я пытался удалить их, но проблема, похоже, в другом. Я читал об этой 5-минутной задержке, связанной с буферами, но я надеялся, что более детальная политика очистки поможет.

Журналы имеют размер всего от 1 КБ до 2 КБ, и я тестирую их, отправляя журналы вручную, поэтомутам над головой я просто отправляю несколько раз в минуту. Я бы хотел, чтобы он быстро очистил свои буферы. После некоторых исследований SO и некоторых блогов, я изменил раздел буфера, но безрезультатно. Конечно, я делаю ошибку, но не могу ее найти. Любая помощь будет высоко ценится.

РЕДАКТИРОВАТЬ:

Кажется, что я не могу получить журналы от Fluentd к ES менее чем за 5 минут. Однако я попытался удалить раздел буфера, ожидая, что он будет быстрее. Хотя я вижу текучие журналы о промывке и очистке кусков, почему-то они не сразу доставляются. Моя конфигурация тестирования немного отличается от исходной публикации, потому что я установил новый ключ в JSON (который я назвал "@es_index_name"), а также удалил раздел буфера.

I 'читаем здесь :

"td-agent непрерывно загружает журналы каждые 5 минут. Вы можете заставить td-agent сбрасывать буферизованные журналы в облако, отправляя сигнал SIGUSR1."

В любом случае, моя текущая конфигурация тестирования: 

<label @udp_stream>
  <match **>
    @type copy
    <store>
      @type elasticsearch
      host elastic
      port 9200
      prefer_oj_serializer true
      target_index_key @es_index_name
      include_tag_key true
      reload_connections true
      reconnect_on_error false
      reload_on_failure false
      flush_interval 5s
    </store>
    <store>
      @type stdout
    </store>
  </match>
</label>

Помимо строк, которые я удалил при попытке упростить, важная строка здесь:

target_index_key @ es_index_name

РЕДАКТИРОВАТЬ 2: По какой-то причине после того, как я развернул этот контейнер как рабочую нагрузку Kubernetes, журналы начали очищаться, как и ожидалось. Я не знаю, почему это происходит, но, в конце концов, я хотел, чтобы это работало так. Теперь одно из наших приложений отправляет журнал UDP на наш Fluentd, и Kibana требуется всего несколько секунд, чтобы отобразить его на своих инструментальных панелях.

...