Buenas prácticas con logs

La gestión de logs ha experimentado una transformación notable gracias a las buenas prácticas con logs. Las organizaciones ya no se ven en la necesidad de sumergirse en montañas de registros sin procesar de aplicaciones e infraestructura cada vez que surge un problema.

Los logs impulsan la observabilidad y, bien estructurados, se han convertido en un recurso fundamental que permite anticiparse a posibles problemas y aprovechar posibles oportunidades.

Sin embargo, aprovechar los logs para obtener una observabilidad eficaz requiere atención y cuidado, como modificar las prácticas de registro para asegurar que los logs refuercen la observabilidad de todo el stack. Vamos a ver algunas de las buenas prácticas de registro de logs para potenciar nuestra organización.

Índice:

• Logging tradicional y observabilidad de todo el stack
• Buenas prácticas con logs para una observabilidad integral del stack
  • Incluir la información correcta en los logs
  • Anticipar escenarios frecuentes
  • Incluir mensajes útiles en los logs
  • Mantener los logs sencillos y concisos
  • No olvidar la fecha y hora
  • Usar un formato de logs analizable
• Un análisis a fondo de los formatos de logs
  • Categorizar y agrupar logs
  • Cardinalidad mediante labels
  • Utilizar herramientas y estructuras de logging
  • Hacer referencia a los valores grandes, no incluirlos
  • Compartir vistas, consultas y alertas útiles
• ¿Qué no incluir en los logs?
• Conclusión de las buenas prácticas con logs
• Referencias

Logging tradicional y observabilidad de todo el stack

En el pasado, la actividad de logging se llevaba a cabo en silos de datos separados, lo que dificultaba obtener una visión completa de lo que sucedía en las aplicaciones e infraestructura. Dependíamos principalmente del monitoreo del rendimiento de aplicaciones (APM) y de la infraestructura para obtener información sobre el estado de nuestro sistema. Sin embargo, estas herramientas no proporcionaban todos los detalles necesarios para comprender por completo el funcionamiento interno de nuestras aplicaciones y dispositivos de infraestructura.

Este enfoque fragmentado presentaba varios desafíos. Las herramientas de monitoreo independientes y aisladas a menudo se centraban en aspectos específicos de nuestras aplicaciones, lo que dificultaba obtener una visión completa del panorama. Esto generaba dificultades para los equipos en términos de acelerar el tiempo de comercialización, comprender el comportamiento del cliente y reducir el tiempo de respuesta a los incidentes, lo que impactaba directamente en el MTTR (Mean Time to Resolution).

Una observabilidad panorámica ofrece una solución integral a estos desafíos. Proporciona una visión completa de todos los aspectos del stack tecnológico que podrían afectar la experiencia del cliente. Esta vista integral incluye métricas, eventos, logs y trazas, permitiendo a los equipos ubicar y corregir los incidentes de manera más eficiente.

Buenas prácticas con logs para una observabilidad integral del stack

Generar logs de todo el stack puede resultar abrumador. Los desarrolladores e ingenieros suelen enfrentarse a preguntas sobre qué incluir en los logs, cuánto detalle agregar y si el exceso de datos impactará negativamente en los costos. Con buenas prácticas para los registros se pueden evitar problemas a la hora de centralizar la observabilidad.

Incluir la información correcta en los logs

Los logs se generan mediante la escritura de texto en una salida estándar o un archivo. Es esencial seleccionar cuidadosamente qué información incluir en ellos. Los logs deben contener todos los metadatos necesarios para ayudar a identificar eventos y causas raíz durante investigaciones posteriores. Estos metadatos pueden abarcar mensajes de error, trazas de stack, valores métricos y eventos relacionados.

Todo lo que se incluya en los logs debe tener un propósito claro y proporcionar información valiosa para el equipo. La información en los datos de los logs debe:

• Ser útil de inmediato para localizar el contexto.
• Proporcionar los detalles necesarios para comprender las causas subyacentes y poder tomar decisiones.

Anticipar escenarios frecuentes

