Graylog2: předávání logu a JSON

[MP]

Ahoj,

studuju moznosti graylog2, a nez se zapletu do ruznych temnych zakouti a nechal se navest na nevhodne cesty, tak bych se predem chtel zeptat:

1] jaka je momentalne nejlepsi cesta pro predavani logu? Zkousim to ted proti nginx takto (GELF):

Kód: [Vybrat]

log_format  graylog2_format  '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$http_x_forwarded_for" ';

access_log syslog:server=IP:12301 graylog2_format;
error_log syslog:server=IP:12302;
To ale logicky prestane logovat do souboru. Pokud bych chtel logovat do souboru a nasledne to pak z nej tahat a predavat do graylogu, co je momentalne nejlepsi zpusob? nxlog? filebeat? sidecar+neco?

2] vyplati se prevest logovani na json? Jednak v pripade multiline jsonu to znemozni grepy apod, jednak je to narust z hlediska obsazeneho mista. Na druhou stranu, lepe se to parsuje nez s regexpy.

3] Pokud Vam to bezi nekde v produkci, jaky HW jste na to museli pouzit, aby to "fungovalo" ve Vasem rozsahu? Staci mi v tuto chvili nonHA reseni.

[Reklama]

[Madmucho]

Dobrý den,
Na Windows klientech používáme nxlog s konfigurací když neni spojení tak loguj do buffru a když zas je pošly to port 12201 GELF na graylog, loguji se tam i txt logy jako iis nebo dhcp nxlog na to ma konfigurace.

Na linux strojích name normalně přesměrovaný syslog na port 514 graylogu.

Logujeme po vyhrazené síti takže nepoužíváme ani JSON ani ssl, máme to zabaleno ve vlan, né vše co tam logujeme je schopné logy balit do ssl.

Obecně je to strašne žravé, máme dva nody v clusteru graylogu tj. s replikou.
Indice děláme po 50GB další nové starší x se mažou, jelikož není místo, a když dojde místo je fakt problém.
Celkem máme 550Gb dat jsou to tak 4 měsice logů zpět, ale např AD object access, kdo kdy změnil učet resnul heslo, přidal skupinu, změnil členství ve skupině AD, jsou na to hezké Dashboardy.

V průměru to jede 25 tisic logu za minutu.
Konfigurace VM jsou to appliance nastavované přes graylog-ctl:
Hlavní nód má všechny zakladní role a 3 vCpu 8GB ram, a potí se.
Druhý replika nod 2vCpu 8GB ram tam už je to resourcema lepší.
Asi bych to klasifikoval jako minimum kde to muže běžet.

Jinak co za to máme? Velmi rychle najdeme, co hledáme, máme na to předuložené query, jsou pěkné dashboardy ke stažení, a máme centrální log management. Myslím si, že je to mocný nástroj ale chce to vyhrazené servery a spoustu místa a interně to není nic jednoduchého.

Snad info pomuže.

[MP]

Diky za odpoved. Dalsi dotazy, co me zatim napadly:

1] Konfigurace VM jsou to appliance nastavované přes graylog-ctl - co si pod tim mam predstavit?
2] pouzivate primarne udp nebo tcp a proc?

Logovat pres vlan me nenapadlo, zkusim si promyslet +/-. (nemam rad moc sitovek na serverech + napadeny server muze pak cist vse).

Ty HW pozadavky zhruba odpovidaji, kolega to kalkuluje na 16 jader (single instance) s 1TB minimalne, akorat kalkuluje s SSD, jak je na tom vas diskovy backend?

[Madmucho]

Dobrý den.
ad 1) myslel jsem tím deploy těch appliances, někdo si to cele na debianu děla po svém od elasticsu po ngix, já sem líný tak jsme použily vm appliance, a ten příkaz na nastavení parametrů z appliances je zde http://docs.graylog.org/en/2.4/pages/configuration/graylog_ctl.html#graylog-ctl

ad 2) Primárně to ženeme tou vyhrazenou vlan, protože prvky mají různou implementaci tak si vybírat nemůžeme, někde jsme rádi že to vůbec ve správném formátu dorazí a graylog to schroupe, máme spousty různých zařízení, tiskarny, nasy, mikrotiky, cisca, junipery Jestli TCP nebo UDP takový luxus ve výběru není všude, jsme tedy připraveni na obě varianty.

