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. A decisión foi impulsada polo alto custo de inxestión de rexistros na nosa plataforma de observación. minimize or eliminate service-level logging 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, e 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. we relied on logs to resolve our issues 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 ( Pero descubrimos que a MTTR era máis a miúdo un síntoma, non unha causa raíz. MTTR Os índices da industria adoitan mostrar que os equipos de elite alcanzaron o MTTR en menos dunha hora. Os sinais de baixa fidelidade, como erros xenéricos 500 ou alertas atrasados de métricas agregadas, non axudan realmente. high-fidelity signals 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, " ” I explored how  Os rexistros poden ser inxeridos continuamente, pero só pagas cando necesitas consultalos ou analizalos. DevSecOps: É hora de pagar a súa demanda, non a inxestión, Sumo lóxico 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. que automaticamente agrupa o comportamento anómalo, detecta outliers e superfície sinais correlacionados entre servizos antes de escribir unha única consulta. machine-assisted triage tools 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!

The code in this story is for educational purposes. The readers are solely responsible for whatever they build with it.

2022 - HackerNoon Contributor of the Year - Cloud Computing

2022 - HackerNoon Contributor of the Year - Design

2022 - HackerNoon Contributor of the Year - Heroku

2022 - HackerNoon Contributor of the Year - Javascript

2022 - HackerNoon Contributor of the Year - Salesforce

2022 - Hackernoons Tech Storyteller of the Year

I ♥ writing code. Find me on GitLab.

Nominated for 2022 - HackerNoon Contributor of the Year - Javascript

Nominated for 2022 - Hackernoons Tech Storyteller of the Year

Nominated for 2022 - HackerNoon Contributor of the Year - Cloud Computing

Nominated for 2022 - HackerNoon Contributor of the Year - Heroku

Nominated for 2022 - HackerNoon Contributor of the Year - Design

Nominated for 2022 - HackerNoon Contributor of the Year - Salesforce

Este audio está producido na lingua orixinal da historia!

Demasiado longo; Ler

Make resilience your competitive advantage

Facer máis con menos? non sen mellores rexistros e mellores ferramentas

About Author

COMENTARIOS

Etiquetas colgantes

ESTE ARTIGO FOI PRESENTADO EN

Related Stories

HackerNoon Decoded 2024: Celebrating Our Startups Community!

Coñece R Systems: HackerNoon empresa da semana

HackerNoon Decoded 2024: Celebrating Our Gaming Community!

R Systems BlogBook—Chapter 1: Round 2 is Now Open for Submissions🎉

HackerNoon Decoded 2024: Celebrating Our Startups Community!

Coñece R Systems: HackerNoon empresa da semana

HackerNoon Decoded 2024: Celebrating Our Gaming Community!

R Systems BlogBook—Chapter 1: Round 2 is Now Open for Submissions🎉

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps