[megoldva] syslog-ng, remote logging, sok host

UNIX haladó

Kezd kialakulni egy kozponti syslog-ng hostunk. Jelenleg nehany host kuldi a logokat, amiket host-onkent valogatom ki. Igazabol minden mukodik, annyi csak a gondom, hogy jo lenne kicsit kevesebb konfigot irni (kevesebb macera, kevesebb hibalehetoseg). Nekem most egy host (pl 'almafa') egy log file-t ir, ami azonos a host nevevel ('almafa.log'). De sajnos igy minden uj host-hoz kell csinalnom egy uj 'filter'-t egy uj 'destination'-t es egy uj 'log'-ot a syslog-ng.conf-ba, holott mindegyik tok ugyanugy nez ki, csak a hostnev mas rendre. Nincs valami mod a destintaion file megadasnal valtozot hasznalni? Valami ilyesmire gondolok: 


destination remotelog { file("/var/log/remotelog/"%HOSTNAME%".log"); };

De vegulis barmilyen mas megoldas erdekel. A lenyeg, hogy a leheto legkevesebbet kelljen a configba irni (kesobb modositani), de legyenek hostonkent szeparalt log file-aim. Midenzt syslog-ng-vel, hacsak lehet.

-------------------------------------------------------------
Update
Megoldas Chris19-tol: 


destination remote-dest-file {
file("/logs/$HOST/messages.$YEAR.$MONTH.$DAY" create_dirs(no));
};

Egyeb hasznalhato valtozok: The syslog-ng Open Source Edition 3.3 Administrator Guide: List of syslog-ng OSE parameters

  • 6524 megtekintés

( _Gabor_ | 2014. 01. 03., p – 22:23 )


destination remotelog {
    file("/var/log/remotelog/$FULLHOST.log"
    template("$R_FULLDATE [$PRIORITY] $FULLHOST $MSGHDR $MSG\n")
    template_escape(no)
    );
};

( mr shadow v | 2014. 01. 03., p – 18:10 )

subscribe
--
>'The time has come,' the Walrus said<

( chris19 | 2014. 01. 03., p – 18:13 )

Remélem jól értem a problémát. Én így szoktam:

destination remote-dest-file {
file("/logs/$HOST/messages.$YEAR.$MONTH.$DAY" create_dirs(no));
};

source remote-src-tcp1514 {
tcp(port(1514)
keep-alive(yes)
so_keepalive(yes)
max_connections(50) );
};

log {
source(remote-src-tcp1514);
destination(remote-dest-file);
};

Csomagszűrőből pedig lehet szabályozni, hogy ki kapcsolódhat a syslog szerverhez.

Ha nagyon sok log jön be akkor érdemes lehet naponta cron-ból gzippelni őket:

03 03 * * * root find /logs -name "messages*" -type f -mtime +0 | grep -v "\.gz$" | xargs /bin/gzip -9

Így később zcat-tal ugyanúgy meg lehet nézni vagy keresni bennük. Syslog-ng mellett nem nagyon használok logrotate-et.

Sok gigas log fajlok alapbol nem szerencsesek.
Ha ekkora a forgalom log szerveren 1 nap alatt ennyi log jon 1 helyrol akkor inkabb jobban kulon kell valogatni a tartalmat vagy orankenti bontasban tarolni.
Ha pedig ennyire keves az eroforras/nagy a terheles, hogy 1 file-t kitomoriteni is megterhelo akkor hogy tomorited be naponta a sok 2 napos file-t?
Vagy miert nem masolod masik gepre a szukseges file-okat es ott dolgozod fel, hogy sima grep se terhelje le ilyenkor a gepet?

Ha turkászni kell, akkor sokgigás a log. És nem csak Murphy szerint :-)
Alkalmazáslogból bizony összejöhet ekkora, és bár lehetne válogatni, de ha a fejlesztő ömlesztve kéri, utólag összelapátolni megint csak erőforrásigényes móka. Az óránkénti darabolás jó ötlet... Lenne, ha nem keletkezne mondjuk napi 1000+ darab logfájl óránkénti darabolás nélkül is...
A terhelés (feldolgozott logsor/s) sok esetben nem egyenletes, alacsony forgalmú időben simán elképzelhető, hogy két nagyságrenddel kevesebb logot kell adott idő alatt feldolgozni/szortírozni - akkor van CPU a tömörítésre, munkaidőben meg mondjuk nem igazán.
Az elmásolás akár jó is lehet, de ahhoz kell egy olyan logmatató gép, amire a központi naplózószerverrel azonos biztonsági/hozzáférési/audit beállítások érvényesek, mert lehet, hogy nem minden log másolgatható szabadon ide-oda...

( zolo | 2014. 01. 03., p – 23:07 )

Sot, a fentieken kivul, ha sok geped van, akkor erdemes elgondolkodni egy puppet server felhuzasan, svn-nel igen praktikus, egyszeru es kenyelmes.

( Gorkhaan (nem ellenőrzött) | 2014. 01. 04., szo – 02:22 )

Logstash + Kibana combo nem pálya Puppettel?

|| "Software is like sex: it's better when it's free." Linus Torvalds