syslog-ng(OSE)->mysql->loganalyzer logrotate

Linux-haladó

Sziasztok!

syslog-ng(OSE)->mysql->loganalyzer rendszerre szeretnék valami logrotate megoldást, megelőzvén, hogy megteljen a merevlemez a sok logtól, meg egyébként sincs szükségem évekre visszamenőleg a logokra.
Az a gond, hogy google-al még csak találta sincs, mintha ez csak nekem jutott volna eszembe, biztos valamit én nézek be.
Amiket eddig találtam:
-syslog-ng-nek nincs vagy nem találtam logrotate funkciót, csak ha fájlban tárolom a logokat.
-gondoltam még mysql before insert triggerre csak ugye ugyanabba a táblába nem tud visszaírni.
-a loganalyzerban sem találtam erre lehetőséget, ha tudtok jobb és ingyenes logelemző progit akkor szívesen kipróbálok mást is.

előre is köszi a segítséget.

  • 10503 megtekintés

( lx | 2013. 09. 26., cs – 12:24 )

Egy táblából vagy törölheted a régi rekordokat (lassú), vagy elláthatod egy (minden indexkulcsba felvett!) saját törlésjelző flaggel (ez se gyors nagy tételnél), vagy partícionált táblát használsz egy okosan kitalált partícionáló kulccsal, amellyel egyetlen alter table paranccsal lecsatolhatod a feleslegessé vált rekordhalmazt.

Ha jól látom (most kerestem rá, mert csak távolról ugatom a motort), a mysql támogatja az utóbbi megközelítést.

( eldar | 2013. 09. 26., cs – 16:44 )

Szia,

A tablak neveben hasznalhatsz syslog-ng makrokat ugyanugy, mint a fileok neveben, igy pl. naponta uj tablaba tudod rakni az aznapi logokat, a regieket meg torolheted, ha mar nincs ra szukseg. Hogy a loganalyzer ezt tudja-e kezelni, azt nem tudom.

( uid_194 | 2013. 09. 26., cs – 17:22 )

loganalyzer-t nem ismerem, szoval az alabbiak lehet, hogy nem jo megoldasok, de hatha:

1) A tablanevbe tudsz makrot tenni: table("data_${YEAR}${MONTH}"), es a regi tablakat igy egyszeruen es gyorsan lehet torolni.

2) ....ezt idokozben elfelejtettem. majd meg visszanezek ide kesobb.

--
|8]

GÁNY ON

Ha meg lehet reszkírozni az ehhez szükséges idő esetleges kiesését, cronból rendszeresen eljátszható, hogy

RENAME RENAME TABLE logtabla TO logtabla-${datum}
CREATE TABLE logtabla ...

vagy még inkább

CREATE TABLE uj_logtabla ...
RENAME RENAME TABLE logtabla TO logtabla-${datum}
RENAME RENAME TABLE uj_logtabla TO logtabla

Hát igen, egyelőre marad a gány, én ezt találtam a legegyszerűbbnek, cronból naponta futtatom.
delete from logtabla where log_ideje < (NOW() - INTERVAL 100 DAY); ahol a log_ideje a log rögzítésének ideje, date formában.

Lehet cserélem az egész rendszert, még csak most építem, de kétségeim támadtak a syslog-ng-vel kapcsolatban, eleinte jó volt, de pl ez a rotate egy alap dolog lenne úgy gondolom. Szétnézek még rsyslog táján is, lehet lecserélem a loganalyzert is, most még könnyen változtattatok bármin.

"de pl ez a rotate egy alap dolog lenne úgy gondolom"

Azért ezt gondold végig...
Fájloknál megkapod a rotate-et, mert az az adott aspektusból nézve része a log KIÍRÁSÁNAK, ami a syslog-ng feladata. Adatbázisnál is a KIÍRÁS a feladata. Azt nem kell tudnia, hogy te milyen analizálóval akarod és tudod majd megszólítani az adatbázist: bármelyik törlési módszert szerelnék össze vele, az megtorpedózhatná a riportolásod és/vagy beszúrásod teljesítményét, vagy túlléphetne az analizálód képességein.

Nemtrivi problémát addig oldottak meg, amíg izolálhatóan trivi, és ez így jobb, mint a nemtrivi részek elvarrása miatt szűkíteni az alkalmazhatóságot.

