nxlog má funkci reliable delivery při přerušení tcp spojení až v placené verzi, to je povětšinou dost zásadní funkce a nechceš ztrácet logy při restartech servové části.
Proč chceš používat tyhle obskurní nástroje (ano, nxlog je prostě takový běžný enterprise SW, u nás ho třeba máme v rajfce) místo poměrně etablovaného a stabilního řešení v podobě rsyslogu? Stejně tak se tady nabízí ještě syslog-ng.
Ty moderní nástroje mají často problém se spolehlivostí, neumí se snadno vypořádat s pády, restarty, rotováním souborů a jinými neduhami.
U postfixu se mi dlouhé roky osvědčuje používat syslog logování, dávat to do rsyslog relay s lokální cache a rovnou posílat na rsyslog server, z kterého se to poté již může distribuovat do různých grafických udělátek. Při výpadku konektivity se logy pošlou dodatečně, mohu jednoduše alertovat, když logy přestanou chodit, mám to jednotné s ostatními nástroji a infrastrukturou.
Z těch placených je poměrně solidní Splunk, umí se totiž asi nejlépe vypořádávat s rotováním souborů, jejich truncování po rotování, s přejmenováním a jinými operacemi, když už teda pustíš aplikaci, aby si mohla sama spravovat logy a sama do nich zapisovat.
Diky za zhodnoceni.
Ja pouzivam filebeat pro graylog, ktery s rotacemi logu a vypadky spojeni problem nema, tak jsem necekal u nxlogu, ze by to bylo v zakladni verzi problem. Ale protoze se mi automaticky konfiguruje z graylogu, tak ho jiz vyuzit nemuzu.
Duvodu, proc nepouzivam rsyslog na tyhle veci (pokud to z principu jinak nejde, napr. switche) je tento:
1] vice a vice se prechazi na journald
2] standarizace konfigurace/zabezpeceni/nahraditelnost aplikace nasaditelna defacto vsude, nez se prat s tim, jak to rsyslogem nekam poslat
3] nesnasim regexpy, je to neintuitivni, casovy zrout
Zobrazit příspěvky
