Järjestelmä toimii. Siihen asti, kunnes ei enää toimi
Kuvittele verkkokauppa, jossa asiakkaat voivat selailla tuotteita, lisätä niitä ostoskoriin ja siirtyä maksamaan. Palvelin vastaa, sivu aukeaa ja infrastruktuurin perusmittarit eivät näytä mitään vakavaa ongelmaa. Päällisin puolin kaikki näyttää toimivan oikein.
Samaan aikaan osa asiakkaista ei pysty viimeistelemään tilaustaan. Joillakin maksu kestää useita kymmeniä sekunteja, toisilla ilmenee virhe. Tekninen tiimi saa ilmoituksia, mutta ei vielä tiedä, johtuuko syy maksupalvelusta, tietokannasta, sovelluksen viimeisimmästä päivityksestä vai kenties palvelujen välisestä viestintäongelmasta.
Tässä tilanteessa tavallinen valvonta voi osoittautua riittämättömäksi. Se pystyy osoittamaan, että virheiden määrä kasvoi tai vastausaika piteni, mutta ei aina tarjoa tietoja, joita tarvitaan syyn nopeaan löytämiseen.
Juuri tähän aukkoon vastaa observability eli järjestelmän havainnoitavuus. Sen tavoitteena ei ole vain todeta, että sovellus toimii virheellisesti. Kyse on mahdollisuudesta analysoida sen käyttäytymistä, toistaa tapahtumien kulku ja löytää ongelman lähde myös silloin, kun tiettyä vikatilannetta ei ole aiemmin ennakoitu.
Valvonta ja observability - samankaltaiset tavoitteet, eri mahdollisuudet
Valvonta ja observability liittyvät tiiviisti toisiinsa, mutta ne eivät tarkoita samaa asiaa.
Valvonta tarkoittaa sovelluksen ja infrastruktuurin tilaa koskevien tietojen järjestelmällistä keräämistä ja analysointia. Sen avulla voidaan seurata tiettyjä parametreja, havaita poikkeamia sovituista normeista ja käynnistää hälytyksiä, kun tarvitaan reagointia.
Esimerkkikysymyksiä, joihin valvonta vastaa, ovat:
- Onko palvelin käytettävissä?
- Mikä on API:n keskimääräinen vastausaika?
- Ylittääkö HTTP 500 -virheiden määrä asetetun rajan?
- Mikä on muistin ja prosessorin käyttöaste?
- Kasvaako tehtäväjono nopeammin kuin järjestelmä ehtii käsitellä sitä?
Observability menee pidemmälle. Sen avulla voidaan analysoida järjestelmän eri osista tulevaa dataa ja yhdistää se kontekstiin, joka auttaa ymmärtämään, miksi tietty käyttäytyminen ilmeni.
Tämän voi tiivistää kolmeen kysymykseen:
- Valvonta: Onko jokin vialla?
- Diagnostiikka: Missä ongelma ilmestyi?
- Observability: Mitä tapahtui, miksi ja mikä oli vaikutus järjestelmän toimintaan?
Havainnoitavuus ei korvaa valvontaa. Se on lähestymistapa, joka hyödyntää valvontaa ja asianmukaisesti valmisteltua telemetriadataa mahdollistaakseen sovelluksen käyttäytymisen syvemmän tutkimisen. OpenTelemetry kuvaa observabilityä kykynä esittää järjestelmälle sen käyttäytymistä koskevia kysymyksiä signaalien, kuten lokien, metriikoiden ja hajautettujen jälkien, perusteella. <Cite ref="turn154932search0"/>
Observabilityn kolme pilaria: lokit, metriikat ja tracing
Havainnoitavuuden perustana on kolme telemetriatiedon tyyppiä: logs, metrics ja traces. Jokainen niistä näyttää sovelluksen toiminnasta eri näkökulman. Vasta niiden yhdistäminen antaa laajemman kuvan tilanteesta.
1. Lokit - mitä sovelluksessa tapahtui?
Lokit (logs) ovat sovelluksen, käyttöjärjestelmän, palvelimien, tietokantojen ja muiden infrastruktuurin osien tuottamia jäsenneltyjä tapahtumatietoja.
Ne voivat tallentaa esimerkiksi:
- prosessin käynnistymisen ja päättymisen,
- käyttäjän kirjautumisyrityksen,
- pyynnön lähettämisen ulkoiseen API:in,
- tietojen validointivirheen,
- epäonnistuneen maksutapahtuman,
- sovelluksen ilmoittaman poikkeuksen,
- tilauksen tilan muutoksen.
Loki voi sisältää aikaleiman, vakavuustason, palvelun nimen, viestin, pyynnön tunnisteen sekä lisäattribuutteja, jotka kuvaavat tapahtumaa.
On hyvä erottaa tekstilokit rakenteellisista lokeista. Tekstipohjainen merkintä voi näyttää esimerkiksi tältä:Virhe tilausta käsiteltäessä
Tällainen viesti kertoo ongelman esiintymisestä, mutta kertoo vain vähän sen kontekstista. Rakenteellinen loki voi puolestaan sisältää erillisiä kenttiä, kuten tilauksen tunnisteen, operaation nimen, virhekoodin, suoritusaikaan ja jäljen tunnisteen. Näin tietoa voidaan suodattaa, ryhmitellä ja analysoida automaattisesti.
Hyvä käytäntö: lokit kannattaa suunnitella myöhempää analyysiä varten, ei vain viestien tallentamista varten. On hyvä käyttää yhtenäistä nimeämistä, vakavuustasoja ja korrelaatiotunnisteita, joiden avulla eri komponenteista peräisin olevat tapahtumat voidaan yhdistää toisiinsa.
Samalla lokitus vaatii harkintaa. Jokaisen operaation tallentaminen täysin kattavasti voi synnyttää valtavia määriä dataa, nostaa säilytyskustannuksia ja vaikeuttaa olennaisen tiedon löytämistä. Yhtä tärkeää on, etteivät lokit paljasta salasanoja, käyttöoikeustokeneita, maksukorttitietoja tai muita arkaluonteisia tietoja. On käytettävä peittämistä, käyttöoikeuksien hallintaa, asianmukaisia säilytysaikoja ja turvallisen datankäsittelyn periaatteita.
2. Metriikat - miten järjestelmä käyttäytyy ajan kuluessa?
Metriikat (metrics) ovat koottuja numeerisia tietoja, jotka kuvaavat järjestelmän tilaa, suorituskykyä ja käyttäytymistä tiettynä aikana.
Esimerkkimetriikoita ovat:
- sekunnissa käsiteltyjen pyyntöjen määrä,
- virheeseen päättyneiden pyyntöjen osuus,
- API:n vastausaika,
- CPU:n ja muistin käyttö,
- aktiivisten istuntojen määrä,
- tehtäväjonon pituus,
- valmiiksi saatettujen transaktioiden määrä,
- odotusaika tietokantayhteydelle.
Niiden suurin etu on trendien tarkkailu. Yksittäinen virhe voi olla yksittäistapaus, mutta vähitellen kasvava vastausaika, lisääntyvä epäonnistuneiden transaktioiden määrä tai kasvava tehtäväjono voivat viitata kehittyvään ongelmaan.
Käytännössä metriikat auttavat vastaamaan paitsi kysymykseen siitä, toimiiko sovellus, myös siihen, vastaako sen suorituskyky käyttäjien odotuksia ja liiketoiminnan vaatimuksia.
Erityisen hyödyllisiä ovat vastausajan prosenttipisteet, esimerkiksi p95 ja p99. Keskiarvo voi peittää tilanteen, jossa suurin osa käyttäjistä saa vastauksen nopeasti, mutta pieni osa kokee erittäin suuria viiveitä. Prosenttipisteet osoittavat, kuinka kauan hitaampien pyyntöjen käsittely kestää, ja auttavat havaitsemaan ongelmia, jotka eivät näy keskiarvoissa.
Hyvä käytäntö: valitse metriikat, joilla on merkitystä käyttäjälle ja liiketoimintaprosessille. Pelkkä tieto prosessorikuormasta ei kerro, voiko asiakas tehdä tilauksen. Siksi kannattaa seurata myös keskeisiin toimintoihin liittyviä mittareita, kuten maksujen onnistumisastetta, tilauksen läpimenoaikaa tai tärkeimpien toimintojen saatavuutta.
3. Tracing - mitä reittiä pyyntö kulki?
Tracing, ja erityisesti distributed tracing eli hajautettu jäljitys, mahdollistaa yksittäisen pyynnön kulun seuraamisen järjestelmän eri komponenttien läpi.
Nykyaikaisessa sovelluksessa käyttäjän toiminta voi koostua useista vaiheista. Painikeen ”Tee tilaus” klikkaus voi käynnistää selaimessa pyynnön, joka siirtyy API:lle, sitten tilausten palvelulle, tietokannalle, varastojärjestelmälle ja ulkoiselle maksupalveluntarjoajalle.
Jos prosessi hidastuu, pelkkä koko API:n vasteaikatieto ei välttämättä riitä. Tracingin avulla tämä aika voidaan jakaa yksittäisiin toimintoihin ja nähdä, mikä vaihe aiheuttaa viiveen.
Jäljityksen (trace) peruselementti on span, eli yhden toiminnon merkintä. Span voi sisältää aloitus- ja lopetusajan, toiminnon nimen, tilan sekä metatiedot. Yhdistetyt spanit muodostavat jäljen, joka näyttää koko pyynnön kulun.
Esimerkiksi:
- API vastaanottaa pyynnön ja välittää sen eteenpäin.
- Tilauspalvelu tarkistaa tiedot.
- Tietokanta tallentaa tilauksen.
- Varastopalvelu tarkistaa tuotteen saatavuuden.
- Ulkoinen maksupääte käsittelee tapahtuman.
- Sovellus palauttaa tuloksen käyttäjälle.
Jos koko prosessi kestää 8 sekuntia, tracing voi näyttää, että 6,5 sekuntia kului ulkoisen maksupäätteen vastaukseen, ja muut toiminnot etenivät normaalisti. Tiimi saa silloin konkreettisen kohdan jatkoanalyysia varten sen sijaan, että diagnostiikka aloitettaisiin satunnaisista komponenteista.
Tracing on erityisen hyödyllistä mikropalveluarkkitehtuureissa, hajautetuissa järjestelmissä, jonoihin perustuvissa sovelluksissa ja ratkaisuissa, jotka integroivat useita ulkoisia palveluja. <Cite ref="turn154932search0"/>
Hälytykset - tiedon on päästävä oikealle henkilölle
Telemetriatiedosta on hyötyä vain, jos niiden perusteella voidaan toimia. Siksi observabilityn olennainen osa on hälytysjärjestelmä.
Hälytys on ilmoitus tapahtumasta tai tilasta, joka vaatii huomiota. Sen voi laukaista metriikan rajan ylittyminen, tietyn virhekuvion havaitseminen tai toteamus siitä, että sovelluksen kriittinen toiminto ei toimi odotetusti.
Kaikki kuormituksen kasvu ei kuitenkaan saisi aiheuttaa hälytystä. Jos järjestelmä käsittelee säännöllisesti suurta liikennettä ruuhka-aikoina, ilmoitus jokaisesta pyyntömäärän noususta aiheuttaa informaatiomelua. Liian monet hälytykset johtavat niiden ohittamiseen ja lopulta todellisen olennaisen häiriön huomaamatta jäämiseen.
Siksi kannattaa määrittää:
- mitkä tapahtumat vaativat välitöntä reagointia,
- mitkä ongelmat voidaan analysoida normaalissa työtilassa,
- kuka vastaa tietystä hälystypistä,
- mitä tietoja ilmoituksen pitäisi sisältää,
- mitä toimia on tehtävä sen vastaanottamisen jälkeen.
Hyvä lähtökohta on määritellä hälytykset käyttäjävaikutuksen ja luotettavuustavoitteiden perusteella, ei pelkästään infrastruktuuriparametrien mukaan. Esimerkiksi hälytys kasvavasta epäonnistuneiden maksujen osuudesta voi olla liiketoiminnan kannalta merkittävämpi kuin lyhytaikainen CPU:n käytön piikki.
Hälytyksen pitäisi johtaa toimintaan. Jos ei tiedetä, kuka sitä käsittelee tai mitä pitää tehdä, se on vain yksi viesti järjestelmässä.
Käytännön esimerkki: miten observability auttaa löytämään häiriön syyn?
Oletetaan, että B2B-sovelluksen käyttäjät ilmoittavat raporttien luomisen kestävän paljon normaalia kauemmin. Valvonta havaitsee vasteajan kasvun ja laukaisee hälytyksen.
Tiimi aloittaa analyysin:
- Metriikat osoittavat, että ongelma koskee pääasiassa raportteja, jotka kattavat suuria tietomääriä. Muut toiminnot toimivat normaalisti.
- Tracing näyttää, että suurin viive syntyy tietokantakyselyn suorittamisen aikana.
- Lokit sisältävät kyselyn yksityiskohdat, sen operatiiviset parametrit ja tiedot virheistä paljastamatta arkaluonteisia tietoja.
- Tietojen korrelaatio mahdollistaa tietyn jäljen yhdistämisen vastaaviin lokimerkintöihin ja metriikkakaavioissa näkyviin muutoksiin.
- Muutosanalyysi osoittaa, että ongelma ilmaantui uuden raporttiversion käyttöönoton jälkeen, ja se alkoi suorittaa kallista kyselyä.
Tämän ansiosta tiimin ei tarvitse sokkona tarkistaa koko infrastruktuuria. Se voi keskittyä tiettyyn toimintoon, verrata käyttäytymistä ennen ja jälkeen käyttöönoton ja sitten optimoida kyselyn tai peruuttaa muutoksen.
Observability ei poista häiriöitä eikä takaa, että jokainen syy löydetään automaattisesti. Se kuitenkin auttaa rajaamaan etsintäaluetta, lyhentämään diagnoosiaikaa ja perustamaan päätökset dataan oletusten sijaan.
Tietojen korrelaatio - suurin arvo syntyy yhdessä
Lokit, metriikat ja tracing ovat hyödyllisiä erikseen, mutta niiden todellinen arvo paljastuu, kun ne voidaan yhdistää toisiinsa.
Kuvitellaan, että dashboard näyttää äkillisen vasteajan kasvun. Metriikka kertoo, milloin ja missä mittakaavassa ongelma ilmeni. Trace näyttää, mitkä toiminnot muodostivat hitaan pyynnön. Lokit auttavat tarkistamaan, mitä tapahtumia tietyssä vaiheessa esiintyi.
Jotta tämä olisi mahdollista, järjestelmän pitäisi välittää pyynnön konteksti johdonmukaisesti palvelujen välillä. Trace- ja span-tunnisteita voidaan käyttää lokimerkintöjen yhdistämiseen jälkiin. Kannattaa myös säilyttää yhtenäiset tiedot palvelun nimestä, ympäristöstä, sovellusversiosta ja muista datalähdettä kuvaavista attribuuteista.
Ilman korrelaatiota tiimillä voi olla käytössään monta dashboardia, tiedostoa ja työkalua, mutta se menettää silti aikaa selvittäessään manuaalisesti, mitkä tapahtumat liittyvät toisiinsa. OpenTelemetry osoittaa lokien, jälkien ja resurssikontekstin korrelaation tärkeäksi osaksi käyttökelpoisen telemetrian rakentamista. <Cite ref="turn154932search1"/>
OpenTelemetry - yhteinen standardi telemetriatiedolle
Observabilityn käyttöönotto ei tarkoita välttämättä riippuvuutta yhdestä työkalutoimittajasta. Yksi yhteentoimivuutta tukevista ratkaisuista on OpenTelemetry (OTel) - avoin standardien, API-rajapintojen, kirjastojen ja työkalujen kokonaisuus telemetriatiedon instrumentointiin, tuottamiseen, keräämiseen ja vientiin.
OpenTelemetry antaa sovellukselle mahdollisuuden lähettää metriikoita, lokitietoja ja jälkiä yhtenäisessä mallissa. Tiedot voidaan sen jälkeen välittää valittuun observability-taustajärjestelmään, joka vastaa niiden tallennuksesta, hausta, visualisoinnista ja analyysistä.
Tärkeä osa ekosysteemiä on OpenTelemetry Collector. Se voi vastaanottaa dataa eri lähteistä, käsitellä sitä, rikastaa sitä lisäkontekstilla ja viedä sen määritettyihin järjestelmiin. Näin sovelluksen ei tarvitse olla suoraan sidottu jokaiseen analyysissa käytettävään työkaluun.
Tämä lähestymistapa on erityisen hyödyllinen, kun yritys käyttää useita teknologioita, kehittää järjestelmäarkkitehtuuriaan tai haluaa säilyttää mahdollisuuden vaihtaa työkalutoimittajaa. Itse standardi ei kuitenkaan takaa täydellistä observabilityä. Tarvitaan edelleen oikea instrumentointi, harkittu tiedonkeruustrategia, asianmukaiset dashboardit, hälytykset ja reagointiprosessit. <Cite ref="turn154932search3"/>
Milloin observability kannattaa ottaa käyttöön?
Observability voi olla hyödyllistä sekä suurissa hajautetuissa järjestelmissä että pienemmissä sovelluksissa, joissa käyttökatko tai vaikeasti havaittava vika voi aiheuttaa merkittäviä liiketoimintavaikutuksia.
Tätä lähestymistapaa kannattaa erityisesti harkita, kun:
- sovellus koostuu monista palveluista tai integraatioista,
- ongelmat ilmenevät satunnaisesti ja niitä on vaikea toistaa,
- käyttäjät raportoivat virheistä, joita ei näy tavallisissa testeissä,
- häiriöiden diagnosointiin kuluva aika on liian pitkä,
- seuraavat käyttöönotot aiheuttavat vaikeasti ennustettavia seurauksia,
- yritys kehittää järjestelmää ja tarvitsee tietoa suorituskyvyn suunnitteluun,
- sovellus tukee keskeisiä myynnin, operatiivisia tai taloudellisia prosesseja,
- tiimin on ymmärrettävä paremmin ulkoisten palveluiden vaikutus koko ratkaisun toimintaan.
Tämä ei kuitenkaan tarkoita, että jokainen verkkosivusto tarvitsee laajaa telemetria-ympäristöä. Pienessä, yksinkertaisessa palvelussa voivat riittää perustason lokit, käytettävyyden seuranta ja muutama keskeinen metriikka. Ratkaisun laajuuden tulisi vastata sovelluksen monimutkaisuutta, liikenteen mittakaavaa, luotettavuusvaatimuksia sekä mahdollisten käyttökatkosten kustannuksia.
Milloin observability voi olla liiallista?
Laajojen työkalujen käyttöönotto ilman selkeästi määriteltyä tavoitetta voi tuoda enemmän kustannuksia kuin hyötyä.
Yleisimpiä virheitä ovat:
- Kaiken kerääminen ilman suunnitelmaa. Liiallinen data kasvattaa kustannuksia ja vaikeuttaa diagnoosin kannalta olennaisen tiedon löytämistä.
- Ei kysymyksiä, joihin järjestelmän pitäisi vastata. Koontinäytöt voivat näyttää näyttäviltä, mutta eivät auttaa todellisten ongelmien ratkaisemisessa.
- Hälyttäminen jokaisesta poikkeamasta. Liian suuri ilmoitusten määrä aiheuttaa hälytysväsymystä ja lisää riskiä, että häiriö jää huomaamatta.
- Vastuun puute reagoinnissa. Jopa hyvin havaittu ongelma voi kestää pitkään, jos kukaan ei tiedä, kenen pitäisi hoitaa se.
- Tietosuojan puute. Telemetria voi sisältää arkaluonteisia tietoja, käyttäjätunnisteita tai operatiivisia tietoja, jotka vaativat rajattua pääsyä ja asianmukaista säilytystä.
- Instrumentoinnin kustannusten sivuuttaminen. Yksityiskohtaisten jälkien ja lokien kerääminen suuressa mittakaavassa voi vaikuttaa sovelluksen suorituskykyyn sekä aiheuttaa merkittäviä tallennus- ja käsittelykustannuksia.
- Työkalun käsittäminen valmiina ratkaisuna. Pelkkä alustan asentaminen ei takaa oikeaa instrumentointia eikä sujuvaa diagnosointiprosessia.
Observability vaatii siis teknologian lisäksi myös organisatorisia päätöksiä: mitä tietoja tarvitaan, kuka niitä analysoi, miten tiimi reagoi ja miten häiriöistä saadut opit viedään järjestelmän muutoksiin.
Miten observabilityn käyttöönotto kannattaa suunnitella?
Turvallisinta on kehittää havaittavuutta vaiheittain aloittaen prosesseista ja toiminnoista, joiden häiriöllä on suurin vaikutus käyttäjiin ja yritykseen.
1. Määritä keskeiset liiketoimintaprosessit
Tunnista tärkeimmät toiminnot, kuten kirjautuminen, tilausten tekeminen, maksut, dokumenttien luonti tai tietojen synkronointi. Niiden pitäisi olla lähtökohta sille, mitä sovelluksen oikea toiminta tarkoittaa.
2. Määritä luotettavuusmittarit
Valitse metriikat, jotka heijastavat käyttäjäkokemusta, esimerkiksi keskeisten toimintojen käytettävyys, vasteaika tai onnistuneiden operaatioiden osuus. Tärkeille palveluille voidaan määritellä SLI (Service Level Indicator), eli palvelutason mittari, sekä SLO (Service Level Objective), eli tavoite kyseiselle mittarille.
3. Huolehdi rakenteellisista lokeista
Yhdenmukaista lokien muoto, tärkeysasteet ja perustunnisteet. Huolehdi korrelaatiotunnisteista sekä käytännöstä, jolla arkaluonteiset tiedot poistetaan tai peitetään. Lokien tulee olla tiimille luettavia ja työkalujen käsiteltävissä.
4. Lisää tracing kriittisiin polkuihin
Aloita prosesseista, jotka kattavat useita palveluita, tietokantoja tai ulkoisia integraatioita. Seuraa pyynnön kulkua järjestelmässä ja huolehdi kontekstin välittämisestä komponenttien välillä.
5. Rakenna dashboardit tiettyjen kysymysten ympärille
Yhden valtavan paneelin sijaan valmistele näkymiä, jotka vastaavat eri roolien tarpeisiin. Tekninen tiimi voi tarvita tietoa virheistä ja viiveistä, kun taas tuotteen omistaja - tietoja keskeisten prosessien tehokkuudesta ja häiriöiden vaikutuksesta käyttäjiin.
6. Suunnittele hälytykset ja reagointikäytännöt
Määritä kynnykset, prioriteetit, vastuuhenkilöt ja toimintaohjeet. Hälytyksen tulisi sisältää konteksti, joka auttaa aloittamaan diagnosoinnin nopeasti, eikä vain ilmoittaa arvon ylittymisestä.
7. Testaa havaittavuus
Tarkista, pystyykö tiimi löytämään esimerkkivirheen syyn käytettävissä olevan datan perusteella. Voidaan tehdä hallittuja häiriötestejä testiympäristössä tai harjoitella incident-reaktiota. Kannattaa myös varmistaa, laukeavatko hälytykset silloin kun niiden pitäisi.
8. Kehitä ratkaisua häiriöiden perusteella
Jokaisen merkittävän ongelman jälkeen kannattaa tarkistaa, mitä tietoja oli saatavilla, mitä puuttui ja miten instrumentointia, hälyttämistä tai käytäntöjä voidaan parantaa. Observability ei ole kertaluonteinen projekti, vaan prosessi, jolla syvennetään tietoa järjestelmän toiminnasta.
Kustannukset ja tietoturva - kaksi näkökulmaa, joita ei voi sivuuttaa
Telemetriadatalla on hintansa. Kustannuksia voi syntyä instrumentoinnista, siirrosta, indeksoinnista, tallennuksesta, säilytyksestä ja datan analysoinnista. Suuren liikenteen järjestelmissä erityisen kallista voi olla kaiken jäljen tai hyvin yksityiskohtaisten lokien kerääminen.
Siksi kannattaa käyttää tarpeisiin sopivaa säilytysaikaa, datan suodatusta, jälkien otantaa (sampling) ja eri tarkkuustasoja ympäristöstä riippuen. Esimerkiksi tuotantojärjestelmä voi kerätä täydet tiedot virheistä ja valituista kriittisistä operaatioista, ja osan onnistuneista pyynnöistä voi ottaa otantaan volyymin rajoittamiseksi.
Yhtä tärkeää on datan suojaus. Lokit ja jäljet voivat tahattomasti sisältää henkilötietoja, istuntotunnisteita, kyselyiden osia tai tietoa infrastruktuurin rakenteesta. Telemetrian käyttöoikeuksia on rajoitettava, tarpeettomat tiedot poistettava, arkaluonteiset tiedot peitettävä ja säilytysajat kontrolloitava. On myös hyvä käsitellä observability-järjestelmiä osana tuotantoympäristöä, joka itsekin vaatii suojausta, varmuuskopioita ja käyttöoikeuksien hallintaa.
Observability johtamisen työkaluna, ei vain diagnostiikkana
Vaikka havaittavuus yhdistetään useimmiten kehittäjien, DevOpsin ja ylläpitäjien työhön, sen arvo ulottuu IT:n ulkopuolelle.
Tiedot vasteajasta, virheistä, käytettävyydestä ja prosessien onnistumisesta voivat auttaa yritystä ymmärtämään, mitkä teknologian osat tukevat liiketoimintaa ja mitkä rajoittavat sitä. Ne auttavat tunnistamaan toistuvia ongelmia, arvioimaan muutosten vaikutuksia ja suunnittelemaan kehitystä järjestelmän todellisen toiminnan perusteella.
Jos esimerkiksi tilausjärjestelmä hidastuu säännöllisesti tiettyinä aikoina, telemetriadata voi auttaa selvittämään, tarvitaanko kyselyiden optimointia, tehtävien käsittelytavan muuttamista vai infrastruktuurin laajentamista. Sen sijaan, että investoitaisiin lisäresursseihin intuition perusteella, yritys voi ensin tunnistaa todellisen pullonkaulan.
Observability tukee myös käyttöönottojen vaikutusten analysointia. Mittareiden, jälkien ja lokien vertailu ennen muutosta ja sen jälkeen auttaa havaitsemaan regressiot nopeammin ja arvioimaan, tuottiko päivitys odotetun vaikutuksen.
Observabilitya ei kuitenkaan pidä sekoittaa automaattiseen päätöksentekoon. Data näyttää järjestelmän käyttäytymisen, mutta sen tulkinta vaatii arkkitehtuurin, liiketoimintaprosessien ja yksittäisen häiriön kontekstin tuntemusta.
Käsitteiden sanasto
- Observability (havaittavuus) - kyky ymmärtää järjestelmän sisäistä käyttäytymistä sen tuottaman datan perusteella.
- Monitoring - valittujen parametrien jatkuva seuranta ja huomiota vaativien tiettyjen tilojen havaitseminen.
- Telemetry (telemetria) - sovelluksista ja infrastruktuurista kerätty ja siirretty data niiden toiminnan analysoimiseksi.
- Logs (lokit) - sovelluksessa tai infrastruktuurissa tapahtuvien tapahtumien tallenteet.
- Metrics (mittarit) - järjestelmän tilan, suorituskyvyn tai käyttäytymisen numeeriset mittaukset ajan kuluessa.
- Tracing - operaatioiden kulun seuraaminen sovelluksen komponenttien läpi.
- Distributed tracing - yksittäisen pyynnön seuraaminen useista palveluista tai prosesseista koostuvassa järjestelmässä.
- Span - yksittäisen operaation tallenne, joka on osa jälkeä.
- Trace - joukko toisiinsa liittyviä span-eja, jotka esittävät operaation kulun.
- Alert - ilmoitus havaitusta tilasta tai tapahtumasta, joka vaatii reagointia.
- SLI - mittari, joka mittaa palvelun toiminnan tiettyä osa-aluetta.
- SLO - määritelty tavoite valitulle luotettavuusmittarille.
- Sampling - tekniikka, jolla kerättävän telemetriadatan määrää rajoitetaan valitsemalla edustava osa tapahtumista.
- OpenTelemetry - avoin standardien ja työkalujen kokonaisuus, joka tukee instrumentointia ja telemetriadatan vientiä.
Yhteenveto
Sovelluksen häiriö ei aina ala saavuttamattomasta palvelimesta tai virheilmoituksesta. Joskus järjestelmä toimii muodollisesti, mutta keskeinen toiminto muuttuu liian hitaaksi, osa transaktioista ei onnistu tai integraatio pettää vain tietyissä olosuhteissa.
Monitoring auttaa havaitsemaan poikkeamat. Observability auttaa ymmärtämään, mikä johti niiden syntymiseen ja millainen vaikutus niillä oli sovelluksen toimintaan. Lokit, mittarit, tracing ja hyvin suunnitellut hälytykset muodostavat yhdessä perustan tehokkaammalle diagnostiikalle, tietoiselle kehitykselle ja operatiivisen riskin pienentämiselle.
Kyse ei ole siitä, että kerättäisiin mahdollisimman paljon dataa tai luotaisiin mahdollisimman monimutkaisia dashboardeja. Kyse on siitä, että ongelman ilmetessä ei kysytä ainoastaan: „Toimiiko järjestelmä?”, vaan voidaan selvittää: „Mitä järjestelmässä tarkalleen tapahtui, miksi ja mitä meidän pitäisi tehdä seuraavaksi?”
Kypsä sovellus ei ole vain sellainen, joka toimii. Se on myös sellainen, jonka käyttäytyminen voidaan ymmärtää, diagnosoida ja parantaa.
