Utilizando o processor JSON

O processor de JSON com certeza está no TOP 5 de quem trabalha com Observabilidade,
principalmente se for ingerindo logs de Kubernetes. Mas ai vem a pergunta:

“Se Elasticsearch já trabalha com formato JSON por que usar um processor JSON dentro
do JSON?”

A resposta é: Normalmente os encaminhadores de Logs enviam os metadados em formato

JSON e o log raw em formato texto, então mesmo que o log raw seja também um JSON o
mesmo não será parseado ao ser enviado para o Elasticsearch e é ai que entra o processor
JSON, pois com ele você consegue parsear essa string.

Com base nesse entendimento vamos a nossa API Simulate.

POST /_ingest/pipeline/_simulate
{
"pipeline": {
"description": "PIPELINE JSON",
"processors": [
{
"json": {
"field": "message",
"add_to_root": true
}
}
]
},
"docs": [
{
"_index": "index",
"_id": "id",
"_source": {
"message": """{"level":"INFO","os":"linux","type":"audit"}"""
}
}
]
}

No processor acima passamos o campo message com um string que apesar de ser JSON
ela está sendo “escapa” por três aspas duplas, isso indica para o Elasticsearch ignorar
qualquer outro carácter especial que tenha dentro e a indexe como string, mas ao passá-la
no processor JSON o mesmo compreende que a mesma possui uma sintaxe JSON e
parseia os dados, inclusive estou adicionando um parâmetro chamado “add_to_root” para
que tais campos sejam adicionados na raíz do documento.
Como retorno temos o seguinte:

{
"docs" : [
{
"doc" : {
"_index" : "index",
"_type" : "_doc",
"_id" : "id",
"_source" : {
"os" : "linux",
"level" : "INFO",
"message" : """{"level":"INFO","os":"linux","type":"audit"}""",
"type" : "audit"
},
"_ingest" : {
"timestamp" : "2023-01-28T21:28:22.006308894Z"
}
}
}
]
}

Veja que os campos “os”,”level” e “type” foram separados da string do message e colocado
na raíz do documento.

Ref:
● https://www.elastic.co/guide/en/elasticsearch/reference/current/json-processor.html