Los logs no solo deben utilizarse para responder a incidentes, sino que también pueden ser valiosos en otras áreas del negocio, como la creación de perfiles de rendimiento o la recopilación de datos estadísticos. Al anticipar escenarios comunes, se puede garantizar que los logs aporten un valor directo a la organización.

Por ejemplo, los logs relacionados con la interacción del usuario pueden ofrecer información crucial sobre la experiencia del cliente, mientras que los logs del sistema pueden monitorear problemas o fallos de hardware. Además, los logs que detallan el comportamiento de la aplicación pueden iluminar aspectos relacionados con el rendimiento y posibles problemas, como las fugas de memoria.

Incluir mensajes útiles en los logs

Los mensajes en los logs son valiosos solo si ofrecen la información y el contexto necesarios. Cuando los detalles son suficientes y los logs son comprensibles, los equipos pueden utilizarlos con eficacia. Si bien la infraestructura de terceros suele capturar los detalles granulares necesarios, para las aplicaciones internas, los equipos deben capturar detalles en los logs que permitan diagnosticar y determinar por qué ocurrió un error o evento.

Los mensajes de error deben proporcionar información sobre lo que está sucediendo, preferiblemente con detalles específicos, como la línea de código relevante. Los códigos de error o estados también deben ir acompañados de una breve descripción para facilitar la resolución de problemas.

Mantener los logs sencillos y concisos

Es importante encontrar un equilibrio entre la cantidad de información incluida en los logs y su concisión. Los datos innecesarios y excesivos pueden aumentar el tamaño del almacenamiento de los logs y los costos asociados, así como ralentizar las búsquedas y distraer del problema principal.

Los equipos deben mantener los logs concisos para capturar solo la información más crítica. Deben explicar por qué ocurrió un error y, al mismo tiempo, evitar excesos. Deben proporcionar información sobre la causa raíz sin incluir detalles irrelevantes del entorno.

No olvidar la fecha y hora

Incluir un timestamp en los logs es fundamental para contextualizar los eventos en el tiempo. Aunque pueda parecer obvio, algunos desarrolladores e ingenieros podrían pasar por alto este detalle, especialmente si están acostumbrados a sistemas que automáticamente registran la fecha y la hora en una base de datos.

Es recomendable seleccionar el nivel de granularidad apropiado para los logs. Las tareas frecuentes pueden requerir timestamps que incluyan hasta los milisegundos, mientras que para las tareas menos frecuentes, minutos o incluso solo el día pueden ser suficientes.

Además, es esencial que todos los sistemas estén sincronizados en el tiempo para permitir que una plataforma de observabilidad correlacione los eventos de los registros con otros datos de telemetría.

Ejemplos:

•  Formato completo con milisegundos:
  • 2024-05-08 12:30:45.678
  • 2023-11-15 23:45:59.123
• Formato sin milisegundos:
  • 2022-09-30 08:15:30
  • 2024-03-17 18:20:00
• Formato con zona horaria:
  • 2024-07-20 10:00:00.456 UTC
  • 2023-12-10 15:30:20.789 EST

Estos ejemplos muestran diferentes formatos de timestamps que pueden utilizarse en los logs para proporcionar contexto temporal a los eventos registrados.

Usar un formato de logs analizable

Es crucial que los registros sean analizables para extraer información significativa. Los equipos deben utilizar un formato de logs que los desarrolladores e ingenieros puedan procesar fácilmente y mantener una estructura uniforme para facilitar su recopilación y agregación.

Un ejemplo de un formato de logs no analizable es el registro de acceso predeterminado de NGINX, que consiste en texto sin estructura. Aunque es útil para realizar búsquedas, carece de la estructura necesaria para responder la mayoría de las preguntas.

Aquí tienes un ejemplo de una línea típica de registro de acceso de NGINX:

126.10.51.30 - - [2/May/2024:11:03:23 +0000] "GET /downloads/product_1 HTTP/1.1" 304 0 "-" "Debian APT-HTTP/1.3 (0.8.16~exp12ubuntu10.21)"

Después de analizarlo, el registro se organiza en atributos, como código de respuesta y URL de solicitud. Aquí tienes un ejemplo de la misma información de registro en un formato analizable:

