130 lukemat

Tehdä enemmän vähemmällä? ei ilman parempia lokeja ja parempia työkaluja

kirjoittaja John Vester6m2025/06/27
Read on Terminal Reader

Liian pitkä; Lukea

Päiväkirjan kulumisen leikkaaminen tuntuu hyödylliseltä - kunnes häiriö tapahtuu ja yhtäkkiä tarvitset todella näitä signaaleja! Katso, miten nollakustannusten kulutus voi päästä eroon MTTR: n ahdistuksesta.
featured image - Tehdä enemmän vähemmällä? ei ilman parempia lokeja ja parempia työkaluja
John Vester HackerNoon profile picture
0-item

Koska aloitin tekniikan vuonna 1992 (yli kolme vuosikymmentä sitten!), Olen törmännyt lukemattomiin skenaarioihin, joissa minun odotettiin "tekevän enemmän vähemmällä."

Yksi kokemus erottuu aikani backend-arkkitehdina pilvipalveluiden nykyaikaistamishankkeessa.minimize or eliminate service-level loggingPäätös johtui lokitietojen syöttämisen korkeista kustannuksista havainnointialustallamme.

Tämä toimi – kunnes se ei toimi.

Me todella tarvitsimme näitä levyjä!

Väistämättä syntyi odottamaton ongelma, ja tarvitsimme niitä puuttuvia lokeja. He osoittautuivat ainoa tapa tunnistaa perimmäinen syy. Ilman niitä tunteja kulki ilman ratkaisua, epävarmuus kasvoi ja ahdistus seurasi koko tiimiä.


// 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"
}


Jos olisimme säilyttäneet sen, yksinkertainen jäsennelty virhepäiväkirja (kuten edellä) olisi voinut helposti suodattaa lokitietopalvelussa yksinkertaisella lokikirjeellä (kuten alla) ja antaa meille mahdollisuuden ymmärtää, diagnosoida ja korjata ongelma.


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

Kun pyydetään vähentämään metsästämistämme dramaattisesti, koko hanke joutuu haavoittuvaan tilaan.

Lean ei tarkoita resurssien nälkää

On selvää, että "tehdä enemmän vähemmällä" ajattelutapa ei ole luonnostaan huono. Monet startup-yritykset menestyvät keskittymällä keskeisiin painopisteisiin ja hyödyntämällä kevyitä, tehokkaita ohjelmistoja.

Mutta tämä ei ollut "hyvä" tyyppinen lean. Ja määräaika siirtyä pilveen oli kiinteä. Kilpailimme selaimen vähentämispäivämäärää vastaan. Tämä tarkoitti palvelujen kirjoittamista uudelleen pilvipohjaiseen muotoiluun, koordinointia asiakasryhmien kanssa ja toimitusta paineen alla.we relied on logs to resolve our issuesja auttaa määrittämään odottamattomien skenaarioiden perimmäisen syyn.Se oli aluksi OK, olemme vain lisänneet tarvittavat lokitukset työskennellessämme kussakin menetelmässä.

Mutta kun logging katkaistiin, joukkue oli alttiina. ensisijainen turvaverkko oli poissa.

Root Cause ilman verkkoa

Sisäinen testaus sujui hyvin.Kun tuotanto lähestyi, olimme varmoja uudesta pilvipohjaisesta arkkitehtuuristamme.Olemme ratkaisseet testissä tunnetut ongelmat ja täyttäneet määräajan.

Mutta huomasimme pian, että luottamuksemme oli väärässä paikassa ja testaus kattavuutemme puuttui.

Kun olimme tuotannossa ja todelliset asiakkaat käyttivät alustaa, nämä surulliset odottamattomat edge-tapaukset ilmestyivät. Ja tietenkin ilman yksityiskohtaisia lokeja tai riittävää havaittavuutta meillä ei ollut tapaa tutkia ongelmaa.

If we had logs for both the backend tests and production customers on the frontend, we could have known what was happening and alerted the team (and the user). It would be a simple log query:


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

Ilman lokeja tapahtumien jäljentäminen paikallisesti oli lähes mahdotonta. Todellisissa käyttötapauksissa oli vain liikaa vaihtelua. Yritimme ottaa osittainen lokerointi uudelleen käyttöön, mutta tämä johti vain lisääntyneisiin kulutuksiin, joita pyydettiin vähentämään, antamatta toimivia oivalluksia.

Joissakin tapauksissa emme voineet tunnistaa perimmäistä syytä ollenkaan.Tämä on vaikea asema olla: tietäen, että on ongelma, joka vaikuttaa käyttäjiin ja ei pysty selittämään sitä.

MTTR versus signaalin laatu

