Zas´ıl´an´ı log˚u do Splunku
Aby se nemusel nastavovat mechanismus alert˚u na serveru pˇri vznikl´e kritick´e chybˇe, je vˇzdy nejnovˇejˇs´ı event v log souboru zasl´an do Splunku pomoc´ı curl v bash skriptu.
To se dˇeje pomoc´ı HTTP Event Collectoru (HEC), d´ıky kter´emu je moˇzn´e zas´ılat
data do Splunku pˇres HTTP nebo HTTPS protokol. HEC pouˇz´ıv´a ovˇeˇrov´an´ı pomoc´ı tokenu, kter´y se generuje pro dan´y index. V tokenu jsou uloˇzeny informace, kter´e slouˇz´ı jak k autentizaci, tak i k smˇerov´an´ı a ukl´ad´an´ı dat (na poˇzadovan´y index).
1 #!/bin/bash
2 #Bash script for getting last line from log file and sending it to splunk
3 tag=$( tail -n 1 lastevent )
4 curl -H "Authorization: Splunk token"
5 "https://mysplunkserver.example.com:8088/services/collector/event" -d
6 '{"sourcetype": "_json", "event": '"$tag"'}'
Zdrojov´y k´od 8: Odes´ıl´an´ı eventu z log souboru
M´ısto Splunk token je konkr´etn´ı token vygenerovan´y pro index, do kter´eho se data budou pos´ılat a indexovat. Pro tyto projekty z´ısk´av´an´ı dat ze Splunku byl zaloˇzen nov´y index. Jde o to, ˇze aplikac´ı pro z´ısk´av´an´ı dat bude v budoucnu v´ıce, a tedy je dobr´e m´ıt je pohromadˇe v jednom indexu pro kontrolu a monitoring funkˇcnosti. Sourcetype je pole, kter´e urˇcuje strukturu dat. Tou m˚uˇze b´yt napˇr´ıklad json, csv a dalˇs´ı, kter´e Splunk zn´a a hned je um´ı naparsovat do pol´ı. Sourcetype m˚uˇze b´yt tak´e klidnˇe i n´azev, kter´y neodpov´ıd´a pˇr´ımo struktuˇre dat, jako napˇr´ıklad cisco log. Pokud ale struktura dat bude odpov´ıdat json form´atu, Splunk jej dok´aˇze spr´avnˇe naparsovat.
4.3.2 Testov´ an´ı k´ odu
Vzhledem k t´eto aplikaci nen´ı testov´an´ı aˇz tak rozs´ahl´e. Ve skuteˇcnosti se jedn´a pouze o tˇri testovateln´e metody.
Prvn´ı metoda, kterou lze testovat, je metoda pro vytvoˇren´ı session ve splunk auth skriptu. Ta oˇcek´av´a na vstupu konfiguraˇcn´ı soubor (objekt modulu importlib), ze kter´eho si naˇcte konfiguraci potˇrebnou pro vytvoˇren´ı session. Tato metoda vrac´ı
´
uspˇeˇsnˇe vytvoˇrenou session, pokud pˇri vytv´aˇren´ı session nedoˇslo k v´yjimce.
V n´asleduj´ıc´ıch dvou uk´azk´ach k´odu jsou testov´any pˇr´ıpady spr´avn´eho typu v´ystupn´ıch dat. Tedy zda je v´ystup spr´avn´e instance a zda nejsou data typu None.
1 # Returns True if session is created successfully
2 def test_auth_instance(self):
3 instance = create_instance(conf)
4 self.assertIsInstance(instance, client.Service)
5
6 # Returns True if data are not None
7 def test_auth_none(self):
8 instance = create_instance(conf)
9 self.assertIsNotNone(instance, msg=None)
Zdrojov´y k´od 9: Testov´an´ı metody pro vytvoˇren´ı session
Druhou metodou k otestov´an´ı je metoda pro z´ısk´an´ı dat pomoc´ı REST API. Na v´ystupu se oˇcek´av´a objekt typu ResultsReader, kter´y by nemˇel b´yt pr´azdn´y.
1 # Returns True if data are downloaded successfully
2 def test_results_instance_of_reader(self):
3 instance = create_instance(conf)
4 res = get_search_results(instance, conf)
5 self.assertIsInstance(res, results.ResultsReader)
6
7 # Returns True if data are not None
8 def test_results_not_empty(self):
9 instance = create_instance(conf)
10 res = get_search_results(instance, conf)
11 self.assertIsNotNone(results, msg=None)
Zdrojov´y k´od 10: Testov´an´ı metody pro z´ısk´an´ı spr´avn´eho typu dat
Posledn´ı metoda k otestov´an´ı je metoda, kter´a jiˇz ukl´ad´a data do v´ystupn´ıho souboru. Zde jsou uk´az´any testy, kter´e kontroluj´ı, zda byl v´ystupn´ı soubor vytvoˇren a z´aroveˇn jestli nen´ı pr´azdn´y.
Zdrojov´y k´od 11: Testov´an´ı metody pro pro vytvoˇren´ı v´ystupn´ıho souboru
4.4 Kontrola datov´ eho toku a v´ ysledn´ a anal´ yza dat
Pro kontrolu a testov´an´ı datov´eho toku byly vytvoˇreny reporty v Power BI. Tyto reporty jsou vizualizaˇcnˇe identick´e s reporty ve Splunku.
Jak jiˇz bylo zm´ınˇeno, data jsou stahov´ana ze Splunku vˇzdy na konci smˇeny. To znamen´a, ˇze data se mohla zkontrolovat kdykoliv v pr˚ubˇehu dne, jelikoˇz ve Splunku i v Power BI lze filtrovat data dle ˇcasov´eho rozpˇet´ı (tedy v dobˇe jedn´e smˇeny). Jenˇze automatick´a aktualizace dat z data lake do Power BI musela b´yt otestov´ana p´ar mi-nut po konci smˇeny. Tedy ve skuteˇcnosti jedin´y pˇrijateln´y ˇcas byl na konci rann´ı smˇeny, po 14:00.
Testov´an´ı bylo zah´ajeno v pr˚ubˇehu ´unora. Jeˇstˇe pˇredt´ım, neˇz byla data zas´ıl´ana z data lake do Power BI, prob´ıhaly testy ˇcistˇe pomoc´ı generov´an´ı csv souboru a pro-hled´av´an´ı tˇechto dat ruˇcnˇe. Z poˇc´atku se vˇse zd´alo jeˇstˇe lepˇs´ı, neˇz se oˇcek´avalo, co se t´yˇce rychlosti z´ısk´av´an´ı dat ze Splunku. To hlavnˇe z toho d˚uvodu, ˇze search job je ve skuteˇcnosti sloˇzen ze dvou search job˚u, a ty jsou spojeny pˇr´ıkazem ap-pend. V obou search jobech prob´ıh´a vˇetˇs´ı poˇcet operac´ı nad daty (parsovan´ı pomoc´ı regex˚u, maz´an´ı duplicitn´ıch hodnot, pˇrejmenov´av´an´ı pol´ı apod.). Kv˚uli tˇemto ope-rac´ım (a hlavnˇe kv˚uli pˇr´ıkazu append) search job trv´a ve Splunku i des´ıtky vteˇrin.
Kdeˇzto pˇri z´ısk´av´an´ı dat pomoc´ı tohoto search jobu pˇres REST API byla doba trv´an´ı i s uloˇzen´ım dat do souboru maxim´alnˇe 2 vteˇriny, coˇz bylo ve skuteˇcnosti dost pozoruhodn´e a bylo to br´ano jako ´uspˇech. Ovˇsem kdyˇz byla prvn´ı data zasl´ana do data lake a n´aslednˇe do Power BI, byla zjiˇstˇena chyba. Bylo z´ısk´av´ano v´ıce dat, neˇz by ve skuteˇcnosti mˇelo b´yt. Po nˇekolika hodin´ach debugov´an´ı, testov´an´ı apli-kace a proch´azen´ı logu byla zjiˇstˇena pˇr´ıˇcina. Jednalo se o chybu v konfiguraˇcn´ım skriptu, konkr´etnˇe v samotn´em search jobu. Chyba byla v m´ıstˇe, kde se nastavuje cesta k log souboru pro z´ısk´av´an´ı dat do Splunku. Jedn´a se o cestu k souboru v operaˇcn´ım syst´emu Windows, a tedy jsou pouˇzita zpˇetn´a lom´ıtka. Ve Splunku je jedn´ım zpˇetn´ym lom´ıtkem urˇceno escapov´an´ı, tedy byla pouˇzita dvˇe. Jenˇze v Py-thonu je opˇet zpˇetn´e lom´ıtko pouˇzito pro escapov´an´ı, a tedy doˇslo k tomu, ˇze cesta nebyla korektn´ı. Po opraven´ı t´eto chyby jiˇz byla data spr´avn´a. Nakonec tedy doba
trv´an´ı z´ısk´av´an´ı dat i s uloˇzen´ım trv´a pˇribliˇznˇe 6 vteˇrin.
N´asleduj´ıc´ı dvˇe vizualizace dat zn´azorˇnuj´ı funkˇcnost datov´eho toku a z´aroveˇn umoˇzˇnuj´ı z´ıskat prvn´ı n´ahled na data.
Pod obˇema obr´azky je v popisku uvedeno, ˇze data byla upravena. To je z d˚uvodu citlivosti dat, avˇsak tato ´uprava nijak v´aˇznˇe nezkresluje v´yznam ani smysl vizuali-zace. Zjednoduˇsenˇe ˇreˇceno, nˇekter´e z´aznamy byly odebr´any a jin´e pˇrid´any.
V prvn´ı vizualizaci jsou moˇznosti filtrov´an´ı dat dle ˇcasu, hosta a smˇeny (sekce ˇc´ıslo 1). Samotn´a smˇena nen´ı souˇc´asti dat, ale d´ıky znalosti zaˇc´atku a konce smˇen lze pˇridat odpov´ıdaj´ıc´ı hodnoty do nov´eho sloupce.
1 Smˇena = each if [Time] >= #time(22,0,0) then "noˇcn´ı" else if
2 [Time] >= #time(14,0,0) then "odpoledn´ı" else if
3 [Time] >= #time(6,0,0) then "rann´ı") else if
4 [Time] < #time(6,0,0) then "noˇcn´ı" else "?"
Zdrojov´y k´od 12: Pˇrid´an´ı sloupce smˇeny v Power BI
V t´eto vizualizaci jsou d´ale ˇctyˇri objekty reprezentuj´ıc´ı data. V prvn´ı sekci je moˇzn´e filtrovat data. Sekce ˇc´ıslo dva reprezentuje matici poˇctu chyb. ˇR´adky jsou poˇcty chyb v dan´em ˇcase a sloupce jsou samotn´a ˇc´ısla chyb. Ve tˇret´ı sekci je graf, kter´y zn´azorˇnuje pr˚ubˇeh chyb v ˇcase pro dan´eho hosta. Sekce ˇc´ıslo 4 ud´av´a celkov´y poˇcet chyb a sekce ˇc´ıslo 5 zn´azorˇnuje rozloˇzen´ı chyb. Je moˇzn´e si povˇsimnout ˇcern´eho obd´eln´ıku, ve kter´em se nach´az´ı bliˇzˇs´ı informace pro vybran´y datov´y ´usek. Zde je opˇet nav´ıc pole n´azev dne, kter´e tak´e nebylo souˇc´ast´ı dat, ale bylo stejnˇe jako sloupec pro smˇenu pˇrid´ano do datov´e sady v Power BI.