ha fájlbaba írom, akkor sem a syslog-ng csinálja hanem a logrotate progi. Jobban belegondolva visszavonom, tényleg jogos, nem feltétlen a syslog-ng-nek a feladata, de úgy gondolnom, hogy legalább ez egyik programba beleférne opcióként egy rotálás mert így nekem kell faragni, nem mintha lusta lennék, de egy gyári megoldás tisztább érzést ad nekem(főleg ha működik.
Arra is kíváncsi lennék, hogy a nagyok ezt hogy csinálják, de gondolom, komolyabb helyeken, nem ingyenes megoldásokkal bohóckodnak.

Múltkoriban belefutottam egy olyan syslogd-be, aminek van logrotate opciója és meg is csinálja.
Más kérdés, hogy ez kinek a feladata lenne.
(szerintem amíg fájlba ír, addig belefér, ha adatbázisba, ott már nem bíznám rá)

Egyébként szóba került a particionálás. Szerintem nézz utána! Nem egy nagy művészet megoldani (nem hinném, hogy bonyolultabb, mintha Oracle-ben csinálnád ugyanezt)

apropo: ezzel amit csinálsz, ha jól értelmezem, komoly gondot is okozhatsz a loggernek, mivel egy időre kirántod alóla a táblákat amiket használna. Mi lesz azokkal a bejegyzésekkel, amik épp akkor keletkeznének, amikor a régi már, az új még nem létezik? (bocs, ez lx-nek szólt volna)

Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

A kíhúzott részen én is agyalok, mert az én megoldásomban a delete idejére valszeg a syslog-ng alól is kivágom a táblát(mondjuk 0,03-4mp alatt lefüt). Most megint úgy érzem hogy mégiscsak a syslog-ng-nek kéne csinálnia a rotálást, pont ezért hogy a rotálás ideje alatt is tárolva legyenek a logok.

A delete-tel csak lockolod, azt még el tudom képzelni, hogy kivárja a démon. Ha az eredeti, átnevezős variációt csinálod, ott van egy minimális esély, hogy épp rosszkor fordul az adatbázishoz és annak nem tudom, mi lesz a következménye (ha én írom a loggert, akkor crash, mert valaki belepiszkált az adatbázisba)

A te variációddal inkább ott lehet a gond, hogy esetleg fragmentálódni kezd az adatbázisod és ettől pár év után nagyon lelassul.
(feltételezés)

Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Ha kellek, szólj, csak ha privátot írsz, jelezd itt is, mert a regisztrációhoz használt címem automatikusan kukáz mindent, mert az elmúlt tíz évben csak spamet kaptam bele. :)

Egyébként felraktam a syslog-ng-t egy vadiúj Debianra, de már a telepítésnél megdöglött. Anyáztam vagy húsz percet, mire rájöttem, hogy a SELinux-ot nem szereti. :)

Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Emlékeim szerint ha insert error van, akkor a syslog-ng megnézi, hogy megvan-e a tábla, ha nem, akkor pedig létrehozza az sql destination paraméterei alapján. Ha a "hiba" fennáll, akkor néhányszor még megpróbálja, aztán vár egy time_reopen-nyit. (Nagyon rég láttam ezt, azóta változhatott.)

"Arra is kíváncsi lennék, hogy a nagyok ezt hogy csinálják, de gondolom, komolyabb helyeken, nem ingyenes megoldásokkal bohóckodnak."

Sok, akár többszintű tárolóhellyel és/vagy tömörítéssel (ez a jellemzően ismétlődő szövegeket tartalmazó logok tárolásánál drámai méretcsökkenést jelent) és/vagy az említett eldobható partíciók használatával.

És persze jól kitalált indexekkel -- ezt a pont gyakran kiesik azoknál, akik párrekordos adatbázisra fejlesztgettek, azt kezelgették, és minden gyors volt anélkül is, hogy azzal a felesleges hülyeséggel foglalkoztak volna, amire amúgy se figyeltek oda a suliban.

Ha mar patchelos kedvedben vagy, akkor eszembe is jutott par dolog, amit lehetne fixalni, ha ujabb verziokban nem kerult meg javitasra:

- Ha lvs mogott van tobb syslog-ng(3.3.5 el neztem) sima roundrobin + DR, akkor beragadnak tcp kapcsolatok. ESTABLISHED-ben maradnak es elfogy connection 2-3 het utan(termeszetes beallitas fuggo mennyi a max, de egyszer mindenkepp eleri maxot). (inhibit_on_failure eseten is)
- Ha lvs mogott van tobb syslog-ng ES keepalived tcp checket tolok 3 masodpercenkent (sima lingeres connect + closet tol, szal RST vel vegzodik kapcsolat), akkor 1-2 napon belul szethal egesz syslog.
- Ha barmelyik remote syslog kapcsolat meghal egy syslog-ng ben, akkor van ra esely, hogy egyik remote cucc sem fog mukodni.

Bugreportot lusta voltam irni, meg keresgetni, hogy fixalva lett e vagy eppen nem, hogy milyen workaround van hibak kikuszobolesere. (gecireg ota fennalnak ezek a hibak)

Szia,

milyen verziójú syslog-ng-t használsz?

1. Elég furának tűnik, meg tudod próbálni úgy, hogy bekapcsolod a source-on a TCP keepalive-ot az so_keepalive(yes)-el?
2. Ez segfaultot jelent? Ha igen, akkor el tudod indítani a syslog-ng-t az --enable-core command line paraméterrel és eljuttatni a keletkezett core file-t Algernon-hoz vagy hozzám?
3. Ez by design ilyen, ha a flow-control be van kapcsolva az adott log statement-ben, akkor az ugyanabba a log statement-be eső destination-ök a _leglassabb_ sebességére fognak beállni (nyilván, hogy a flow-control meg tudjon valósulni). Sőt, ha van egy logpath, ami flow-control-os, akkor az a source hiába szerepel még más logpath-ban, akkor már a kiolvasás annak a destination-nek a sebességére fog beállni. Ezt csak a log_fifo_size egekbe emelésével és a flow-control kikapcsolásával tudod megoldani (vagy kereskedelmi syslog-ng-vel és disk bufferrel (x) ;)).

A debian wheezy default syslog-ng t hasznalom 3.3.5(http://packages.debian.org/wheezy/syslog-ng). (de squeeze default verzioval is ez volt a helyzet.)

- so_keepalive ot probaltuk. Sajnos nem segit azon, hogy beragad egy kapcsolat. Mintha nem kezelne le ha nem vart eredmennyel szakad meg egy kapcsolat es nem closeolja fdt.

- Nem segfault. Memleak. durvan elkezd noni memoriahasznalat es egy ido utan elfogy.

Mar reg meg lett volna veve kereskedelmi syslogng, ha tudnank, hogy ezek a hibak nem fognak elojonni abban. Nem tudom pontosan mit csinal disk buffer syslogngben de neve alapjan csak valami garancia arra, hogy megjon az uzenet. De nekem nem az a lenyeg hogy garantaltan megjojjon az uzenet. Hanem, hogy garantaltan ES idoben megjojjon, akkor is ha failel 2-3 connection.

3.3.5 ota rengeteg memleaket javitottunk. En javasolnam, hogy probaljatok ki egy 3.3.11-et, abbol van squeeze csomag is, emerre: http://asylum.madhouse-project.org/projects/debian/

A tobbi hibanak utanajarok. Egy bugreport, akar listara, akar bugzillaba, akar githubon, akar nekem emailben (algernon kukac balabit pont tudodhol) es akkor nem fogom elfelejteni se.

--
|8]

Köszi, ha zaklatni kell miatta valakit, akkor (miattam) hagyd a fenébe!
Én csak játszom vele az itthoni gépeken.
A SELinux csak kíváncsiságból került fel és kissé meglepett, hogy már a syslog-ng telepítése sem megy le hiba nélkül.
Szóval ha érdekel valakit, bugreport helyett talán... de egyébként nem biztos, hogy érdemes foglalkozni vele(m).

Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Tegnap le is csereltem. Megint elkezdett noni beragadt kapcsolatok szama. Az lvs mogott levon syslog-ngn ip cimenkent 15-20 kapcsolat van. Ahonnan a kapcsolat jon syslogok 1 kapcsolat latszik mindossze. Tehat tuloldalon nincs beragadva semmi.

ii syslog-ng 3.3.11-1~mhp1 all Next generation system logging daemon (metapackage)
ii syslog-ng-core 3.3.11-1~mhp1.sysvinit~wheezy amd64 Next generation system logging daemon (core)
ii syslog-ng-mod-sql 3.3.11-1~mhp1.sysvinit~wheezy amd64 Next generation system logging daemon (SQL plugin)

