Sedert ek in tegnologie begin het in 1992 (meer as drie dekades gelede!), het ek ontelbare scenario's ontmoet waar ek verwag word om "meer met minder te doen." Een ervaring onderskei uit my tyd as 'n backend-argitek op 'n cloud-modernisasie-projek. Die besluit is gedryf deur die hoë koste van log ingeslag op ons waarnemingsplatform. minimize or eliminate service-level logging Dit het gewerk - totdat dit nie. Ons het regtig daardie rekords nodig gehad! Onvermydelik het 'n onverwagte probleem ontstaan, en ons het daardie ontbrekende logboeke nodig gehad. Hulle het blyk te wees die enigste manier om die worteloorsaak te identifiseer. // 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"
}
 As ons dit bewaar het, kon 'n eenvoudige gestruktureerde foutlog (soos die hierbo) maklik gefiltreer word in 'n logplattform met 'n eenvoudige logvraag (soos die hieronder) en ons toegelaat het om die probleem te verstaan, te diagnoseer en op te los. _sourceCategory=prod/preference-engine "Worker queue overflow"
| count by userId, requestId
 As ons gevra word om ons houtbeskerming drasties te verminder, het ons die hele projek in 'n kwesbare toestand geplaas. Lean hoef nie te beteken honger vir hulpbronne Om duidelik te wees, is die "doe meer met minder" gedagtes is nie inherent sleg nie. Baie start-ups groei deur te fokus op sleutelprioriteiteite en gebruik van ligte, doeltreffende sagteware. minimalistiese ontwerp kan lei tot beter gehalte, mits die sleutel gereedskap bly. Maar dit was nie die "goeie" soort lean nie. En ons deadline om na die wolk te beweeg, was vasgestel. Ons het teen 'n leser-afkortingsdatum hardloop. Dit beteken dat ons dienste na 'n wolk-natiewe ontwerp herskryf, saam met kliënte-teams koordineer en onder druk lewer. en help om die worteloorsaak van onverwagte scenario's te bepaal. Dit was OK in die begin, ons het net die nodige logging ingevoeg terwyl ons op elke metode werk. we relied on logs to resolve our issues Maar toe die logging teruggesny is, is die span blootgestel. ons primêre veiligheidsnet was weg. Root Cause sonder 'n net Interne toetse het goed gegaan.Toe produksie nader, het ons vertroue gevoel in ons nuwe wolk-gebaseerde argitektuur.Ons het bekende probleme in toets opgelos en aan ons deadline voldoen. Maar ons het gou besef dat ons vertroue verkeerd geplaas is en ons toetsdekking ontbreek. Sodra ons in produksie was en werklike kliënte die platform gebruik het, het daardie bedrieglike onverwagte rand gevalle verskyn. En natuurlik, sonder gedetailleerde logboeke of voldoende waarnembaarheid, het ons geen manier gehad om die probleem te ondersoek nie. As ons logboeke vir beide die backend toetse en produksie kliënte op die frontend gehad het, kon ons weet wat gebeur en die span (en die gebruiker) gewaarsku het. _sourceCategory=prod/preference-engine OR prod/frontend error
| join ( _sourceCategory=prod/tester-feedback “queue error” )
  on requestId
