Pˇreruˇsovanou ˇc´arou je zn´azornˇeno pouˇzit´ı dalˇs´ı aplikace. Tedy je zapotˇreb´ı pouze vytvoˇrit nov´y konfiguraˇcn´ı skript s nov´ymi parametry, a t´ım p´adem je potom novˇe vznikl´y csv soubor bez jak´ychkoliv dalˇs´ıch ´uprav.
Konfiguraˇcn´ı skript
V konfiguraˇcn´ım skriptu pro jin´e datov´e zdroje je moˇzn´e mˇenit n´asleduj´ıc´ı parame-try: samotn´y search job, v´ystupn´ı promˇenn´e ze search jobu, interval pro z´ısk´an´ı dat, v´ystupn´ı soubor a popˇr´ıpadˇe log soubor.
V´ystupn´ımi promˇenn´ymi jsou myˇsleny parametry, kter´e se z cel´eho search jobu na-konec z´ıskaj´ı. Aplikace je totiˇz postaven´a tak, aby Splunk search job mˇel na konci form´atov´an´ı do tabulky. To znamen´a, ˇze search job bude vypadat n´asledovnˇe:
1 index=example_search ... | table
Zdrojov´y k´od 2: Poˇzadovan´y form´at search jobu
Za pˇr´ıkaz table (form´atov´an´ı do tabulky) se n´aslednˇe automaticky vloˇz´ı parame-try, kter´e jsou ruˇcnˇe vloˇzeny do datov´e struktury list pˇred samotn´ym search jobem.
D´ıky tomuto ˇreˇsen´ı je potom v hlavn´ım skriptu moˇzn´e automaticky ukl´adat hodnoty do csv souboru, jelikoˇz n´azvy sloupc˚u jsou totoˇzn´e s tˇemito parametry.
Na v´ystupn´ı soubor jsou kladen´e jist´e n´aroky. T´ım je myˇsleno, ˇze soubor mus´ı b´yt pro integraci do Cloudery Hadoop vˇzdy form´atu csv a k´odov´an´ı utf-8. Pakliˇze by se nˇekdy situace zmˇenila, aplikace je na to pˇripraven´a, jelikoˇz v konfiguraˇcn´ım souboru je oddˇelen´y jak n´azev a k´odov´an´ı souboru, tak i jeho pˇr´ıpona. Dalˇs´ım poˇzadavkem je ukl´ad´an´ı timestampu za n´azev souboru, kter´y pˇredstavuje ˇcas vytvoˇren´ı souboru.
Tedy pro tento konkr´etn´ı use case: cakl errorcodes YYYYMMDDHHmmss.csv, kde cakl je n´azev aplikace, errocodes je n´azev tabulky a na konci je form´at timestampu.
Vkl´ad´an´ı timestampu je opˇet ˇreˇseno automaticky bez ruˇcn´ıho z´asahu.
Autentizaˇcn´ı skript
Tento skript opˇet nevyˇzaduje ˇz´adn´y z´asah. Je volan´y z hlavn´ıho skriptu a jednoduˇse si z´ısk´a ´udaje z konfiguraˇcn´ıho souboru a vytvoˇr´ı si session se Splunk frontend no-dem, kterou n´aslednˇe poˇsle do metody pro z´ısk´an´ı dat. Tato session m´a v z´akladn´ı konfiguraci timeout jednu hodinu, coˇz tedy plat´ı i v tomto pˇr´ıpadˇe. Samozˇrejmˇe je to konfigurovateln´y atribut, kter´y lze zmˇenit v obecn´e konfiguraˇcn´ı sekci serveru.
Nejdˇr´ıve je potˇreba vytvoˇrit Splunk uˇzivatele s pr´avy a rolemi pro REST API a obecnˇe REST API povolit na nˇejak´em nodu (tyto vlastnosti nejsou v´ychoz´ı). Pro vytvoˇren´ı session je potˇreba tedy zn´at jm´eno a heslo Splunk uˇzivatele s rol´ı REST API user, host, port a voliteln´y parametr scheme, coˇz je typ spojen´ı (HTTP nebo HTTPS).
20 log_event("error", NAME + " " + str(e))
21 sys.exit(1)
Zdrojov´y k´od 3: Vytvoˇren´ı Splunk session
Hlavn´ı skript
Jak bylo jiˇz zm´ınˇeno, v hlavn´ım skriptu se dˇeje hlavn´ı ˇc´ast transformace dat. Vzhle-dem k poˇzadavku na univerz´alnost a pˇrenositelnost ˇreˇsen´ı je naˇc´ıt´an´ı konfiguraˇcn´ıho skriptu ˇreˇseno pomoc´ı parametru pˇri spouˇstˇen´ı hlavn´ıho skriptu. Funkcionalita je uk´az´ana na n´asleduj´ıc´ım bloku k´odu.
1 if __name__ == '__main__':
2 parser = argparse.ArgumentParser(description='Splunk ETL into hadoop')
3 parser.add_argument("--c", type=str,
4 help="Enter python config file with extension", required=True)
5 args = parser.parse_args()
6 config_name = args.c
7
8 if os.path.isfile(config_name):
9 # in case of another location of config file, or for cron usage
10 config_name = config_name.split("/")[-1]
11 # import of config file from args
12 config_name = config_name.split(".")
13 conf = importlib.import_module(config_name[0])
14 else:
15 log_event("error", NAME +
16 " Config file from command line arguments does not exist: " +
17 config_name)
18 sys.exit(1)
Zdrojov´y k´od 4: Naˇcten´ı konfiguraˇcn´ıho souboru
Po z´ısk´an´ı a naˇcten´ı konfiguraˇcn´ıho skriptu je vytvoˇrena Splunk session. Pokud tento proces probˇehl v poˇr´adku, dalˇs´ım krokem je odesl´an´ı pomoc´ı REST API search job a z´ısk´an´ı v´ysledk˚u. Jak bylo zm´ınˇeno v kapitole 3.2.1, pro odesl´an´ı a z´ısk´an´ı dat je pouˇzit oneshot search. Oneshot search potˇrebuje ve vstupn´ıch atributech samotn´y search job a slovn´ık parametr˚u. Mezi tyto parametry patˇr´ı ˇcasov´y interval, ve kter´em se maj´ı data st´ahnout. Tento ´udaj je opˇet br´an z konfiguraˇcn´ıho souboru. Je t´ım myˇslen ˇcas nejstarˇs´ı ud´alosti. Druh´y ˇcasov´y ´udaj je ˇcas nejnovˇejˇs´ı ud´alosti, tedy ˇcas ve chv´ıli, kdy se operace odehr´av´a. N´aslednˇe m´od search jobu, coˇz je v pˇr´ıpadˇe oneshotu normal mode a nakonec limit pro poˇcet event˚u. Tento limit je nepovinn´y parametr a bez jeho definov´an´ı je limit 100 event˚u. Pro z´ısk´an´ı vˇsech event˚u je
potˇreba nastavit tento parametr na 0. Cel´y tento proces z´ısk´av´an´ı dat je ˇcasovˇe
5 # count:0 => return more than 100 events
6
7 dt_started = datetime.datetime.utcnow()
8 try:
9 oneshotsearch_results = service.jobs.oneshot(SEARCH_QUERY, **kwargs)
10 except Exception as e:
11 log_event("error", NAME + " "+ config.NAME + " " + str(e))
12 sys.exit(1)
13 dt_ended = datetime.datetime.utcnow()
Zdrojov´y k´od 5: Nastaven´ı z´ısk´an´ı dat
Pokud odesl´an´ı search jobu a z´ısk´an´ı dat probˇehlo v poˇr´adku (bez z´ıskan´e v´yjimky), data jsou n´aslednˇe parsov´ana. Datov´y typ z´ıskan´ych dat je objekt Resul-tReader, ve kter´em jsou data uloˇzena ve formˇe slovn´ıku. Ukl´ad´an´ı dat do souboru tedy prob´ıh´a v cyklu, ve kter´em je n´aslednˇe kontrolov´an typ dat. Pokud je form´at slovn´ık, data jsou dle parametr˚u z konfiguraˇcn´ıho souboru ukl´ad´ana do souboru. Po-kud jsou form´atu result.Message, jedn´a se o diagnostick´e zpr´avy. Tedy tyto zpr´avy se ukl´adaj´ı do log souboru. Jedn´a se totiˇz o zpr´avy ze Splunk serveru o moˇzn´e chybˇe.
Po uloˇzen´ı vˇsech dat je do log souboru uloˇzena zpr´ava s levelem info o ´uspˇeˇsn´em uloˇzen´ı dat.
Datov´y model
Vytv´aˇren´ı datov´eho modelu prob´ıhalo v prostˇred´ı Power Designer. Datov´y model je potˇreba pro vytvoˇren´ı prostˇred´ı v data lake. V z´asadˇe se jedn´a o dva json soubory, ve kter´ych jsou pops´ana metadata. Napˇr´ıklad z jak´eho oddˇelen´ı data poch´azej´ı, jak moc jsou citliv´a, jestli se jedn´a o jednor´azov´a data nebo o data pˇr´ır˚ustkov´a. Pokud jde o data pˇr´ır˚ustkov´a, je pops´ano, jak ˇcasto m´a prob´ıhat kontrola nov´eho souboru na
´
uloˇziˇsti, optimalizace dat v date lake a podobnˇe. Vzhledem k jednoduchosti datov´eho
modelu t´eto aplikace nen´ı potˇreba detailnˇe zn´azorˇnovat jeho datov´y model a popisy.
Jedn´a se v podstatˇe o tˇri sloupce. ˇCas vzniku chyby, host a samotn´y identifik´ator chyby.
Datov´y model integrovan´y do data lake tedy vypad´a n´asledovnˇe.