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.minimize or eliminate service-level loggingDie besluit is gedryf deur die hoë koste van log ingeslag op ons waarnemingsplatform.
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.we relied on logs to resolve our issuesen 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.
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 (Die MTTROns het egter bevind dat MTTR die meeste keer 'n simptom was, nie 'n worteloorsaak nie.
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 ishigh-fidelity signalsLae-truth-signale, soos algemene 500-foute of vertraagde waarskuwing van geaggregeerde metrikes, help nie regtig nie.
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, "DevSecOps: It’s Time To Pay for Your Demand, Not Ingestion,“Ek het ondersoek hoeDie logika vandie 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.
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.machine-assisted triage toolsdie abnormale gedrag outliers, opspoor, en oppervlak korrelatiewe signale oor dienste, voordat jy 'n enkele query skryf.
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!
