Infrastruktuurin valvonta on muuttunut viime vuosina merkitt\u00e4v\u00e4sti. Yksitt\u00e4isten palvelimien seuranta on v\u00e4istynyt hajautettujen pilvi-infrastruktuurien, mikropalveluiden ja kontaineroitujen ymp\u00e4rist\u00f6jen tielt\u00e4. Samalla on kasvanut tarve ymm\u00e4rt\u00e4\u00e4, mit\u00e4 j\u00e4rjestelmiss\u00e4 todella tapahtuu, ei ainoastaan silloin, kun jokin menee pieleen, vaan jatkuvasti ja ennakoivasti. T\u00e4h\u00e4n tarpeeseen vastaavat metriikat, lokit ja j\u00e4ljet, jotka yhdess\u00e4 muodostavat modernin observability-k\u00e4yt\u00e4nn\u00f6n perustan.<\/p>\n
T\u00e4ss\u00e4 artikkelissa k\u00e4ymme l\u00e4pi n\u00e4m\u00e4 kolme telemetrian pilaria alusta alkaen: mit\u00e4 ne tarkoittavat, miten ne t\u00e4ydent\u00e4v\u00e4t toisiaan, miten telemetriaa ker\u00e4t\u00e4\u00e4n k\u00e4yt\u00e4nn\u00f6n infrastruktuuriymp\u00e4rist\u00f6iss\u00e4 ja mitk\u00e4 ovat yleisimm\u00e4t ongelmat, joihin organisaatiot t\u00f6rm\u00e4\u00e4v\u00e4t. Lopuksi katsomme, miten n\u00e4m\u00e4 osat yhdistet\u00e4\u00e4n toimivaksi observability-strategiaksi.<\/p>\n
Infrastruktuurin telemetria tarkoittaa kaikkea sit\u00e4 dataa, jota j\u00e4rjestelm\u00e4t tuottavat itsest\u00e4\u00e4n toimintansa aikana. T\u00e4m\u00e4 data jaetaan kolmeen selke\u00e4sti erilaiseen signaalityyppiin: metriikoihin, lokeihin ja j\u00e4lkiin. Jokainen niist\u00e4 kertoo eri asioita, ja yhdess\u00e4 ne antavat kokonaiskuvan siit\u00e4, mit\u00e4 infrastruktuurissa tapahtuu.<\/p>\n
Metriikat ovat numeerisia mittauksia, joita ker\u00e4t\u00e4\u00e4n s\u00e4\u00e4nn\u00f6llisesti ajan kuluessa. Tyypillisi\u00e4 esimerkkej\u00e4 ovat CPU:n k\u00e4ytt\u00f6aste, muistin kulutus, verkkoliikenteen m\u00e4\u00e4r\u00e4, levyn I\/O ja palvelupyynt\u00f6jen vasteaika. Metriikat ovat tehokkaita, koska ne ovat kevyit\u00e4 tallentaa, helppo visualisoida ja soveltuvat hyvin h\u00e4lytysten perustaksi.<\/p>\n
Hyv\u00e4 analogia on auton mittaristo: nopeusmittari, polttoainemittari ja moottorin l\u00e4mp\u00f6tila kertovat ajotilanteen tilan yhdell\u00e4 silm\u00e4yksell\u00e4. Ne eiv\u00e4t kerro, miksi polttoaine loppuu tai miksi moottori ylikuumenee, mutta ne kertovat selv\u00e4sti, ett\u00e4 jotain on vialla.<\/p>\n
Lokit ovat aikaleimattuja tekstimuotoisia tapahtumamerkint\u00f6j\u00e4, joita sovellukset ja infrastruktuurin komponentit kirjoittavat toimintansa aikana. Ne voivat kertoa, milloin k\u00e4ytt\u00e4j\u00e4 kirjautui sis\u00e4\u00e4n, milloin tietokantayhteys katkesi tai mik\u00e4 virhekoodi palautti ep\u00e4onnistuneen pyynn\u00f6n. Toisin kuin metriikat, lokit ovat rikkaita yksityiskohtia t\u00e4ynn\u00e4, mutta niit\u00e4 syntyy suuria m\u00e4\u00e4ri\u00e4 ja niiden l\u00e4pik\u00e4yminen manuaalisesti on hidasta.<\/p>\n
Lokit ovat infrastruktuurin observabilityn muisti. Kun jokin menee pieleen, lokit kertovat tarkalleen, mit\u00e4 tapahtui ja miss\u00e4 j\u00e4rjestyksess\u00e4.<\/p>\n
J\u00e4ljet, englanniksi traces, kuvaavat yksitt\u00e4isten pyynt\u00f6jen tai tapahtumien kulkua j\u00e4rjestelm\u00e4n l\u00e4pi alusta loppuun. Modernissa mikropalveluarkkitehtuurissa yksi k\u00e4ytt\u00e4j\u00e4n toiminto saattaa kulkea kymmenen eri palvelun kautta. J\u00e4ljet n\u00e4ytt\u00e4v\u00e4t t\u00e4m\u00e4n polun ja paljastavat, miss\u00e4 kohdassa viive kasvaa tai miss\u00e4 pyynt\u00f6 katkeaa.<\/p>\n
Jos metriikat ovat auton mittaristo ja lokit ovat huoltokirja, j\u00e4ljet ovat GPS-j\u00e4ljitys, joka n\u00e4ytt\u00e4\u00e4 t\u00e4sm\u00e4lleen, mit\u00e4 reitti\u00e4 auto kulki ja miss\u00e4 se hidastui.<\/p>\n
Metriikat, lokit ja j\u00e4ljet eiv\u00e4t ole kilpailevia vaan toisiaan t\u00e4ydent\u00e4vi\u00e4 signaalityyppej\u00e4. Tehokas infrastructure telemetry perustuu siihen, ett\u00e4 n\u00e4m\u00e4 kolme l\u00e4hdett\u00e4 toimivat yhdess\u00e4, ei erill\u00e4\u00e4n.<\/p>\n
Ajatellaan konkreettista tilannetta: verkkokaupan vasteajat kasvavat \u00e4killisesti. Metriikat havaitsevat ongelman ensimm\u00e4isen\u00e4, koska vasteaikamittari ylitt\u00e4\u00e4 normaalin kynnysarvon ja h\u00e4lytys laukeaa. T\u00e4ss\u00e4 vaiheessa tied\u00e4t, ett\u00e4 jotain on vialla, mutta et viel\u00e4 tied\u00e4 miss\u00e4 tai miksi. Seuraavaksi k\u00e4\u00e4nnyt lokien puoleen: niist\u00e4 n\u00e4et, ett\u00e4 tietokantayhteydet alkavat tuottaa virheit\u00e4 juuri ennen vasteaikojen kasvua. Lopuksi j\u00e4ljet paljastavat, ett\u00e4 ongelma ei ole tietokannassa itsess\u00e4\u00e4n, vaan yhdess\u00e4 mikropalvelussa, joka tekee tarpeettoman monta tietokantakysely\u00e4 silmukassa.<\/p>\n
Ilman kaikkia kolmea pilaria t\u00e4m\u00e4 tutkintaprosessi olisi huomattavasti hitaampaa. Metriikat ilman lokeja kertovat, ett\u00e4 ongelma on olemassa, mutta eiv\u00e4t miss\u00e4. Lokit ilman j\u00e4lki\u00e4 n\u00e4ytt\u00e4v\u00e4t virheit\u00e4, mutta eiv\u00e4t niiden alkuper\u00e4\u00e4 hajautetussa j\u00e4rjestelm\u00e4ss\u00e4. J\u00e4ljet ilman metriikkoja eiv\u00e4t h\u00e4lyt\u00e4 ongelmasta ajoissa. Yhdess\u00e4 ne lyhent\u00e4v\u00e4t merkitt\u00e4v\u00e4sti aikaa, joka kuluu ongelman havaitsemisesta sen ratkaisemiseen.<\/p>\n
Telemetrian ker\u00e4\u00e4minen riippuu siit\u00e4, mink\u00e4laisessa ymp\u00e4rist\u00f6ss\u00e4 infrastruktuuri toimii. Hybridit, pilvinatiiviit ja perinteiset on-prem-ymp\u00e4rist\u00f6t asettavat kukin omat vaatimuksensa datan ker\u00e4\u00e4miselle.<\/p>\n
AWS:ss\u00e4, 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\u00e4 n\u00e4m\u00e4 natiivit metriikat kattavat vain alustakerroksen, eiv\u00e4t sovellustasoa tai liiketoimintaprosesseja.<\/p>\n
Kattavan telemetrian saavuttamiseksi pilvi-infrastruktuurissa tarvitaan agenttipohjainen ker\u00e4ys sovellustasolle, OpenTelemetry-standardin mukainen instrumentointi j\u00e4lkien ker\u00e4\u00e4miseen sek\u00e4 keskitetty lokienhallinta, joka kokoaa hajautettujen palveluiden lokit yhteen paikkaan.<\/p>\n
Hybridit ymp\u00e4rist\u00f6t ovat telemetrian ker\u00e4\u00e4misen 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\u00e4ytt\u00e4en. T\u00e4ss\u00e4 auttavat v\u00e4litasot, kuten Edge Hub -tyyppiset ratkaisut, jotka normalisoivat ja suodattavat dataa paikallisesti ennen sen l\u00e4hett\u00e4mist\u00e4 keskitettyyn analytiikkaymp\u00e4rist\u00f6\u00f6n.<\/p>\n
K\u00e4yt\u00e4nn\u00f6n nyrkkis\u00e4\u00e4nt\u00f6 hybridittelemetrialle: ker\u00e4\u00e4 ensin se, mit\u00e4 on helppo ker\u00e4t\u00e4, mutta varmista, ett\u00e4 ker\u00e4ysarkkitehtuuri tukee my\u00f6hemp\u00e4\u00e4 laajentamista ilman suuria rakenteellisia muutoksia.<\/p>\n
OpenTelemetry on avoin standardi, joka on noussut de facto -ratkaisuksi telemetrian ker\u00e4\u00e4miseen myyj\u00e4riippumattomalla tavalla. Se tukee metriikoita, lokeja ja j\u00e4lki\u00e4 yhden instrumentointikerroksen kautta ja mahdollistaa datan l\u00e4hett\u00e4misen useisiin eri analytiikkaty\u00f6kaluihin ilman, ett\u00e4 sovelluskoodia tarvitsee muuttaa. T\u00e4m\u00e4 on merkitt\u00e4v\u00e4 etu, koska se v\u00e4hent\u00e4\u00e4 toimittajasidonnaista riski\u00e4.<\/p>\n
Vaikka telemetrian ker\u00e4\u00e4minen on teknisesti mahdollista l\u00e4hes kaikissa ymp\u00e4rist\u00f6iss\u00e4, organisaatiot t\u00f6rm\u00e4\u00e4v\u00e4t toistuvasti samoihin ongelmiin. N\u00e4iden tunnistaminen etuk\u00e4teen auttaa rakentamaan kest\u00e4v\u00e4mm\u00e4n observability-k\u00e4yt\u00e4nn\u00f6n.<\/p>\n
Yksi yleisimmist\u00e4 ongelmista on se, ett\u00e4 metriikoihin perustuvia h\u00e4lytyksi\u00e4 on liikaa. Kun jokainen pieni poikkeama laukaisee h\u00e4lytyksen, on-call-tiimit turtuvat nopeasti ja alkavat sivuuttaa ilmoituksia. T\u00e4m\u00e4 on vaarallista, koska kriittiset h\u00e4lytykset hukkuvat kohinaan. Ratkaisuna on adaptiiviset kynnysarvot, jotka ottavat huomioon normaalit vaihtelut, sek\u00e4 h\u00e4lytysten priorisointi liiketoimintavaikutuksen mukaan.<\/p>\n
Monissa organisaatioissa metriikat, lokit ja j\u00e4ljet ovat eri j\u00e4rjestelmiss\u00e4, jotka eiv\u00e4t kommunikoi kesken\u00e4\u00e4n. T\u00e4ll\u00f6in ongelman tutkiminen vaatii manuaalista tietojen yhdistely\u00e4 useista k\u00e4ytt\u00f6liittymist\u00e4, mik\u00e4 hidastaa ratkaisemista merkitt\u00e4v\u00e4sti. Infrastruktuurin observability k\u00e4rsii erityisesti silloin, kun pilviymp\u00e4rist\u00f6n metriikat ovat yhdess\u00e4 paikassa ja on-prem-palvelimien lokit toisessa.<\/p>\n
Tekninen telemetria kertoo, ett\u00e4 palvelin on ylikuormittunut, mutta ei sit\u00e4, kuinka moneen asiakkaaseen t\u00e4m\u00e4 vaikuttaa tai kuinka paljon liikevaihto k\u00e4rsii joka minuutti. T\u00e4m\u00e4 kontekstin puute vaikeuttaa priorisointia ja tekee vaikeaksi perustella investointeja observability-infrastruktuuriin liiketoimintajohdolle. Liiketoimintametriikoiden, kuten tilausten m\u00e4\u00e4r\u00e4n tai maksusuoritusten onnistumisprosentin, yhdist\u00e4minen tekniseen telemetriaan on yksi t\u00e4rkeimmist\u00e4 kypsyyden merkeist\u00e4.<\/p>\n
Telemetriadata kasvaa nopeasti. Ilman selkeit\u00e4 s\u00e4ilytys- ja arkistointik\u00e4yt\u00e4nt\u00f6j\u00e4 kustannukset nousevat ja j\u00e4rjestelm\u00e4t hidastuvat. Hyv\u00e4 k\u00e4yt\u00e4nt\u00f6 on m\u00e4\u00e4ritell\u00e4 eri signaalityypeille eri s\u00e4ilytysajat: korkean resoluution metriikat voidaan s\u00e4ilytt\u00e4\u00e4 lyhyemm\u00e4n ajan, kun taas lokit ja j\u00e4ljet kriittisist\u00e4 tapahtumista tarvitsevat pidemm\u00e4n arkiston.<\/p>\n
Rakentaen edell\u00e4 k\u00e4ytyjen k\u00e4sitteiden pohjalta voidaan nyt hahmottaa, mit\u00e4 yhten\u00e4inen observability-strategia infrastruktuurille tarkoittaa k\u00e4yt\u00e4nn\u00f6ss\u00e4. Kyse ei ole yksitt\u00e4isten ty\u00f6kalujen k\u00e4ytt\u00f6\u00f6notosta, vaan siit\u00e4, miten metriikat, lokit ja j\u00e4ljet yhdistet\u00e4\u00e4n toimivaksi kokonaisuudeksi, joka palvelee sek\u00e4 teknisi\u00e4 tiimej\u00e4 ett\u00e4 liiketoimintaa.<\/p>\n
Strategian rakentaminen kannattaa aloittaa use caseista, ei teknologiavalinnoista. Mitk\u00e4 ovat ne tilanteet, joissa n\u00e4kyvyyden puute aiheuttaa eniten vahinkoa? Onko se tuotantolinjan seisokit, verkkokaupan hitaus huipputuntien aikana vai maksupalvelun h\u00e4iri\u00f6t? Kun k\u00e4ytt\u00f6tapaukset ovat selvill\u00e4, voidaan valita oikeat signaalityypit ja rakentaa dashboardit, jotka vastaavat juuri n\u00e4ihin kysymyksiin.<\/p>\n
Yhten\u00e4inen observability-strategia sis\u00e4lt\u00e4\u00e4 tyypillisesti nelj\u00e4 kerrosta:<\/p>\n
Strategian kypsyys n\u00e4kyy siin\u00e4, kuinka nopeasti tiimisi pystyy vastaamaan kysymykseen: miksi t\u00e4m\u00e4 ongelma tapahtui ja kenen pit\u00e4\u00e4 korjata se? Jos vastaus vaatii tunteja manuaalista tutkimusta, observability-k\u00e4yt\u00e4nt\u00f6 on viel\u00e4 reaktiivinen. Jos vastaus l\u00f6ytyy minuuteissa korreloitujen signaalien avulla, ollaan proaktiivisen infrastruktuurin hallinnan alueella.<\/p>\n
K\u00e4yt\u00e4nn\u00f6n esimerkkin\u00e4 toimii infrastruktuurin observabilityn toimintaperiaate<\/a>, jossa metriikat, lokit ja j\u00e4ljet yhdistet\u00e4\u00e4n yhten\u00e4iseksi n\u00e4kym\u00e4ksi, joka mahdollistaa sek\u00e4 reaaliaikaisen reagoinnin ett\u00e4 pitk\u00e4aikaisen optimoinnin. T\u00e4m\u00e4 on se taso, johon kannattaa t\u00e4hd\u00e4t\u00e4, kun organisaatio rakentaa kest\u00e4v\u00e4\u00e4 observability-strategiaa.<\/p>\n