{
"remote_addr":"95.10.51.7",
"time":"1588412603",
"method":"GET",
"path":"/downloads/product_1",
"version":"HTTP/1.1",
"response":"304",
"bytesSent": 0,
"user_agent": "Debian APT-HTTP/1.3 (0.8.16~exp12ubuntu10.21)"
}

Estandarizar un formato de registros que se pueda utilizar en todas las aplicaciones facilita la incorporación de datos en la plataforma de observabilidad, incluso cuando diferentes equipos desean tener visibilidad de distintos atributos.

Un análisis a fondo de los formatos de logs

Cuando se trata de estructurar el texto de los registros, generalmente se utilizan tres categorías de formatos que influyen en su usabilidad una vez que los datos son recopilados por una herramienta de agregación de logs. Estas categorías son:

• Estructurado: Uno de los formatos estructurados más populares, altamente flexible y liviano es JSON. Otros ejemplos de datos de logs estructurados comunes son CSV (valores separados por coma) y TSV (valores separados por tabulador). Las buenas prácticas con logs es utilizar siempre este formato.
• Común: Un formato común no es estructurado pero es ampliamente conocido, definido e invariable. Un ejemplo de esto es el formato que emplea Apache para logs de acceso. La ventaja de un formato común es que muchas herramientas pueden analizar los datos sin necesidad de configuración adicional.
• Personalizado: Si una aplicación no utiliza un formato estructurado o común, escribe los logs empleando un formato personalizado. Sin embargo, esto puede requerir análisis adicional para reconocer el inicio y el fin de cada línea de registro individual durante el reenvío de logs.

Categorizar y agrupar logs

Especificar un modelo de datos para los logs permite búsquedas más efectivas. Los equipos deben definir e incluir atributos siempre que sea posible para categorizar y agrupar los logs adecuadamente.

Las normas de OpenTelemetry para logs, creadas por una coalición de líderes de la industria, abarcan muchos elementos, como convenciones de nombres y definiciones de valores de campos. Aunque no todas las estructuras admiten nativamente logs formateados según estas normas, pueden servir de guía.

Algunos atributos comunes que pueden ser útiles en un modelo de datos de logs son:

• Recursos (Resources): Definen cuándo y de dónde vinieron los logs. Por ejemplo:
  • Fecha y hora
  • Nombre de host o identificador de la máquina
  • Nombre de la aplicación o el servicio
• Logs en contexto (Context logs): Estos registros no solo capturan eventos, sino que también agregan detalles adicionales que proporcionan un panorama completo de lo que está sucediendo en el sistema en un momento dado.
• Niveles de logs (Log levels): Describen la importancia relativa de un evento y la cantidad de información proporcionada por el framework de logging.
  • Fatal: Son críticos y pueden provocar un bloqueo o un mal funcionamiento general de la aplicación. Se colocan en las partes más críticas de la aplicación y requieren una acción inmediata para resolverlos.
  • Error: Se utiliza para errores comunes que afectan el funcionamiento de la aplicación o una característica específica. Estos mensajes ayudan a identificar fallos en la aplicación que requieren atención.
  • Warning: Indica que algo no está funcionando como se espera, pero no llega a ser un error. Puede ser útil para identificar problemas potenciales antes de que se conviertan en errores.
  • Info: Proporciona información básica sobre el funcionamiento de la aplicación.
  • Debug: Utilizado para mensajes detallados destinados a la depuración y análisis de la aplicación. Estos mensajes suelen contener información sobre variables, argumentos de funciones y pasos relevantes del proceso.
  • Verbose o trace: Este nivel es similar al «debug» pero aún más detallado.
  • WTF: Este término (abreviatura de «What The Fuck») se utiliza para mensajes de error relacionados con situaciones inesperadas o inusuales que no deberían ocurrir.

Cardinalidad mediante labels

Las etiquetas (labels) son metadatos clave para categorizar y organizar registros de logs. En un entorno de Kubernetes, por ejemplo, podemos utilizar etiquetas para representar la cardinalidad de pods en un clúster:

