La agregación de registros ya no es una mercancía, sino un componente crítico en plataformas basadas en contenedores

La gestión de registros no parece un tema muy fantástico. No es el tema que ves y dices: “¡Oh! ¡Increíble! Esto es con lo que he soñado toda mi vida”. No, soy consciente de que esto no es muy atractivo, pero eso no lo hace menos crítico que otras capacidades que tu arquitectura necesita tener.

Desde el principio de los tiempos, hemos usado archivos de registro como la única fuente de datos confiable cuando se trataba de solucionar problemas de tus aplicaciones o saber qué falló en tu implementación o cualquier otra acción relacionada con una computadora.

El procedimiento era fácil:

• Lanzar “algo”
• “Algo” falló.
• Revisar los registros
• Cambiar algo
• Repetir

Y lo hemos estado haciendo de esa manera durante mucho, mucho tiempo. Incluso con otros enfoques más robustos de manejo y gestión de errores como el Sistema de Auditoría, también volvemos a los registros cuando necesitamos obtener el detalle minucioso sobre el error. Buscar una traza de pila allí, más detalle sobre el error que se insertó en el Sistema de Auditoría o más datos que solo el código de error y la descripción que proporcionó una API REST.

Los sistemas comenzaron a crecer, la arquitectura se volvió más complicada, pero incluso con eso, terminamos con el mismo método una y otra vez. Estás al tanto de arquitecturas de agregación de registros como la pila ELK o soluciones comerciales como Splunk o incluso ofertas SaaS como Loggly, pero simplemente piensas que no son para ti.

Son caras de comprar o caras de configurar, y conoces muy bien tu ecosistema, y es más fácil simplemente entrar en una máquina y seguir el archivo de registro. Probablemente también tengas tu caja de herramientas de scripts para hacer esto tan rápido como cualquiera puede abrir Kibana e intentar buscar algo como el ID de instancia allí para ver el error de una transacción específica.

Ok, necesito decirte algo: Es hora de cambiar, y te voy a explicar por qué.

Las cosas están cambiando, y TI y todos los nuevos paradigmas se basan en algunos fundamentos comunes:

• Vas a tener más componentes que van a funcionar aislados con sus archivos de registro y datos.
• Las implementaciones serán más regulares en tu entorno de producción, y eso significa que las cosas van a estar mal más a menudo (de una manera controlada, pero más a menudo)
• Las tecnologías van a coexistir, por lo que los registros van a ser muy diferentes en términos de patrones y diseños, y necesitas estar preparado para eso.

Así que, discutamos estos tres argumentos que espero te hagan pensar de una manera diferente sobre las arquitecturas y enfoques de Gestión de Registros.

1.- Tu enfoque simplemente no escalable

Tu enfoque es excelente para sistemas tradicionales. ¿Cuántas máquinas gestionas? ¿30? ¿50? ¿100? Y puedes hacerlo bastante bien. Imagina ahora una plataforma basada en contenedores para una empresa típica. Creo que un número promedio podría ser alrededor de 1000 contenedores solo para propósitos comerciales, sin hablar de arquitectura o servicios básicos. ¿Eres capaz de estar listo para ir contenedor por contenedor para verificar 1000 flujos de registros para conocer el error?

Incluso si eso es posible, ¿vas a ser el cuello de botella para el crecimiento de tu empresa? ¿Cuántos registros de contenedores puedes seguir? ¿2000? Como decía al principio, eso simplemente no es escalable.

2.- Los registros no están allí para siempre

Y ahora, lees el primer tema y probablemente solo estás diciendo a la pantalla que estás usando para leer esto. ¡Vamos! Ya sé que los registros no están allí, se están rotando, se pierden, y así sucesivamente.

Sí, eso es cierto, esto es aún más importante en el enfoque nativo de la nube. Con plataformas basadas en contenedores, los registros son efímeros, y además, si seguimos el manifiesto de la aplicación de 12 factores, no hay archivo con el registro. Todas las trazas de registro deben imprimirse en la salida estándar, y eso es todo.

¿Y dónde se eliminan los registros? Cuando el contenedor falla… ¿y cuáles son los registros que más necesitas? Los que han fallado.

Así que, si no haces nada, las trazas de registro que más necesitas son las que vas a perder.

