Desde que empecei na tecnoloxía en 1992 (hai máis de tres décadas!), atopei innumerables escenarios onde se esperaba que "facese máis con menos".
Unha experiencia destaca do meu tempo como arquitecto de backend nun proxecto de modernización de nube.minimize or eliminate service-level loggingA decisión foi impulsada polo alto custo de inxestión de rexistros na nosa plataforma de observación.
Isto funcionou - ata que non funcionou.
Realmente necesitábamos eses libros!
Inevitablemente, xurdiu un problema inesperado, e necesitamos aqueles rexistros perdidos. Resultaron ser a única forma de identificar a causa raíz. Sen eles, horas pasaron sen unha solución, a incerteza creceu e a ansiedade seguiu ao equipo enteiro.
// 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"
}
Se a gardásemos, un simple rexistro de erros estruturado (como o anterior) podería ser facilmente filtrado nunha plataforma de rexistro cunha simple consulta de rexistro (como o seguinte) e permitirnos comprender, diagnosticar e solucionar o problema.
_sourceCategory=prod/preference-engine "Worker queue overflow"
| count by userId, requestId
Dixéronnos que reduciríamos drasticamente a nosa silvicultura e puxemos todo o proxecto nun estado vulnerable.
Lean non significa ter fame de recursos
Para ser claro, a mentalidade de "facer máis con menos" non é inherentemente mala. Moitas startups prosperan concentrándose en prioridades clave e aproveitando software lixeiro e eficiente.
Pero este non era o "bo" tipo de lean. E o noso prazo para pasar á nube foi fixado. Estabamos correndo contra unha data de depreciación do navegador. Isto significaba reescribir servizos a un deseño nativo da nube, coordinarse con equipos de clientes e entregar baixo presión. Sen tempo para cobertura completa de probas ou integracións de observación profunda,we relied on logs to resolve our issuese axudar a determinar a causa raíz para os escenarios inesperados. que estaba ben ao principio, só introducimos o rexistro necesario mentres traballamos en cada método.
Pero cando o rexistro foi cortado, o equipo foi exposto.A nosa rede de seguridade primaria desapareceu.
Raíz causa sen unha rede
As probas internas foron boas.Como se achegaba a produción, sentímonos confiados na nosa nova arquitectura baseada na nube.Resolvemos problemas coñecidos en probas e cumprimos o noso prazo.
Pero axiña nos decatamos de que a nosa confianza estaba equivocada e que faltaba a nosa cobertura de probas.
Unha vez que estabamos en produción e os clientes reais estaban a usar a plataforma, apareceron aqueles casos de borda inesperados.E, por suposto, sen rexistros detallados ou observación suficiente, non tiñamos forma de investigar o problema.
Se tivésemos rexistros tanto para as probas de backend como para os clientes de produción no frontend, poderíamos saber o que estaba a suceder e alertar ao equipo (e ao usuario).
_sourceCategory=prod/preference-engine OR prod/frontend error
| join ( _sourceCategory=prod/tester-feedback “queue error” )
on requestId
| fields requestId, _sourceCategory, message
Pero sen os rexistros, reproducir os incidentes localmente era case imposible.Había só demasiada variabilidade nos casos de uso do mundo real.Intentamos reactivar o rexistro parcial, pero isto só levou de volta ao aumento dos custos de inxestión que se nos pediu que cortásemos, sen ofrecer información viable.
Esa é unha posición difícil de estar: saber que hai un problema que afecta aos usuarios e ser incapaz de explicalo.
MTTR versus calidade de sinal
Outro problema era que nas nosas retrospectivas de incidentes, significa tempo para a recuperación (MTTRPero descubrimos que a MTTR era máis a miúdo un síntoma, non unha causa raíz.
Os índices da industria adoitan mostrar que os equipos de elite alcanzaron o MTTR en menos dunha hora.high-fidelity signalsOs sinais de baixa fidelidade, como erros xenéricos 500 ou alertas atrasados de métricas agregadas, non axudan realmente.
En contraste, os sinais contextuais detallados, como os rexistros estruturados con userId, requestId e un rastro de servizo, cortan directamente á causa raíz.
Se os seus rexistros non responden a estas preguntas, o seu MTTR non é sobre a velocidade do equipo - é sobre a claridade do sinal.
Como o modelo de Sumo Logic podería salvar o día
Entón, que podería ser diferente -e mellor - durante o meu proxecto de modernización de nube?
En primeiro lugar, realmente desexaría que tivésemos unha mellor análise de rexistro e monitorización de rendemento de aplicacións (APM). E xunto con esa APM, xestión de rexistro, monitores de servizo, alertas e métricas definidas estreitamente aliñadas co éxito ou fracaso funcional.
E quero os meus rexistros de volta! Na miña publicación anterior, "DevSecOps: É hora de pagar a súa demanda, non a inxestión,” I explored how Sumo lóxicoOs rexistros poden ser inxeridos continuamente, pero só pagas cando necesitas consultalos ou analizalos.
Es un equipo sen cobertura de probas de unidade completa? Sofre de falta de alertas en tempo real ou métricas granulares?
Coa inxestión completa de cero custos, os equipos poden rexistrar o que precisan sen preocupacións.E cando ese incidente finalmente ocorre (e vai ocorrer), a análise pode ser desencadeada a demanda, a un custo xustificado directamente ligado ao impacto do cliente ou á continuidade do negocio.
Este enfoque restablece o control e reduce a ansiedade porque os equipos están capacitados para investigar a fondo cando máis importa.
Pero espera: tamén necesitas triado asistido por máquina para aclarar as túas consultas
A observación moderna non se trata só de ter todos eses fermosos datos de rexistro, senón tamén de saber onde buscar eses datos.high-fidelity signals.
Cando ten inxestión ilimitada, ten unha tonelada de datos. E cando comeza a buscar información, precisa dun lugar para comezar.machine-assisted triage toolsque automaticamente agrupa o comportamento anómalo, detecta outliers e superfície sinais correlacionados entre servizos antes de escribir unha única consulta.
Detrás das escenas, Sumo Logic usou algoritmos estatísticos e aprendizaxe automática para:
- Cluster logs por semellanza (aínda que expresado de forma diferente entre os nodos).
- Detectar outliers en métricas e rexistros (por exemplo, picos de erro por servizo, rexión ou cohorte de usuarios).
- Enriquecer anomalías con metadatos (por exemplo, etiquetas de AWS, Kubernetes pod info, marcadores de implementación).
- Os clústeres de procesamento de linguaxe natural rexistran por semellanza semántica, non só por correspondencia de cadeas.
Isto é especialmente útil no ambiente de alto volume de inxestión ilimitada. en lugar de navegar a través de decenas de miles de liñas de rexistro, recibe "signaturas de rexistro" - patróns condensados que representan grupos de eventos relacionados.
Exemplo de fluxo de traballo
_sourceCategory=prod/* error
| logreduce
Este comando único agrupa datos de rexistro ruidosos en buckets accionables como:
Error: Worker queue overflow
Error: Auth token expired for user *
Error: Timeout in service *
Unha vez agrupados, os equipos poden pórse en contexto máis profundo:
| where message matches "Auth token expired*"
| count by userId, region
O resultado? menos buscas cegas. camiños de decisión máis rápidos. menos ansiedade durante un incidente.
Conclusión
A filosofía de "facer máis con menos" non ten que poñer en desvantaxe aos equipos de enxeñaría, pero debe ir acompañada das ferramentas axeitadas.
Os meus lectores poden lembrar a miña declaración de misión persoal, que creo que se pode aplicar a calquera profesional de TI:
“Concentra o teu tempo en ofrecer recursos/funcionalidades que amplíen o valor da túa propiedade intelectual.
“Concentra o teu tempo en ofrecer recursos/funcionalidades que amplíen o valor da túa propiedade intelectual.
Neste artigo, examinamos como un modelo de inxestión de cero custos se axusta a esta misión. Axuda aos equipos a identificar rapidamente as causas orixinais, reducir os tempos de inactividade e reducir os niveis de estrés, todo sen romper o orzamento.
Que teñades un gran día!
