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. Päätös johtui lokitietojen syöttämisen korkeista kustannuksista havainnointialustallamme. minimize or eliminate service-level logging 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. ja 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ä. we relied on logs to resolve our issues 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 ( Mutta havaitsimme, että MTTR oli useimmiten oire, ei perimmäinen syy. MTTR Teollisuuden vertailuarvot osoittavat yleensä, että eliittijoukkueet saavuttavat MTTR:n alle tunnissa. Alhaisen uskottavuuden signaalit, kuten yleiset 500-virheet tai viivästyneet hälytykset yhteenlasketuista mittareista, eivät todellakaan auta. high-fidelity signals 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, ” ”Olen tutkinut miten Päiväkirjat voidaan syöttää jatkuvasti, mutta maksat vain, kun sinun on kysyttävä tai analysoitava niitä. DevSecOps: On aika maksaa kysynnästäsi, ei saannista, Sumo logiikka 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. joka automatisoi epätavallisen käyttäytymisen ryhmittymisen, havaitsee ulospäätteitä ja pinnoittaa korreloituja signaaleja eri palveluissa ennen kuin kirjoitat yhden kyselyn. machine-assisted triage tools 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ä!

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

Tämä ääni on tuotettu tarinan alkuperäisellä kielellä!

Liian pitkä; Lukea

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

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

About Author

KOMMENTIT

RIPUTA TAGSIA

TÄMÄ ARTIKKELI ESITETTIIN

Related Stories

About Bitcoin And “Web 2.5,” HackerNoon’s First Documentary

Spaghetti

10x Research: How a FIL Backed USD Stablecoin By Secured Finance Would Boost The Filecoin Ecosystem

Meet Filestack: HackerNoon Company of the Week

About Bitcoin And “Web 2.5,” HackerNoon’s First Documentary

Spaghetti

10x Research: How a FIL Backed USD Stablecoin By Secured Finance Would Boost The Filecoin Ecosystem

Meet Filestack: HackerNoon Company of the Week

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps