FI 3
Hacklab Helsinki #web-kehitys kurssi 21.4.2021 -
Kuva: Kyläsaaren jätteenpolttolaitos, 1976, Salmela Erkki HKM CC BY-AS 4.0
Tällä kurssikerralla:
- tarkastellaan 1. kerralla tehtyä tuotantoon vientiä tarkemmin
- tutustutaan frontin lokeihin Cloud Logging:ssa (jos mahdollista)
- seurataan sovelluksen suorituskykyä; mitä siitä kannattaa pitää silmällä (Firebase Performance Monitoring)
Tuotannon seurannan taustalla on kiinnostus siitä, millaisen käyttökokemuksen sovelluksemme käyttäjät saavat.
Tätä voi selvittää:
- sovelluksen sisäisillä kyselyillä
- erikseen lähetetyillä käyttäjäkyselyillä
- reaaliaikaisella seurannalla
Reaaliaikainen seuranta, jota tällä kerralla katsomme, on näistä parempi koska:
- se kattaa kaikki käyttäjät!
- siitä saadaan ajan mittaan vertailukelpoista metriikkaa
Kyselyt taas soveltuvat vapaamuotoiseen palautteen antoon ja esim. ehdotuksiin uusista toiminnoista - asioihin, joita sovelluksessa vielä ei ole.
Mitä mieltä olette seurannasta? Mitä teidän käyttökokemuksesta saa seurata / mitä ei?
Tämän kurssikerran lopuksi Google Meet kysyy, millainen yhteyden laatu oli. Mitä mieltä olet siitä kysymyksestä? Vastaatko yleensä siihen?
Nyt äskeiseen on lisätty reaaliaikainen seuranta.
Taustajärjestelmään raportoidaan:
- "kaatumiset" = poikkeukset, joita sovellus ei käsitellyt
- lokia operoinnin kannalta kriittisistä asioista; esim. varoituksia
- ajastustietoa
Analyysipuolella näitä tietoja käsitellään yleensä massana, ei yksittäisinä asioina (paitsi ehkä kaatumiset).
Asioita ei kannata lokittaa "varmuuden vuoksi" - se sotkee koodia.
Kyse on siitä, mitä joku haluaa tietää sovelluksen toiminnasta. Tämä joku voi olla kehittäjä, projektipäällikkö tai firman/hankkeen pomo.
Mahdollisia kysymyksiä:
- Montako käyttäjää käyttää sovellusta päivittäin?
- Miten pitkään sovellusta käytetään? (jakauma)
- Montako uutta käyttäjää meillä on, päivittäin?
- Miten pitkään vietetään osiossa X?
- ...
Jostain kysymyksestä voi seurata alakysymyksiä (esim. "Montako kaatumista päivässä?" -> "Minkä selaimen käyttäjillä kaatumisia on eniten?").
Kannattaa välttää:
- turhamaista statistiikkaa ("vanity metrics"). Nämä palvelevat kehittäjän/tiimin/yrityksen egoa, mutta eivät tuo varsinaista tuotannon arvoa.
- keskiarvoja. Ne valehtelevat. Mieluummin jakauma koko datasetistä ja siitä mediaani sekä esim. 5. ja 95. "persentiili" (engl. percentile)
Kysymyksiä on hyvä aika ajoin vaihdella. Näin ei päädytä optimoimaan tiettyjä asioita ja unohdeta loput.
Kuva: Dynatrace > "Use percentiles to analyze application performance"
Keksittekö lisää hyviä kysymyksiä, joihin lokituksella voidaan saada vastaus?
Cloud Logging on osa Google Cloud Platform:ia (GCP). Firebase-projektin luotuasi sinulla on jo saman niminen GCP-projekti olemassa.
GCP Console > (projekti) > Logging:
Koetetaan käyttää valvomonäyttöä.
Ilmaiskäytössä Cloud Logging säilyttää lokeja 30 vrk.
[Firebase Console] > (projekti) > Performance
tbd. KESKEN
Miten tiedot kertyivät lokeihin ja suorituskykykonsoliin?
Katsotaan!
Etsitään projektista (hakemisto packages/app/src) mainintoja central. -kutsuista.
Katsotaan, miten
central.*on toteutettu (sovelluksen ei tarvitse siitä välittää!)
Etsitään projektista mainintoja @ops/perf ja trace:sta.
Tuotantokerros ohjaa nämä suoraan Firebase Performance Monitoringille, joka lisäksi kerää tietoja selaimen yleisestä toiminnallisuudesta.
Automaattisesti kerätään:
- ... tbd.
Mitä liitetietoja Firebase Performance Monitoring lisää keräämäänsä dataan (selaimen tyyppi, mitä muuta?)
Painetaan sovelluksessa Make Error tai kehittäjäkonsolissa throw new Error("boo!").
Jääkö tästä jälki johonkin??
Lokeihin voi päästä käsiksi isompi joukko ihmisiä kuin varsinaiseen sovelluksen tietokantaan. Lokitulosteita on tapana copy-paste:ta esim. virheenetsinnän avuksi tiketöintijärjestelmiin.
Jotta käyttäjätietoa ei koskaan vuotaisi tätä kautta ulos, laadi jotkut ohjeet, joita itse / kaikki kehittäjäsi noudattavat!
Esimerkiksi:
| tieto | kategoria | kommentit |
|---|---|---|
| funktiokutsut, muuttujan nimet tms. | 🟢 | soveltuu lokitukseen |
| käyttäjätunnus | 🟡 | voidaan harkinnalla liittää lokeihin |
| käyttäjän identifioiva data (sposti, nimi, osoite, tilinumero) | 🔴 | ei missään tapauksessa!!! |
| käyttäjän tuottama data | 🔴🔴 | ei missään tapauksessa!!! |
Käyttäjän yksilöinti käyttäjätunnisteesta vaatii pääsyn tietokantaan, joten lokitekstin mahdollinen vuotaminen ei suoraan paljasta esim. hänen sähköpostiosoitettaan. Tässä pitää tasapainoilla, voi riippua myös sovelluksen tyypistä ja käyttäjäkunnasta.
Sanotaan, että teet veppisovellusta, jolla myydään jotain. Miten toimisit, jos asiakkaan tilinumero pitäisi liittää virhelokiin?
Mitä vaihtoehtoja keksit?
Firebase ei ole mitenkään erityisen hyvä web-sovelluksen tuotannon seurannan alustana.
Muita vaihtoehtoja:
-
LogRocket keskittyy vain web-aplikaatioiden tuotannon seurantaan ja analysointiin. Se tarjoaa:
- session replay
- performance monitoring
- product analytics
- error tracking and management
- user experience analytics
Ilmaiskäyttö: hinnasto
- enint. 1000 käyttäjäsessiota / kk asti
- 1kk talletusaika
- 3 kehittäjätunnusta
Sovellusalustan tämä puoli (central.*, trace ja kaatumisten seuranta) on toteutettu siten, että ne eivät ole sidoksissa tiettyyn toimijaan, vaan voit vaihtaa lokitusalustaa koskematta itse sovellukseen. Voit myös käyttää useita alustoja rinnakkain esim. vertailumielessä. 😌
Jos alue kiinnostaa, voit etsiä tietoa seuraavista:
-
Hälytykset. Miten lokien pohjalle voi rakentaa kokonaan automaattisen hälytysjärjestelmän.
- Jotain menee pieleen
- Se näkyy lokeissa
- Lokeille on määritelty filtterit
- Hälytin etsii sinut puhelimella/pikaviestimellä/tms.
- Korjaat tietenkin asian! :)
esim. Cloud Logging > Creating Charts and Alerts
-
SRE Books (Google)
Google loi SRE-käsitteen (Service Reliability Engineer(ing)). Heidän kirja tästä on klassikko ja oivaa luettavaa kaikille softan operoinnista kiinnostuneille!
2021 keväällä linkin takaa löytyy kolme kirjaa (2 luettavissa ilmaiseksi online):
Seuraavaksi: 4 Firebase taustajärjestelmissä