Canvas Power Appsin on voinut kytkeä Azuren Application Insights -palveluun jo vuodesta 2020. Harva kuitenkaan näin tekee. Tuotantokäytössä olevat Canvas Power Appsit kannattaa kuitenkin kytkeä Application insightsiin.

Miksi? Mitä sen käytössä tulisi ottaa huomioon?

Application Insights lyhyesti

Application Insights on Azuren palvelu web-sovellusten monitorointiin, vianselvitykseen ja käytön seurantaan. Se kerää automaattisesti tietoja sovelluksen käytöstä. Lisäksi sovellukseen voi lisätä omaa lokitusta (custom trace), joka tallennetaan Application Insightsiin.

Muodostuneeseen lokitietoon voi tehdä monipuolisia kyselyjä KQL:ää (Kusto Query Language) käyttäen.

Kyselyitä voi hyödyntää suoraan Power BI:n tietolähteinä, eli omien raporttien rakentaminen on todella helppoa. Kyselyistä voi myös muodostaa Azuren Dashboardille tiiliä, mikäli se on omassa käytössä Power BI:tä luontevampi paikka seurata sovelluksen tilaa.

Power Appsin ja Application Insightsin yhteiselo on muuttunut hyvin vähän sitten vuoden 2020. Tutustuminen kannattaakin aloittaa silloin kirjoittamastani jutusta.

Mihin Application Insights:ia voi käyttää?

Vaikka mihin. Itse olen käyttänyt sitä muun muassa seuraaviin tarkoituksiin.

Käyttäjämäärien seuranta

Haluamme tietää kuinka moni käyttäjä avaa sovelluksen päivittäin. Application Insights lokittaa sovelluksen käynnistykset automaattisesti. Sovellukseen ei siis tarvitse tehdä mitään muutoksia tätä varten. Haetaan vain kyseiset tapahtumat.

traces
| where message startswith "Sovellus käynnistyi"
| where timestamp > ago(90d)

Kyselyn voi visualisoida muutamalla lisärivillä.

traces
| where message startswith "Sovellus käynnistyi"
| where timestamp > ago(7d)
| summarize RequestsCount=sum(itemCount) by bin(timestamp,1d)
| render timechart

Mikäli samaan Application Isnights:iin lokittaa useampi sovellus, voidaan ne esittää omina käppyröinään. Esimerkissä toinen sovellus on avattu ainoastaan kerran 22.12.

traces
| where message startswith "Sovellus käynnistyi" or message startswith "App started"
| where timestamp > ago(7d)
| extend AppId = tostring(customDimensions["ms-appId"])
| summarize RequestsCount=sum(itemCount) by bin(timestamp,1d), AppId
| render timechart

Mikäli haluamme mukaan myös sovelluksen nimen, joudumme lisäämään sovelluksiin oman Trace-komennon käynnistyksen yhteyteen. Sellaisen missä tallennetaan myös sovelluksen nimi.

Trace(
"App open",
TraceSeverity.Information,
{
User: User().Email,
AppName: "funtapped",
Action: "App opened"
}
)

Näin saamme kuvaajiin mukaan myös sovelluksen selkokielisen nimen.

traces
| where message startswith "App open"
| where timestamp > ago(7d)
| extend AppName = tostring(customDimensions.AppName)
| summarize RequestsCount=sum(itemCount) by bin(timestamp,1d), AppName
| render timechart

Vieraskäyttäjien seuranta

Entäpä jos haluaisimme tietää ketkä sovellusta tosiasiallisesti käyttävät? Jokaisella lokirivillä on mukana käyttäjän tunniste. Eli GDPR näkökulmasta käyttäjät ovat jo tunnistettavissa. Mutta toimenpiteitä ajatellen (lisenssien optimointi tms) olisi helpompaa jos näkisimme myös käyttäjien nimet.

Power BI raportilla käyttäjien tunnisteet voi tietenkin liittää käyttäjien muihin tietoihin.

Mutta käyttäjän sähköpostiosoitteen voi lisätä myös Power Appsissa lokia kirjoitettaessa (User).

