Fluent-bit — разделение журнала json на структурированные поля в Elasticsearch
Я пытаюсь найти способ в конфигурации Fluent-bit, чтобы сообщить/принудить ES хранить журналы в формате json (бит журнал ниже, который исходит от docker stdout/stderror) в структурированном виде - см. изображение внизу для лучшего объяснения. Например, помимо (или вместе с) хранения журнала в виде простой записи json в поле log, я хотел бы хранить каждое свойство отдельно, как показано в красный.
Документация для фильтров и синтаксических анализаторов очень плохая и непонятная. Кроме того, вход forward не имеет опции «парсер». Я пробовал json/docker/regex парсеры, но безуспешно. Мое регулярное выражение здесь, если мне нужно использовать регулярное выражение. В настоящее время используется ES (7.1), Fluent-bit (1.1.3) и Kibana (7.1), а не Kubernetes.
Если кто-нибудь может направить меня к примеру или дать один, я был бы очень признателен.
Спасибо
{
"_index": "hello",
"_type": "logs",
"_id": "T631e2sBChSKEuJw-HO4",
"_version": 1,
"_score": null,
"_source": {
"@timestamp": "2019-06-21T21:34:02.000Z",
"tag": "php",
"container_id": "53154cf4d4e8d7ecf31bdb6bc4a25fdf2f37156edc6b859ba0ddfa9c0ab1715b",
"container_name": "/hello_php_1",
"source": "stderr",
"log": "{\"time_local\":\"2019-06-21T21:34:02+0000\",\"client_ip\":\"-\",\"remote_addr\":\"192.168.192.3\",\"remote_user\":\"\",\"request\":\"GET / HTTP/1.1\",\"status\":\"200\",\"body_bytes_sent\":\"0\",\"request_time\":\"0.001\",\"http_referrer\":\"-\",\"http_user_agent\":\"curl/7.38.0\",\"request_id\":\"91835d61520d289952b7e9b8f658e64f\"}"
},
"fields": {
"@timestamp": [
"2019-06-21T21:34:02.000Z"
]
},
"sort": [
1561152842000
]
}
Спасибо
конф
[SERVICE]
Flush 5
Daemon Off
Log_Level debug
Parsers_File parsers.conf
[INPUT]
Name forward
Listen 0.0.0.0
Port 24224
[OUTPUT]
Name es
Match hello_*
Host elasticsearch
Port 9200
Index hello
Type logs
Include_Tag_Key On
Tag_Key tag
Ответы 2
Для этой цели вы можете использовать фильтр Fluent Bit Nest, см. следующую документацию:
https://docs.fluentbit.io/manual/filter/nest
Документации ОЧЕНЬ не хватает
Решение следующее.
[SERVICE]
Flush 5
Daemon Off
Log_Level debug
Parsers_File parsers.conf
[INPUT]
Name forward
storage.type filesystem
Listen my_fluent_bit_service
Port 24224
[FILTER]
Name parser
Parser docker
Match hello_*
Key_Name log
Reserve_Data On
Preserve_Key On
[OUTPUT]
Name es
Host my_elasticsearch_service
Port 9200
Match hello_*
Index hello
Type logs
Include_Tag_Key On
Tag_Key tag
[PARSER]
Name docker
Format json
Time_Key time
Time_Format %Y-%m-%dT%H:%M:%S.%L
Time_Keep On
# Command | Decoder | Field | Optional Action
# =============|==================|=================
Decode_Field_As escaped_utf8 log do_next
Decode_Field_As json log
Большое спасибо за этот ответ. Документация просто ужас. Один вопрос: как в конечном итоге расшифровывается ваша запись log? Я получаю строку ключ = значение (например, name=john age=27 city=paris), а не декодированную структуру (это не строка JSON, но и не видимая Kibana структура)
Не уверен, что понимаю, что именно вы имеете в виду, но мои журналы приложений по умолчанию имеют формат JSON. Таким образом, ваш пример был бы {"name":"john","age":"27","city":"paris"}, если бы это было мое приложение. Впоследствии вся эта строка будет выглядеть так же в Кибане под клавишей log, как показано выше на изображении. Я надеюсь, что это помогает. Также взгляните на это для более подробного примера.
Извините, что не ясно выразился. Раньше у меня была запись {"name":"john","age":"27","city":"paris"} в качестве записи message в моем журнале, отображаемая Kibana как таковая. Я надеялся, что эта запись может быть декодирована Fluent Bit, чтобы она попала в Elasticsearch как настоящая запись JSON, и чтобы у меня были ключи name, age и city в качестве полей (на том же уровне, что и ваш вход tag или source.
(продолжение) У меня все еще есть запись message, которая теперь name=john age=27 city=paris (вместо строкового представления JSON, которое было раньше). Мне было интересно, является ли это ожидаемым поведением (что делает декодер бесполезным, потому что я не могу искать, например, по ключу city)
Другими словами, запись под message была переписана из строки {"name":"john","age":"27","city":"paris"} в строку name=john age=27 city=paris, что не соответствует ожидаемому парсингу (→ чтобы «взорвать» строку JSON в фактические поля для Kibana)
Также спасибо за вашу ссылку - я вижу, что то, что автор получил в самом конце, это именно то, что я ищу - так что это должно быть что-то на моей стороне. Я получаю перевод пар ключ/значение JSON → вместо ожидаемого синтаксического анализа.
Если журнал вашего приложения представляет собой строку в формате JSON, у вас должно быть поле log в Kibana, содержащее исходный JSON как есть. Кроме того, у вас также должны быть name, age и city в качестве отдельных полей. Все это зависит от синтаксического анализатора, поэтому, если вы использовали самый последний синтаксический анализатор в этом блоге (такой же как у меня выше), он должен работать. Также обратите внимание на бит фильтра в файле fluent-bit.conf.
Эй, @BentCoder, что, если мне нужно проанализировать поле журнала, которое не является json, это строка в одну строку, например «2020-07-11 10:55:38,022 - INFO kv: 1», если они строго выровнены, 0, если нет тогда какие изменения нам нужно сделать на стороне фильтра
@AmanKumarSoni, для этого вам нужно использовать format regex (с функцией именованного захвата): docs.fluentbit.io/manual/pipeline/parsers/regular-expression
Как назвать Key_Data, если ключ вложенный. В моем случае это log_processed['message']. И я пробовал: log_processed['message'], log_processed.message и log_processed_message ничего из этого не работает.
ОП - «Документация для фильтров и парсеров очень плохая и непонятная». Я провел достаточно времени с документом, поэтому причина остановилась на этом вопросе.