3.- Necesitas poder predecir cuándo las cosas van a fallar

Pero los registros no solo son válidos cuando algo sale mal, son adecuados para detectar cuándo algo va a estar mal, sino para predecir cuándo las cosas van a fallar. Y necesitas poder agregar esos datos para poder generar información y conocimientos a partir de ellos. Para poder ejecutar modelos de ML para detectar si algo va como se espera o si algo diferente está sucediendo que podría llevar a algún problema antes de que ocurra.

Resumen

Espero que estos argumentos te hayan hecho pensar que incluso para tu empresa de pequeño tamaño o incluso para tu sistema, necesitas poder configurar una técnica de Agregación de Registros ahora y no esperar a otro momento cuando probablemente sea demasiado tarde.

Log Aggregation are not more a commodity but a critical component in container-based platforms

Log Management doesn’t seem like a very fantastic topic. It is not the topic that you see and says: “Oh! Amazing! This is what I was dreaming about my whole life”. No, I’m aware that this is not to fancy, but that doesn’t make it less critical than other capabilities that you’re architecture needs to have.

Since the start of time, we’ve been used log files as the single trustable data source when it was related to troubleshoot your applications or know what was failed in your deployment or any other actions regarding a computer.

The procedure was easy:

• Launch “something”
• “something” failed.
• Check the logs
• Change something
• Repeat

And we’ve been doing it that way for a long, long time. Even with other more robust error handling and management approaches like Audit System, we also go back to logs when we need to get the fine-grained detail about the error. Look for a stack trace there, more detail about the error that was inserted into the Audit System or more data than just the error code and description thas was provided by a REST API.

Systems starting to grow, architecture became more complicated, but even with that, we end with the same method over and over. You’re aware of log aggregation architectures like the ELK stack or commercial solutions like Splunk or even SaaS offerings like Loggly, but you just think they’re not just for you.

They’re expensive to buy or expensive to set, and you know very well your ecosystem, and it’s easier to just jump into a machine and tail the log file. Probably you also have your toolbox of scripts to do this as quickly as anyone can open Kibana and try to search for something instance ID there to see the error for a specific transaction.

Ok, I need to tell you something: It’s time to change, and I’m going to explain to you why.

Things are changing, and IT and all the new paradigms are based on some common grounds:

• You’re going to have more components that are going to run isolated with its log files and data.
• Deployments will be more regular in your production environment, and that means that things are going to be wrong more usual (on a controlled way, but more usual)
• Technologies are going to coexist, so logs are going to be very different in terms of patterns and layouts, and you need to be ready for that.

So, let’s discuss these three arguments that I hope make you think in a different way about Log Management architectures and approaches.

1.- Your approach just doesn’t scale

Your approach is excellent for traditional systems. How many machines do you manage? 30? 50? 100? And you’re able to do it quite fine. Imagine now a container-base platform for a typical enterprise. I think an average number could be around 1000 containers just for business purposes, not talking about architecture or basic services. Are you able to be ready to go container by container to check 1000 logs streams to know the error?

Even if that’s possible, are you going to be the bottleneck for the growth of your company? How many container logs do you can keep a trace on? 2000? As I was saying at the beginning, that just not scale.

2.- Logs are not there forever

And now, you read the first topic and probably are you just saying to the screen you’re using to read is. Come on! I already know that logs are not there, they’re getting rotated, they got lost, and so on.

Yeah, that’s true, this is even more important in cloud-native approach. With container-based platforms, logs are ephemeral, and also, if we follow the 12-factor app manifesto there is no file with the log. All log traces should be printed to the standard output, and that’s it.

And where the logs are deleted? When the container fails.. and which records are the ones that you need more? The ones that have been failed.

So, if you don’t do anything, the log traces that you need the most are the ones that you’re going to lose.

3.- You need to be able to predict when things are going to fail

But logs are not only valid when something goes wrong are adequate to detect when something is going to be wrong but to predict when things are going to fail. And you need to be able to aggregate that data to be able to generate information and insights from it. To be able to run ML models to detect if something is going as expected or something different is happening that could lead to some issue before it happens.

Summary

I hope these arguments have made you think that even for your small size company or even for your system, you need to be able to set up a Log Aggregation technique now and not wait for another moment when it will probably be too late.