Español
English
La plataforma de Google Cloud (GCP) provee de un sistema de logging con una política de retención de logs de 30 días en prácticamente todos los tipos de logs disponibles. Por este motivo, si queremos guardar un histórico, analizar tendencias, entre otros, tendremos que guardar estos logs en otro lugar donde perduren más tiempo y que además nos permita extraer información útil. Para este propósito podemos encontrar múltiples herramientas, pero en este artículo nos vamos a centrar en el ELK.
Las herramientas utilizadas en este escenario son las siguientes: Logging de GCP, Google Cloud Pub/Sub, PubSubBeat y Elasticsearch. El logging de GCP lo utilizaremos para la extracción de los logs. La combinación de pub/sub y pubsubbeat nos servirá para enviar estos logs hacia el nodo elastic que estará esperando los datos y elasticsearch para inyectarlos y mostrarlos en kibana.
Logging de GCP
Primeramente tendremos que hacer un estudio previo para analizar que tipos de logs nos interesa guardar para estudiar y que tipo de logs nos interesa descartar. Este primer estudio puede llegar a hacerse realmente costoso si trabajamos con múltiples proyectos y servicios de Google Cloud, pues la información generada por cada servicio añade datos muy detallados que hay que tener en cuenta. Concretamente, nos podemos encontrar con logs en formato json cuya estructura tiene tal número de anidaciones de diccionarios y listas que incluso elastic no sea capaz de ingestar debido a errores de parseo. Después de este primer estudio se deberá trabajar en la creación de filtros para la correcta extracción de los logs deseados. Una vez hecho esto, hay que crear un sink. Un sink en GCP es un filtro que se encarga de buscar todos los logs generados que coincidan con el filtro aplicado y enviarlos al lugar donde se le ha configurado, en este caso a Pub/Sub, aunque también se puede enviar a BigqQuery o a Google Cloud Storage.
Pub/Sub y PubSubBeat
Estos dos servicios los añadimos como un mismo paquete pues están altamente relacionados en el sistema que queremos montar. Pub/Sub es un sistema de mensajería de datos que permite enviar los datos tanto en streaming como en bulk. El funcionamiento de Pub/Sub es sencillo: tenemos un topic que es un almacenamiento abstracto de datos donde uno o varios publisher enviarán la información que uno o más subscribers están esperando. En nuestro escenario, tendríamos que crear un topic donde enviar los datos, y como anteriormente el sink enviaba los datos al mismo Pub/Sub, este haría el trabajo de publisher en el topic. De hecho, al configurar el sink se debe añadir el topic donde irán los datos, así que la gestión se hace mucho más sencilla.
Hasta el momento, con lo que hemos explicado conseguimos tener los logs exportados a un topic, y ahora faltaría recoger esos logs del topic con un subscriber, pues la retención de logs en un topic es de 7 días y nosotros queremos tenerlo en el ELK. Aquí es donde aparece PubSubBeat, que es un beat no oficial de elasticsearch cuyo funcionamiento es el de hacer de subscriber absorbiendo los logs del topic e inyectandolos al elastic. Parece que ya se ha terminado el proceso, pero hay que tener en cuenta el formato en el que vienen estos logs. Estos logs los recibe PubSubBeat en forma de string con los caracteres especiales escapados usando contrabarras (‘\’). Para conseguir mostrar todos los campos correctamente en kibana, hace falta configurar una pipeline de elasticsearch. En la versión actual (7.x), hay diversos procesadores de datos que pueden ser utilizados en la pipeline para formatear el log. El más útil en este caso concreto es el procesador de json, pues al aplicar este procesador todo el log completo pasa a ser un json que elastic, si no hay nada raro, podrá mostrar de manera correcta. Estos procesadores también nos dan otras posibilidades como formatear un timestamp de manera correcta, cambiar nombres y valores de campos, buscar patrones en el log para modificarlos…
Finalmente y a modo de resumen, es muy importante saber que logs extraemos para tener controlada la información que vamos a inyectar en el elastic. Así podremos detectar problemas que nos puedan surgir durante todo el proceso. Por otra parte, hay que aprovechar el amplio abanico de posibilidades que nos dan los procesadores en la configuración de pipelines, ya que nos pueden ayudar mucho en la correcta ingesta de datos en elastic y posterior visualización de los logs.
Autor: Oscar Palomo