- Pontosabbat tcpdump-ból lehetne mondani, tudnál készíteni egy megszakadásos dump-ot?
- Ahogy algernon is írta, ebből sok javításra került, ha esetleg mégis úgy látnád, hogy növekszik a memórahasználat, akkor kérlek egy SIGABRT-vel core-oltasd el és juttasd el a core file-t.

Az az igazság, hogy ott is csak akkor javulnak hibák, ha a support tud róla és egy kis segítséget adsz a nekik a reprodukálásban. Nem nagyon akartam belemenni, azért is (x)-eltem meg, de ha már előjött, akkor gyorsan leírom mire jó. Nyilván az a legelterjedtebb felhasználási módja a diszk buffernek, hogy kapcsolatmegszakadás esetén ide írja a syslog-ng a logokat, amíg vissza nem tér a szerveroldal, viszont koncepciójában valóban egy buffer, ezért a garancia mellett a sebességhez is köze van. Lehet akár olyat is csinálni, hogy a küldést belimitálod egy adott event/sec értékre throttle-el (mert pl. a SIEM-ed úgy licenszelődik) és a többletet addig a syslog-ng a diszk bufferbe írja, amíg be tudja hozni magát.

A Te use-case-edben csak akkor tudod egyszerre több helyre a lehető leggyorsabban küldeni a logot, ha kikapcsolod a flow-control-t. Ezzel viszont OSE-ban sajnos erősen megnöveled a logvesztés lehetőségét, ebben az esetben tipikusan a log_fifo_size-nyi logod el fog férni a memóriában, afölött el fogja kezdeni eldobálni a logokat a syslog-ng (a syslog-ng-ctl stats kimenetéből szépen látszik). Nyilván lehet ezt is emelni egy darabig, de pl egy leállás esetén ezek az üzenetek elvesznek, minél nagyobb a mérete, annál jobban fáj.

Ha viszont az egyes destination-ökre ráakasztod a megfelelő méretű diszk buffert, akkor attól függetlenül, hogy a szerver tudja-e fogadni (akár csak megfelelő sebességgel), a többi kapcsolaton tudja tovább küldeni és az az egy szerver destination-jénél a diszk bufferbe kezdenek el gyűlni az üzenetek. A flow-control és a queue-k koncepciója elég jól össze van foglalva a dokumentációban, a két verzió között szépen látszik is a különbség.

OSE: http://www.balabit.com/sites/default/files/documents/syslog-ng-ose-3.3-…
PE: http://www.balabit.com/sites/default/files/documents/syslog-ng-pe-4.2-g…

( hardhead | 2013. 09. 27., p – 11:39 )

Egy jó ideje fejlesztek egy saját logelemző motort. (Massalyzer)
Jelenleg az éles tesztek futnak különböző helyeken.

Fejlesztéskor én a szöveges logfeldolgozásra koncentráltam, ugyanakkor
van lehetőség arra, hogy a logelemzővel a syslog-ng szöveges adatait folyamatosan (real-time) bedolgozza adatbázisba. A logelemzőmmel meg lehet oldani, hogy menet közben felfüggessze a működését, majd onnan folytassa ahol abbamaradt. Így el tudok képzelni egy olyan helyzetet, hogy a mysql rotálás alatt a feldolgozás szünetel majd újraindul. Amíg megy a rotálás a fájlban gyűlnek az események. Rotálás után pedig folytatódik a feldolgozás. Ha pedig nincs már szükség rá, akkor utólag törölheted a fájlt is.

Tehát valahogy így nézne ki a dolog

syslog-ng-->logfájl-->Massalyzer--->MySql--->....

Ha érdekel a dolog szólj bátran!

( kallo | 2013. 09. 27., p – 17:20 )

Félre érthető voltam, nem a mysql rotálás megvalósítását gondolom alapnak, hanem azt, hogy egy syslogd szoftver ne addig gyűjtse a logokat ameddig meg nem telik a lemez. Már látom, hogy nincs nagyon ilyen funkció meg azt is, hogy nem is olyan triviális a megvalósítása mint azt elsőre gondoltam.

Mindenkinek köszönöm a sok segítséget egyelőre maradok a törlésnél, még csekély méretű a log, ha később gond lesz vele visszatérek rá.