У нас есть два экземпляра приложения (одно и то же приложение, другая база данных), давайте назовем их app1 и app2. Маршрут, по которому идут журналы:
Все хорошо. В случае app1 и 2 фильтры представляют собой grok, который разбивает сообщение на поля, по которым мы затем можем искать.
app1 работает, журналы обрабатываются фильтром и отображаются в правильном индексе в elasticsearch, как и ожидалось.
app2 не работает. Проблема в правилах grok, я знаю это, потому что если я удалю правила grok, которые запускаются для app2, журналы будут отображаться, как ожидалось. В тот момент, когда я раскомментирую правила grok, журналы для app2 перестают отображаться в elasticsearch везде
Фильтры для приложений app1 и app2 идентичны:
filter {
if "app2" in [tags] {
mutate {
gsub => ["message", "\n", "LINE_BREAK"]
}
grok {
match => [ "message", "%{TIMESTAMP_ISO8601:time}\s+%{WORD:level}\s+\[%{DATA:thread_name}\]\s+%{DATA:class}\:%{DATA:line} %{DATA:method}\s*-\s*%{DATA:message}$" ]
overwrite => [ "message" ]
}
date {
match => [ "time", "YYYY-MM-dd HH:mm:ss,SSS"]
target => "@timestamp"
}
mutate {
remove_field => [ "time" ] # Removes the 'time' field
}
}
}
Я подозреваю, что elasticsearch отказывается индексировать журналы из app2. Естественно, я проверил журналы и elasticsearch, и logstash, но никаких проблем не было. Это заставило меня исследовать, как «включить» ведение журнала в elasticsearch.
Кто-нибудь знает, как заставить elasticsearch сообщать об ошибках, связанных с приемом этих журналов? или есть представление о том, как я могу узнать, что происходит с журналами app2, когда Grok включен?
Я пробовал это:
# curl -X PUT "localhost:9200/_cluster/settings" -H 'Content-Type: application/json' -d'
{
"transient": {
"logger._root": "trace"
}
}
'
что предсказуемо дает мне «пожарный шланг ко рту», но, по крайней мере, кое-что, что можно схватить. Тег упоминается только с точки зрения обработки определенной строки журнала.
Заранее спасибо.
Еще немного об этом: я только что запустил logstash с установленными правилами app2 grok и с включенным журналированием фильтра следующим образом:
# curl -XPUT 'localhost:9600/_node/logging?pretty' -H 'Content-Type: application/json' -d'
{
"logger.logstash.filters.grok" : "ALL"
}'
Ошибок не появляется, что еще раз подтверждает мою теорию о том, что правила Grok сами по себе верны и что его elasticsearch отказывается индексировать сообщения. Я также сделал это:
# curl -XPUT 'localhost:9600/_node/logging?pretty' -H 'Content-Type: application/json' -d'
{
"logger.logstash.outputs.elasticsearch" : "ALL"
} '
Для проверки отсутствия ошибок индексации. Хотя об ошибках не сообщается, что несколько тревожно, НИЧЕГО не сообщается, что заставляет меня задаться вопросом, не лаяю ли я не на то дерево.
По моему опыту, когда ES рвет вставку, она сразу же заносится в журналы, чтобы бедняга мог расшифровать и выяснить. Я обычно вижу это, когда возникает проблема с отображением. Либо коллизия типов, либо искаженный документ.
(Это причина номер один, по которой я не веду журналы своих журналов ES. Этот плохой прием приведет к сбою приема снова, когда он находится в журналах ES, и вокруг выполняется цикл ошибок. Кроме того, это PII-бомба в правильных случаях)
Еще один шаг по устранению неполадок, который следует попробовать, - установить условный вывод рядом с выходом ES, чтобы отбросить app1
и app2
события в файл. Это даст вам возможность посмотреть на них бок о бок в том состоянии, в котором они будут отправлены в ES. Это может дать некоторые подсказки относительно того, что происходит. Возможно, какой-то другой этап фильтрации манипулирует одним. Или, может быть app2
никогда не заходит так далеко, поэтому проблема между фильтром и output {}
этапы.