Documente Academic
Documente Profesional
Documente Cultură
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
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.
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 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
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
filebeat:
prospectors:
paths:
- /var/log/apps/*.log
input_type: log
output:
logstash:
hosts: ["localhost:5044"]
input {
beats {
filter {
grok {
output {
elasticsearch {
}
Ambos archivos de configuración son autoexplicativos. El único fragmento que merece una
explicación es:
grok {
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
Espero que te haya invitado, era una broma. Instale Kibana para la exploración de registros para que
los desarrolladores se sientan extáticos.