Sündmusteenuste monitooring riigi IT-majade näitel
Organisatsiooni nimi
Riigi Infosüsteemi Amet
Kokkuvõte
Meil tulevad Sündmusteenused ja need koosnevad mitmetest osateenustest mis paiknevad erinevates IT-majades aga kodanikule/ettevõtjale paistavad nad välja ühtse teenusena.
Probleem mis vajaks lahendamist on see, et oleks vaja nüüd logida, monitoorida, jälitada pöördumisi ja nende põhjal anomaaliaid tuvastada, statistikat koguda jne. Kuna pöördumised kulgevad üle erinevate IT-majade ja saab alustada erinevatest kohtadest nii e-teenustest, kui ka ametnike poolt. Selleks on nüüd vaja välja mõelda lahendus, kuidas kogu logi ühte kohta kokku koguda või vajadusel logisi üle API-de pärida. Seda on vaja ,et teenuse haldajatel/omanikel oleks üks keskne koht kust kiiresti võimalik teada saada , kus probleem juhtus ja mis juhtus, mitte ei peaks põrgatama, it-majade vahel seda infot.
Meil analüüs ka tehtud aga seal nüüd vaja rohkem detaili minna, siin väike väljavõtte selle kohta.
Logimine:
Süsteemi igas komponendis tuleb süsteemsed ja kasutajate tegevused ning veaolukorrad logida ning logikirjed tsentraalselt kokku koguda indekseeritud logi andmebaasi. Logima peab tegevusi nii palju kui vajalik ja nii vähe kui võimalik selleks, et logide pealt oleks võimalik teostada monitooringu ja analüütilisi tegevusi.
Monitooring:
Tehniliste komponentide monitooring peab võimaldama kiirelt tuvastada komponentide rikkeid või ebaoptimaalset toimivust. Konteinerite paigalduskeskkond Kubernetes platvorm pakub selleks baasfunktsionaalsust, võimaldades jälgida komponentide /health API-t, mille pealt tuvastada teenuse tõrge. Tõrke korral üritab Kubernetes teenust uuesti käivitada.
Kubernetes jälgib ka komponentide ressursside (CPU, mälu) kasutust, võimaldades paindlikult ressursse suurendada ja konteinerite instantse automaatselt juurde tekitada (vertikaalne ja horisontaalne skaleerimine).Selleks peavad komponendid väljastama meetrika andmeid vastava API kaudu. Meetrika kogumiseks saab kasutadaPrometheus meetrika formaati, mille integreerimine SpringBoot põhistes teenustes ei nõua lisaarendus. Kubernetes võimaldab monitooringuandmete jälgimist ja probleemide tekkimisel teavituste saatmist Grafana analüütika tarkvaramooduliga.
Erinevad teenuste süsteemid võivad olla paigaldatud teiste asutuste majutuskeskkondadesse, sellisel juhul ei saa kasutada tsentraalseid Kubernetes keskkonda paigaldatud monitooringu lahendusi. Nagu eelnevalt kirjeldatud, peavad sellised süsteemid pakkuma staatus API't, mille põhjal on võimaliktuvastada väliste teenuse süsteemide rikked. Väliste süsteemide staatuse monitoorimiseks võib kasutada Zabbix tarkvara, mis võimaldab API põhiselt koguda andmeid teenuse toimivuse kohta.
Monitooringu funktsionaalsuse osaks peab olema ka kasutajate käitumise kohta andmete kogumine. Selleks saab kasutada erinevaidlahendusi, mis koguvad andmeid kasutaja tegevuste erinevate aspektide kohta.
Tsentraalsed logid Elasticsearch andmebaasis -logide põhiselt on võimalik kokkukoguda kasutajate päringud, mis on teostatud läbi staatuspaneeli. Nende analüüs võimaldab vastata küsimustele, millistest süsteemidest kasutajate andmeid päriti. Ka tsentraalses süsteemis paigaldatud teenuste süsteemide logi saab koguda samasse andmebaasi.
Päringute jälgimiseks erinevate teenuste vahel kasutada OpenTelemetry lahendust.
eenuse süsteemide kasutamise kohta tekivad andmed teenuse süsteemi logiserverisse, mida tsentraalses analüütikasüsteemis kasutada ei saa. Teenusepõhise analüütika vajadus tuleb tuvastada teenuse loomise detailanalüüsi käigus. Selliste andmed peavad vastama küsimusele näiteks mitu avaldust on esitatud. Antud statistilised andmed tuleb salvestada teenuse süsteemi andmebaasi ja need API kaudu tsentraalsele süsteemile väljastada.
Kasutajate tegevused kasutajaliideses saab kokku koguda spetsiaalse veebianalüütika vahendeid pakkuva tarkvaraga, näiteks Matomo. Kogutud andmete põhjal saab väljastada erinevate teenussüsteemide kasutusstatistika ning kasutusteekonnad.
Probleem mis vajaks lahendamist on see, et oleks vaja nüüd logida, monitoorida, jälitada pöördumisi ja nende põhjal anomaaliaid tuvastada, statistikat koguda jne. Kuna pöördumised kulgevad üle erinevate IT-majade ja saab alustada erinevatest kohtadest nii e-teenustest, kui ka ametnike poolt. Selleks on nüüd vaja välja mõelda lahendus, kuidas kogu logi ühte kohta kokku koguda või vajadusel logisi üle API-de pärida. Seda on vaja ,et teenuse haldajatel/omanikel oleks üks keskne koht kust kiiresti võimalik teada saada , kus probleem juhtus ja mis juhtus, mitte ei peaks põrgatama, it-majade vahel seda infot.
Meil analüüs ka tehtud aga seal nüüd vaja rohkem detaili minna, siin väike väljavõtte selle kohta.
Logimine:
Süsteemi igas komponendis tuleb süsteemsed ja kasutajate tegevused ning veaolukorrad logida ning logikirjed tsentraalselt kokku koguda indekseeritud logi andmebaasi. Logima peab tegevusi nii palju kui vajalik ja nii vähe kui võimalik selleks, et logide pealt oleks võimalik teostada monitooringu ja analüütilisi tegevusi.
Monitooring:
Tehniliste komponentide monitooring peab võimaldama kiirelt tuvastada komponentide rikkeid või ebaoptimaalset toimivust. Konteinerite paigalduskeskkond Kubernetes platvorm pakub selleks baasfunktsionaalsust, võimaldades jälgida komponentide /health API-t, mille pealt tuvastada teenuse tõrge. Tõrke korral üritab Kubernetes teenust uuesti käivitada.
Kubernetes jälgib ka komponentide ressursside (CPU, mälu) kasutust, võimaldades paindlikult ressursse suurendada ja konteinerite instantse automaatselt juurde tekitada (vertikaalne ja horisontaalne skaleerimine).Selleks peavad komponendid väljastama meetrika andmeid vastava API kaudu. Meetrika kogumiseks saab kasutadaPrometheus meetrika formaati, mille integreerimine SpringBoot põhistes teenustes ei nõua lisaarendus. Kubernetes võimaldab monitooringuandmete jälgimist ja probleemide tekkimisel teavituste saatmist Grafana analüütika tarkvaramooduliga.
Erinevad teenuste süsteemid võivad olla paigaldatud teiste asutuste majutuskeskkondadesse, sellisel juhul ei saa kasutada tsentraalseid Kubernetes keskkonda paigaldatud monitooringu lahendusi. Nagu eelnevalt kirjeldatud, peavad sellised süsteemid pakkuma staatus API't, mille põhjal on võimaliktuvastada väliste teenuse süsteemide rikked. Väliste süsteemide staatuse monitoorimiseks võib kasutada Zabbix tarkvara, mis võimaldab API põhiselt koguda andmeid teenuse toimivuse kohta.
Monitooringu funktsionaalsuse osaks peab olema ka kasutajate käitumise kohta andmete kogumine. Selleks saab kasutada erinevaidlahendusi, mis koguvad andmeid kasutaja tegevuste erinevate aspektide kohta.
Tsentraalsed logid Elasticsearch andmebaasis -logide põhiselt on võimalik kokkukoguda kasutajate päringud, mis on teostatud läbi staatuspaneeli. Nende analüüs võimaldab vastata küsimustele, millistest süsteemidest kasutajate andmeid päriti. Ka tsentraalses süsteemis paigaldatud teenuste süsteemide logi saab koguda samasse andmebaasi.
Päringute jälgimiseks erinevate teenuste vahel kasutada OpenTelemetry lahendust.
eenuse süsteemide kasutamise kohta tekivad andmed teenuse süsteemi logiserverisse, mida tsentraalses analüütikasüsteemis kasutada ei saa. Teenusepõhise analüütika vajadus tuleb tuvastada teenuse loomise detailanalüüsi käigus. Selliste andmed peavad vastama küsimusele näiteks mitu avaldust on esitatud. Antud statistilised andmed tuleb salvestada teenuse süsteemi andmebaasi ja need API kaudu tsentraalsele süsteemile väljastada.
Kasutajate tegevused kasutajaliideses saab kokku koguda spetsiaalse veebianalüütika vahendeid pakkuva tarkvaraga, näiteks Matomo. Kogutud andmete põhjal saab väljastada erinevate teenussüsteemide kasutusstatistika ning kasutusteekonnad.
Lõputöö kaitsmise aasta
2021-2022
Juhendaja
Keegi ülikoolist?
Suhtlemiskeel(ed)
eesti keel
Nõuded kandideerijale
Tase
Magister
Märksõnad
Kandideerimise kontakt
Nimi
Peeter Madisson
Tel
E-mail