S těmi několika vm síťovkami to si myslím že není takový problém.

HW požadavky máte mnohem lepší. U nás ukládá data noda každá na svuj datasor který je iSCSI distribuovaný z HP VSA dvou clusterů, respektive je to to co zbylo, a stíhá.

Nejvíc se IO točí kolem graylog jurnalu nezpracovaných logů (kafka), a pak kolem samotného elasticsu kde je to již zpracované, tyhle dvě věci jsou nejvíce na IO operace. Java pak podle množství indices produkuje jejich procesy to je zas na RAM, proto je v graylogu více rolí dá se to takhle škálovat na všechny strany. Vše je v dokumentaci popsáno.

Jinak graylog cluster nebudete mít v zeleném když plánujete jeden stroj, standart je mít stroje dva, sežere to tak dvakrát více místa, ale pak dá zelenou že jsou data na dvou nodách, replikuje to samo a aktivně na query to oba nody používá.

[MP]

Supr. Nakonec to zelezo pobezi 100pro s SSD, coz dost pomuze. Druhy node zatim ne.

Jeste k tem logum - pouzivate logovani do JSONu kde je to mozne? Nebo to vse delat v nativnim formatu a pak to pres collectory nejak formatujete? Muzu totiz napr. nginx logovat v json, ale zda se, ze tim prestanou fungovat veskere ruzne analyticke/monitoring nastroje, ktere v drtive vetsine umi zrejme jen ten nativni format parsovat.

[Reklama]

[Madmucho]

Supr. Nakonec to zelezo pobezi 100pro s SSD, coz dost pomuze. Druhy node zatim ne.

Jeste k tem logum - pouzivate logovani do JSONu kde je to mozne? Nebo to vse delat v nativnim formatu a pak to pres collectory nejak formatujete? Muzu totiz napr. nginx logovat v json, ale zda se, ze tim prestanou fungovat veskere ruzne analyticke/monitoring nastroje, ktere v drtive vetsine umi zrejme jen ten nativni format parsovat.

Dobrý den,
vůbec nepoužíváme logovaní do JSONu, nebyl k tomu důvod, používáme GELF a nebo Syslog formát. Pro Nás bylo duležitejší aby logování v případě výpadku spojení nebo serveru logovalo do lokaní vyrovnávací paměti a po obnovení spojení vše vysypalo do Graylogu a v případě výpadku logovaci služby bylo schopné od checkpointu logy dohledat a doposlat, to se týká primárně windows. U linuxu je v to v pohodě.

[MP]

Supr. Nakonec to zelezo pobezi 100pro s SSD, coz dost pomuze. Druhy node zatim ne.

Jeste k tem logum - pouzivate logovani do JSONu kde je to mozne? Nebo to vse delat v nativnim formatu a pak to pres collectory nejak formatujete? Muzu totiz napr. nginx logovat v json, ale zda se, ze tim prestanou fungovat veskere ruzne analyticke/monitoring nastroje, ktere v drtive vetsine umi zrejme jen ten nativni format parsovat.

Dobrý den,
vůbec nepoužíváme logovaní do JSONu, nebyl k tomu důvod, používáme GELF a nebo Syslog formát. Pro Nás bylo duležitejší aby logování v případě výpadku spojení nebo serveru logovalo do lokaní vyrovnávací paměti a po obnovení spojení vše vysypalo do Graylogu a v případě výpadku logovaci služby bylo schopné od checkpointu logy dohledat a doposlat, to se týká primárně windows. U linuxu je v to v pohodě.

Co pouzivate na to logovani do lokalni pameti a nasledne predani do graylogu?

[Madmucho]

Dobry den, na windows je to nxlog je to hezky nastavitelny log shipper do windows jde tam delat routing, logy => disk nebo ram cache => graylog, kdyz neni graylog je to v keši, pak se batoh vyprazdni jakmile to bude mozne.

[MP]

Dobry den, na windows je to nxlog je to hezky nastavitelny log shipper do windows jde tam delat routing, logy => disk nebo ram cache => graylog, kdyz neni graylog je to v keši, pak se batoh vyprazdni jakmile to bude mozne.

