Infrastruktuurin valvonta on muuttunut viime vuosina merkittävästi. Yksittäisten palvelimien seuranta on väistynyt hajautettujen pilvi-infrastruktuurien, mikropalveluiden ja kontaineroitujen ympäristöjen tieltä. Samalla on kasvanut tarve ymmärtää, mitä järjestelmissä todella tapahtuu, ei ainoastaan silloin, kun jokin menee pieleen, vaan jatkuvasti ja ennakoivasti. Tähän tarpeeseen vastaavat metriikat, lokit ja jäljet, jotka yhdessä muodostavat modernin observability-käytännön perustan.
Tässä artikkelissa käymme läpi nämä kolme telemetrian pilaria alusta alkaen: mitä ne tarkoittavat, miten ne täydentävät toisiaan, miten telemetriaa kerätään käytännön infrastruktuuriympäristöissä ja mitkä ovat yleisimmät ongelmat, joihin organisaatiot törmäävät. Lopuksi katsomme, miten nämä osat yhdistetään toimivaksi observability-strategiaksi.
Mitä metriikat, lokit ja jäljet tarkoittavat infrastruktuurissa?
Infrastruktuurin telemetria tarkoittaa kaikkea sitä dataa, jota järjestelmät tuottavat itsestään toimintansa aikana. Tämä data jaetaan kolmeen selkeästi erilaiseen signaalityyppiin: metriikoihin, lokeihin ja jälkiin. Jokainen niistä kertoo eri asioita, ja yhdessä ne antavat kokonaiskuvan siitä, mitä infrastruktuurissa tapahtuu.
Metriikat: numerot, jotka kertovat mitä tapahtuu nyt
Metriikat ovat numeerisia mittauksia, joita kerätään säännöllisesti ajan kuluessa. Tyypillisiä esimerkkejä ovat CPU:n käyttöaste, muistin kulutus, verkkoliikenteen määrä, levyn I/O ja palvelupyyntöjen vasteaika. Metriikat ovat tehokkaita, koska ne ovat kevyitä tallentaa, helppo visualisoida ja soveltuvat hyvin hälytysten perustaksi.
Hyvä analogia on auton mittaristo: nopeusmittari, polttoainemittari ja moottorin lämpötila kertovat ajotilanteen tilan yhdellä silmäyksellä. Ne eivät kerro, miksi polttoaine loppuu tai miksi moottori ylikuumenee, mutta ne kertovat selvästi, että jotain on vialla.
Lokit: tapahtumat, jotka kertovat mitä tapahtui ja miksi
Lokit ovat aikaleimattuja tekstimuotoisia tapahtumamerkintöjä, joita sovellukset ja infrastruktuurin komponentit kirjoittavat toimintansa aikana. Ne voivat kertoa, milloin käyttäjä kirjautui sisään, milloin tietokantayhteys katkesi tai mikä virhekoodi palautti epäonnistuneen pyynnön. Toisin kuin metriikat, lokit ovat rikkaita yksityiskohtia täynnä, mutta niitä syntyy suuria määriä ja niiden läpikäyminen manuaalisesti on hidasta.
Lokit ovat infrastruktuurin observabilityn muisti. Kun jokin menee pieleen, lokit kertovat tarkalleen, mitä tapahtui ja missä järjestyksessä.
Jäljet: polut, jotka kertovat missä ongelma sijaitsee
Jäljet, englanniksi traces, kuvaavat yksittäisten pyyntöjen tai tapahtumien kulkua järjestelmän läpi alusta loppuun. Modernissa mikropalveluarkkitehtuurissa yksi käyttäjän toiminto saattaa kulkea kymmenen eri palvelun kautta. Jäljet näyttävät tämän polun ja paljastavat, missä kohdassa viive kasvaa tai missä pyyntö katkeaa.
Jos metriikat ovat auton mittaristo ja lokit ovat huoltokirja, jäljet ovat GPS-jäljitys, joka näyttää täsmälleen, mitä reittiä auto kulki ja missä se hidastui.
Miten kolme pilaria täydentävät toisiaan
Metriikat, lokit ja jäljet eivät ole kilpailevia vaan toisiaan täydentäviä signaalityyppejä. Tehokas infrastructure telemetry perustuu siihen, että nämä kolme lähdettä toimivat yhdessä, ei erillään.
Ajatellaan konkreettista tilannetta: verkkokaupan vasteajat kasvavat äkillisesti. Metriikat havaitsevat ongelman ensimmäisenä, koska vasteaikamittari ylittää normaalin kynnysarvon ja hälytys laukeaa. Tässä vaiheessa tiedät, että jotain on vialla, mutta et vielä tiedä missä tai miksi. Seuraavaksi käännyt lokien puoleen: niistä näet, että tietokantayhteydet alkavat tuottaa virheitä juuri ennen vasteaikojen kasvua. Lopuksi jäljet paljastavat, että ongelma ei ole tietokannassa itsessään, vaan yhdessä mikropalvelussa, joka tekee tarpeettoman monta tietokantakyselyä silmukassa.
Ilman kaikkia kolmea pilaria tämä tutkintaprosessi olisi huomattavasti hitaampaa. Metriikat ilman lokeja kertovat, että ongelma on olemassa, mutta eivät missä. Lokit ilman jälkiä näyttävät virheitä, mutta eivät niiden alkuperää hajautetussa järjestelmässä. Jäljet ilman metriikkoja eivät hälytä ongelmasta ajoissa. Yhdessä ne lyhentävät merkittävästi aikaa, joka kuluu ongelman havaitsemisesta sen ratkaisemiseen.
Telemetrian kerääminen käytännön infrastruktuuriympäristöissä
Telemetrian kerääminen riippuu siitä, minkälaisessa ympäristössä infrastruktuuri toimii. Hybridit, pilvinatiiviit ja perinteiset on-prem-ympäristöt asettavat kukin omat vaatimuksensa datan keräämiselle.
Pilvi-infrastruktuurissa
AWS:ssä, Microsoft Azuressa ja Google Cloud Platformissa pilvipalveluntarjoajat tuottavat osan telemetriasta valmiiksi. EC2-instanssit, RDS-tietokannat ja EKS-klusterit tarjoavat natiiveja metriikoita suoraan alustan hallintapaneeleista. Haasteena on se, että nämä natiivit metriikat kattavat vain alustakerroksen, eivät sovellustasoa tai liiketoimintaprosesseja.
Kattavan telemetrian saavuttamiseksi pilvi-infrastruktuurissa tarvitaan agenttipohjainen keräys sovellustasolle, OpenTelemetry-standardin mukainen instrumentointi jälkien keräämiseen sekä keskitetty lokienhallinta, joka kokoaa hajautettujen palveluiden lokit yhteen paikkaan.
Hybridit ja on-prem-ympäristöt
Hybridit ympäristöt ovat telemetrian keräämisen kannalta haastavimpia, koska data syntyy useissa eri paikoissa eri formaateissa. Windows- ja Linux-palvelimet, verkkolaitteet ja IoT-sensorit voivat kaikki tuottaa dataa eri protokollia käyttäen. Tässä auttavat välitasot, kuten Edge Hub -tyyppiset ratkaisut, jotka normalisoivat ja suodattavat dataa paikallisesti ennen sen lähettämistä keskitettyyn analytiikkaympäristöön.
Käytännön nyrkkisääntö hybridittelemetrialle: kerää ensin se, mitä on helppo kerätä, mutta varmista, että keräysarkkitehtuuri tukee myöhempää laajentamista ilman suuria rakenteellisia muutoksia.
OpenTelemetry standardina
OpenTelemetry on avoin standardi, joka on noussut de facto -ratkaisuksi telemetrian keräämiseen myyjäriippumattomalla tavalla. Se tukee metriikoita, lokeja ja jälkiä yhden instrumentointikerroksen kautta ja mahdollistaa datan lähettämisen useisiin eri analytiikkatyökaluihin ilman, että sovelluskoodia tarvitsee muuttaa. Tämä on merkittävä etu, koska se vähentää toimittajasidonnaista riskiä.
Infrastruktuurin yleisimmät telemetriaongelmat ja niiden tunnistaminen
Vaikka telemetrian kerääminen on teknisesti mahdollista lähes kaikissa ympäristöissä, organisaatiot törmäävät toistuvasti samoihin ongelmiin. Näiden tunnistaminen etukäteen auttaa rakentamaan kestävämmän observability-käytännön.
Hälytysten tulva ja signaalin kadottaminen
Yksi yleisimmistä ongelmista on se, että metriikoihin perustuvia hälytyksiä on liikaa. Kun jokainen pieni poikkeama laukaisee hälytyksen, on-call-tiimit turtuvat nopeasti ja alkavat sivuuttaa ilmoituksia. Tämä on vaarallista, koska kriittiset hälytykset hukkuvat kohinaan. Ratkaisuna on adaptiiviset kynnysarvot, jotka ottavat huomioon normaalit vaihtelut, sekä hälytysten priorisointi liiketoimintavaikutuksen mukaan.
Datan hajanaisuus eri työkaluissa
Monissa organisaatioissa metriikat, lokit ja jäljet ovat eri järjestelmissä, jotka eivät kommunikoi keskenään. Tällöin ongelman tutkiminen vaatii manuaalista tietojen yhdistelyä useista käyttöliittymistä, mikä hidastaa ratkaisemista merkittävästi. Infrastruktuurin observability kärsii erityisesti silloin, kun pilviympäristön metriikat ovat yhdessä paikassa ja on-prem-palvelimien lokit toisessa.
Puuttuva liiketoimintakonteksti
Tekninen telemetria kertoo, että palvelin on ylikuormittunut, mutta ei sitä, kuinka moneen asiakkaaseen tämä vaikuttaa tai kuinka paljon liikevaihto kärsii joka minuutti. Tämä kontekstin puute vaikeuttaa priorisointia ja tekee vaikeaksi perustella investointeja observability-infrastruktuuriin liiketoimintajohdolle. Liiketoimintametriikoiden, kuten tilausten määrän tai maksusuoritusten onnistumisprosentin, yhdistäminen tekniseen telemetriaan on yksi tärkeimmistä kypsyyden merkeistä.
Datan säilytyksen hallitsemattomuus
Telemetriadata kasvaa nopeasti. Ilman selkeitä säilytys- ja arkistointikäytäntöjä kustannukset nousevat ja järjestelmät hidastuvat. Hyvä käytäntö on määritellä eri signaalityypeille eri säilytysajat: korkean resoluution metriikat voidaan säilyttää lyhyemmän ajan, kun taas lokit ja jäljet kriittisistä tapahtumista tarvitsevat pidemmän arkiston.
Yhtenäinen observability-strategia infrastruktuurille
Rakentaen edellä käytyjen käsitteiden pohjalta voidaan nyt hahmottaa, mitä yhtenäinen observability-strategia infrastruktuurille tarkoittaa käytännössä. Kyse ei ole yksittäisten työkalujen käyttöönotosta, vaan siitä, miten metriikat, lokit ja jäljet yhdistetään toimivaksi kokonaisuudeksi, joka palvelee sekä teknisiä tiimejä että liiketoimintaa.
Strategian rakentaminen kannattaa aloittaa use caseista, ei teknologiavalinnoista. Mitkä ovat ne tilanteet, joissa näkyvyyden puute aiheuttaa eniten vahinkoa? Onko se tuotantolinjan seisokit, verkkokaupan hitaus huipputuntien aikana vai maksupalvelun häiriöt? Kun käyttötapaukset ovat selvillä, voidaan valita oikeat signaalityypit ja rakentaa dashboardit, jotka vastaavat juuri näihin kysymyksiin.
Yhtenäinen observability-strategia sisältää tyypillisesti neljä kerrosta:
- Keräyskerros: agentit, OpenTelemetry-instrumentointi ja integraatiot, jotka tuovat metriikat, lokit ja jäljet yhteen paikkaan
- Normalisointikerros: datan puhdistus, deduplikointi ja korrelointi, jotta eri lähteistä tuleva data on vertailukelpoista
- Analytiikkakerros: dashboardit, anomalioiden tunnistus ja hälytykset, jotka muuttavat raakadatan toimintakelpoiseksi tiedoksi
- Toimintakerros: prosessit ja työnkulut, jotka varmistavat, että oikeat ihmiset saavat oikean tiedon oikeaan aikaan
Strategian kypsyys näkyy siinä, kuinka nopeasti tiimisi pystyy vastaamaan kysymykseen: miksi tämä ongelma tapahtui ja kenen pitää korjata se? Jos vastaus vaatii tunteja manuaalista tutkimusta, observability-käytäntö on vielä reaktiivinen. Jos vastaus löytyy minuuteissa korreloitujen signaalien avulla, ollaan proaktiivisen infrastruktuurin hallinnan alueella.
Käytännön esimerkkinä toimii infrastruktuurin observabilityn toimintaperiaate, jossa metriikat, lokit ja jäljet yhdistetään yhtenäiseksi näkymäksi, joka mahdollistaa sekä reaaliaikaisen reagoinnin että pitkäaikaisen optimoinnin. Tämä on se taso, johon kannattaa tähdätä, kun organisaatio rakentaa kestävää observability-strategiaa.
Jos haluat arvioida, missä kohtaa oman infrastruktuurisi observability-kypsyys tällä hetkellä on ja mitä seuraava askel voisi olla, ota yhteyttä tiimiimme ja aloitetaan keskustelu siitä, millainen observability-ratkaisu sopii juuri teidän ympäristöönne.