KARELIA-AMMATTIKORKEAKOULU
Tietojenkäsittely
Jarmo Kiiski
AZURE MONITOR: HÄLYTYKSET, RAPORTOINTI JA PARHAAT KÄYTÄNNÖT
Opinnäytetyö Kesäkuu 2021
OPINNÄYTETYÖ Kesäkuu 2021
Tietojenkäsittelyn koulutus
Tikkarinne 9 80200 JOENSUU
+358 13 260 600 (vaihde) Tekijä
Jarmo Kiiski Nimeke
Azure Monitor: Hälytykset, raportointi ja parhaat käytännöt Toimeksiantaja
Sebitti Oy Tiivistelmä
Opinnäytetyön tarkoituksena oli suunnitella ja toteuttaa toimeksiantajalle sovelluspalveli- men hälytys- ja raportointitoiminnot Azure Monitor -alustalla sekä lisätä tietämystä häly- tyksissä ja raportoinnissa käytetyistä palveluista. Toimeksiantajana opinnäytetyössä oli Sebitti Oy.
Teoriaosuudessa on käsitelty pilvipalvelumalleja ja pilvityyppejä, valvonta-käsitettä sekä Azure Monitor -alustan rakennetta yleisellä tasolla. Toimeksiannon hälytys- ja raportointi- toimintoihin liittyvät Azure Monitorin -palvelut on käsitelty syvällisemmin. Lisäksi teoria- osuudessa on katsaus valvonnan parhaista käytännöistä toimeksiannon näkökulmasta.
Raportissa on kuvattu hälytyssäännön ja viikkoraportin toteutuksen vaiheet. Hälytys- ja raportointitoiminnot toteutettiin Microsoft Azure -pilvipalvelun ja paikallisen laiteympäris- tön muodostamassa hybridipilvessä.
Opinnäytetyön esimerkit osoittavat, että koneoppimiseen pohjautuva dynaaminen häly- tyksen kynnysarvo on toimiva vaihtoehto hälytyssääntöjen käytössä ja Logic Apps -palve- lulla voidaan automatisoida tehtäviä ja toteuttaa resurssien välisiä integraatioita loogi- sessa sovelluksessa.
Kieli suomi
Sivuja 37 Liitteet
Liitesivumäärä Asiasanat
Azure Monitor, mittari, valvonta, hälytys
THESIS June 2021
Business Information Technology
Tikkarinne 9 80200 JOENSUU FINLAND
+ 358 13 260 600 (switchboard) Author
Jarmo Kiiski Title
Azure Monitor: Alerts, Reporting and best practices Commissioned by
Sebitti Oy Abstract
The purpose of the thesis was to plan and implement the application server's alarm and reporting functions on the Azure Monitor platform for the client and increase the knowledge about the services used in alarms and reporting. The client in the thesis was Sebitti Oy.
The theoretical part deals with cloud service models and cloud types, the concept of mon- itoring and the structure of the Azure Monitor platform at a general level. Azure Monitor's services related to the alert and reporting functions of the assignment have been consid- ered in more depth. In addition, the theory section provides an overview of best practices in monitoring from a perspective of assignment.
The report describes the steps of implementing the alarm rule and the weekly report. The alert and reporting functions were implemented in a hybrid cloud formed by the Microsoft Azure cloud service and the on-premises hardware environment.
The examples in the thesis show that a dynamic alarm threshold based on machine learn- ing is a viable option in the use of alarm rules and the Logic Apps service can automate tasks and implement integrations between resources in a logical application.
Language Finnish
Pages 37 Appendices
Pages of Appendices Keywords
Azure Monitor, metrics, monitor, alert
Sisältö
Lyhenteet ... 5
1 Johdanto ... 7
2 Pilvipalvelu ... 8
2.1 Mikä on pilvipalvelu ... 8
2.2 Pilvipalvelumallit ... 8
2.3 Pilvityypit ... 9
3 Valvonta ... 11
4 Azure Monitor ... 12
4.1 Rakenne ... 12
4.2 Tiedon lähteet ... 13
4.3 Tietovarastot ... 14
4.3.1 Toimintalokitiedot ... 14
4.3.2 Mittarilokitiedot ... 14
4.4 Toiminnot ... 15
4.4.1 Application Insights ... 16
4.4.2 Log Analytics ... 17
4.4.3 Logic Apps ... 18
4.4.4 Mittarihälytykset ... 19
5 Toimeksianto ... 21
6 Toteutus ... 21
6.1 Hälytykset ... 21
6.2 Viikkoraportti ... 25
7 Parhaat käytännöt ... 32
8 Tulokset ... 33
9 Pohdintaa ... 34
Lähteet ... 36
Lyhenteet
Azure Microsoftin pilvipalvelu.
Hälytys (Alert) Ilmoitus laiteympäristössä tai sovelluksessa tapahtu- neesta ongelmasta.
IaaS Infrastructure as a Service, pilvipalvelumalli, jossa asiakas vastaa virtuaalisista palvelimista ja laitteista sekä sovelluk- sista. Palvelutarjoaja vastaa alustoista.
Koontinäyttö (Dashboard) Käyttöliittymä, jolle on koottu valvontatietoa jär- jestelmien ja sovellusten tilasta.
KQL Kusto Query Language, Azuren vain luku -kyselykieli.
Liipaisin (Trigger) Ennalta määrätyn ehdon toteutuessa toiminnan käynnistävä tapahtuma.
Logiikkasovellus (Logic App) Logic Appsillä tehty työnkulkusovellus.
Logic Apps Palvelu työnkulkujen, joilla automatisoidaan ja integroidaan sovelluksia ja resursseja, luomiseen.
Log Analytics Lokitietojen analysointipalvelu.
Valvonta (Monitor) Tietoteknisten laitteiden, palveluiden ja sovellusten telemetriatietoihin perustuvaa seurantaa.
On-premises Paikallinen, käyttäjän ylläpitämä laiteympäristö.
PaaS Platform as a Sevice, pilvipalvelumalli, jossa palveluntarjoaja vastaa laiteympäristöstä ja käyttöjärjestelmistä. Asiakas vas- taa sovelluksista.
SaaS Software as a Service, pilvipalvelumalli, jossa asiakas ylläpi- tää sovellusta ja palveluntarjoaja vastaa alustoista, laitteista, käyttöjärjestelmistä ja sovelluksista.
Sovellus (Application) Tiettyyn tarkoitukseen kehitetty sovellus.
Tenant Organisaatiolle automaattisesti luotu säilö Azuressa, missä on tiedot asiakkaan pilvipalveluun liiteytyistä tilauksista ja käyttäjistä (2021h).
Tilaus (Subscription), asiakkaan käytössä oleva pilvipalvelun alusta tai palvelu (Microsoft 2021h).
Työnkulku (Workflow) Yhteenliitetyistä toiminnoista koostuva sovellus.
1 Johdanto
Pilvipalveluluista on tällä vuosikymmenellä kehittynyt monimutkainen kokoelma erilaisia pilvi- ja palvelumalleja. Pilvipalvelut tarjoavat kustannustehokkaita ratkai- suja palveluntarjoajien ylläpitämissä laiteympäristöissä. Käyttämällä pilvipalve- luita yritykset säästävät Investointi- ja ylläpitokustannuksista, mikä on ollut mer- kittävä syy siirtyä käyttämään pilvessä olevia palveluita. Pilvipalvelussa sovellukset ja resurssit voivat sijaita toisessa pilvipalveluissa ja paikallisissa lai- tetiloissa. Jotta erilaisissa ympäristöissä olevista sovelluksista ja resursseista saadaan hälytyksiä ja diagnostiikkatietoja ovat palveluntarjoajat kehittäneet omia ratkaisuja pilvipalveluissa tapahtuvaan valvontaan. (Cheshire 2020.)
Tämä opinnäytetyö liittyy Microsoft Azure -pilvipalvelun Azure Monitor -valvonta- palvelun käyttöön hälytyksissä ja raportoinnissa. Opinnäytetyön toimeksiantaja on oululainen ohjelmistoalan yritys Sebitti Oy, joka tekee ohjelmistotuotekehitystä kumppaneilleen. Toimeksiannossa suunnitellaan Reportronic-ohjelmistotuot- teelle sovelluspalvelimen suorituskykyvalvontaan hälytys- ja raportointitoiminnal- lisuus, joka toteutetaan Azure Monitor -ympäristössä.
Opinnäytetyön teoriaosuudessa käsitellään yleisesti pilvipalvelun käsitettä, pilvi- palvelumalleja ja valvontaa. Koska Microsoft Azure Monitor -alusta on laaja ko- konaisuus, Monitorin rakennetta käsitellään yleisellä tasolla. Toimeksiantoon liit- tyviä Monitorin palveluita tarkastellaan tarkemmin.
Opinnäytetyön toteutusosassa esitetään käytännön toteutukset ohjekirjamai- sesti. Toteutusosan jälkeen esitellään Azure Monitorin käyttöön liittyviä parhaita käytäntöjä. Tulokset ja pohdintaosassa käsitellään yleisesti huomioitavia asioita.
2 Pilvipalvelu
2.1 Mikä on pilvipalvelu
Pilvipalvelu on tietotekninen malli, jossa jaetut tietokoneresurssit, verkot, palveli- met, tietovarastot, sovellukset ja palvelut, ovat helposti saavutettavissa ja ylläpi- dettävissä Internetissä. Pilvi itsessään koostuu tuhansia tietokoneita sisältävien tietokonekeskusten verkosta, jotka ovat kytketty toisiinsa tietoliikenneverkolla.
(Ranjan, Chen, Wang & Benatallah 2017, luku 1.1.)
Sovellusten ja tietojen käytettävyys on kriittinen toiminto liiketoiminnalle. Pilvipal- veluille on ominaista korkea käytettävyys, joustavuus, vikasietoisuus ja toipumis- kyky. Lisäksi pilvipalvelu on kustannustehokas, koska pilvipalveluissa asiakkaan ei tarvitse investoida palvelimiin ja laitetiloihin. Asiakas vuokraa resurssit palve- luntarjoajalta tai maksaa pelkästä käytöstä. (Cheshire 2020.)
2.2 Pilvipalvelumallit
Infrastructure-as-a-Service
Infrastructure-as-a-Service eli IaaS-palvelumalli muodostuu itse konfiguroidusta ja ylläpidetystä IT-ympäristöstä pilvipalvelussa. IT-ympäristö koostuu virtuaali- sista palvelimista, verkkolaitteista ja muista tarvittavista IT-resursseista. Asiakas hallitsee laiteympäristöä pilvipalvelun käyttöliittymien ja työkaluohjelmien avulla ja vastaa ympäristön konfiguroinnista ja käytöstä, palveluntuottajan vastatessa alustoista. (Erl, Mahmood & Puttini 2013, luku 4.3.)
Platform-as-a-Service
Platform-as-a-Service eli PaaS-palvelumalli muodostuu palveluntuottajan tarjoa- masta ja konfiguroimasta toimintaympäristöstä, jossa asiakkaan ohjelmistot toi- mivat. Asiakas konfiguroi ja ylläpitää sovelluksiaan, palveluntuottajan vastatessa alustoista sekä laitteista ja käyttöjärjestelmistä. (Erl ym. 2013, luku 4.3.)
Software-as-a-Service
Software-as-a-Service eli SaaS-palvelumallissa palvelu on ohjelmisto, joka on laajan käyttäjäkunnan saatavilla. Hyvänä esimerkkinä toimii verkkokauppa tai sähköpostipalvelu. Asiakkaan ylläpitovastuu on rajoittunut ohjelmistoon, palve- luntoimittajan vastatessa järjestelmän ylläpidosta. (Erl ym. 2013, luku 4.3.)
Palveluntarjoajan ja asiakkaan ylläpitovastuutaulukossa kuviossa 1 esitetään pal- velumalleihin kuuluvat palveluiden ylläpitovastuut. Vihreä väri ilmaisee palvelun- tarjoajan ja harmaa väri asiakkaan ylläpitovastuuta palvelumallissa.
Kuvio 1. Ylläpitovastuut palvelumalleissa (Modi 2019).
2.3 Pilvityypit
Julkinen pilvi
Julkinen pilvi (Public cloud) on pilvipalvelualusta, joka sijaitsee palveluntarjoajan ylläpitämässä datakeskuksessa. Palveluntarjoaja ylläpitää datakeskusta ja pal- velun ostaja, asiakas, käyttää vain hankkimaansa palvelua. Julkisessa pilvessä kaikki toiminta tapahtuu pilvipalvelussa ilman integraatiota paikalliseen, on-pre- mises, datakeskukseen tai yksityiseen pilveen. Tunnettuja palveluntarjoajia ovet Azure, Amazon Web Services ja Google Cloud Platform. (De Tender ym. 2020, luku 1.)
Yksityinen pilvi
Yksityinen pilvi (Private cloud) on tietyn organisaation yksinomaiseen käyttöön tarkoitettu pilvipalvelu. Koska pilvi on yhden organisaation käytössä, ratkaisu on tietoturvallisempi kuin julkinen pilvi. (Ranjan ym. 2017, 1.4 The Cloud Architec- ture and Cloud Deployment Techniques.) Teknisesti ratkaisu voi olla paikallinen (on-premises) tai ulkopuolinen (off-premises) toteutus, organisaation itse tai kol- mannen osapuolen vastatessa ylläpidosta (Smooth & Nam 2011, luku 1).
Hybridipilvi
Hybridipilvi (Hybrid cloud) muodostuu lavean määritelmän mukaan perinteisestä IT-infrasta, yksityisestä pilvestä ja julkisesta pilvipalvelusta tai yksittäisistä julki- sen pilven palveluista. Tarkemman määritelmän mukaan hybridipilvi on julkisen ja yksityisen pilven muodostama kokonaisuus. (Trautman 2018, luku 1.)
Kuviossa 2 oleva lavean määritelmän mukainen hybridipilvi koostuu erilaisista palveluista, pilvistä ja paikallisesta laiteympäristöstä.
Kuvio 2. Lavean määritelmän mukainen hybridipilvi (Trautman 2018, luku 1).
Koska hybridipilvet voivat rakentua useiden palveluntarjoajien pilviympäristöistä, joissa ylläpitovastuut vaihtelevat, niiden rakentaminen ja hallinta voi olla hyvinkin haasteellista (Erl ym. 2013, luku 4.4).
Monipilvi
Monipilvi-toimintamalli (Multi-cloud) on usean pilvipalvelun muodostama koko- naisuus. Malli muodostuu useasta julkisesta pilvestä ja hybridipilvestä. (Trautman 2018, luku 1.) Mallilla haetaan mm. toimintavarmuutta. Jos palvelu ei ole käytet- tävissä oletuspilvessä, niin käytetään palvelua sieltä missä se on käytettävissä, sekä kustannustehokkuutta jaettaessa kuormaa palveluntarjoajien välillä (De Tender ym. 2020, luku 1).
3 Valvonta
Pilvipalveluiden yleistyessä ja monipuolistuessa on tärkeää, että järjestelmiä pys- tytään valvomaan, monitoroimaan, entistä tehokkaammin (Erl ym. 2013, luku 4.3). Tietojärjestelmien valvonnalla pyritään lisäämään toiminnan ennustetta- vuutta, ennakointia ja nopeampaa reagointia ongelmiin, tietoturvaa ja toiminnan tehokkuutta (Chakraborty & Karthikeyan 2019, luku 1).
Valvonta tuottaa valtavasti erilaisessa muodossa olevaa informaatiota. Jotta toi- minnan kannalta olennaiset tiedot, trendit ja tapahtumat löytyisivät, täytyy valvon- tatyökalujen kyetä suodattamaan tietoa valtavasta tietomäärästä, visualisoida tu- lokset tai olla yhdistettävissä visualisointipalveluun sekä tuottaa raportteja.
Lisäksi työkalujen tulee kyetä automaattisesti tehdä korjauksia, joko itse tai API- rajapinnan kautta toisella sovelluksella. (Chakraborty ym. 2019, luku 1.)
Valvonnalla saadaan oleellista tietoa siitä, miten erilaiset tapahtumat vaikuttavat järjestelmiin ja käyttäjiin (Copeland, Soh, Puca, Manning & Gollob 2015, luku 13) sekä palveluntarjoajalle ja asiakkaalle tärkeää tietoa siitä, että maksa-mitä-käy- tät-malli perustuu todelliseen käyttöön (Erl ym. 2013, luku 4.3). Ranjan ym. (2017) kirjoittavat monitoroinnin kolmesta tasosta; tiedonkeruu-, hallinta- ja arviointitaso, arviointitason ollessa ylin hallintotaso, missä tapahtuu kerätyn tiedon jälkikäsit- tely. Valvonnan tulisi toimia vähintään tiedonkeruu- ja hallintatasolla (Erl ym.
2013, luku 15).
4 Azure Monitor
4.1 Rakenne
Azuren Monitor on Microsoft Azure -pilvipalvelun valvonta-alusta, joka kerää, yh- distää ja analysoi pilvi ja paikallisesta ympäristöstä kerättävää infrastruktuuri- ja alustapalvelutietoa sekä palveluiden, kuten Application Insights ja Security Cen- ter, keräämää tietoa (Microsoft 2020a). Monitorissa valvonta voidaan jakaa pe- rustoimintojen valvontaan ja tapauskohtaiseen valvontaan. Perustoimintojen val- vonta kohdistuu Azuren oletuksena käytettävissä oleviin komponentteihin.
Tapauskohtaiseen valvontaan kuuluvat muut resurssit ja komponentit, mukaan lukien Azuren erikseen määriteltävät tai lisäkustannuksia aiheuttavat palvelut.
(De Tender ym. 2020, luku 1.) Valvonnan avulla pyritään maksimoimaan sovel- lusten ja palveluiden toimintaa ymmärtämällä niiden suoriutumista analysoimalla ja havaitsemalla kerätystä datasta ongelmia ja riippuvuuksia ja ennakoimalla mahdollisia tulevia ongelmia (Microsoft 2019a).
Azure Monitor koostuu kolmesta toiminnallisuudesta, jotka ovat tiedon lähteet, tietovarastot ja tiedon käsittelijät. Kuvio 3 esittää Monitorin ylätason kuvauksen,
jakaa tiedon lähteisiin, tietovarastoihin ja tiedon käsittelijöihin. Valvottavat resurs- sit, joista tietoa kerätään ovat kuviossa vasemmalla, tietovarastot keskellä ja tie- toja käsittelevät toiminnot oikealla (Microsoft 2019a).
Kuvio 3. Monitorin ylätason kuvaus (Microsoft 2019a).
4.2 Tiedon lähteet
Azure Monitor voi kerätä tietoa tuetuista sovelluksista, käyttöjärjestelmistä, pal- veluista ja alustapalveluista:
• Alustasta riippumattomien sovellusten suorituskykyyn ja toimintaan liitty- vät tiedot (Application monitoring data).
• Sovellusten alustana toimivien paikallisten ja pilvessä olevien palvelimien käyttöjärjestelmätietoja (Guest OS monitoring data).
• Azuren resurssien toimintaan liittyvää tietoa (Azure resource monitoring data).
• Azure-tilauksen hallinta- ja toimintatietoja sekä tietoja Azure-pilvipalvelun tilasta ja toiminnasta (Azure subscription monitoring data).
• Tenantin, esim. organisaation Azure Active Directory, toimintaan liittyvää tietoa (Azure tenant monitoring data). (Microsoft 2019a.)
Lisäksi Azure Monitoriin voidaan luoda mukautettuja valvontoja keräämällä loki- tietoja REST-asiakasohjelmista Data Collector -ohjelmointirajapintaa käyttäen (Microsoft 2020b).
4.3 Tietovarastot
4.3.1 Toimintalokitiedot
Azure Monitor Logs -palvelu, joka vuoteen 2019 tunnettiin Log Analytics nimellä (Microsoft 2019b), kerää ja ylläpitää Azuren pilvi- ja paikallisista resursseista mo- ninaista käyttöön ja suorituskykyyn liittyvää tietoa. Yhdistämällä nämä eri läh- teistä kerätyt valvontatiedot samalle alustalle niitä voidaan analysoida Azure Mo- nitorin työkaluilla. (Microsoft 2020c.)
Toimintalokit ovat tekstipohjaisia, vaihteleva rakenteisia tietueita, joiden keräämi- sen käynnistää erillinen tapahtuma (Gillespie 2020). Keräämällä tietoja samaan työtilaan, tiedoista voidaan monipuolisilla kyselyillä hakea, yhdistää ja analysoida valvontatietoja ja löytää esim. kriittisiä tapahtumasarjoja (Microsoft 2020c). Toi- mintalokeihin kerättyjen yksityiskohtaisten tietojen avulla voidaan selvittää tapah- tumien juurisyitä. (Gillespie 2020).
4.3.2 Mittarilokitiedot
Suorituskykymittarit (metrics) ovat tärkein Azuren keräämistä telemetria tiedoista (De Tender ym. 2020, luku 1). Azure Monitor Metrics kerää järjestelmän toimin- taan, suorituskykyyn, liittyvää numeerista tietoa valvottavista resursseista (Micro- soft 2021a). Mittarit ovat säännöllisin väliajoin kerättyä yksilöityä numeerista tie- toa järjestelmän tilasta tiettynä ajankohtana. Mittaritieto koostuu aikaleimasta, nimestä, arvosta ja vähintään yhdestä nimikkeestä (label). (Zaal 2020, luku 1.) Tietojen keräysaikaväli on säädettävissä, oletusarvon ollessa yksi minuutti (Mic- rosoft 2021a). Tiedot tallennetaan aikaleimatun tiedon analysointiin optimoituun
tietokantaan (Zaal 2020, luku 1). Mittaritietojen säilytysaika on yleensä 93 päivää (Microsoft 2019c).
Koska mittaritiedoilla saadaan lähes reaaliaikainen näkymä resursseihin, niitä voidaan käyttää hälytyksiin ja ongelmien nopeaan havaitsemiseen (Zaal 2020, luku 1). Hälytysten lisäksi mittaritietoja voidaan mm. analysoida, vertailla ja visu- alisoida kiinnittämällä kaavioita koontinäytölle ja työkirjaan Metrics explorerilla (Microsoft 2021a). Metrics explorer on toiminto mittaritietojen analysointiin ja graafiseen esittämiseen (2019c).
Yhteenvetotaulukko kuviossa 4 esittää toimintaloki- ja mittaritietojen eroavaisuu- det.
Kuvio 4. Lokitietojen eroavaisuudet (Gillespie 2020).
4.4 Toiminnot
Tietojen keräämisestä ei ole hyötyä, jos niillä ei saada lisää tietämystä järjestel- mien toiminnasta. Azure Monitorissa on useita toimintoja kerättyjen tietojen kä- sittelemiseen. Toimintojen avulla saadaan lisää ymmärrystä järjestelmien ja so- vellusten toimintaan, voidaan ennakoida mahdollisia ongelmia ja reagoida nopeammin ongelmiin. (Microsoft 2019a.)
• Insights-toiminnoilla valvotaan sovellusten (Application Insights), virtuaali- palvelimien (VM) ja säilöjen (Container) suorituskykyä ja saavutettavuutta (Microsoft 2019a).
• Visualize-toiminnoilla voidaan esittää tiedoista yhteenveto kaavioita ja tau- lukkoja koottuna koontinäytöille (Dashboard), yhdistää tietolähteitä ja luoda työkirjoja (Workbooks) sekä siirtää lokitietoja ja visualisoida ne Po- werBI-palvelussa (Microsoft 2019a).
• Analyze-toiminnoilla voidaan hakea, yhdistää ja analysoida tietoja (Log Analytics) (Microsoft 2019a) ja esittää, vertailla ja havainnollistaa eri läh- teiden tietoja kaavioissa (Metrics Explorer) (Microsoft 2019a).
• Respond-toiminoilla voidaan reagoida ennakoivasti kriittisiin tilanteisiin ja ongelmiin, hälyttämällä ongelmista esim. sähköpostilla (Alerts) ja automa- tisoimalla toimintoja, tekemällä sääntöjä resurssien automaattiseen skaa- lautumiseen (Autoscaling) (Microsoft 2019a).
• Integrate-toiminoilla voidaan automatisoida prosesseja työnkuluilla, joissa yhdistetään eri järjestelmiä ja palveluja (Logic Apps), ja rakentaa omia so- velluksia hälytys- ja lokitietojen siirtoon rajapintoja käyttäen (Export APIs) (Microsoft 2019a).
4.4.1 Application Insights
Tietotekniset ratkaisut ovat usein hajautettuja ratkaisuja. Hajautetussa ratkai- sussa tietojärjestelmä voi olla asennettuna usealle palvelimelle paikallisessa ko- nehuoneessa, pilvessä tai pilven ja paikallisen konehuoneen muodostamassa hybridiratkaisussa. Sovellukset voivat olla asennettuna usealle palvelimelle ko- nesalissa, pilvessä sekä pilvessä ja konesalissa. Hajautetun ratkaisun tehokas valvonta edellyttää sovelluksen suorituskyvyn hallintapalvelun, Application Per- formance Management (APM), käyttöä. (Chilberto, Zaal, Aroraa & Price 2020, luku 4.)
Azure-pilvipalvelussa sovellusten suorituskykyä valvotaan Application Insights - palvelulla (Chilberto ym. 2020, luku 4). Application Insights -palvelulla saadaan tarkkaa tietoa sovellusten toiminnasta ja löydetään sovelluksissa ilmeneviä suo- rituskyky ja saatavuus ongelmia. Sovelluksista kerättyjä tietoja voidaan mm. esit- tää koontinäytössä, analysoida PowerBIssä ja käyttää hälytysten pohjana.
(Chakraborty ym. 2019, luku 2.)
Application Insighs -palvelulla voidaan valvoa mm. .Net, Java, Node.JS ja Phyto- nilla kehitettyjä sovelluksia. Mobiilisovellusten valvonta ja hallinta onnistuu Visual Studio app center -integraation avulla. DevOps-integraatioon kautta Application
Insights on yhdistettävissä useisiin kehittämistyökaluihin. Palvelu kerää myös so- velluksen palvelimen (Windows, Linux) suorituskykytietoja, mihin perustuen voi- daan määrittää hälytyksiä. (Microsoft 2019d.)
Application Insights otetaan käyttöön instrumentoimalla valvottava sovellus. Inst- rumentoinnissa sovellukseen asennetaan hallintapaketti (SDK) tai Azuren tuke- missa sovelluksissa aktivoidaan Application Insights Agentti. Instrumentointi ke- rää sovelluksesta tietoja, jotka yksilöidään GUID-numerolla (Instumentation Key), ja välittää ne Application Insights -palvelulle. (Microsoft 2019d.) Application In- sightsin käyttö ei rajoita toimimista hybridipilvessä, sillä kolmansien osapuolien instrumentointipakettien asentaminen Azuressa toimiviin sovelluksiin ei ole rajoi- tettu (Chakraborty ym. 2019, luku 2).
4.4.2 Log Analytics
Laitteistot ja sovellukset synnyttävät tietoa lokeihin lähes kaikista tapahtumista tietoteknisessä ympäristössä. Lokeihin kerätty tieto järjestelmien tapahtumista, prosesseista ja ilmoituksista on tärkeä osa ongelmien nopeassa ratkaisemisessa ja sovellusten katkeamattomassa toiminnassa. (Gillespie 2020.)
Log Analytics -palvelulla käsitellään Microsoft Azuressa Monitor Logsin ylläpitä- miä toimintalokitietoja. Log Analyticsissä voidaan muokata ja suorittaa lokiky- selyitä, joiden tuloksia voidaan analysoida ja käsitellä Log Analyticsin toiminnoilla tai käyttää tuloksia Azure Monitorin toisissa palveluissa, esim. tehdä niistä häly- tyssääntöjä tai esittää työkirjoissa. Lokikyselyillä voidaan tehdä myös vaativia ti- lastollisia analyysejä. (Microsoft 2020d.)
Log Analytics kerää Azuren ja paikallisten resurssien telemetriatiedot Log Analy- tics työtilaan (Hargreaves ym. 2020, luku 1). Työtila, joita voi olla useita, on luo- tava ennen tietojen keräämistä. Jokaisella työtilalla on oma konfiguraatio, jossa on määritelty työtilan tietolähteet ja muut työtilaan liittyvät määritykset. (Microsoft 2021b.) Kun useasta lähteestä kerätyt tiedot yhdistetään samaan työtilaan, voi-
daan niihin kohdistaa hakuja, yhdistää haetut tiedot ja analysoida hakujen tulok- set (Microsoft 2020d). Kokoamalla, yhdistämällä ja analysoimalla tietoja Log Ana- lytics lisää ymmärrystä tietoteknisestä ympäristöstä (Gillespie 2020).
Tietojen haku ja analysointi tapahtuu Kusto Query Languagella (KQL) (Hargrea- ves ym. 2020, luku 1). KQL on vain luku -kyselykieli (read-only) tietojen hakemi- seen, käsittelyyn ja tulosten tuottamiseen (Microsoft 2020e). Log Analyticsissä on valikoima valmiita kyselyjä eri tarkoituksiin. Kyselyitä voi muokata omiin tar- peisiin sopiviksi ja testata Log Analyticsissä. Kyselyt voi tallentaa ja visualisoida esim. kiinnittämällä kyselyn koontinäyttöön tai käyttää kyselyä hälytyssäännössä.
(Microsoft 2020d.)
Log Analytics käynnistetään Logs-valinnalla, mikä voidaan tehdä useassa eri kohdassa Azure Portalissa. Käytettävissä oleva lokitieto määräytyy käytettävän resurssin mukaan, esim. käytettäessä tietyssä työtilassa Logs-valintaa, käytössä on työtilaan liitettyjen resurssien valvontatiedot. (Microsoft 2020d.)
4.4.3 Logic Apps
Pilvipalveluiden yleistyessä tietotekniset ratkaisut ovat usein hybridiratkaisuja, jossa järjestelmät, palvelut ja sovellukset ovat hajautettuna pilveen sekä paikalli- seen laiteympäristöön. Palveluiden ja palvelumallien kehittymisen ja lisääntymi- sen seurauksena hajautettujen järjestelmien ja palveluiden yhdistäminen on muuttunut entistä haasteellisemmaksi. Azuressa hajautettujen järjestelmien ja palveluiden integroimiseen on joukko palveluita, joita kutsutaan Azure integraa- tiopalveluiksi (Azure Integation Services). (Mahendrakar & Kumar 2019.)
Logic Apps, joka on yksi Azure integraatiopalveluista, on palvelu tehtävien ja pro- sessien automatisointiin ja hallintaan sekä palveluiden, sovellusten ja järjestel- mien integrointiin Azure Monitorissa (Microsoft 2021c). Chilberto ym. (2020, luku 3) kuvaa Logic Appsia skaalautuvaksi iPaaS-palveluksi (Integration Platform as a Sevice).
Logic Apps on serverless-palvelu (Chilberto ym. 2020, luku 3). Serverless on käyttöön pohjautuva ratkaisu, jossa hyödynnetään pilvipalvelussa olevia ylimää- räisiä virtuaalipalvelimia, joita palveluntarjoaja on varannut asiakkaiden tarpeiden vaihtelun varalle. Ohjelma siirretään, suoritetaan ja lopuksi poistetaan virtuaali- palvelimelta ja käyttäjä maksaa vain ohjelman suorittamisesta eikä virtuaalipal- velimesta. (Cheshire 2020.)
Logic Apps -palvelulla luodaan työnkulkuja (workflow) visuaalisella Logic Apps designer -suunnittelutyökalulla, Visual Studiolla tai Visual Studio Codella. Työn- kulku on sarja yhteen liitettyjä toimintoja (action), jotka suorittavat vuorollaan yh- den tehtävän. Työnkulku alkaa aina liipaisimella (trigger), joka käynnistää työn- kulun. Käynnistävä tapahtuma voi olla ehdon toteutuminen, tapahtuma tai ajastettu ajankohta. (Microsoft 2021c.) Erilaiset Azuressa, kolmannen osapuolen pilvipalveluissa ja paikallisessa laiteympäristöissä olevat resurssit ja palvelut voi- daan kytkeä Logic Apps -prosesseihin liittimillä (connector) (Zaal 2020), jotka toi- mivat rajapintana ulkopuoliseen palveluun (Microsoft 2021c). Logic Appsissa on satoja valmiita liittimiä ja käyttäjät voivat tarvittaessa luoda omia liittimiä tai käyt- tää palvelua protokollan, esim. http, yli. Valmista työnkulkua kutsutaan logiikka- sovellukseksi (logic app). (Microsoft 2021g.)
4.4.4 Mittarihälytykset
Hälytykset ilmoittavat laiteympäristössä ja sovelluksissa ilmenevistä ongelmista.
Hälytysten avulla voidaan reagoida ongelmiin ennakoivasti, ennen kuin ongelmat aiheuttavat käyttöhäiriöitä. (Microsoft 2021f.) Mittarihälytykset tarkistava säännöl- lisesti kerätystä mittaritiedosta onko hälytysehto toteutunut ja hälyttävät ehdon toteutuessa (Microsoft 2021e).
Mittarihälytyksissä voidaan määrittää hälytyksen kynnysarvo joko staattisena tai dynaamisena. Staattinen kynnysarvo on käyttäjän määrittämä kiinteä arvo. Dy- naamista kynnysarvoa käytettäessä ei määritetä hälytyksen kynnysarvoa, vaan koneoppiminen oppii mitattavan arvon käyttäytymisestä löytäen mahdollisiin on-
gelmiin viittavia poikkeamia ja toimintakaavoja. Dynaamisen kynnysarvon käyttä- minen ei edellytä niin syvällistä tietämystä järjestelmästä kuin staattisen kynnys- arvon käyttö. Kerran luotua dynaamiseen kynnysarvoon perustuvan hälytyssään- nön voi liittää automaattisesti resursseihin niitä luotaessa. (Zaal 2020, luku 1.) Jos dynaamisella kynnysarvolla ei ole käytettävissä mittaritietoja tai valvottava kohde on uusi, hälytystä ei tehdä, ennen kuin tarkan kynnysarvon määrittä- miseksi on tarpeeksi mittaritietoa. Kynnysarvon määrittämiseksi mittaritietoja tar- vitaan vähintään 30 näytettä 3 päivän ajalta. (Microsoft 2021d.)
Staattista kynnysarvoa käytettäessä hälytys laukeaa, kun valvottavan arvon vii- meisen viiden minuutin keskiarvo ylittää kynnysarvon. Dynaamista kynnysarvoa käytettäessä viimeinen kahdenkymmen minuutin jakso lohkotaan viiden minuutin osiin. Hälytys laukeaa, kun jokaisen viiden minuutin jakson keskiarvo ylittää kyn- nysarvon. Hälytyksen lauettua hälytyssääntö lähettää ilmoituksen Monitoriin ja suorittaa mahdolliset määritetyt toiminnot, esim. lähettää sähköpostin. (Microsoft 2021d.)
Hälytyksen tapahduttua hälytyssääntö ei tee uutta hälytystä, vaikka resurssin käyttö jatkuisi hälytysarvon ylittäen, ennen kuin resurssin käyttö on palautunut normaalitilaan. Normaalitilaan palautuminen edellyttää kolmea peräkkäistä kyn- nysarvon alapuolelle asettuvaa arvoa, minkä jälkeen hälytyssääntö ilmoittaa ti- laksi ratkaistu ja suorittaa mahdolliset muut toiminnot. (Microsoft 2021e.)
Hälytyksen laukaisemisen määritykseen käytetään hälytyksen kynnysarvon herk- kyys -käsitettä, joka määrittää hälytykseen vaadittavan mitattavan arvon poik- keaman. Hälytyksen kynnysarvon herkkyys on kolmetasoinen käsite hälytyksen laukaisemiseksi metriikkapoikkeamien määrän perusteella:
• korkea hälytyksen kynnysarvo on kireä ja hälytys laukeaa pienimmästä poikkeamasta antaen eniten hälytyksiä
• keskitason hälytys on järjestelmän oletus ja sen kynnysarvo on väljempi, antaen vähemmän hälytyksiä
• matalan hälytyksen kynnysarvo on väljin, sallien suurimmat poikkeamat, antaen vähiten hälytyksiä. (Microsoft 2021d.)
Hälytyksen vakavuusaste määritetään viisitasoisella asteikolla:
0 = Kriittinen (Critical) 1 = Virhe (Error)
2 = Varoitus (Warning) 3 = Tietotus (Informational)
4 = Sanallinen (Verbose) (Microsoft 2021f).
5 Toimeksianto
Toimeksiannon sisältö tarkentui prosessin edetessä. Alkuun toimeksiantona oli suunnitella sovelluksen saavutettavuus testit Application Insights -palvelussa.
Toimeksiannon sisältöä uudelleenarvioitiin prosessin kuluessa ja toimeksiannon sisältöön tehtiin joitakin muutoksia ja tarkennuksia.
Uudelleen määritellyssä toimeksiannossa tehtävänä oli sovelluspalvelimen häly- tyssääntöjen ja viikkoraportoinnin suunnittelu Azure Monitorissa sekä selvittää valvontaan liittyviä parhaita käytäntöjä. Toteutus suoritettaisiin Azuren ja paikalli- sen laiteympäristön muodostamassa hybridipilvessä.
6 Toteutus
6.1 Hälytykset
Toimeksiannon ensimmäisenä osana oli paikallisen sovelluspalvelimen (Win- dows) suorituskykyyn liittyvät hälytykset. Hälytyssäännöt suunniteltiin käytetty prosessorin suoritusaika, käytettävissä oleva muisti ja vapaa levytila valvotuilla mittareille.
Hälytyssääntö voidaan luoda Azure Monitorissa useasta kohdasta, mm. koonti- näytöissä olevista mittarikaaviosta (chart) sekä Monitor-näkymän siirtymäpalkin
Alerts-toiminnosta. Tässä tehtävässä valvontatiedot kerätään aiemmin luotuun Log Analytics -työtilaan ja hälytyssääntöjen määrittäminen aloitetaan työtilan Alerts-toiminnon +New alert rule -valinnasta (kuvio 5) käyttäen ko. työtilaan ke- rättäviä mittaritietoja.
Kuvio 5. Log Analytics -työtilan toiminnot-valikko.
Hälytyssäännön luominen tapahtuu avautuvasta Create Alert rule -ikkunasta (kuvio 6), mistä määritetään valvottavan resurssin nimi ja mihin resurssiryhmään resurssi kuuluu, hälytysehto ja hälytyksen tapahtuessa suoritettavat toimenpiteet.
Kun säännön resurssina käytetään Log Analytics -työtilaa, resurssitiedot tulevat automaattisesti työtilan määrityksistä.
Kuvio 6. Hälytyssäännön luonti-ikkuna.
Hälytysehdon lisääminen tehdään Create Alert rule -ikkunan Add condition - valinnasta. Avautuvan Configure signal logic -ikkunan (kuvio 7) käytettävissä olevista mittareista valitaan mittarin hälytyssääntöön.
Kuvio 7. Hälytyssääntöön valittavan mittarin valinta.
Mittarin valinta avaa uuden näkymän (kuvio 8), missä valitaan käytettävä kynnys- arvo, staattinen tai dynaaminen, ja sen määritykset. Toimeksiannon hälytyksissä
käytetään dynaamista kynnysarvoa, aggregaattina keskiarvoa (average) ja kyn- nysarvon herkkyytenä medium-arvoa. Suurempi kuin -operaattoria käytetään prosessori aikahälytyssäännössä ja pienempi kuin -operaattoria käytetään muis- tin käyttö- ja vapaa levytila -hälytyssäännössä. Muut asetukset ovat järjestelmän oletusarvoja.
Kuvio 8. Hälytysehtojen määritys.
Hälytysehdon määrityksen jälkeen määritellään hälytyksen tapahtuessa tehtävät toiminnot Create Alert rule -ikkunan Add action groups -valinnasta. Avautu- vasta näkymästä (kuvio 9) valitaan, jos hälytyssäännölle ollaan luomassa uusi ryhmä (action group) toimintoineen, +Create action group tai valitaan ryhmä olemassa olevien listasta. Tehtävissä käytetään valmista ryhmää, jonka jäsenille lähetetään hälytysehdon lauetessa sähköposti.
Kuvio 9. Hälytysryhmän määrittäminen hälytyssäännölle.
Lopuksi annetaan hälytyssäännölle nimi, lyhyt kuvaus säännöstä, resurssiryhmä, määritetään hälytyksen vakavuusaste ja hyväksytään sääntö (kuvio 10). Hälytys- sääntö on heti aktiivinen, jos Enable alert rule upon creation -valinta on valittu.
Kuvio 10. Hälytyssäännön nimeäminen ja kuvaaminen.
Hälytystilastoa voidaan seurata Azure Monitorin Alerts-palvelusta.
6.2 Viikkoraportti
Toimeksiannon toinen osa oli viikkoraporttiin tehtävä laajennus. Viikkoraporttiin kerätään kerran viikossa valvontatietoa sovelluspalvelimen suorituskykymitta- reista. Mittariarvoista muodostetaan graafinen kaavio, joka lähetetään sähköpos- titse. Mittareina ovat käytetty prosessori aika, käytettävissä oleva muisti ja vapaa levytila.
Raportin lokikyselyt tehtiin ja testattiin resurssin työtilan Log Analyticsissä. Kyse- lyiden valmistuttua seurasi työnkulun toteuttaminen Logic Apps -palvelussa.
Työnkulku aloitetaan liipaisimella. Tässä käytetään ajastettua liipaisinta, valitaan Recurrence ja määritellään ajastustiedot kuviossa 11.
Kuvio 11. Liipaisimen ajastaminen.
Liipaisinta seuraa aina toiminto. Valitaan + New step.
Haetaan Choose an action -näytöltä kirjoittamalla Azure monitor ja valitaan Azure Monitor Logs.
Valitaan Azure Monitor Logs -näytöltä Run query and visualize results (kuvio 12).
Kuvio 12. Toiminnon valinta Azure Monitor Logs -ikkunasta.
Toiminnolle määritetään liitin resurssiin. Yhteys resurssiin voidaan tehdä käyt- täjä- tai service principal -tunnuksella, joka on resurssin käyttöön luotu tunnus.
Yhteyden voi vaihtaa Visual Analytics query -ikkunasta Change connection - linkistä.
Visual Analytics query kuviossa 13, 14 ja 15.
Nimetään kysely.
Täytetään resurssin tiedot; tilaus, resurssiryhmä, resurssityyppi ja resurssin nimi.
Query-kenttään syötetään kysely, joka on tehty ja testattu Logic Appsissa.
Kyselyn aloittava Perf ilmaisee, että käytetään suorituskykymittaritaulua.
Kerätään tiedot 14 vrk ajalta prosessoriaikamittarista kuvio 13. Kuvion 14 kyse- lyssä käytetty käytettävissä oleva muisti -mittaria ja kuviossa 15 käytetty vapaa levytilamittaria.
Ajanjakson voi määrittää joko kyselyssä tai Time Range -kentässä. Tässä vali- taan Set in query, koska ajanjakso on määritetty kyselyssä.
Valitaan esitysmuoto Chart Type -kentässä.
Kuvio 13. Kysely prosessoriajan käytöstä.
Kuvio 14. Kysely käytettävissä olevasta muistista.
Kuvio 15. Kysely vapaasta levytilasta.
Koska sähköpostin runko käännetään HTML-muotoon, kyselyn tuloksen nimi tu- lee esittää HTML-muodossa, mikä tehdään luomalla työnkulkuun muuttuja. Tu- loksen nimen voi selvittää suorittamalla työnkulun ja katsomalla toiminnon OUTPUTS-osion Attachment Name -kentästä.
Työnkulkuun lisätään uusi toiminto valitsemalla + ja Add an action (kuvio 16).
Kuvio 16. Toiminnon lisääminen työnkulkuun.
Haetaan Choose an action -näytöltä kirjoittamalla variables ja valitaan Variab- les-toiminto. Valitaan listalta Initialize variable (kuvio 18).
Kuvio 18. Listaus valittavista muuttujista.
Nimetään toiminto.
Syötetään Name-kenttään nimi, jota käytetään sähköpostin liitteessä.
Valitan Type-kentässä String.
Syötetään Value-kenttään <img src=”cid:% Free Space_ + liitetään At- tachment Name muuttujan arvokenttään Dynamic content -ikkunan listalta (ku- vio 19).
Kuvio 19. Muuttujan määrittäminen.
Työnkulku päätetään lisäämällä työnkulun loppuun Mail-toiminto valitsemalla Add an action.
Haetaan Choose an action -näytöltä kirjoittamalla Outlook ja valitaan Office 365 Outlook -toiminto.
Valitaan listasta Send an email (V2).
Painetaan hiiren ensisijaisella näppäimellä sähköpostin rungossa ja valitaan avautuvasta Dynamic content -listasta muuttuja. Toiminto toistetaan Attachment Name – ja Content-kentässä, mutta valitaan kyselyn nimen alla olevasta listasta Attachement Name ja Attacment Content (kuvio 20).
Kuvio 20.Liitetiedostojen lisääminen.
Kuviossa 21 on valmis sähköposti liitteineen.
Kuvio 21. Valmis sähköposti.
Kuviossa 22 esitetään valmiin logiikkasovelluksen työnkulku, josta käy selkeästi ilmi työnkulun ketjumainen rakenne. Liipaisin aloittaa työnkulun ja sen jälkeen yhteen liitetyt yksittäiset toiminnot.
Kuvio 22. Valmis työnkulku.
7 Parhaat käytännöt
Toimeksiannon kolmantena osan oli tutkia Azure Monitoriin liittyviä parhaita käy- täntöjä. Azure-pilvipalvelu ja siihen kytkeytyvät muut resurssit, esim. paikallinen laiteympäristö, on laaja kokonaisuus ja siihen liittyviä parhaita käytäntöjä on run- saasti. Tähän on kerätty parhaita käytäntöjä työn aihepiiriin liittyen.
Sovellusten valvonta
Sovellusten suorituskyvyn varmistamiseksi, kaikkien sovellusten tulisi olla val- vonnassa (Bagaria 2018). Instrumentoimalla sovellukset saadaan tietoa ongel- mien ratkaisemiseen ja päätöksentekoon (Microsoft 2016). Instrumentoinnin voi tehdä lisäämällä sovellukseen Application Insights SDKn tai käyttämällä muuta menetelmää, esim. status monitor for .NET (Bagaria 2018).
Laiteympäristön valvonta
Olisi tärkeää valvoa kaikkia olennaisia laiteympäristön resursseja (Bagaria 2018).
Laiteympäristön valvonnalla saadaan näkymä järjestelmän tilasta ja suoritusky- vystä sekä resurssien saavutettavuuteen (Microsoft 2016). Mahdollisimman kat- tava laiteympäristön valvonta auttaa ongelmien juurisyiden selvittämisessä (Ba- garia 2018).
Hälytykset
Käyttämällä hälytyksiä saadaan tieto mahdollisista virhetilanteista ja ongelmista.
Hälytyssäännöt tulisi asettaa kaikille ennakoitaville virhetilanteille ja hälytyksille olisi määritettävä tarvittavat toiminnot, esim. SMS tai sähköposti ilmoitukset. Jos mahdollista valvonta olisi hyvä yhdistää IT-palvelunhallinta- tai hälytystenhallin- tajärjestelmään. Ennakoida ja käyttää automaattisesti skaalautuvaa kuormanja- koa. (Bagaria 2018.)
Työtilat ja työkirjat
Jatkuvan valvonnan, ongelmien nopean havaitsemisen ja ratkaisemisen varmis- tamiseksi kehittäjillä ja ylläpidolla tulisi olla pääsy samoihin valvontatyökaluihin ja tietoihin. Käyttämällä yhteisiä koontinäyttöä ja työkirjoja varmistetaan tietojen ja ohjeiden jakaminen kehittäjien ja ylläpidon välillä. (Bagaria 2018.)
8 Tulokset
Opinnäytetyön tuloksena syntyi raportti, jonka teoriaosuudessa käsitellään häly- tyssääntöjen kynnysarvojen toimintaperiaatetta ja hälytyssääntöihin liittyviä määrityksiä. Raporissa syvennytään myös valvonnassa käytettävien lokitietojen tehtäviin ja eroavaisuuksiin sekä tietojen varastointiin ja analysointiin liittyviin palveluihin. Lopuksi raportissa esitetään valvontaan liittyviä parhaita käytäntöjä.
Opinnäytetyön toteutuksessa syntyi hälytyssääntöjä, joissa käytetään koneoppi- miseen perustuvaa dynaamista kynnysarvoa sekä logiikkasovellus, joka hakee ja muodostaa mittaritiedoista raportin. Hälytyssäännöt eivät ole aiheuttaneet vääriä hälytyksiä ja logiikkasovellus on toiminut virheettömästi.
9 Pohdintaa
Azure Monitor on erilaisista palveluista muodostuva laaja kokonaisuus. Toimin- nallisesti palvelut liittyvät toisiinsa, mikä teki opinnäytetyön rajaamisesta haasta- van. Tietyn toiminnon ymmärtämiseksi on tunnistettava ja ymmärrettävä kytkey- tyvien palveluiden merkitys toimintoon. Rajatessani aihetta, jouduin pohtimaan mistä kirjoittaisin ja millä tarkkuudella. Aiheeseen perehtyessäni työn rajaaminen helpottui ja pystyin keskittymään oleelliseen. Työssäni olen pyrkinyt käsittele- mään viitekehyksen kannalta oleelliset palvelut ja asiat.
Kun hälytyssääntöjä tehdään dynaamista kynnysarvoa käyttäen, sääntöä tehtä- essä uutteen resurssiin, on tärkeää huomioida viive minkä koneäly tarvitsee op- piakseen tarkan kynnysarvon. Jos kyseessä on kriittinen komponentti ja hälytys- ten tulee toimia välittömästi, on syytä käyttää staattista kynnysarvoa.
Kynnysarvon voi muuttaa myöhemmin dynaamiseksi, kun järjestelmään on ker- tynyt riittävästi historiatietoa kynnysarvon tarkkaan määrittämiseen.
Toimittaessa pilvi- ja hybridiympäristöissä on hyvä kiinnittää huomiota integraati- oissa käytettäviin käyttäjätunnuksiin. Yhteyksissä automatisoiduista työkaluista, esim. logiikkasovellus, Azuren resursseihin ja isännöityihin palveluihin tulisi käyt- tää käyttäjätunnusten sijaan tarkoitukseen luotua service principal -tunnusta.
Tunnuksella on pääsy vain määrättyihin resursseihin rajoitetuilla valtuuksilla, mitkä määritetään tunnukseen liitetyillä rooleilla. Microsoft suosittelee tietotur- vasyistä käyttämään service principal -tunnusta käyttäjätunnusten sijaan. (Micro- soft 2020f.) Käyttämällä service principal -tunnusta varmistetaan myös yhteyk- sien ja sovellusten toiminta, jos yhteyden luontiin käytetty käyttäjätunnus poistetaan käytöstä.
Valvonta tulisi nähdä jatkuvana prosessina. Tekniset muutokset, järjestelmien päivitykset ja sovelluksen kehittäminen tuovat mahdollisia muutostarpeita ja uu- sia tarpeita valvontaan ja raportointiin. Kerättävän tiedon määrä voi olla hyvin
suuri ja on hyvä tarkastella, mitä tietoja tulee kerätä ja kuinka pitkään tietoja tulisi säilyttää. Suurin osa kerättävästä tiedosta on päivittäisten toimintojen tuottamaa rutiinitietoa, jolla on vähäinen merkitys (Gillespie 2020).
Lähteet
Bagaria, R. 2018. Seven best practices for Continuous Monitoring. Microsoft Azure Blog. 22.10.2018. https://azure.microsoft.com/en-us/blog/7- best-practices-for-continuous-monitoring-with-azure-monitor.
26.4.2021.
Copeland, M., Soh, J., Puca, A., Manning, M. & Gollob, D. 2015.Microsoft Az- ure: Planning, Deploying, and Managing Your Data Center in the Cloud. New York: Apress.
Chakraborty, B. & Kathikeyan, S.A. 2019.Understanding Azure Monitoring: In- cludes IaaS and PaaS Scenarios. New York: Apress.
Cheshire, J. 2020. Exam Ref AZ-900 Microsoft Azure Fundamentals, 2nd Edi- tion. Hoboken: Pearson Education, Inc.
Chilberto, J., Zaal, S., Aroraa, G. & Price, E. 2020. Cloud Debugging and Profil- ing in Microsoft Azure: Application Performance Management in the Cloud. New York: Apress.
De Tender, P., Leonardo, G. & Milgram, J. 2020. Azure Strategy and Implemen- tation Guide - Third Edition. Birmingham: Packt Publishing Ltd.
Erl, T., Mahmood, Z. & Puttini, R. 2013. Cloud Computing: Concepts, Technol- ogy & Architecture.Upper Saddle River: Pearson.
Gillespie, M. 2020. Understanding Log Analytics at Scale. Sebastopol:O'Reilly Media, Inc.
Hargreaves, B. & Zaal, S. 2020. Implementing Microsoft Azure Architect Tech- nologies: AZ-303 Exam Prep and Beyond - Second Edition. Birming- ham: Packt Publishing Ltd.
Mahendrakar, S. & Kumar, A. 2019. Serverless Integration Design Patterns with Azure. Birmingham: Packt Publishing Ltd.
Microsoft. 2019a. Azure Monitor overview. Microsoft Corporation.
https://docs.microsoft.com/en-us/azure/azure-monitor/overview.
4.12.2020.
Microsoft. 2019b. Azure Monitor naming and terminology changes. Microsoft Corporation. https://docs.microsoft.com/en-us/azure/azure-moni- tor/terminology. 24.5.2021.
Microsoft. 2019c. Getting startd with Azure Metrics Explorer. Microsoft Corpora- tion. https://docs.microsoft.com/en-us/azure/azure-monitor/essen- tials/metrics-getting-started. 24.5.2021.
Microsoft. 2019d. What is Application Insights? Microsoft Corporation.
https://docs.microsoft.com/en-us/azure/azure-monitor/app/app-in- sights-overview. 4.12.2020.
Microsoft. 2019e. Advanced features of the Azure metrics explorer. Microsoft Corporation. https://docs.microsoft.com/en-us/azure/azure-moni- tor/essentials/metrics-charts. 24.5.2021.
Microsoft. 2020a. Monitoring options available in Azure. Microsoft Corporation.
https://docs.microsoft.com/en-us/learn/modules/design-monitoring- strategy-on-azure/3-azure-monitoring-options. 3.12.2020.
Microsoft. 2020b. Send log data to Azure Monitor with the HTTP Data Collector API (public preview). Microsoft Corporation. https://docs.mi-
crosoft.com/en-us/azure/azure-monitor/logs/data-collector-api.
2.3.2021.
Microsoft. 2020c. Azure Monitor Logs overview. Microsoft Corporation.
https://docs.microsoft.com/en-us/azure/azure-monitor/logs/data-plat- form-logs. 8.12.2020.
Microsoft. 2020d. Overview of Log Analytics in Azure Monitor. Microsoft Corpo- ration. https://docs.microsoft.com/en-us/azure/azure-moni-
tor/logs/log-analytics-overview. 25.5.2021.
Microsoft. 2020e. Getting started with Kusto. Microsoft Corporation.
https://docs.microsoft.com/en-us/azure/data-explorer/kusto/con- cepts/. 25.3.2021.
Microsoft. 2020f. Create an Azure service principal with Azure PowerShell. Mi- crosoft Corporation. https://docs.microsoft.com/en-us/powershell/az- ure/create-azure-service-principal-azureps?view=azps-6.0.0.
30.5.2021.
Microsoft. 2021a. Azure Monitor Metrics overview. Microsoft Corporation.
https://docs.microsoft.com/en-us/azure/azure-monitor/essen- tials/data-platform-metrics. 4.5.2021.
Microsoft. 2021b. Create a Log Analytics workspace in the Azure portal. Mi- crosoft Corporation. https://docs.microsoft.com/en-us/azure/azure- monitor/logs/quick-create-workspace. 5.5.2021.
Microsoft. 2021c. What is Azure Logic Apps? Microsoft Corporation.
https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-over- view. 7.5.2021.
Microsoft. 2021d. Metric Alerts with Dynamic Thresholds in Azure Monitor. Mi- crosoft Corporation. https://docs.microsoft.com/en-us/azure/azure- monitor/alerts/alerts-dynamic-thresholds. 1.4.2021.
Microsoft. 2021e. Understand how metric alerts work in Azure Monitor. Mi- crosoft Corporation. https://docs.microsoft.com/en-us/azure/azure- monitor/alerts/alerts-metric-overview. 11.3.2021.
Microsoft. 2021f. Overview of alerts in Microsoft Azure. Microsoft Corporation.
https://docs.microsoft.com/en-us/azure/azure-monitor/alerts/alerts- overview. 11.3.2021.
Microsoft. 2021g. Connectors for Azure Logic Apps. Microsoft Corporation.
https://docs.microsoft.com/en-us/azure/connectors/apis-list.
29.5.2021.
Microsoft. 2021h. Subscriptions, licenses, accounts, and tenants for Microsoft's cloud offerings. Microsoft Corporation. https://docs.microsoft.com/en- us/microsoft-365/enterprise/subscriptions-licenses-accounts-and-ten- ants-for-microsoft-cloud-offerings?view=o365-worldwide. 3.6.2021.
Modi, R. 2019. Azure for Architects - Second Edition.Birmingham: Packt Pub- lishing Ltd.
Ranjan, R., Chen, J; Wang, L. & Benatallah, B. 2017.Cloud Computing. Boca Raton: CRC Press.
Smoot, S.R. & Tan, N.K. 2011. Private Cloud Computing. Waltham: Morgan Kaufmann.
Trautman, P. 2018. Designing and Building a Hybrid Cloud. Sebastopol:
O’Reilly Media Inc.
Zaal, S. 2020. Microsoft Azure Architect Technologies: Exam Guide AZ-300.
Birmingham: Packt Publishing Ltd.
