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.