Trace(
"App open",
TraceSeverity.Information,
{
User: User().Email,
AppName: "funtapped",
Action: "App opened"
}
)

Nyt voimme tehdä kyselyn, joka paluttaa käyttäjäkohtaiset sovelluksen avaamiset esimerkiksi 7 päivän ajalta.

traces

| where message startswith "App Open"
| where timestamp > ago(7d)
| extend AppName = tostring(customDimensions.AppName)
| extend UserName = tostring(customDimensions.User)
| summarize RequestsCount=sum(itemCount) by UserName
| render columnchart

Näin voisimme seurata esimerkiksi miten moni vieraskäyttäjä sovellusta käyttää ja keitä he ovat.

Tarkka käyttöanalytiikka

Mikäli haluamme tietää, mitä sovelluksen ominaisuuksia käyttäjät käyttävät, voimme ryhtyä lokittamaan myös tätä tietoa. Esimerkiksi työpaikkamme alkoholittomien oluiden arvostelu -sovellus lokittaa kaikki käyttäjän sovelluksessa tekemät toiminnot.

Alla esimerkki miten uuden olutarvostelun lisääminen lokitetaan myös Application Insightsiin.

Trace(
"Action",
TraceSeverity.Information,
{
User: User().Email,
Screen: App.ActiveScreen.Name,
AppName: "funtapped",
Action: "Rating added"
}
)

Näin voimme muodostaa kokonaiskuvan siitä, mitä sovelluksen toiminnallisuuksia käytetään ja miten paljon.

traces
| where message startswith "Action"
| where timestamp > ago(7d)
| extend AppName = tostring(customDimensions.AppName)
| extend UserName = tostring(customDimensions.User)
| extend Action = tostring(customDimensions.Action)
| summarize RequestsCount=sum(itemCount) by Action
| render piechart

Näemme esimerkiksi sen, että jokainen skannattu olut on myös arvosteltu.

Virheiden lokitus

Säästin parhaan viimeiseksi. Application Insightiin kannattaa lokittaa kaikki virheet. Esimerkiksi tietoja tallennettaessa.

IfError(
Patch(
Beers,
Defaults(Beers),
{
Name: inpBeerName.Value,
Manufacturer: inpBrandName.Value,
EAN: locEAN
}
),
Trace(
"Error",
TraceSeverity.Error,
{
User: User().Email,
AppName: "funtapped",
Kind: FirstError.Kind,
Message: FirstError.Message,
Observed: FirstError.Observed,
Screen: App.ActiveScreen.Name,
Source: FirstError.Source
}
)
)

Myös kaikki käsittelemättä jääneet virheet on hyvä lokittaa (App -> OnError).

Trace(

"Unhandled Error (own)",
TraceSeverity.Error,
{
User: User().Email,
Kind: FirstError.Kind,
Message: FirstError.Message,
Observed: FirstError.Observed,
Screen: App.ActiveScreen.Name,
Source: FirstError.Source
}
);

Notify(
Concatenate(
FirstError.Message,
", Observed: ",
FirstError.Observed,
", Source: ",
FirstError.Source
),
NotificationType.Error
);

Huomaa, että lisätessäsi sovelluksen OnError:iin omia komentoja, ei käyttäjälle näytetä käsittelemättömistä virheistä enää vakioilmoitusta. Siksi sinne on hyvä lisätä loppukäyttäjälle näytettävä virhe (Notify).

Varsinkin testausvaiheessa tämä on erinomainen tapa saada kiinni testikäyttäjille tulleita epämääräisiä virheitä. Jotka ovat jääneet kehitysvaiheessa huomioimatta.

Tuotantovaiheessa taas voi rakentaa automaattihälytyksiä näitä hyödyntäen.

Kokeelliset (experimental) ominaisuudet

Power Appsista löytyy muutama kokeellinen ominaisuus aiheeseen liittyen.

Pass error to Azure Application Insights

Tämä tekee käytännössä saman, kuin oman virhelokituksen lisääminen App OnError:iin. Muutamalla erolla.

  • Käyttäjä saa edelleen alustan vakiovirheilmoituksen
  • Sovelluksen ja käyttäjän nimet puuttuvat lokitiedosta

