ELK Registra-se no aplicativo desaparecendo quando as regras de grok estão ativadas

Question

Temos duas instâncias de um aplicativo (mesmo aplicativo, banco de dados diferente), vamos chamá-lo de app1 e app2. A rota que os registros levam é:

1. o appX executa o filebeat, que seleciona o arquivo de log do aplicativo com o appX e envia cada entrada para uma instância do logstash em um cluster rabbitmq. É então adicionado em coqm.
2. A mensagem atravessa o cluster rabbitmq e é consumida por outra instância do logstash, que executa vários filtros dependendo a tag.
3. A mesma instância do logstash envia a linha de log resultante para o elasticsearch.

Tudo bem. No caso de app1 & 2, os filtros são um grok, que divide a mensagem em campos em que podemos pesquisar.

app1 funciona, os logs são processados pelo filtro e aparecem no índice correto em elasticsearch como esperado.

app2 não funciona. O problema são as regras de grok, eu sei disso porque se eu remover as regras de grok que são executadas para app2, os logs aparecem conforme o esperado. No momento em que descomentei as regras de grok, os logs para app2 pararam de aparecer em elasticsearch em qualquer lugar

O filtro para app1 e app2 é idêntico:

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                        
            }
    } 
}

Eu suspeito que o elasticsearch está se recusando a indexar os logs do app2. Naturalmente, verifiquei os registros de elasticsearch e logstash, mas nenhum problema foi relatado. Isso me levou a investigar como "transformar" o registro em elasticsearch.

Alguém sabe como fazer com que o elasticsearch relate qualquer erro relacionado à ingestão desses registros? ou ter uma idéia de como eu posso descobrir o que está acontecendo com os logs do app2 quando o grok está habilitado?

Eu tentei isso:

    # curl -X PUT "localhost:9200/_cluster/settings" -H 'Content-Type: application/json' -d'
{ 
  "transient": {
"logger._root": "trace" 
 } 
}
'

que previsivelmente me dá uma "mangueira de fogo para a boca", mas pelo menos algo que é greppable. A tag é mencionada apenas em termos de processamento de uma linha de registro específica.

Obrigado antecipadamente.

Um pouco mais sobre isso: Acabei de executar o logstash com as regras do app2 grok no lugar e com o log de filtro ativado da seguinte forma:

# curl -XPUT 'localhost:9600/_node/logging?pretty' -H 'Content-Type: application/json' -d'
{
"logger.logstash.filters.grok" : "ALL"
}'

Nenhum erro aparece, o que reforça a minha teoria de que as regras de grok estão corretas e que o elasticsearch está se recusando a indexar as mensagens. Eu também fiz isso:

# curl -XPUT 'localhost:9600/_node/logging?pretty' -H 'Content-Type: application/json' -d' 
{
"logger.logstash.outputs.elasticsearch" : "ALL"
} '

Para verificar se não há erros de indexação. Enquanto nenhum erro é relatado, um pouco preocupante, NADA é relatado, o que me faz pensar se estou latindo na árvore errada.

    

Answer 1

Na minha experiência, quando o ES vomita em uma inserção, ele vai vomitar nos logs para o pobre humano decodificar e descobrir. Eu geralmente vejo quando há um problema de mapeamento. Um tipo de colisão ou um documento mal formado.

(Esta é a razão número um que eu não estou logstashing meus registros ES. Esse mau consumo irá falhar a ingestão novamente quando está nos logs ES, e em torno do loop de erro é executado. Além disso, é uma bomba PII na direita casos)

Outra etapa da solução de problemas é definir uma saída condicional ao lado da saída de ES para descartar os eventos app1 e app2 em um arquivo. Isso lhe dará a chance de olhar para eles lado a lado no estado em que seriam enviados para o ES. Isso pode revelar algumas pistas sobre o que está acontecendo. Talvez algum outro estágio do filtro esteja manipulando um. Ou talvez app2 nunca chegue tão longe, então o problema é entre o filtro e os output {} estágios.