Hacer más con menos? no sin mejores registros y mejores herramientas

Desde que empecé en la tecnología en 1992 (hace más de tres décadas!), he encontrado innumerables escenarios en los que me esperaba “hacer más con menos”.

Una experiencia se destaca de mi tiempo como arquitecto backend en un proyecto de modernización de la nube.minimize or eliminate service-level logging—logging que dependíamos en gran medida para el análisis de los errores y los incidentes.La decisión fue impulsada por el alto coste de la ingestión de registros en nuestra plataforma de observabilidad.

Esto funcionó - hasta que no lo hizo.

¡Realmente necesitábamos esos cuadros!

Inevitablemente, surgió un problema inesperado, y necesitábamos esos registros faltantes. Ellos resultaron ser la única manera de identificar la causa raíz. Sin ellos, horas pasaron sin una solución, la incertidumbre creció, y la ansiedad siguió a todo el equipo.

// Sample (but not the real) log line removed during our cost-cutting
{
  "timestamp": "2025-03-21T14:05:03Z",
  "service": "preference-engine",
  "level": "ERROR",
  "message": "Worker queue overflow: unable to dispatch to worker pool",
  "requestId": "abc123",
  "userId": "admin_42"
}

Si lo hubiéramos mantenido, un simple registro de error estructurado (como el anterior) podría haber sido fácilmente filtrado en una plataforma de registro con una simple consulta de registro (como el siguiente) y nos habría permitido entender, diagnosticar y corregir el problema.

_sourceCategory=prod/preference-engine "Worker queue overflow"
| count by userId, requestId

Cuando se le dice que reduzca drásticamente nuestra recolección de madera, el proyecto entero se encuentra en un estado vulnerable.

Lean no significa tener hambre de recursos

Para ser claro, la mentalidad de “hacer más con menos” no es inherentemente mala.Muchas startups prosperan centrándose en las prioridades clave y aprovechando software ligero y eficiente.El diseño minimalista puede conducir a una mejor calidad, siempre que las herramientas clave permanezcan en su lugar.

Pero este no era el tipo "bueno" de lean. Y nuestro plazo para pasar a la nube estaba fijado. Estábamos luchando contra una fecha de depreciación del navegador. Esto significaba reescribir servicios a un diseño nativo de la nube, coordinar con los equipos de clientes y entregar bajo presión. Sin tiempo para una cobertura completa de pruebas o integraciones de observación profunda,we relied on logs to resolve our issuesy ayudar a determinar la causa raíz de los escenarios inesperados. que estaba bien al principio, simplemente insertamos el registro necesario mientras trabajamos en cada método.

Pero cuando se cortó el registro, el equipo fue expuesto.Nuestra red de seguridad primaria había desaparecido.

Causa raíz sin red

Las pruebas internas fueron buenas.A medida que se acercaba la producción, nos sentimos confiados en nuestra nueva arquitectura basada en la nube.Habíamos resuelto problemas conocidos en las pruebas y cumplimos con nuestro plazo.

Pero pronto nos dimos cuenta de que nuestra confianza estaba equivocada y que carecía de cobertura de pruebas.

Una vez que estábamos en producción y los clientes reales estaban utilizando la plataforma, aparecieron esos casos de borde inesperados.Y por supuesto, sin registros detallados o observación suficiente, no teníamos manera de investigar el problema.La telemetría limitada disponible simplemente no era suficiente para determinar qué había ido mal.

Si tuviéramos registros tanto para las pruebas de backend como para los clientes de producción en el frontend, podríamos haber sabido lo que estaba sucediendo y alertado al equipo (y al usuario).

_sourceCategory=prod/preference-engine OR prod/frontend error
| join ( _sourceCategory=prod/tester-feedback “queue error” )
  on requestId
| fields requestId, _sourceCategory, message

Pero sin los registros, reproducir los incidentes localmente era casi imposible.Había demasiada variabilidad en los casos de uso en el mundo real.Intentamos reactivar el logging parcial, pero esto sólo llevó a los costes de ingestión aumentados a los que se nos pidió que redujamos, sin proporcionar información actuable.

En algunos casos, no podíamos identificar la causa raíz en absoluto. Esa es una posición difícil de estar en: saber que hay un problema que afecta a los usuarios y no ser capaz de explicarlo.

MTTR versus calidad de señal

