ERK'2022, Portorož, 187-190 187 Zajemanje in vizualizacija agregiranega dnevnika dogodkov sistema Symbiot Amadej Pavšiˇ c 1 , Matevž Pustišek 2 , Luka Mali 3 1 Fakulteta za elektrotehniko in Fakulteta za raˇ cunalništvo in informatiko, Univerza v Ljubljani 2, 3 Fakulteta za elektrotehniko, Univerza v Ljubljani E-pošta: 1 ap5512@st.udent.uni-lj.si, 2 matevz.pustisek@fe.uni-lj.si, 3 luka.mali@fe.uni-lj.si Capturing and visualizing the aggregated event log of the Symbiot system The article defines the problem of displaying a specific Symbiot system aggregated event log and seeks a solution for it. The main problem of the Symbiot system in the area of event log display is not having one overall view of all event logs of the system and thus its inability to locate and drill-down any errors in the system. With defined requirements and use-case, we have re- searched technologies to create an integrated solution of event log visualization. The scope of the solution includes the data flow and the display of the data on the web in- terface. Using our research results, two proof-of-concept solutions have been made, using two open-source data observation platforms - Grafana and Kibana. Comparing the two solutions, we concluded, that the Kibana platform emphasises data exploration, while the Grafana platform emphasises a modular interface con- struction that serves as a final solution presented to the client. Based on the specific requirements of the task, we concluded that the concept of the Grafana solution, due to its data use philosophy and the individual components that suit our specific use case, is more appropriate. 1 Uvod V ˇ clanku smo se osredotoˇ cili na dnevniške zapise dogod- kov (ang. event logs, v nadaljevanju tudi: „dnevnik do- godkov“, „dnevniški zapisi“). Dnevnik dogodkov je, na kratko, zbirka zapisov dogodkov, ki nam z raznimi po- datki (kot so ˇ casovni žig, vir dogodka, nivo resnosti, spo- roˇ cilo dogodka ipd.) povedo, kaj se na posameznih kom- ponentah nekega programskega sistema dogaja [1]. Z vedno veˇ cjimi in bolj kompliciranimi programskimi sistemi se veˇ ca tudi število operacij in dogodkov. ˇ Ce že- limo tak sistem razumeti in ohranjati njegovo varnost, so dnevniki dogodkov nepogrešljiva pomoˇ c. Ker je spre- mljanje ter odpravljanje morebitnih napak na sistemu ve- liko lažje z grafiˇ cnim uporabniškim vmesnikom, ki prika- zuje zapise dogodkov za trenutni in pretekli ˇ cas, je smi- selno ustvarjati vizualizacije dnevnikov dogodkov siste- mov. Ker je naloga nastala v sodelovanju s podjetjem, ki je avtorjev štipenditor, se osredotoˇ ca specifiˇ cno na prikaz doloˇ cenega dnevnika dogodkov sistema Symbiot podje- tja Iskraemeco. S tem naloga ne predstavlja le raziskave podroˇ cja, temveˇ c ponuja dejanski primer problema, ki ga je treba rešiti s praktiˇ cnim konceptom rešitve, ki doka- zuje uporabnost raziskanih tehnologij. Namen praktiˇ cne rešitve je izboljšava trenutnega sistema prikaza dnevnika dogodkov in izpolnitev dejanskih zahtev strank in arhi- tektov sistema Symbiot. 2 Sistem Symbiot Sistem Symbiot, produkt podjetja Iskraemeco, je adap- tivna in pametna programska platforma, ki omogoˇ ca eno- stavno, varno in avtomatizirano upravljanje podatkov v realnem ˇ casu [2]. Primarno je uporabljena za povezo- vanje elektriˇ cnih števcev v t. i. pametno omrežje (ang. smart grid) z arhitekturo AMI (ang. Advanced Meter In- frastructure). Arhitektura AMI predvideva dve glavni komponenti sistema – MDM (ang. Meter Data Management) in HES (ang. Head-End System), kar omogoˇ ca dvosmerno ko- munikacijo med pametnimi števci in programsko plat- formo ter s tem prejemanje in procesiranje podatkov v realnem ˇ casu, kar poslediˇ cno pomeni efektivnejše in pa- metnejše upravljanje s celotnim sistemom [3]. Sistem Symbiot je zgrajen modularno, tako da ima vsaka od teh dveh komponent polno prilagodljivih razliˇ cnih storitev, ki opravljajo specifiˇ cne naloge – povezovanje z napravami, branje podatkov iz naprav, pridobivanje podatkov iz po- datkovnih baz itd. 2.1 Trenutno stanje sistema Uporabniki sistem primarno upravljajo preko namiznega programa Symbiot Configurator, ki omogoˇ ca podrobno upravljanje z vsako komponento sistema posebej. Prav tako ponuja pregled ter dodajanje baz podatkov, naprav in ostalih komponent ter vrsto drugih funkcionalnosti. Vse komponente v sistemu Symbiot informacije o iz- vršenih nalogah zapisujejo v dnevnik dogodkov. Zaen- krat so dnevniški zapisi dogodkov prikazani loˇ ceno po storitvah in vidni le z razliˇ cico Windowsovega programa Event Log Viewer znotraj aplikacije Symbiot Configura- tor, prikazano na sliki 1. 2.2 Želeno stanje sistema Znotraj podjetja se je razvila rešitev agregiranja dnev- nikov dogodkov posameznih storitev in so dostopni na enem viru. Ideja je, da se ta združen dnevnik dogodkov 188 Slika 1: Prikazan dnevnik dogodkov storitve Symbiot Mete- rAccess. Vidni so tudi zavihki z nekaterimi ostalimi storitvami. sistema Symbiot vizualizira na nadzorni plošˇ ci, ki upo- rabnikom omogoˇ ca enostaven pregled nad celotnim siste- mom in predvsem lažje odkrivanje in odpravljanje težav. Definirali smo tudi zahteve tovrstne plošˇ ce in jih gra- fiˇ cno prikazali na skici 2. Glavni komponenti sta grafiˇ cni prikaz števila napak po ˇ casu ter tekstualni prikaz v obliki seznama dnevniških zapisov dogodkov, ki se ujemajo s ˇ casovnim razponom grafa. Poleg tega je nujno filtriranje dogodkov glede na ˇ cas, izvor in nivo resnosti. Opcijski pa so še dodatni številˇ cni prikazi v pomoˇ c, npr. odstotek napak in število zapisov glede na izvor. Slika 2: Skica želenega uporabniškega vmesnika z zahtevanimi komponentami. 2.3 Primer uporabe Z našo rešitvijo tako želimo izpolniti sledeˇ ci primer upo- rabe (ang. use-case). Uporabnik opazi, da sistem Sym- biot ne deluje, kot bi moral, zato odpre nadzorno plošˇ co s prikazanim agregiranim dnevnikom dogodkov. Na plošˇ ci izbere ˇ casovni interval zadnjih treh ur in na grafu takoj opazi anomalijo – izbruh napak. ˇ Casovni interval omeji samo na to špico napak in dogodke filtrira samo po nivoju resnosti napake. Prestavi se na seznam dogodkov, kjer lahko po kronološko razporejenih dogodkih išˇ ce izstopa- joˇ cega. Ko na seznamu klikne na posamezni dogodek, se mu prikažejo podrobnosti le-tega. Tako poišˇ ce izvor pro- blema, torej tisti dogodek ali skupino njih, ki so sprožili celoten izbruh napak. 3 Tehnologije prikazovanja dnevnika dogod- kov Tekom naloge smo raziskali tehnologije, ki se navezujejo na podroˇ cje celostne rešitve prikazovanja dnevnika do- godkov, kar obsega zaledni (ang. backend) in ˇ celni (ang. frontend) del. Na podlagi ugotovitev smo izbrali naju- streznejše posamezne tehnologije, ki bodo predstavljale posamezne komponente za gradnjo celotne rešitve. 3.1 Platforme za vizualizacijo dnevnikov dogodkov Sploh v zadnjih letih se razvija veliko platform za vizu- alizacijo dnevniških zapisov dogodkov. Vsaka se osre- dotoˇ ca na posamezni problem gradnje tovrstnih rešitev, ampak v splošnem sta zelo priporoˇ cani odprtokodni re- šitvi Grafana in Kibana, zato smo se tudi sami odloˇ cili za podrobnejši pregled le-teh. Poleg tega imata obe tudi številno in aktivno skupnost, v kateri je bil preizkušen in rešen že marsikateri problem, kar precej olajša reševanje ovir pri gradnji lastne rešitve. 3.1.1 Grafana Loki sklad Grafana je celostna rešitev opazovanja in analize podat- kov iz katerekoli baze podatkov [4]. Primarno se osre- dotoˇ ca na prikaz merjenih podatkov, ampak ponuja tudi možnosti prikaza dnevnikov dogodkov. Velika prednost Grafane je možnost integracije z mnogo razliˇ cnimi zale- dnimi enotami za shranjevanje podatkov. Skupaj z Gra- fano lahko uporabimo sistem znotraj Grafana sklada, spe- cifiˇ cno ustvarjen za reševanje zaledja dnevniških zapisov dogodkov, Grafana Loki [5]. Loki poskrbi za indeksira- nje in shranjevanje podatkov v lokalno bazo, da ob poi- zvedbi iz spletnega vmesnika Grafana vrne ustrezen re- zultat. 3.1.2 Kibana in Elastic sklad Kibana pa je samo ˇ celni del celotnega t. i. Elastic sklada (ang. Elastic stack) [6]. Za svoje delovanje tako nujno potrebuje sistem Elasticsearch, ki predstavlja univerzalni zaledni del in v našem primeru poskrbi tudi za indeksira- nje in shranjevanje podatkov. Je pa Elastic sklad že pri- marno usmerjen v prikazovanje dnevnikov dogodkov in se v prikaz podatkov drugih vrst usmerja šele zadnja leta. 3.2 Podatkovni tok Da bi se podatki ustrezno prikazovali, moramo poskrbeti tudi za primeren dotok podatkov do platforme za vizuali- zacijo. Na splošno je proces toka podatkov pri podobnih sistemih sestavljen iz: 1. virov, ki podatke ustvarijo; 2. podatkovnega cevovoda, ki podatke združi in obdela; 3. ponorov, ki podatke uporabijo za nadaljnjo uporabo. Slika 3: Splošni diagram toka podatkov v kontekstu prikazova- nja velike koliˇ cine podatkov. Slednji proces je prikazan tudi s shemo na Sliki 3. Za naš primer so ti viri razne komponente sistema Symbiot, torej od elektriˇ cnih števcev do raznih Windows storitev, 189 baz podatkov itn. Ponor podatkov pa bo spletni vmesnik z vizualizacijo podatkov Grafana oziroma Kibana. Vsi procesi med njimi spadajo pod pojem podatkovnega ce- vovoda, ki ga lahko definiramo kot „skupek procesov, ki premikajo in preoblikujejo podatke iz raznih virov do ne- kega cilja, kjer se iz podatkov pridobi nova znanja in in- formacije“ [7]. 3.2.1 Apache Kafka Za združevanje podatkov iz razliˇ cnih virov poskrbi že zu- nanja rešitev podjetja. Za našo nalogo smo imeli efek- tivno en vir podatkov v obliki Kafka teme, zapisi dogod- kov pa so v JSON obliki. Apache Kafka je odprtokodna platforma za porazdeljeno pretakanje dogodkov [8]. Kon- ceptualno je dogodek za Kafko sporoˇ cilo z doloˇ cenim ˇ ca- sovnim žigom, kljuˇ cem ter vrednostjo in dodatnimi me- tapodatki. Kafka se izvaja v skupku strežnikov in se tako enostavno horizontalno razširi. Dogodki se organizirajo in shranjujejo v t. i. temo (ang. topic), ki jo lahko po- enostavljeno enaˇ cimo z mapo v datoteˇ cnem sistemu, da- toteke znotraj mape pa predstavljajo posamezne dogodke [8]. 3.2.2 Posrednik podatkov Ker direktna povezava Kafka teme z Grafano ali Kibano ni bila mogoˇ ca, je bil potreben še posrednik podatkov. Kljub temu da imata sklada obeh omenjenih platform tudi svoje posrednike, smo izbrali eno univerzalno orodje za posredovanje podatkov, Vector [9]. Izraz posrednika je lahko podcenjujoˇ c, saj ima v primeru predstavljene arhi- tekturne zasnove podatkovnega cevovoda le-ta osrednjo nalogo. Posrednik Vector, predstavljen tukaj, je pravza- prav „uživalec podatkov“ (ang. data ingester), torej skrbi za ekstrahiranje in nalaganje (ali „izvlek in potisk“) po- datkov. Poleg uživanja podatkov skrbi tudi za lahko trans- formacijo podatkov v obliki poenotenja oblike in oznaˇ ce- vanja podatkov. 3.2.3 Zasnova in struktura podatkovnega cevovoda Sedaj lahko s Sliko 4 tudi podrobneje predstavimo, kako za naš primer izgleda podatkovni tok. Cevovod ima lahko razliˇ cne strukture. Najbolj uporabljena sta ELT in ETL struktura, kjer ˇ crke v kratici pomenijo E – ekstrakcija (ang. extraction), L – nalaganje (ang. loading) in T – transformacija (ang. transformation). Struktura nam tako pove vrstni red, v katerem se omenjene operacije nad po- datki izvajajo. Pri ekstrakciji podatkov si delo razdelita Kafka in Vec- tor, saj slednji izvleˇ ce podatke iz Kafkine teme, kjer so agregirani podatki tudi že ekstrahirani iz drugih zuna- njih virov. Potem sledi prva, t.i. „lahka“, transforma- cija znotraj orodja Vector, nato pa se podatki potisnejo (oziroma „naložijo“, kar predstavlja „L“ del v strukturi) v Loki oziroma Elasticsearch, kjer pa se še enkrat in bolj znatno transformirajo, ko jih omenjeni orodji skladno s svojo sistemsko zgradbo indeksirata in shranita. Zaradi te dvojne transformacije je struktura našega cevovoda malo bolj specifiˇ cna in se imenuje EtLT [10], kjer „t“ predsta- vlja omenjeno lahko transformacijo na posredniku Vec- tor. Slika 4: Podrobni prikaz podatkovnega toka za naš primer. 4 Gradnja konceptnih rešitev Zavoljo ˇ cim realnejše primerjave omenjenih tehnologij je bilo najbolje narediti dve rešitvi, ki se ju je nato med seboj primerjalo. Postavitev in konfiguracija posrednika podatkov Vector ter sistemov Loki in Elasticsearch je bila precej enostavna, potrebno je bilo samo fino uglaševanje. Gradnja spletnih vmesnikov na obeh platformah Gra- fana in Kibana temelji na grafiˇ cnih vsebnikih ali vstavkih (ang. panel). Konˇ cni nadzorni plošˇ ci sta prikazani na Sli- kah 5 in 6. Tudi tukaj z gradnjo ni bilo veˇ cjih težav, saj sta obe platformi zelo intuitivni za uporabo. Slika 5: Celotna rešitev s spletnim vmesnikom Grafana. Slika 6: Celotna rešitev s spletnim vmesnikom Kibana. 5 Primerjava rešitev Obe rešitvi zadovoljujeta zahteve in rešujeta primer upo- rabe, kljub temu pa je med konˇ cnima rešitvama nekaj opaznih razlik. 5.1 Primerjava uporabniških vmesnikov Prva veˇ cja razlika je v grafiˇ cnem prikazu števila zapisov glede na ˇ cas. Pri Kibani je graf t. i. naložen stolpˇ cni grafikon in je za naš primer prikaza zapisov dogodkov 190 s tremi razliˇ cnimi resnostmi zelo pregleden. Pri Grafani tak graf ni bil mogoˇ c, zato so zapisi prikazani s ˇ crtnim grafikonom. Druga opazna razlika pa je v seznamu dnevniških za- pisov dogodkov. Pri Kibani se seznam enostavno gene- rira, ampak nima naprednejših možnosti ali obarvanosti glede na nivo resnosti dogodkov. Pri Grafani ima seznam že privzeto obarvane dogodke, ampak ni pa dobro prila- gojen prikazovanju JSON oblike podatkov, zato smo pre- izkusili še ustvarjanje lastnega vstavka v Grafani. 5.2 Ustvarjanje lastnega vstavka v Grafani Grafana ponuja dokaj obsežno dokumentacijo za ustvar- janje lastnih grafiˇ cnih vsebnikov, ki se jih nato enostavno doda na nadzorno plošˇ co. Tudi gradnja vstavka nekomu z znanjem React okvirja ter jezika Typescript ne predsta- vlja veˇ cjih težav. Tako smo ustvarili seznam dnevnika dogodkov, viden na Sliki 5, ki je tako pregleden kot pri- lagodljiv. Kibana tovrstnega ustvarjanja ne podpira tako kot Grafana. 5.3 Primerjava pristopov k prikazovanju podatkov Ob gradnji smo prišli do zakljuˇ cka, da se platformi osre- dotoˇ cata na razliˇ cna naˇ cina uporabe spletnih vmesnikov. Pri Grafani je veˇ cji poudarek na posameznih vstavkih — vsak vstavek ima svojo poizvedbo, lahko tudi iz razliˇ cnih virov. Prav tako se podatke lahko filtrira za vsak vstavek posebej. Medtem ima pregledna plošˇ ca pri Kibani na- ˇ celoma samo eno glavno poizvedbo in tudi filtriranje se naˇ celoma izvede na vseh vstavkih na plošˇ ci. Uporaba Ki- bane je tako bolj usmerjena v sprotno raziskovanje podat- kov, z rednim spreminjanjem poizvedbe in opazovanjem relacij na enem viru, Grafana pa bolj spodbuja gradnjo plošˇ ce kot neke zakljuˇ cene rešitve, z jasneje definiranimi poizvedbami in z vnaprej doloˇ cenimi vhodnimi podatki, kar nam za naš primer izgradnje vmesnika za stranko bolj ustreza. 5.4 Primerjava uˇ cinkovitosti Loki in Elasticsearch se razlikujeta v naˇ cinu indeksiranja podatkov. To je najbolj vidno pri uˇ cinkovitosti sistemov. S testiranjem smo prišli do zakljuˇ cka, ki je bil glede na in- deksiranje tudi priˇ cakovan – Grafana porabi veliko manj pomnilnika, procesorja in predvsem prostora na disku, ampak za ceno poˇ casnejšega nalaganja poizvedb. Kibana ima v primerjavi z Grafano praktiˇ cno takojšnje ˇ case na- laganja, ne glede na velikost poizvedbe, ampak porabi temu primerno veˇ c virov in prostora. Z vidika uˇ cinkovi- tosti smo za ustreznejšo platformo doloˇ cili Grafano, samo zaradi dejstva, da nam glede na zahteve podjetja in strank veˇ c pomenijo prosti raˇ cunalniški viri. 5.5 Možne izboljšave Ena od možnih izboljšav je obogatitev rešitve z umetno inteligenco. Obe platformi uporabnikom s plaˇ cljivimi na- roˇ cninami ponujata grajenje strojno nauˇ cenih modelov že kar preko spletnega vmesnika. Kibana se osredotoˇ ca bolj na zaznavanje anomalij v dnevniku dogodkov, medtem ko Grafana kot platforma za prikaze meritev ponuja tudi naprednejše modele z napovedovanjem podatkov ter di- namiˇ cnim opozarjanjem. Mogoˇ ce pa je tudi ustvariti svoj model, ga na spletni vmesnik pošiljati kot zunanji vir in prikazovati skupaj z dejanskimi podatki. To bi bila smi- selna nadgradnja obeh rešitev, ki predstavlja še en korak naprej v prihodnost vizualizacije dnevnika dogodkov in daje dodano vrednost sistemu. 6 Zakljuˇ cek V nalogi smo raziskali rešitve prikazovanja dnevnika do- godkov, ki se v zadnjem ˇ casu zelo razvijajo in so ve- dno bolj v uporabi. Ob podrobnejši raziskavi in gradnji konceptne rešitve z dvema odprtokodnima platformama, Grafano in Kibano, smo lahko spoznali, da je razvoj re- šitev relativno enostaven ter pri obeh zelo podoben. Vse- eno je takoj opazno, da je vsak sistem narejen za reševa- nje doloˇ cenih problemov, kar se odseva v filozofiji vme- snikov in naˇ cinu uporabe. Na podlagi teh razlik smo prišli do zakljuˇ cka, da je sklad Grafane primernejši za specifiˇ cno zadan problem, saj nam kot razvijalcem omogoˇ ca lažji razvoj eksaktne re- šitve ter hkrati dovoljuje veliko fleksibilnosti za vse spe- cifiˇ cne potrebe strank. Glavni namen koncepta rešitve – omogoˇ citi uporabniku vmesnik, da enostavno, pregledno in uˇ cinkovito pregleduje dnevnik dogodkov ter da ob po- javitvi napak vzrok poišˇ ce na enostaven naˇ cin – je bil do- sežen pri obeh rešitvah. Literatura [1] A. Chuvakin et al., Logging and log management: the authoritative guide to understanding the concepts sur- rounding logging and log management, ch. 1. Else- vier/Syngress, 2013. [2] Iskraemeco, “Symbiot.” Dosegljivo na: https://symb iot.iskraemeco.com/. [Dostopano: 19. 1. 2022]. [3] T. N. Le et al., “Advanced Metering Infrastructure Based on Smart Meters in Smart Grid,” v Smart Metering Te- chnology and Services - Inspirations for Energy Utilities, IntechOpen, 2016. [4] Grafana Labs, “Grafana: The open observability plat- form.” Dosegljivo na: https://grafana.com. [Do- stopano: 3. 1. 2022]. [5] Grafana Labs, “Grafana loki.” Github, Dosegljivo na: ht tps://github.com/grafana/loki. [Dostopano: 26. 1. 2022]. [6] Elasticsearch B.V ., “Elastic sklad.” Dosegljivo na: http s://www.elastic.co. [Dostopano: 31. 1. 2022]. [7] J. Densmore, Data Pipelines Pocket Reference, ch. 1. O’Reilly Media, Inc., 2021. [8] Apache Software Foundation, “Kafka 3.1 Documenta- tion.” Dosegljivo na: https://kafka.apache.o rg/documentation/. [Dostopano: 23. 2. 2022]. [9] Datadog, Inc., “Vector.” Dosegljivo na:https://vect or.dev/. [Dostopano: 14. 2. 2022]. [10] J. Densmore, Data Pipelines Pocket Reference, ch. 3. O’Reilly Media, Inc., 2021.