Enable Azure Application Insights correlation tracing

Toimii toistaiseksi vain omien yhdistimien (custom connector) kanssa.

Dashboardit

Application Insightsilla tehdyt kyselyt voi nostaa näkyville Azuren dashboardeille.

Mikäli Power BI -raportin tekeminen ei kiinnosta, saa näin muodostettua kohtuuvaivalla yleisnäkymän sovelluksen/sovelluksien tilasta.

Jokaiselle Power Appsille oma Application Insights?

Päätämme ottaa Application Insightsin käyttöön kaikissa Power Appseissamme. Luodaanko kullekin sovellukselle oman Application Insights -palvelu vai olisiko mahdollista käyttää yhtä jaettua?

Application Insights per Power Apps

Loogisinta on luoda jokaiselle sovellukselle oma Application Insights -palvelunsa. Näin jokaisen sovelluksen lokit ovat omassa poterossaan.

Voit kuitenkin tehdä kyselyjä, jotka kattavat usean sovelluksen (=Application Insightsin) tiedot. Lisäät vain haluamasi sovellukset kyselyiden kohteeksi (scope).

Kyselyiden tuloksissa sovellukset erottuvat toisistaan AppName -tiedon perusteella. Tämä ei ole Power Appsin nimi, vaan sitä lokitavan Application Insights:in nimi.

Lokirivien customDimensions-osuudesta löytyy Power Appsin tunniste (ms-appId), tenantin tunnniste (ms-tenantId) ja ympristön tunniste (ms-environmentId). Lisäksi siellä on sovelluksen nimi (ms-appName), joka harmiksemme on useimmiten sama kuin sovelluksen id. Ei siis sovelluksen selkokielinen nimi.

Mikäli kysely kohdistuu useaan Application Insights:iin, ei sitä voi enää käyttää sellaisenaan Power BI:ssä.

Tylsää.

Jokaisen uuden sovelluksen kohdalla käytännössä

  • Luodaan uusi Application Insights instanssi
  • Lisätään se kyselyiden kohteisiin (scope)
  • Lisätään uusi kysely Power BI:hin (mikäli Power BI:tä hyödynnetään analysoinnissa)

Luonnollisesti itse sovellukseen tulee lisätä Application Insightsin Instrumentation key sekä tarvittavat omat lokitukset.

Yhteinen Application Insights Power Appseille

Toinen vaihtoehto on luoda yksi jaettu Application Insights, jota kaikki Power Appsit hyödyntävät.

Tällöin uuden sovelluksen lisääminen ei edellytä muutoksia Application Insightsin kyselyihin eikä Power BI -raporttin.

Muttei tämäkään lähestyminen ole ongelmaton. Lokit eivät sisällä sovelluksen selkokielistä nimeä. Tämän takia sovelluksen nimi tulee lisätä jokaiseen lokitukseen tai vaihtoehtoisesti tehdä Power BI:tä varten oma taulu sovelluksille ja niiden tunnisteille.

Samasta syystä osa Application Insightsin vakio-ominaisuuksista muuttuu enemmän tai vähemmän hyödyttömiksi.

Esimerkiksi käyttäjän etenemistä kuvaava User flows -visualisointi. Allaolevassa kuvassa on Application Insightissa kahden eri sovelluksen lokit. Molemmissa sovelluksissa päänäyttö on nimeltään Home Screen. Visualisoinnissa ne tulkitaan yhdeksi ja samaksi näytöksi, josta käyttäjä on navigoinut

  1. Kirjaamaan tunteja (tuntikirjaussovellus)
  2. Arvostelemaan olutta (funtapped -sovellus)

Yhteenveto

Application Insights on oiva työkalu Power Apps -kehittämisen rinnalle. Sitä voi hyödyntää testausvaiheessa uusien virheiden löytämiseen ja korjaamiseen. Suurin hyöty siitä on kuitenkin tuotantovaiheessa, jolloin sen avulla saa kattavaa analytiikkaa sovelluksen käytöstä.