Pero otro problema fue que en nuestras retrospectivas de incidentes, significa tiempo para la recuperación (MTTRPero encontramos que MTTR era más a menudo un síntoma, no una causa raíz.

Los índices de referencia de la industria suelen mostrar que los equipos de élite alcanzaron el MTTR en menos de una hora.high-fidelity signalsLas señales de baja fidelidad, como los errores genéricos 500 o la alerta retardada de las métricas agregadas, no ayudan realmente.

En contraste, las señales contextuales detalladas, como los registros estructurados con userId, requestId y un rastro de servicio, se cortan directamente a la causa raíz.

Si sus registros no responden a estas preguntas, su MTTR no se trata de la velocidad del equipo, sino de la claridad de la señal.

Cómo el modelo de Sumo Logic podría haber salvado el día

Entonces, ¿qué podría haber sido diferente —y mejor— durante mi proyecto de modernización de la nube?

En primer lugar, realmente me gustaría que tuviera una mejor analítica de log y monitorización de rendimiento de aplicaciones (APM).Y junto con esa APM, gestión de log, monitores de servicio, alertas y métricas definidas estrechamente alineadas con el éxito o fracaso funcional.

Y quiero que mis registros vuelvan! en mi publicación anterior, "DevSecOps: Es hora de pagar por su demanda, no por la ingestión,“Hemos explorado cómoSumo Lógicainterrumpió el espacio de observación ofreciendo un modelo de análisis pay-per.Los registros se pueden ingerir continuamente, pero solo pagas cuando necesitas consultarlos o analizarlos.

¿Eres un equipo sin cobertura de pruebas de unidad completa? ¿Sufriendo de una falta de alertas en tiempo real o de métricas granulares? ¿En un presupuesto apertado? ¿Sufriendo de la falta de registros?

Con la ingesta completa de cero costos, los equipos pueden registrar tanto como necesiten sin preocupaciones.Y cuando ese incidente finalmente ocurra (y lo hará), el análisis puede ser desencadenado a petición, a un coste justificable directamente vinculado al impacto del cliente o la continuidad del negocio.

Este enfoque restaura el control y disminuye la ansiedad porque los equipos están capacitados para investigar minuciosamente cuando más importa.

Pero espere: también necesita triado asistido por máquina para aclarar sus consultas

La observabilidad moderna no se trata sólo de tener todos esos hermosos datos de registro, sino también de saber dónde mirar en esos datos.high-fidelity signals.

Cuando tienes una ingesta ilimitada, tienes una tonelada de datos.Y cuando empiezas a buscar información, necesitas un lugar para empezar.machine-assisted triage toolsque automáticamente agrupa el comportamiento anómalo, detecta outliers y superficialmente señales correlacionadas entre los servicios antes de escribir una única consulta.

Detrás de las escenas, Sumo Logic utilizó algoritmos estadísticos y aprendizaje automático para:

• Cluster logs por similitud (aunque expresado de manera diferente entre los nodos).
• Detectar desviaciones en métricas y registros (por ejemplo, picos de error por servicio, región o cohorte de usuarios).
• Enriquecer las anomalías con metadatos (por ejemplo, etiquetas de AWS, Kubernetes pod info, marcadores de implementación).
• Los clústeres de procesamiento de lenguaje natural registran por similitud semántica, no sólo por la combinación de cuerdas.

Esto es especialmente útil en el entorno de alto volumen de ingesta ilimitada. En lugar de navegar a través de decenas de miles de líneas de registro, se obtienen “signaturas de registro” – patrones condensados que representan grupos de eventos relacionados.

Ejemplo de flujo de trabajo

_sourceCategory=prod/* error
| logreduce

Este comando único agrupa los datos de registro ruidosos en buckets actuables como:

Error: Worker queue overflow
Error: Auth token expired for user *
Error: Timeout in service *

Una vez agrupados, los equipos pueden pivotar a un contexto más profundo:

| where message matches "Auth token expired*"
| count by userId, region

El resultado? menos búsquedas ciegas. vías de decisión más rápidas. menos ansiedad durante un incidente.

Conclusión

La filosofía de “hacer más con menos” no tiene que poner a los equipos de ingeniería en una desventaja, pero debe ir acompañada de las herramientas adecuadas. Sin ellas, incluso los equipos más capaces pueden sentir que están navegando sin propósito durante un incidente, lo que conduce a la frustración y el estrés.

Mis lectores pueden recordar mi declaración de misión personal, que creo que puede aplicarse a cualquier profesional de TI:

“Concentra tu tiempo en ofrecer características/funcionalidades que amplíen el valor de tu propiedad intelectual; aprovecha los marcos, productos y servicios para todo lo demás.” – J. Vester

“Concentra tu tiempo en ofrecer características/funcionalidades que amplíen el valor de tu propiedad intelectual; aprovecha los marcos, productos y servicios para todo lo demás.” – J. Vester

En este artículo, examinamos cómo un modelo de ingestión de cero costes se alinea con esta misión. Ayuda a los equipos a identificar rápidamente las causas radicales, reducir los tiempos de inactividad y reducir los niveles de estrés, todo sin romper el presupuesto.

¡Que tengas un gran día!