eks fluent-bit для тайм-аута эластичного поиска

Итак, у меня была рабочая конфигурация с fluent-bit в eks и elasticsearch на AWS, которая указывала на сервис AWS elasticsearch, но в целях экономии мы удалили этот elasticsearch и создали экземпляр с одиночным elasticsearch, достаточным для целей разработки. А служба aws плохо справляется только с одним экземпляром.

Проблема в том, что во время этой миграции, похоже, что бит fluent-bit сломался, и я получаю много сообщений [предупреждение], которые не удалось сбросить, и некоторые [ошибка] [восходящее] соединение № 55 с ES-SERVER: 9200 истекло время ожидания через 10 секунд. .

Моя текущая конфигурация:

[FILTER]
    Name                kubernetes
    Match               kube.*
    Kube_URL            https://kubernetes.default.svc:443
    Kube_CA_File        /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
    Kube_Token_File     /var/run/secrets/kubernetes.io/serviceaccount/token
    Kube_Tag_Prefix     kube.var.log.containers.
    Merge_Log           On
    Merge_Log_Key       log_processed
    K8S-Logging.Parser  On
    K8S-Logging.Exclude Off
[INPUT]
    Name              tail
    Tag               kube.*
    Path              /var/log/containers/*.log
    Parser            docker
    DB                /var/log/flb_kube.db
    Mem_Buf_Limit     50MB
    Skip_Long_Lines   On
    Refresh_Interval  10
    Ignore_Older      1m

Я думаю, что проблема в одной из этих конфигураций, если я прокомментирую фильтр kubernetes, у меня больше нет ошибок, но я теряю поля в индексах ...

Я попытался настроить некоторые параметры в беглом режиме, но безрезультатно, есть ли у кого-нибудь предложения?

Итак, предыдущие журналы ничего не указали, но я наконец кое-что нашел при активации trace_error в выводе elasticsearch:

{"index":{"_index":"fluent-bit-2021.04.16","_type":"_doc","_id":"Xkxy     23gBidvuDr8mzw8W","status":400,"error":{"type":"mapper_parsing_exception","reas     on":"object mapping for [kubernetes.labels.app] tried to parse field [app] as o     bject, but found a concrete value"}}

Кто-нибудь получал эту ошибку раньше и знает, как ее решить?


person night-gold    schedule 15.04.2021    source источник
comment
Самая распространенная причина, по которой я видел неуспешную очистку блока, заключается в том, что очередь пакетной загрузки в кластере ES заполнена. Вы отправляете больше данных, чем может проиндексировать кластер. Включение ведения журнала отладки в fluentbit должно дать больше информации.   -  person jordanm    schedule 15.04.2021
comment
В таком случае, почему я могу получить данные при удалении фильтра?   -  person night-gold    schedule 15.04.2021
comment
Ах, тогда это может быть конфликт отображения. обязательно включить ведение журнала отладки   -  person jordanm    schedule 15.04.2021
comment
Я добавил журналы отладки в вопрос, помогает ли это.   -  person night-gold    schedule 16.04.2021
comment
Странно то, что он срабатывает один или два раза, когда создаются поды, а затем я получаю флеш-блок.   -  person night-gold    schedule 16.04.2021
comment
Я обнаружил ошибку, когда активировал trace_error из вывода es, я снова обновил сообщение.   -  person night-gold    schedule 16.04.2021
comment
да, конфликт карт. это означает, что у вас есть две разные вещи, выводящие разные типы данных для ключа приложения.   -  person jordanm    schedule 16.04.2021
comment
Да, я просто не понимаю, как это может вызвать эту проблему в поле, таком как ярлык ...   -  person night-gold    schedule 16.04.2021


Ответы (1)


Итак, после просмотра журналов и обнаружения проблемы с отображением, я решил, что проблема решена. Журналы теперь правильно анализируются и отправляются в elasticsearch.

Чтобы решить эту проблему, мне пришлось увеличить лимит повторных попыток вывода и добавить опцию Replace_Dots.

[OUTPUT]
    Name            es
    Match           *
    Host            ELASTICSERVER
    Port            9200
    Index           <fluent-bit-{now/d}>
    Retry_Limit     20
    Replace_Dots    On

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

person night-gold    schedule 19.04.2021