Fórumok
Sziasztok,
az egyik szerverünkön szeretnénk a logolás központosítása végett beüzemelni egy log szervert, szóbajött eddig a
Syslog-NG, Greylog, Logstash, utóbbi kettővel az a probléma, hogy elég nagy az erőforrásigényük.
Amiknek a naplózását szeretnénk bekötni:
- authentikáció
- nginx
- PHP
- MySQL
- Redis
- memcached
- ElasticSearch
- Gearman
- Postfix
- biztonsági mentések
Van valakinek valamilyen tapasztalata a fentebb említett rendszerekkel, tudtok javasolni valamilyen (lehetőleg nem nagy erőforrásigényű) alternatívát?
Előre is köszönök minden segítséget!
Hozzászólások
Én olyat láttam, hogy a lokális syslog-ng szerverek egy központi szerverre tolták fel a logokat tcp-n. Ha jól emlékszem a programok egy named pipe-ra loggoltak amit a syslogszever küldött tovább a központi szervernek. Rég volt már nem is én csináltam végig, csak a bevezetésében vettem részt.
Syslog a legalapabb telepítéseken is szokott lenni, ráadásul majd minden ilyen program képes arra, hogy hálózaton fogadjon vagy hálózatra küldjön napló eseményt. A központi szerverre ezen esetben syslog-ng javasolt, mert nagyon jól konfigurálható és egy olyan helyen, ahova mindenhonnan mindenféle logok dőlnek, igen hamar bebizonyosodik, hogy egy jó struktúra aranyat ér keresésnél.
Ennek az iránynak viszont ára is van: azon programok, amelyek alapban nem syslog-ba naplóznak, átkonfigurálást igényelnek. Az nginx pl. szeret több logot is írni, ha több virtualhost van, akkor illik úgy konfigurálni - szintén a könnyebb kereshetőség végett -, hogy site-onként ír külön naplókat. Ezt vagy átállítjuk, hogy ömlessze be a syslog-ba - annyira nem szerencsés, a site-onkénti kereshetőség nehezebb lesz, stb. - vagy ahogy más is említette, létre hozunk named pipe-okat, amelyet a daemonok írnak, a syslog meg olvas. Ezt már akármelyik syslog nem feltétlenül tudja, de ha ilyet tervez az ember gyereke, akkor az egyszerűség kedvéért célszerű az uniformizálás, a syslog-ng pedig tud ilyet. Sajnos ez sem teljesen jó megoldás: egyfelől a standard konfigtól el kell térni a monitorozni kívánt programoknál - ennél nagyobb baj, hogy ha bármiért megáll a syslog, akkor nem olvassa a named pipe-ot, így amikor a pipe betelik, akkor szépen megáll a monitorozott program. Nem az lesz a gond, hogy nem tudja írni a logot, hanem az, hogy a log írás oprendszer szinten áll meg: az oprendszer várja, hogy valami a pipe-hoz rendelt puffert ürítse le, mert több hely már nincs. Ekkor a write() hívás nem tér vissza, megáll - és ezzel esélyesen magával rántja a szolgáltatás. Egy apache szerveren sikerült ezt a bravúrt elkövetnem - hagyott bennem emléket...
A logstash vitán felül nagyobb erőforrás igénnyel rendelkezik - hogy mást ne mondjak, kell neki java. Ezen ott lehet csiszolni, hogy a jdk helyett elég a jre, illetve esélyesen megfelelő a -headless csomag is. Ha ez utóbbit használjuk, akkor a teljes X függőségtől megszabadulunk. (Ok, erőforrásban nem lesz kevesebb, de függőségben ez a tizede a nem headless jdk felállásnak.) Mindenképpen a logstash mellett szól, hogy sokféle input filtere van, így képes ez is a hálózaton át érkező napló üzenetek fogadására, ugyanakkor a file input modul képes tail -f stílusban olvasni az alkalmazás által írt log file-t, így magához a naplózni kívánt alkalmazáshoz nem kell nyúlni logolás tekintetében.
Mindkét esetben a logok tárolódnak a központi gépen - de valahogy meg kell oldani a kereshetőséget is. A logstash esetén erre elég jó leírásokat láttam - syslog alapú keresésre már kevesebbet, bár ez jelentheti azt is, hogy annak idején én kerestem rosszul.
Ha ilyesmiben gondolkodsz, akkor érdemes lehet megnézned a splunk-ot is. Ez ugyan fizetős, de van ingyenes változata is bizonyos korlátozásokkal. Ilyen korlátozás az is, hogy nem fog elosztott rendszerként működni - de ez áthidalható azzal, hogy csak egy helyen használod, a központi logszerveren - oda meg syslog alapokon áttolod a töbi naplót.
Miert hasznaltal pipe-ot? Ha mar ugyis bekonfiguralod ezeket egyesevel a syslog-ng-nek, akkor akar a logfile-okat is be lehetett olvastathatni vele, de en inkabb socket-et hasznaltam volna. Ha az apache blocking IO-t hasznal logolasnal es nincs mellette egy jol iranyzott alarm() akkor az szerintem bug, de ez megiteles kerdese (lLattam mar olyat, hogy kizarolag non-blocking write eleresehez kellett egy par soros perl scripten keresztul logolni egy programbol kozvetlenul a filerendszerre iras helyett).
Itt fut logstash + elasticsearch ami főleg a suricata logjait is beszedi. Nahh mikor napi 40G került bele, és olyan 1.3 milliárd sornyi log volt 2 hónap alatt. Nahh akkor már lassú volt. Egy 8 magos opteron 16G ram + 4x2T RE disk. Persze a disk volt kevés, SSD jobb, csak nagy kapacitást drágább építeni belőle.
Most kicsit redukálva lett a suricata log, igy fut jól. Meg nekem a logstash felülete is bejött.
Fedora 20, Thinkpad x220
syslog-ng + elasticsearch + kibana trio kivalo. kliensekre syslog-ng ami osszegyujti amit kell, ha epp van eroforras a kliensen, akkor akar patterndbvel picit elofeldolgozza is (maskepp ez a kozpontra harul), betolja ES-be, kibanaval meg szepen meg lehet nezegetni.
Igy a kliens oldalon kellemesen lightos a syslog-ng miatt, a kozpontban meg ott van az ES es a Kibana altal biztositott josagok.
Ha nem akarsz kozvetlen kliensbol ES-be tolni, akkor pedig lehet kozpontban is egy syslog-ng (es akkor kliens es szerver kozott mutual TLS auth), es majd az betolja.
Teljesen korrektul mukodik.
--
|8]