Azure-sovelluksesi alkaa olemaan valmis. Viimeinen mieltä painava asia on miten sovellusta pitäisi tuotannossa valvoa? Onko suorituskyky ja vasteajat kohdallaan? Miten saan ilmoituksen kun jotain menee pieleen? Tämä artikkeli on pieni johdanto näihin aiheisiin.
Lyhyesti
Alla oleva kuva esittää miten valvonta toteutetaan Azuressa. Lähes kaikki eri valmistajien valvontasovellukset toimivat saman periaatteen mukaisesti – komponenttien nimet tietysti vaihtelevat valmistajan mukaan.
Kuva: Azuren valvonnan perusteet.
Kuvaa luetaan vasemmalta oikealle. Vasemmalla ovat järjestelmän tuottamat lokitiedostot, oikeassa reunassa taas näiden pohjalta tuotetut näkymät sekä toiminnot. Käydään putki läpi vaihe kerrallaan, aloitetaan lokien lähdejärjestelmistä.
Lokitiedostot
Valvonta perustuu lähdejärjestelmien tai -komponenttien tuottamiin lokitietoihin. Perinteisissä (virtuaali)koneisiin perustuvissa järjestemissä pystyit aina kirjautumaan sisään koneeseen, ja lataamaan lokitiedostot itsellesi ja tehdä niillä mitä haluat. Jos käytät Azuressa virtuaalikoneita pystyt tietysti tähän edelleenkin. Mikäli sovelluksesi on kuitenkin rakennettu moderneilla PaaS-komponenteilla kuten SQL-tietokanta, Web App, Logic App tai Functions sinulla ei ole enää konetta johon kirjautua! Tarina meneekin Azuressa seuraavasti:
Oletuslokit
Oletuslokeilla tarkoitetaan Azure-komponentin itse omasta toiminnastaan tuottamia lokitietoja. Jos kyseessä on virtuaalikone, oletuslokit sisältävät CPU käyttöastetietoja, levyjen i/o-lukemia, verkkoliikenteen määriä jne. PaaS palveluissa lokin sisältö vaihtelee resurssin mukaan; SQL-kannat tuottavat tietoa tietokannan lukitustilanteista, SQL-virheistä jne. Web App loki sisältää vasteaikoja, virheilmoituksia sekä http-statuskoodeja. Ja niin edelleen.
Näiden oletuslokien kerääminen on yleensä erityisen helppoa: Tyypillisesti laitat “kerää lokit automaattisesti” – vivun päälle, ja kerrot mihin sammioon haluat lokitiedot kasata (sinulla voi olla useampiakin tallennuspaikkoja jos näin haluat).
Muut lokit
Jos sovellustasi ajetaan Azuren virtuaalikoneessa, voit kerätä siellä ajettujen sovellusten lokit ottamalla käyttöön “custom log collectorin”. Esimerkkinä voisi olla vaikkapa virtuaalikoneella ajettava Apache, JBoss, Tomcat tai Nginx, jotka tuottavat määrämuotoista access, stdout ja stderr-lokeja. Haluat ehkä kerätä nämä talteen ja analysoida niitä keskitetyn monitoroinnin puolella.
Voit käytännössä lähettää Azureen lokidataa melkein mistä tahansa: Oman datacenterin virtuaalikoneista, VMWare-alustalta, konteista tai vaikka suoraan REST-apien kautta. Tämä ei kuulu tällä kertaa kuitenkaan blogin sisältöön.
Keskitetty lokivarasto
Järjestelmän ydin. Lokitietovarasto sijaitsee Azuressa, ja sen tehtävä on kerätä lokit kaikista haluamistasi lähteistä yhteen yhteiseen tallennuspaikkaan. Tällä hetkellä varastoa on kahta laatua: Log Analytics ja App Insights. Kaikki Azuren resurssit voivat tarvittaessa kirjoittaa lokinsa jompaan kumpaan näistä.
Log Analytics varastoi dataa, joka kertoo miten rauta käyttäytyy ja mitä käyttöjärjestelmätasolla tapahtuu. Juuri sitä samaa tietoa mitä perinteisissä maailmassa on kerätty kautta maailman sivun: CPU käyttöasteita, I/O -lukemia, Azure AD audit lokeja, windows syslokeja, event lokeja ja sen sellaisia.
App Insights varastoi sovelluksiin liittyvää lokidataa. Tätä varastoa käyttävät tyypillisesti Azuren PaaS-palvelut. Tämä lokidata voidaan vielä jakaa kahteen eri tyyppiin: 1) Paas palvelun itsensä tuottamat tiedot omasta toiminnastaan sekä 2) Sovelluksen sisältä kerättävä mittausdata. Sovellusmetriikka mahdollistaa sovelluksen koodin suorituskykyyn liittyvän profiloinnin sekä liiketoimintaan liittyvien mittaridatan kerääminen.
Ainoa ero Log Analyticsin ja App Insightsin välillä on tiedon tallennusrakenne (=schema) johon lokitiedot Azuressa tallennetaan.Log Analyticsin tietomallissa lokidata löytyy useimmiten LogManagement haaran alta, kun taas App Insightsin tietorakenne sopii paremmin PaaS-sovelluksille. Käyttäjät eivät voi itse muuttaa tallennusrakennetta – se tulee annettuna Microsoftilta.
Image: Log Analytics ja App Insights tallennusrakenne päätasolla.
Kyselyt
Nyt kun kaikki lokit ovat nätisti samassa paikassa, on aika käydä töihin. Lokien sisältöä voi kysellä Log Query – työkalulla. Kyseinen työkalu löytyy App Insightsin sisältä kohdasta Monitoring/Logs (Analytics), ja Log Analyticsin puolelta valinnalla General/Logs. Molemmat vievät sinut samaiseen kyselytyökaluun.
Kuva: Mistä kyselytyökalu löytyy Azuressa.
Voit kirjoittaa työkaluun kyselyn, ja saat vastauksena tiedot mitä juuri nyt tarvitsit. Näitä sanotaan AdHoc-kyselyiksi. Kyselyt tehdään SQL:n kaltaisella Kusto-kielellä. Jos kieli tuntuu aluksi vieraalta, työkalu tarjoaa kasoittain esimerkkikyselyitä, joiden avulla pääset varmasti alkuun.
Voit myös tallentaa kyselyn ja 1) ajaa sen myöhemmin uudelleen, tai 2) julkaista kyselyn tuloksen dashboardissa, tai 3) luoda kyselyn tulokseen perustuvan hälytyksen (alert).
Kyselyiden tulokset
Kysely palauttaa SQL-tyyliin joko listan (vaikkapa SecurityEvent-tiedot viimeisimmän tunnin ajalta), tai graafin (esim. pylväskaavio virheiden lukumäärästä tunneittain 24h tunnin ajalta), tai yksittäisen numeron (virheiden määrä viimeisen 10 min aikana).
Voit julkaista minkä tahansa kyselyn tuloksen dashboardiin klikkaamalla ylärivin “Pin to dashboard” – nappia. Tai voit luoda kyselyn tulokseen perustuvan hälytyksen “+New Alert” – napilla.
Näkymät ja toiminnot
Dashboard (suomeksi kojelauta?) näyttää järjestelmän tilaa ja toimintaa kuvaavat keskeiset tiedot. Dashboard kokoaa yleensä vertailutiedot annetulta ajanjaksolta – vaikkapa viimeisen vuorokauden aikana. Kun jotain on hajoamassa (esim. vasteajat näyttävät pitenevän päivän edetessä), hyvä dashboard pystyy etukäteen näyttämään tämän huolestuttavan trendin sekä tarjoamaan jopa suoran linkin, mistä kaivaa lisätietoja ja korjata ongelman.
Kuva: Dashboard-esimerkki.
Kenenkään ei tietenkään tarvitse kytätä näitä kojelautoja työkseen – siksi meillä on olemassa hälytykset (alerts). Voit luoda hälytyksen, joka laukeaa esimerkiksi kun virheiden määrä viimeisen tunnin aikana on yli viisi. Tai hälytyksen, joka varoittaa kun webbisovelluksen vasteaikojen keskiarvo on yli 5 sekuntia viimeisen 10 minutin ajalta.
Hälytykseen voidaan kytkeä myös toimintoja: Yksinkertaisimmillaan lähetä sähköposti annetulle vastaanottajaryhmälle. Tai vielä parempi: Korjaa tilanne automaattisesti. Hälytys voidaan laittaa kutsumaan webhookia, jonka takana oleva automaatio voi esimerkiksi lisätä uusia instansseja kasvanutta kuormaa tasaamaan. Tai jos vasteajat alkavat putoamaan virtuaalikoneessa – käynnistä virtuaalikone automaattisesti uudelleen.
Lopuksi…
Monitoroinnin toteutusta ei tietenkään hyvien devops-käytäntöjen mukaan tulisi jättää sovelluskehityksen viimeiseksi vaiheeksi. Testit tulisi lisätä osaksi devops-putkea jo aikaisessa kehitysvaiheessa, jolloin jokainen sovelluksen build (tai release) suorittaa testit automaattisesti. Näin teoriassa, yleinen käytäntö ei aina mene näin.
Jotta maailma olisi riittävän monimutkainen, Microsoft on parhaillaan uudelleenbrändäämässä valvontaan liittyvää tuoteperhettä uuden “Azure Monitor” nimen alle. Todellisuudessa tämän sateenvarjotermin alta löytyvät tällä hetkellä vanhat kunnon Log Analytics ja App Insights.
Monitoroinnin perusteet eivät juuri tämän kummallisempia ole. Ei kun kokeilemaan!
Leave A Comment