Los logs son la línea que crece sin que nadie lo decida

El volumen de registro sube con el tráfico, con cada servicio nuevo y con cada sesión de depuración que alguien olvidó apagar. La estructura decide si sirven, y seis reglas deciden si son pagables.

Nadie aprueba un presupuesto de registro. Un servicio sale a producción con el registro de depuración encendido porque así estaba en desarrollo. Una funcionalidad nueva añade una línea por iteración dentro de un bucle. Alguien enciende el registro detallado para perseguir un incidente, el incidente se cierra y el ajuste no. Tres años de eso, y el registro es una de las tres líneas mayores de la factura en una plataforma que nadie considera intensiva en datos.

Lo frustrante es que el volumen y la utilidad son casi independientes. Los entornos con las facturas de registro más grandes suelen ser aquellos en los que un ingeniero todavía no puede responder a "qué le pasó a esta petición concreta" sin buscar con expresiones regulares.

Estructurado significa campos, no una frase

Una línea como "fallo al procesar el pedido 8814 del usuario 22 tras 3 reintentos" no se puede consultar. Para contar reintentos por servicio necesitas una expresión regular, y la expresión regular se rompe el día que alguien reformula el mensaje.

El mismo evento en campos estructurados es un registro que puedes agregar, filtrar y usar para alertar. Emite JSON, o el formato estructurado nativo de tu plataforma, con un nombre de evento estable y las partes variables como campos tipados: identificador de pedido, de usuario, número de reintentos, duración, desenlace. El texto del mensaje pasa a ser una constante, que es exactamente lo que permite agruparlo.

Dos campos hacen la mayor parte del trabajo. El identificador de traza en todas las líneas ata el log a la petición y al tramo, que es el traspaso que hace que investigar un incidente lleve minutos; es el mismo enlace que se describe en trazas con las que depuras de verdad. Y un nombre de evento estable te deja contar ocurrencias sin coincidencia de patrones.

Niveles usados como se diseñaron

Casi todos los entornos usan dos niveles en la práctica, encendido y apagado, y lo pagan.

  • Error significa que una persona tiene que enterarse, en algún momento. Si emites un error por una condición que gestionas y reintentas con éxito, no es un error.
  • Aviso significa algo inesperado que el sistema absorbió. Es el nivel del que más se abusa.
  • Información significa un evento relevante para el negocio: un pedido realizado, un usuario creado, un trabajo terminado. Uno o dos por petición, no veinte.
  • Depuración está apagado en producción, y se puede encender para un solo servicio, o mejor para un solo inquilino o una sola petición, sin volver a desplegar. Los niveles de registro dinámicos merecen construirse; eliminan el incentivo de dejar la depuración encendida para siempre.

La prueba para una línea de información es si la querrías en un registro de lo que hizo el sistema. La entrada y la salida de una función no pasan esa prueba.

Muestrea lo repetitivo, conserva todos los errores

El instinto de que filtrar pierde información es correcto en general y falso para la forma concreta que tienen los datos de registro. Diez mil líneas idénticas de comprobación de salud correcta llevan la misma información que diez de ellas más un recuento.

Así que muestrea por desenlace. Conserva el cien por cien de los errores y los avisos, siempre. Muestrea con agresividad los eventos correctos, frecuentes y de poca variación, y anota la tasa de muestreo en la línea para poder corregir tus recuentos. Descarta por completo las comprobaciones de salud y de disponibilidad en el colector, junto con el registro de acceso del propio balanceador para esas rutas.

Haz el filtrado en el pipeline de recogida y no en el código de la aplicación. Así un despliegue ruidoso se contiene en minutos sin esperar a un cambio de código, la misma palanca que hace manejable la factura de Azure Monitor.

Lo que jamás puede estar en un log

Esto es un control de cumplimiento, no una preferencia de estilo. Los logs se copian a más sitios que cualquier otro dato que guardes, se conservan bajo reglas distintas y los lee más gente.

Nunca registres: contraseñas, tokens, claves de API, cookies de sesión, cabeceras de autorización, números completos de tarjeta de pago ni datos personales más allá de un identificador que puedas resolver en otro sitio. Los cuerpos completos de petición y respuesta son la vía habitual por la que llegan todos a la vez.

Construye la redacción dentro de la librería de registro para que sea el valor por defecto y no una disciplina. Usa una lista de campos permitidos en vez de una de prohibidos, porque una lista de prohibidos falla la primera vez que alguien añade un campo. Y escanea periódicamente una muestra de los logs de producción buscando patrones de secretos; las herramientas de escaneo de secretos funcionan también sobre archivos de log.

Un token filtrado en un log es un evento de rotación y, si hay datos personales de por medio, potencialmente uno notificable bajo el RGPD.

Retención por clase, no un número para todo

Una única retención para toda el área de trabajo significa aplicar el requisito más estricto a cada byte. Es la configuración más cara posible.

Divide por clase:

  • Registros de auditoría y de seguridad, donde un marco de cumplimiento fija el periodo. A menudo un año o más, y el nivel de archivo es el sitio correcto para casi todo.
  • Registros de aplicación para depuración operativa. De siete a treinta días en modo interactivo cubren casi cualquier investigación real.
  • Registros de acceso y de infraestructura. Retención interactiva corta, retención barata más larga si alguien la pide.
  • Salida de depuración. Días, no semanas.

Y después usa los niveles. Todas las plataformas ofrecen ya una clase más barata con funciones de consulta limitadas para datos de mucho volumen y poca lectura, y un archivo mucho más barato todavía con una recuperación más lenta. Verifica que ninguna alerta depende de una tabla antes de moverla a un nivel más barato, porque perder las alertas es la forma en que este cambio sale mal.

Lo que se olvida

  • Las trazas de pila multilínea multiplican. Una excepción puede ser sesenta líneas y sesenta unidades de facturación salvo que el colector las una en un solo evento.
  • Una línea de log cuesta más que sus bytes. Serializar, enviar e indexar consumen CPU y red en el nodo que además está sirviendo tráfico.
  • Los logs dentro de un bucle escalan con el tráfico. Una línea por elemento de un lote está bien con cien elementos y es ruinosa con un millón.
  • La recogida duplicada es habitual. Un agente sidecar, un agente de nodo y la recogida propia de la plataforma enviando el mismo fichero es una factura pagada tres veces. Audita qué está recogiendo de verdad.
  • Las métricas son más baratas que los logs para contar. Si lo único que haces con una línea es agregarla, debería haber sido un contador.

Qué hacer esta semana

Saca las diez fuentes de registro con más volumen de los últimos treinta días y averigua, para cada una, cuándo la consultó alguien por última vez. La diferencia entre lo que entra y lo que alguien lee es donde está el dinero, y en casi todos los entornos la fuente individual más grande es algo que ningún panel ni ninguna alerta ha tocado jamás. Arrancamos la línea de observabilidad de un proyecto cloud con exactamente esa comparación.

ConsultorIA

¿Quieres esto en tu nube?

El diagnóstico de diez días en solo lectura es gratuito, y con Skyline puedes ver tu entorno en un mapa antes de escribirnos.

Artículos relacionados

Módulos que la gente reutiliza en vez de copiar

Los dos fracasos son un módulo que envuelve un recurso y no aporta nada, y un módulo que lo hace todo y que nadie se atreve a cambiar. Una interfaz mínima, valores por defecto seguros y un versionado honesto son lo que los separa.