• datacenter: Indica el centro de datos donde se encuentra el clúster, como `aws_eu-west-1`, `local`, `gcloud_eu-west1`.
• tenant: Identifica al cliente al que pertenece el clúster, como `cliente1` o `cliente2`.
• application: Representa el conjunto de servicios relacionados.
• service: Nombre del servicio específico dentro de la aplicación.
• version: La versión del servicio o la aplicación.
• env: El entorno, más allá de los namespaces, como `desarrollo`, `pruebas` o `producción`.
• resource_type: Tipo de componente, como `frontend`, `backend`, `base de datos`, `caché`, `mensajería`, `microservicio`, `cola`, `balanceador de carga`, `middleware`, etc.

Estas etiquetas permiten una clasificación detallada de los pods en el clúster, lo que facilita la gestión, el análisis y el seguimiento de los registros de logs en un entorno complejo y dinámico como Kubernetes.

Utilizar herramientas y estructuras de logging

Al adoptar herramientas establecidas de logging como Fluentd, ELK Stack, Prometheus/Protail + Loki + Grafana, AWS CloudWatch Logs y Google Cloud Logging, los equipos evitan la complejidad de desarrollar soluciones personalizadas. Estas herramientas ofrecen funcionalidades clave, como la decoración de logs con metadatos relevantes.

Son ampliamente utilizadas en entornos cloud y Kubernetes, facilitando la recolección, almacenamiento y análisis de logs. Con lo cual, esto permite a los equipos centrarse en resolver problemas y optimizar el rendimiento sin preocuparse por la infraestructura de logging.

Últimamente, para leer logs directamente de los ficheros o a través del output de un comando, estoy utilizando una pequeña herramienta llamada humalog 🙂

Hacer referencia a los valores grandes, no incluirlos

En situaciones donde se necesite una cantidad significativa de datos en los logs para proporcionar un contexto exhaustivo, como un volcado de memoria o archivos grandes, es preferible almacenar esos datos por separado o cargarlos en un servidor designado.

Para evitarlo, en lugar de incluir estos datos directamente en los logs, se puede hacer referencia a su ubicación. Esto ayuda a mantener los logs livianos y facilita el acceso a los datos de manera más eficiente.

Compartir vistas, consultas y alertas útiles

Es fundamental que los equipos creen y compartan visualizaciones, consultas y alertas estándar para mejorar la visibilidad y la comunicación entre los equipos. Esto permite que los logs brinden una perspectiva más amplia del estado actual de la organización y facilita la detección temprana de problemas.

La colaboración en la creación y el intercambio de recursos de observabilidad contribuye significativamente a la observabilidad de todo el stack.

¿Qué no incluir en los logs?

Al registrar información en los logs, es fundamental evitar ciertos tipos de datos que podrían comprometer la seguridad y la privacidad, así como aquellos que no aportan valor significativo.

• Información confidencial: Incluye datos regulados como PII y números de tarjetas de crédito, sujetos a leyes como GDPR y HIPAA. Evitar la transmisión de PII fuera de la organización es crucial.
• Código fuente y datos de propiedad exclusiva: Evitar la inclusión de código fuente de aplicaciones y datos protegidos que revelen secretos comerciales o proyectos no anunciados.
• Información duplicada: Aunque agregar información adicional no suele ser problemático, la duplicación excesiva puede generar logs innecesarios y dificultar el análisis eficiente de los datos.

Evitar estos tipos de datos garantiza la seguridad, la eficiencia y la integridad de los logs.

Conclusión de las buenas prácticas con logs

Implementar estas mejores prácticas con logs convierte los registros en una herramienta poderosa para mejorar la observabilidad de todo el stack. Y esto permitirá tomar decisiones más rápidas y efectivas, liberando tiempo para la innovación y reduciendo el tiempo dedicado a la depuración de problemas.

Referencias

• European Commission. n.d. “EU data protection rules.”
• OpenTelemetry. n.d. “OpenTelemetry Logging Overview.”
• Open Web Application Security Project (OWASP). n.d. “OWASP Logging Guide.”
• U.S. Department of Health and Human Services (HHS). n.d. “Summary of the HIPAA Security Rule.” HHS.gov.