Toinen ongelma oli se, että tapahtumien taaksepäin katsominen tarkoittaa aikaa toipua (MTTRMutta havaitsimme, että MTTR oli useimmiten oire, ei perimmäinen syy.

Teollisuuden vertailuarvot osoittavat yleensä, että eliittijoukkueet saavuttavat MTTR:n alle tunnissa.high-fidelity signalsAlhaisen uskottavuuden signaalit, kuten yleiset 500-virheet tai viivästyneet hälytykset yhteenlasketuista mittareista, eivät todellakaan auta.

Päinvastoin, yksityiskohtaiset, kontekstuaaliset signaalit – kuten jäsennellyt lokit, joissa on userId, requestId ja palvelun jälki – leikkaavat suoraan perimmäisen syyn.

Jos lokit eivät vastaa näihin kysymyksiin, MTTR ei ole tiimin nopeudesta – se on signaalin selkeydestä.

How Sumo Logic’s Model Could Have Saved The Day

Joten mikä olisi voinut mennä toisin – ja paremmin – pilvipalveluiden nykyaikaistamisen aikana?

Ensinnäkin toivon todella, että meillä olisi ollut parempi lokitietojen analysointi ja sovellusten suorituskyvyn seuranta (APM). Ja sen lisäksi APM, lokien hallinta, palvelun seuranta, hälytykset ja määritellyt mittarit ovat tiiviisti linjassa toiminnallisen menestyksen tai epäonnistumisen kanssa.

Ja haluan päiväkirjani takaisin! aiemmissa julkaisuissani, ”DevSecOps: On aika maksaa kysynnästäsi, ei saannista,”Olen tutkinut mitenSumo logiikkaPäiväkirjat voidaan syöttää jatkuvasti, mutta maksat vain, kun sinun on kysyttävä tai analysoitava niitä.

Oletko tiimi, jolla ei ole täyttä yksikön testauskattavuutta? Kärsitkö reaaliaikaisten hälytysten tai rakeisten mittareiden puutteesta? tiukalla budjetilla?

Nollakustannusten täyden kulutuksen avulla tiimit voivat kirjautua niin paljon kuin tarvitsevat ilman huolta. Ja kun tämä tapahtuma tapahtuu lopulta (ja se tapahtuu), analyysi voidaan käynnistää pyynnöstä, oikeutetulla kustannuksella, joka liittyy suoraan asiakkaan vaikutukseen tai liiketoiminnan jatkuvuuteen.

Tämä lähestymistapa palauttaa hallinnan ja vähentää ahdistusta, koska tiimillä on valtuudet tutkia perusteellisesti, kun se on tärkeintä.

Mutta odota: Tarvitset myös koneellisesti avustetun kolmiulotteisuuden selvittääksesi kysymyksesi

Nykyaikainen havainnointi ei ole pelkästään siitä, että sinulla on kaikki nämä kauniit lokitiedot – se on myös siitä, että tiedät, mistä etsiä näitä tietoja.high-fidelity signals.

Kun sinulla on rajoittamaton saanti, sinulla on tonnia tietoja. Ja kun alat etsiä tietoa, tarvitset paikan aloittaa.machine-assisted triage toolsjoka automatisoi epätavallisen käyttäytymisen ryhmittymisen, havaitsee ulospäätteitä ja pinnoittaa korreloituja signaaleja eri palveluissa ennen kuin kirjoitat yhden kyselyn.

Taustalla Sumo Logic käytti tilastollisia algoritmeja ja koneoppimista:

  • Cluster-päiväkirjat ovat samankaltaisia (vaikka ne ilmaistaan eri tavoin solmujen välillä).
  • Tunnista outliers mittareissa ja lokeissa (esim. virheen huiput palvelua, aluetta tai käyttäjän kohorttia kohden).
  • Rikastuttaa poikkeavuuksia metatiedoilla (esim. AWS-tunnisteet, Kubernetes pod info, käyttöönottomarkkerit).
  • Luonnon kielen prosessointi klustereita lokit semanttisella samankaltaisuudella, ei vain string matching.

Tämä on erityisen hyödyllistä suuressa tilavuusympäristössä, jossa on rajoittamaton saanti. Sen sijaan, että tarkastelet kymmeniä tuhansia lokiviivoja, saat ”log-allekirjoituksia” – tiivistettyjä kuvioita, jotka edustavat liittyvien tapahtumien ryhmiä.

Esimerkki työnkulusta

_sourceCategory=prod/* error
| logreduce

Tämä yksittäinen komento ryhmittelee meluiset lokitiedot toimiviin ruukkuihin, kuten:

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

Kun ryhmittymät on ryhmitelty, ryhmät voivat kääntyä syvemmälle kontekstiin:

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

Tuloksena on vähemmän sokeita etsintöjä, nopeampia päätöksenteon reittejä ja vähemmän ahdistusta tapahtumien aikana.

Johtopäätös

"Tee enemmän vähemmällä" -filosofian ei tarvitse haitata insinööritiimiä, mutta sen on oltava mukana oikeilla työkaluilla.Ilman niitä jopa kykenevimmät tiimit voivat tuntea, että ne navigoivat tarkoituksettomasti tapahtuman aikana - mikä johtaa turhautumiseen ja stressiin.

Lukijani voivat muistaa henkilökohtaisen tehtäväni, jonka mielestäni voi soveltaa mihin tahansa IT-ammattilaiseen:


”Keskittäkää aikaanne tarjoamaan ominaisuuksia/toimintoja, jotka laajentavat henkisen omaisuutenne arvoa. Hyödynnä kehyksiä, tuotteita ja palveluita kaikkeen muuhun.” – J. Vester

”Keskittäkää aikaanne tarjoamaan ominaisuuksia/toimintoja, jotka laajentavat henkisen omaisuutenne arvoa. Hyödynnä kehyksiä, tuotteita ja palveluita kaikkeen muuhun.” – J. Vester


Tässä artikkelissa tarkastelimme, miten nollakustannusten kulutusmalli sopii tähän tehtävään. Se auttaa tiimejä tunnistamaan nopeasti perimmäiset syyt, vähentämään käyttökatkoksia ja alentamaan stressitasoja - kaikki rikkomatta budjettia.

Olkoon todella hieno päivä!

Trending Topics

blockchaincryptocurrencyhackernoon-top-storyprogrammingsoftware-developmenttechnologystartuphackernoon-booksBitcoinbooks