Recopilación de registros en Elasticsearch con Filebeat y Logstash

Tienes suerte si nunca has estado involucrado en la confrontación entre los desarrolladores y
desarrolladores en tu carrera en cualquier lado. En esta publicación, mostraré una solución a un
problema que a menudo está en disputa: el acceso a los registros de aplicaciones en producción.

El tema en cuestión

Imagina que eres un devops responsable de ejecutar las aplicaciones de la empresa en producción.
Las aplicaciones son compatibles con los desarrolladores que, obviamente, no tienen acceso al
entorno de producción y, por lo tanto, a los registros de producción.

Imagine que cada servidor ejecuta varias aplicaciones, y las aplicaciones almacenan los registros
/var/log/apps. Un servidor con dos aplicaciones en ejecución tendrá un diseño de registro:

$ tree /var/log/apps

/var/log/apps

├── alice.log

└── bob.log

El problema: ¿Cómo permitir a los desarrolladores acceder a sus registros de producción de manera
eficiente?

Una solución

Al sentir el dolor de los desarrolladores (o enojarse con los "favores" regulares), decidió recopilar
todos los registros de aplicaciones en Elasticsearch, donde cada desarrollador puede buscarlos. La
implementación más sencilla sería la de configuración Elasticsearch y configurar Filebeat para
reenviar registros de la aplicación directamente a Elasticsearch.

Elasticsearch

He descrito en detalles una introducción rápida a Elasticsearch y cómo instalarlo en mi publicación

anterior . Así que echa un vistazo allí si no sabes cómo hacerlo.

Filebeat

Filebeat, que reemplazó a Logstash-Forwarder hace algún tiempo, se instala en sus servidores como
agente. Supervisa los archivos de registro y puede reenviarlos directamente a Elasticsearch para su
indexación.

La configuración de Filebeat que resuelve el problema mediante el reenvío de registros directamente

a Elasticsearch podría ser tan simple como:
filebeat:

prospectors:

paths:

- /var/log/apps/*.log

input_type: log

output:

elasticsearch:

hosts: ["localhost:9200"]

Funcionará Los desarrolladores podrán buscar el registro usando el sourcecampo, que Filebeat agrega
y contiene la ruta del archivo de registro.

Tenga en cuenta que utilicé localhost con el puerto predeterminado y la configuración mínima.

Si estás paranoico con respecto a la seguridad, probablemente ya te has levantado las cejas. Los
desarrolladores no deben saber sobre la ubicación de los registros. Pero esta es una historia
diferente.

Apuesto a que los desarrolladores se enojarán muy pronto con esta solución. Deben realizar una
búsqueda de términos con la ruta completa del archivo de registro o se arriesgan a recibir registros no
relacionados de registros con un nombre parcial similar. El problema se agrava si ejecuta aplicaciones
dentro de contenedores de Docker administrados por Mesos o Kubernetes.

Una mejor solucion

Una mejor solución sería introducir un paso más. En lugar de enviar registros directamente a
Elasticsearch, Filebeat debería enviarlos primero a Logstash . Logstash enriquecerá los registros con
metadatos para permitir una búsqueda simple y precisa y luego reenviará los registros enriquecidos a
Elasticsearch para su indexación.

Logstash

Logstash es el mejor motor de recopilación de datos de código abierto con capacidades de

canalización en tiempo real. Logstash puede limpiar los registros, crear nuevos campos mediante la
extracción de valores del mensaje de registro y otros campos utilizando un lenguaje de expresión
extensible muy potente y mucho más.

La introducción de un nuevo appcampo, con el nombre de la aplicación del rodamiento extraído del
sourcecampo, sería suficiente para resolver el problema.
Configuración final

La configuración de Filebeat cambiará a

filebeat:

prospectors:

paths:

- /var/log/apps/*.log

input_type: log

output:

logstash:

hosts: ["localhost:5044"]

y la configuración de Logstash se verá como

input {

beats {

port => "5044"

filter {

grok {

match => { "source" => "%{GREEDYDATA}/%{GREEDYDATA:app}.log" }

output {

elasticsearch {

hosts => ["localhost:9200"]

}
Ambos archivos de configuración son autoexplicativos. El único fragmento que merece una
explicación es:

grok {

match => { "source" => "%{GREEDYDATA}/%{GREEDYDATA:app}.log" }

Si el sourcecampo tiene el valor "/var/log/apps/alice.log", la coincidencia extraerá la palabra alice y la

establecerá como el valor del campo recién creado app.

La línea de fondo

La solución final es mucho mejor. Los desarrolladores pueden ejecutar consultas de términos exactos
en el appcampo, por ejemplo:

$ curl
http://localhost:9200/_all/_search?q=app:bob&sort=@tymestamp:asc&sort=offset:asc&fields=messa
ge&pretty | grep message

con salida

"message" : [ "Bob message 1" ]

"message" : [ "Bob message 2" ]

"message" : [ "Bob message 3" ]

"message" : [ "Bob message 4" ]

"message" : [ "Bob message 5" ]

"message" : [ "Bob message 6" ]

"message" : [ "Bob message 7" ]

"message" : [ "Bob message 8" ]

"message" : [ "Bob message 9" ]

"message" : [ "Bob message 10" ]

Espero que te haya invitado, era una broma. Instale Kibana para la exploración de registros para que
los desarrolladores se sientan extáticos.