| fields requestId, _sourceCategory, message
 Maar sonder die logboeke was dit byna onmoontlik om die gebeurtenisse plaaslik te reproduseer. Daar was net te veel variabiliteit in werklike gebruik gevalle. Ons het probeer om gedeeltelike logboeke weer te aktiveer, maar dit het net gelei tot die verhoogde inname koste wat ons gevra is om te verminder, sonder om werkbare insigte te lewer. Dit is 'n moeilike posisie om in te wees: om te weet dat daar 'n probleem is wat gebruikers beïnvloed en dit nie kan verduidelik nie. MTTR versus signaalkwaliteit Nog 'n probleem was dat in ons incident retrospektiewe, beteken tyd tot herstel ( Ons het egter bevind dat MTTR die meeste keer 'n simptom was, nie 'n worteloorsaak nie. Die MTTR Industriële benchmarks toon gewoonlik elite spanne wat MTTR in minder as 'n uur bereik het.Maar wat ons besef het, was dat spoed nie net outomasie is nie - dit is Lae-truth-signale, soos algemene 500-foute of vertraagde waarskuwing van geaggregeerde metrikes, help nie regtig nie. high-fidelity signals In teenstelling, gedetailleerde, kontekstuele signale—soos gestruktureerde logs met userId, requestId, en 'n diens spoor—skort direk na die wortel oorsaak. As jou logboeke nie hierdie vrae beantwoord nie, gaan jou MTTR nie oor span spoed nie – dit gaan oor signaal helderheid. Hoe Sumo Logic se model die dag kon gered het So wat kon anders – en beter – gedurende my wolk modernisasie projek gegaan het? Eerstens, ek wens regtig dat ons beter log analytics en toepassing prestasie monitering (APM) gehad het. En saam met daardie APM, log bestuur, diensmoniteurs, waarschuwings, en gedefinieerde metrikes nauw aangepas met funksionele sukses of mislukking. En ek wil my logs terug! in my vorige publikasie, " “Ek het ondersoek hoe die waarnemingsruimte verstoor deur 'n pay-per-analysemodel aan te bied. logs kan voortdurend ingespoel word, maar jy betaal slegs wanneer jy dit nodig het om te vra of te analiseer. DevSecOps: It’s Time To Pay for Your Demand, Not Ingestion, Die logika van Is jy 'n span sonder 'n volledige eenheid toetsdekking? ly aan 'n gebrek aan real-time waarschuwings of granulêre metrikes? Op 'n beperkte begroting? vermy van gebrek aan logboeke? Met nul koste volle inname, kan teams so veel log as wat hulle nodig het sonder bekommernis. En wanneer daardie voorval uiteindelik plaasvind (en dit sal), kan analise op versoek, teen 'n regverdige koste direk gekoppel aan kliënte-impak of besigheidskontinuïteit, veroorsaak word. Hierdie benadering herstel beheer en verlaag angs, want teams is gemagtig om grondig te ondersoek wanneer dit die belangrikste is. Maar wag: Jy het ook masjien-geassisteerde triage nodig om jou vrae te verduidelik Moderne waarnemingsvermoë gaan nie net oor al daardie pragtige logdata nie – dit gaan ook oor om te weet waar om in daardie data te kyk. . high-fidelity signals Wanneer jy onbeperkte inname het, het jy 'n ton data. En wanneer jy begin soek na inligting, benodig jy 'n plek om te begin. die abnormale gedrag outliers, opspoor, en oppervlak korrelatiewe signale oor dienste, voordat jy 'n enkele query skryf. machine-assisted triage tools In die agtergrond het Sumo Logic statistiese algoritmes en masjienlering gebruik om: 
 
 
 
 
 Cluster logs deur soortgelykheid (selfs as dit verskillend in nodes uitgedruk word). Detekteer outliers in metrikes en logboeke (bv, foutspike per diens, streek of gebruikerskohorte). Verryk anomalieë met metagegevens (bv, AWS-tags, Kubernetes pod info, ontplooiingsmarkers). Natuurlike taalverwerking clusters logs deur semantiese ooreenkoms, nie net string ooreenkoms. Dit is veral nuttig in die hoë-volume omgewing van onbeperkte inname.In plaas daarvan om deur tienduisende loglynne te kyk, kry u "logtekeninge" - gekondenseerde patrone wat groepe verwante gebeure verteenwoordig. Voorbeeld van 'n werkstroom _sourceCategory=prod/* error
| logreduce
 Hierdie enkele bevel groepeer lawaaierige log data in aksieerbare buckets soos: Error: Worker queue overflow
Error: Auth token expired for user *
Error: Timeout in service *
 Sodra gekluster is, kan teams in dieper konteks draai: | where message matches "Auth token expired*"
| count by userId, region
 Die resultaat? Minder blinde soeke. vinniger beslissingspads. Minder angs tydens 'n voorval. Konklusie Die filosofie van "doe meer met minder" hoef ingenieursteams nie in 'n nadeel te stel nie. Maar dit moet gepaard gaan met die regte gereedskap. sonder hulle kan selfs die mees bekwame teams voel asof hulle doelloos navigeer tydens 'n voorval - wat tot frustrasie en stres lei. My lesers kan my persoonlike missieverklaring onthou, wat ek dink kan toepas op enige IT-professionele: 
 
 Fokus jou tyd op die lewering van funksies / funksionaliteite wat die waarde van jou intellektuele eiendom uitbrei. Fokus jou tyd op die lewering van funksies / funksionaliteite wat die waarde van jou intellektuele eiendom uitbrei. In hierdie artikel het ons gekyk na hoe 'n nul-kost-inname model in ooreenstemming is met hierdie missie. Dit help teams vinnig root oorsake te identifiseer, stoptyd te verminder en stresvlakke te verlaag - alles sonder om die begroting te breek. Het 'n werklik groot dag!

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

Hierdie oudio word in die oorspronklike taal van die storie vervaardig!

Te lank; Om te lees

Make resilience your competitive advantage

Doen meer met minder? nie sonder beter logs en beter gereedskap nie

About Author

KOMMENTAAR

HANG TAGS

HIERDIE ARTIKEL IS AANGEBIED IN

Related Stories

$30M Raised in 30 Minutes and the Controversies to Follow: The Story Behind Dexter’s GM.ai Project

Startups of The Year: Meet the Business Industry

Top Actionable Tips to Grow a Community: More Tips to Monetize

How to Vote in the HackerNoon 2021 Noonies Awards #Noonies2021

$30M Raised in 30 Minutes and the Controversies to Follow: The Story Behind Dexter’s GM.ai Project

Startups of The Year: Meet the Business Industry

Top Actionable Tips to Grow a Community: More Tips to Monetize

How to Vote in the HackerNoon 2021 Noonies Awards #Noonies2021

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps