Yksi Power Automaten heikkouksista on sen valvonta. Siis sen puute. Usein haluamme olla tietoisia esimerkiksi seuraavista asioista

  • Onko joissain ympäristössä (environment) työnkulkuja, joita suoritetaan todella paljon (muodostavat paljon Power Platform pyyntöjä)?
  • Onko jossain työnkulkuja, joiden suoritusmäärät ovat normaalista poikkeavia (flow jäänyt esimerkiksi silmukkaan)?
  • Onko tuotantoympäristöissä päätynyt työnkulkuja virheeseen? Mitkä työnkulut?
  • Onko työnkulkua x ajettu tänään kertaakaan?
  • jne

Perusasioita. Mutta näiden tietojen esiinkaivaminen, saati automaattinen reagointi, ei yllättäen olekaan ollut yksinkertaista.

Tietoa on kyllä saatavilla. Power Platformin hallintakeskuksesta näkee esimerkiksi tiedot työnkulkujen suorituksista.

Jokaisen flow’n osalta näemme ajohistorian lisäksi analytiikkaa käytöstä ja virheistä.

Flow’n omistaja saa sähköpostia erilaisista tapahtumista. Toki pahimmillaan viikon viiveellä.

Tämän takia keskeisiin työnkulkuihin lisätään usein erillinen osio, joka ilmoittaa virheestä sovittuihin kanaviin.

Tämä ratkaisee vain yhden pienen osan haasteesta. Lisäksi vuosien aikana on voitu rakentaa satoja työnkulkuja ilman yhdenmukaista ilmoitusmekanismia. Mukava iltapuhde käydä jälkikäteen lisäämässä se kaikkiin.

Voi kun saisimme kaikki flow’n tapahtumat jollekin oikealle valvonta-alustalle (Application Insights). Silloin voisimme rakentaa kaiken tarpeellisen valvontaa varten itse.

Voimme lopettaa haaveilun, sillä tämä on nyt mahdollista.

Katsotaan miten se tehdään.

Power Automaten kytkeminen Application Insightsiin

Ensimmäiseksi tarvitsemme Azureen Application Insights -palvelun. Luodaan sellainen.

Tämän jälkeen Power Platformin hallintakeskuksessa (Power Platform admin center, PPAC) voi määritellä Power Automate -tapahtumat siirtymään Application Insightsiin.

Käytännössä Analytics (1) alta valitaan Data export (2). Siirrytään sivulla App Insights -välilehdelle (3) ja luodaan uusi data export (4).

Nimetään paketti ja valitaan sisällöksi Power Automate. Paketti voi sisältää tiedot

  • flow’n suorituksista (Cloud flow runs)
  • flow’n käynnistyksistä (Cloud flow triggers)
  • flow’n toimintojen suorituksista (Cloud flow actions)

Seuraavaksi valitaan ympäristö, jonka tapahtumista olemme kiinnostuneita. Yksi paketti sisältää yhden ympäristön tapahtumat. Ympäristön tulee olla halllittu (managed environment), jotta tapahtumat voi ylipäätään siirtää.

Lopuksi kerrotaan mistä käytettävä Application Insights löytyy.

Olemme valmiit. Pienen viiveen jälkeen tapahtumat alkavat näkymään Application Insights -palvelussa.

Application Insights

Application Insights on Azuren palvelu web-sovellusten monitorointiin, vianselvitykseen ja käytön seurantaan. Mikäli kyseessä on uusi tuttavuus, voit lukea aluksi aiemmat kirjoitukseni jotka käsittelevät sen hyödyntämistä Power Appsien valvonnassa.

Metrics-työkalulla pääsee helposti alkuun. Flow’n suoritukset (runs) löytyvät Server requests ja triggerien ja toimintojen tiedot taas Dependency calls alta.

Meitä kiinnostavat kuitenkin omien kyselyiden teko näihin tietoihin (Logs). Kyselyissä flow’n suoritukset löytyvät requests-taulusta ja triggerien sekä toimintojen tiedot dependencies-taulusta.

Tapahtumista tallennetaan varsin paljon tietoja.

Esimerkiksi

  • Ympäristö
  • Resurssin (flow’n) tunniste
  • Flow’n nimi
  • Lopputila
  • Suorituksen kesto
  • Triggerin tyyppi

Tapahtumista löytyy sitten lisäksi vielä paljon paljon muutakin.

Tehdään muutama esimerkkikysely.

Epäonnistuneet suoritukset (runs) per flow

Haetaan epäonnistuneet suoritukset. Esitetään suoritukset erikseen jokaisen flow’n osalta.

requests
| where customDimensions ['resourceProvider'] == 'Cloud Flow'
| where customDimensions ['signalCategory'] == 'Cloud flow runs'
| where success == false
| extend Data = todynamic(tostring(customDimensions.Data))
| extend FlowName = tostring(Data["FlowDisplayName"])
| summarize FailedCount = sum(itemCount) by FlowName

Näemme heti yhden flow’n päättyneen virheeseen useita kertoja.

Kaikki suoritukset

Haetaan kaikki suoritukset ja esitetään päiväkohtaiset lukumäärät ajan yli.

requests
| where customDimensions ['resourceProvider'] == 'Cloud Flow'
| where customDimensions ['signalCategory'] == 'Cloud flow runs'
| summarize RequestCount = sum(itemCount) by bin(timestamp, 1d)
| render timechart

Näin voimme seurata onko flow’den kokonaissuoritusmäärässä jotain poikkeamia.

Power Platform pyynnöt

Mikäli meitä kiinnostaa ympäristön työnkulkujen generoimat Power Platform -pyynnöt, voimme arvioida niiden lukumärää laskemalla yhteen suoritettujen toimintojen ja suoritettujen käynnistimien lukumäärät.

Lopputulos ei ole tarkka totuus, mutta parempi arvio kuin ei mitään.

dependencies
| where customDimensions['resourceProvider'] == 'Cloud Flow'
| where (customDimensions['signalCategory'] == 'Cloud flow triggers' and success == True) or customDimensions['signalCategory'] == 'Cloud flow actions'
| summarize TotalCount=sum(itemCount) by bin(timestamp, 1d) 
| render timechart

27. päivä on tapahtunut jotain, jota kannattaisi kenties tutkia.

Onko flow x ajettu tänään?

Meillä on flow, joka ajetaan joka aamu. Flow’n suoritus on kriittistä loppupäivän toimintojen kannalta.

Kyseisen flow’n virheiden seuraaminen ei riitä. Flow’ta ei ehkä ole ajettu lainkaan. Triggerin yhteys on mennyt vanhaksi, ulkoista herätettä triggerille ei ole tullut, alusta on laittanut flow’n jäähylle (susped) tms.

Nämä kaikki pitäisi saada kiinni. Tehdään kysely, joka laskee kyseisen flow’n onnistuneiden suoritusten lukumäärän viimeisen 24h aikana.

requests
| where customDimensions ['resourceProvider'] == 'Cloud Flow'
| where customDimensions ['signalCategory'] == 'Cloud flow runs'
| where customDimensions ['resourceId'] == 'd0483697-7254-0e21-a335-f95c36c69427'
| where success = true
| where timestamp > ago(1d)
| summarize RunCount=sum(itemCount)

Lukumäärän tulisi olla aina yksi. Mikäli ei ole, on syytä reagoida.

Esimerkkien kyselyt ovat hyvin yksinkertaisia. Application Insightsisa käytettävä kyselykieli KQL (Kusto Query Language) mahdollistaa todella monipuolisten kyselyjen teon.

Dashboards

Kyselyitä voi hyödyntää Azuren dashboardeilla. Helpoiten tämä onnistuu kiinnittämällä kysely (Pin to) suoraan halutulle dashboardille.

Ensimmäinen versio ympristöjen flow’den tilaa kuvaavasta dashboardista näyttää seuraavalta.

Hälytykset

Käppyrät ovat huippuja. Todellinen tarve on kuitenkin automaattiset hälytykset. Niitä pääsee muodostamaan Monitoring -> Alerts -osiosta.

Luodaan uusi hälytyssääntö (alert tule).

Ensimmäisenä määritellään tekijä, joka käynnistää hälytyksen.

Voime hyödyntää valmiita signaaleja kuten

  • Failed requests (flow suoritusten epäonnistuminen)
  • Server requests (flow suoritukset)
  • Dependency call failures (käynnistimien tai toimintojen epäonnistuminen)
  • Dependency call (käynnistimien ja toimintojen suoritukset)

Tehdään hälytys, joka tarkkailee flow’den epäonnistumisia (failed requests). Mikäli yksikin flow on mennyt virheeseen, muodostetaan hälytys. Tilanne tarkistetaan tunnin välein (check every) ja tarkastellaan aina edeltävän tunnin suorituksia (lookback period).

Hälytyksen kustannukseksi arvioidaan 10 senttiä kuukaudessa. Ei kauhean kallista.

Seuraavaksi määritellään mitä hälytyksen sattuessa tehdään. Tällä kertaa lähetetään sähköpostia.

Lopuksi annetaan säännölle nimi ja kuvaus, sekä valitaan sille tilaus ja resurssiryhmä.

Kyselyyn perustuvat hälytykset

Varsinainen pihvi ovat kuitenkin omiin kyselyihin pohjautuvat hälytykset.

Tehdään hälytys joka laukeaa jos tiettyä flow’ta ei ole suoritettu onnistuneesti edellisen 24h sisällä.

Alerts-toiminnon lähettämät sähköpostit näyttävät kaikki seuraavalta.

Yhteenveto

Vihdoin Power Automatea voi valvoa kuten pitääkin. Ilman työnkulkuihin tehtyjä virityksiä. Valvonnan voi rakentaa nopeasti myös olemassa olevaan ratkaisuun. Mikä parasta, nyt on mahdollista valvoa tilanteita, joiden valvonta on aikaisemmin ollut haastavaa (esim. työnkulkua x ei ole suoritettu).

Raportit ja hälytyslogiikka tehdään aina tarpeen mukaan. Yleensä muutamia geneerisiä hälytyksiä ja kriittisille työnkuluille omia tarkempia ja tiheämmin lähetettäviä hälytyksiä.

Ominaisuus on esikatselu (preview) vaiheessa. Nyt on siis aika tutustua. Tuotantokäyttöön sitten myöhemmin.