Tohle by me zajimalo presneji jak to pouzivate. Logujete na disk nebo ram? RAM se mi zda riskantni (ale io free). Pouzivate intervalovy sber dat, nebo posilate rovnou?

Co jsem zkousel:

1] log -> network - zde kdyz neni graylog, dojde k ztrate logu = nepouzitelne
2] log -> disk <- filebeat -> graylog - skenovani logu v casovem intervalu, nezavisi na dostupnosti graylogu

O nxlogu vim. Co me zajima (jeste jsem na to nenarazil, nebyl cas zkoumat), je bod 1], zda nxlog/filebeat umi neco takoveho treba v tomto stylu - realtime prenost pokud je graylog aktivni, jinak cekej (nebo skenuj logy v intervalu).

Diky.

[Madmucho]

Dobry den, na windows je to nxlog je to hezky nastavitelny log shipper do windows jde tam delat routing, logy => disk nebo ram cache => graylog, kdyz neni graylog je to v keši, pak se batoh vyprazdni jakmile to bude mozne.

Tohle by me zajimalo presneji jak to pouzivate. Logujete na disk nebo ram? RAM se mi zda riskantni (ale io free). Pouzivate intervalovy sber dat, nebo posilate rovnou?

Co jsem zkousel:

1] log -> network - zde kdyz neni graylog, dojde k ztrate logu = nepouzitelne
2] log -> disk <- filebeat -> graylog - skenovani logu v casovem intervalu, nezavisi na dostupnosti graylogu

O nxlogu vim. Co me zajima (jeste jsem na to nenarazil, nebyl cas zkoumat), je bod 1], zda nxlog/filebeat umi neco takoveho treba v tomto stylu - realtime prenost pokud je graylog aktivni, jinak cekej (nebo skenuj logy v intervalu).

Diky.

Konfig kde se to řeší vypadá takhle, dávám jen kousek z něj, je to hezky čitelné něco tam máme i filtrované že nechceme, o tom realném čase se dá polemizovat, netuším jak často nxlog čte, ale tuším co vteřinu a v log souboru si děla checkpoint takže jak ho vypnete tak ví co už zpracovával (SavePos True), a na realtime také nepřidá graylog jelikož jeho zpracování je asynchronní je tam dost bufferů, na realtime ale nejedeme potřebujeme data mít a data takto máme.

Když jsem ladil konfig nxlogu a ještě ladím tak jej distribuuji na widle pomocí batáčku a psexecu zastav přepiš konfig nastartuj.

V konfigu můžete mít sběrných míst více, je všeobecně známo že ne všechno loguje do win logů, např dhcp server, iisko, ftpko mají svoje textové logy složky, i ty můžete sosat a posílat si do centrály. Všechny útržky najdete na netu hodně je toho na githubu, mě tohle přijde funkční a tak jsem nehledal dále.

Kód: [Vybrat]

<Extension gelf>
    Module      xm_gelf
</Extension>

<Extension logrotate>
    Module  xm_fileop
    <Schedule>
        When    @daily
        Exec    file_cycle('%ROOT%\data\nxlog.log', 7);
    </Schedule>
</Extension>

<Input in>
SavePos True
ReadFromLast True
    Module      im_msvistalog
# For windows 2003 and earlier use the following:
#   Module      im_mseventlog
# Exec if ($EventID == 4202 or $EventID == 4208 or $EventID == 4302 or $EventID == 4304 or $EventID == 5004) drop();\
#   else{\
# if ( $EventType == "INFO" ) $SyslogSeverityValue = 6;\
# if ( $EventType == "WARNING" ) $SyslogSeverityValue = 4;\
# if ( $EventType == "ERROR" ) $SyslogSeverityValue = 3;\
#   }
</Input>

###############
# Processors  #
###############

<Processor buffer>
    Module      pm_buffer
    # 1Gb disk buffer 1048576 kilo-bytes
    MaxSize    1048576
WarnLimit 524288
    Type    Disk
    Directory  %ROOT%\data
</Processor>

<Output out>
    Module      om_udp
    Host        xxx.xxx.xxx.xxx
    Port        12201
    OutputType  GELF
</Output>

<Route 1>
    Path        in => buffer => out
</Route>