Kedvenc syslog megoldásom a(z)...

Linux

sysklogd
1% (4 szavazat)
rsyslog
12% (32 szavazat)
syslog-ng
33% (92 szavazat)
dsyslog
0% (0 szavazat)
inetutils syslogd
0% (0 szavazat)
egyéb, lent leírom
1% (3 szavazat)
amit épp a disztribúcióm szállít
36% (100 szavazat)
nem tudom / nem értem / csak az eredmény érdekel
16% (45 szavazat)
Összes szavazat: 276

( heidrich | 2013. 10. 19., szo – 16:43 )

Attól függ, hogy mi a cél. Ipari környezetben syslog-ng, egyébként ami jön.

( zeller | 2013. 10. 19., szo – 17:02 )

A kedvencem nem azonos azzal, amit a használt disztribúcióban találok, de a szükség és a support nagy úr... :-/

( traktor | 2013. 10. 20., v – 00:56 )

A syslog-ng -t szerettem regen, mindent tudott ami nekem kellett, es a configja egesz emesztheto. Ha nem keleltt syslog configot matatnom, akkor hagyom az eredetit.

( traktor | 2013. 10. 20., v – 00:58 )

Valaki rsyslog barat leirna, hogy mitol jo az rsyslog? Nekem a konfigja ugyanolyan elcseszettnek tunik, mint a 'hagyomanyos' syslog config, azzal meg valahogy soha nem tudtam megbaratkozni. Bar ahogy olvasom a 7-es verziotol ez mintha valtozna....

Én nem vagyok egyik barátja sem, így csak félve kérdem (leginkább csak találgatok): nem lehet, hogy bizonyos funkciók, amiket a syslog-ng csak fizetős változatban tud, benne vannak az rsyslogban ingyen?

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

Közben megtaláltam a man-ban: omrelp - erre írta a doksi, hogy "ha nem akarom, hogy elvesszenek bejegyzések", amikor távoli szerverre küldöm a logokat. Viszont úgy tudom, hogy a syslog-ng-ben a hasonló funkció csak a fizetős verzióban érhető el. Nem néztem alaposan utána, syslog-ng-ből meg csak egy százéves, openwrt-re készült verzióm van kéznél, így nem tudom, igaz-e.

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

Nem azt mondom hogy annyira jo az rsyslog, csak azon kivul syslog-ng-t probaltam komolyabban konfiguralgatni, azzal viszont tobbszor is hulyesegbe futottam mar.

Peldaul olyan gondjaim voltak syslog-ng-vel, hogy frissites utan kitalaltak nem kompatibilis az addigi network filter megadasi forma, vagy masik esetben hogy igazabol frissites elott se volt jo szintaktikailag, csak megis ertelmezte, aztan frissites-ben javitottak.
De olyan is volt regebbi verzioban, hogy egyszerubb halozati eszkozbol nyert syslogot nem sikerult rendesen ertelmeznie alapertelmezetten, legutobb peldaul abba futottam bele hogy regebbi verzion ugy teszteltem siman egy filtert, hogy telnet-el a portra bekuldtem a teszt stringet (string match lett volna a filter feladata), ami regebbi verzioban mukodott, frissites utan (talan 12.04-es ubuntuban) viszont jopar oram elment arra, hogy kideritsem azert nem mukodik, mert a bekuldott szoveg elso reszet a program nevenek probalja ertelmezni, igy ha csak a stringet irom telneten nem mukodik a filter (ezt mondjuk kulon nem teszteltem rsyslog eseten, hogy telnettel bekuldott szoveget hogy ertelmez).

Ezzel szemben rsyslog frissitesekkel nemigazan remlenek ilyen problemak, teny hogy macerasabb ertelmezni a konfigjat, de szamomra tobbszor is csalodas volt syslog-ng, hogy ilyen viszonylag alap dolgokban is mennyi hiba van.

Igen, a teljesen hulye inputokat neha maskepp ertelmezi egy-egy syslog-ng verzio, mert javitunk a parseren, es ilyenkor ami eddig teljesen veletlenul jo volt, most eltorik. Ez van akkor, ha az ember arra epit hogy a hibas input is eppen jol mukodik. A --debug opcio egyebkent sokat tud segiteni, illetve a format-json template function, amivel konnyen es fajdalommentesen ki lehet dumpolni, hogy az adott inputbol a syslog-ng tulajdonkepp mit is csinalt.

(Egyebkent bugreportokat szivesen latjuk, a regressziokat igyekszunk egyreszt elkerulni, masreszt ha megis becsuszik, akkor a leheto leghamarabb javitani.)

--
|8]

( DirtY_iCE | 2013. 10. 20., v – 02:56 )

amit a disztribuciom szallit, kiveve hogy a disztribuciom gentoo, ott meg a handbookba az van hogy itt egy kalap system logger, tedd fel amelyik tetszik, ugyhogy metalog :)

I hate myself, because I'm not open-source.

( uid_4656 v | 2013. 10. 20., v – 12:02 )

Nincs igazi kedvencem, de ha választani kellene log megoldást és kizárólag az IT szempontok érdekelnének (azaz a költségek és a támogathatóság nem érdekelne), akkor valószínűleg syslog-ng-t választanék a logok továbbítására és hezitálnék a splunk és a logstash között a tárolás/feldolgozás/elemzés témakörben (a splunk-ot ismerem és jó erre, a logstash-t meg nem ismerem, de jókat hallottam róla).

A sysklogd manapság sok dologra kevés. Túlságosan kötött, hogy csak a facility/priority párost használhatod a logsorok szűrésére, hiányzik belőle a syslogtag és/vagy message alapú szűrés. A gyakorlatban ezekre szükség van a különféle hülye programok konfigurálhatatlan logolási megoldásai körüli workaroundok építéséhez.

Az rsyslog hozzáértő kezekben valószínűleg a leggyorsabb logolási megoldás, ami nagyon menő dolog. Ezt javasolnám mindenhova, ahol kettő csilliárdnál több logsort kell kezelni másodpercenként, azaz úgy tizenhárom kutatóintézetnek az egész földön. Másoknak inkább nem ajánlanám a szoftvert, mert:
- a konfigformátuma _nagyon_ rossz (az új, 7-es verzióban is, csak ott máshogy), olvashatatlan és nagyon nehezen írható
- nincs használható dokumentáció a program architekturális felépítéséről
- az rsyslogban van egy rakás konkrét hiba (pl. a v5 verzió fájlok felolvasásakor logsorok felét elfelejti felolvasni meg hasonlók)
Ezen kívül előnyei az rsyslognak, hogy GPL, van rá support is, akár a RedHat-tól, akár a fejlesztő cégétől. A tapasztalat, hogy megoldáják a hibákat, de nagyon lassan.

A syslog-ng előnye, hogy teljesen baráti a konfigurációja és újabban a GPL változatban is megvan minden olyan feature, amire általában szükség van. Hátránya, hogy ha használod, akkor rád akarják sózni a fizetős változatot is, ami igazából nem kell. További hátránya, hogy a licenszelése miatt bizonyos háklisabb disztribúciókba nem kerülhet bele. Még hátránya, hogy erősebb akaratú fejlesztőcég van mögötte, mint az rsyslog mögött, így a fiztetős disztribúciók kevésbé szeretik, mert nem tudják arra hajlítani a fejleszőt, amerre szeretnék.

A többi logtovábbítót nem ismerem (még nxlog-gal találkoztam, az kb. egyesítette az eddig felsoroltak hibáit és adott nehzítésként egy rossz interfészt a programhoz).

Ha Windowsokat is akarunk belekavarni a dologba, akkor ott a Splunk a nyerő megoldás nagyjából mindenre - cserébe elég drága dolog. Ha logokat elemezni is akarunk, akko szintén a Splunk a király, de még mindig drága. Kíváncsi vagyok, hogy a logstash mennyivel jobb/rosszabb - szükség lenne alternatívára...

> még nxlog-gal találkoztam, az kb. egyesítette az eddig felsoroltak hibáit és
> adott nehzítésként egy rossz interfészt a programhoz

Gondolom volt valami rossz tapasztalatod vele és onnantól közellenség lett számodra. Ettől függetlenül engem érdekelne, hogy konkrétan mit értesz a "felsorolt hibák" illetve az "interfész" alatt. Már csak azért is, mert igyekszünk ezeket az észrevételeket figyelembe venni a (tovább)fejlesztése során, hogy esetleg te is adhass neki még egy esélyt.

A következők nem tetszettek az nxlogban (kb. 1.5-2 éve, azóta javulhatott a helyzet és lehet, hogy nem mindenre emlékszem jól):

- a syslog-ng-hez hasonlóan csak a fizetős változatban (vagy abban sem) voltak bizonyos feature-ök, amelyek kellettek volna (SSL-es logtovábbítás és timestampek kérése logfájlokra)

- az rsyslog-hoz hasonlóan olvashatatlan volt a konfigformátum (apache-re hasonlító, xml-szerű fő konfig blokkok, de bennük vegyes perl/C közötti szintaktikájú inputok/minták/célpontok, aztán egy harmadik szintaktikájú összekötögetés az input-minta-célpont hármas elemei között)

- gyárilag nincs debian és társaiban valamint redhat és társaiban.

Konkrétabb dolgok:

- egy különösen zavaró és fájó pont volt, hogy a telepítés közben az rpm -ihv vagy a yum localinstall nx* után feldobott egy ncurses-es dialógusablakot a telepítő, ezzel adva némi munkát, hogy bele lehessen reszelni az egészet egy kickstartba

- emlékeim szerint elég sok idő elment olykor-olykor arra, hogy kiderítsük, miért nem kommunikál az nxlog kliens és az nxlog szerver (tűzfal? lejárt a certificate? segfaultolt éppen a kliens? - előfordult mind a három)

- a menedzseléshez használható webservice api nem része a CE-nek, a fizetőshöz kapott dokumentáció meg elég gyengécske volt - cserébe szerintem nem is az nxsec írta, hanem a disztribútor, akitől jött az nxlog.

Kb. ezek voltak a bánataim.

Megtaláltam a régi levelemet erről, a stílusa nem túl szép és véleményem szerint ezek azóta megoldód(hat)tak, ez 2012. januárjában volt a helyzet:

Hibák velekapcsolatban:

- az rpm-es telepítője ncurses-es felületen kérdezget az embertől (azrpm-eknek nagyon nem kéne ilyet tennie)
- az init scriptje nem túl jó:

restart|force-reload)
echo "Reloading nxlog daemon..."
$nxlog -r
RETVAL=$?
;;

Frissítés után vígvidáman mondtam neki egy restartot, aminek az
eredménye egy reload lett, ami miatt ilyeneket kaptam:

2012-02-09 11:10:19 ERROR Failed to load module from
/opt/nxsec/libexec/nxlog/modules/input/im_tcp.so,
/opt/nxsec/libexec/nxlog/modules/input/im_tcp.so: undefined symbol: nx_mo DSO load failed

Pedig a doksi szerint a restart és a reload között azért van különbség:

http://fedoraproject.org/wiki/Packaging:SysVInitScript#Required_Actions

- néha megáll, mint a szög, legalábbis a kliensoldal, néha ilyesmi üzenetekkel:

2012-01-31 19:32:13 CRITICAL ### PANIC at line 647 in main-unix.c/_got_sigterm(): "double termination request, aborting (aborted due to uncaught exception)." ###

Néha meg csak úgy, üzenet nélkül.

> - a syslog-ng-hez hasonlóan csak a fizetős változatban (vagy abban sem)
> voltak bizonyos feature-ök, amelyek kellettek volna (SSL-es logtovábbítás és
> timestampek kérése logfájlokra)
SSL mindig is volt. Timestamp/TSA nem, de ezt ne is várd el hogy lesz, mert tipikusan ez olyan funkció, amely csak komoly vállalati környezetben előírás.

> - az rsyslog-hoz hasonlóan olvashatatlan volt a konfigformátum
> (apache-re hasonlító, xml-szerű fő konfig blokkok, de bennük vegyes
> perl/C közötti szintaktikájú inputok/minták/célpontok, aztán egy harmadik
> szintaktikájú összekötögetés az input-minta-célpont hármas elemei között)
Az rsyslog konfig formátumával nem összehasonlítható.
Ez egyébként egyéni ízlés dolga. Van akinek a markó/template alapú nem tetszik, van akinek a perl/apache stílus a ronda. Az eddigi visszajelzések alapján a felhsználók többsége pont a konfig formátum letisztultsága miatt kedveli.

> - gyárilag nincs debian és társaiban valamint redhat és társaiban.
A debian-ban hamarosan benne lesz, már a NEW queue-ban van egy fél éve. A többi meg idő és kitartás kérdése, ez nem olyan egyszerű feladat.

> yum localinstall nx* után feldobott egy ncurses-es dialógusablakot a telepítő,
Ez a dialog alapú rpm-es telepítő személy szerint engem is zavart. Az ellenérvek között az szerepelt, hogy a deb is ilyen illetve hogy a rendszergazdák többsége (főleg windowson, de tisztelet a kivételnek) nem képes egy konfig fájlt sem rendesen módosítani.

> emlékeim szerint elég sok idő elment olykor-olykor arra, hogy kiderítsük,
> miért nem kommunikál az nxlog kliens és az nxlog szerver (tűzfal? lejárt a
> certificate? segfaultolt éppen a kliens? - előfordult mind a három)
Talán ez ügyben is javult némileg a helyzet, ám ez a téma a legtöbb hasonló eszközzel/helyzetben is viszonylag sok debug-olást kíván.

> Frissítés után vígvidáman mondtam neki egy restartot, aminek az
> eredménye egy reload lett, ami miatt ilyeneket kaptam
Ez azóta már javítva lett AFAIK, és teljesen jogos az észrevétel.

> néha megáll, mint a szög, legalábbis a kliensoldal, néha ilyesmi üzenetekkel:
> 2012-01-31 19:32:13 CRITICAL ### PANIC at line 647 in main-unix.c/_got_sigterm():
> "double termination request, aborting (aborted due to uncaught exception)." ###
A leállításkor néha kis idő kell neki, hogy üzenetvesztés nélkül vagy mindent lementsen vagy elküldjön. Többszöri leállítgatásra szándékosan abort() a vége.

Egyébkent 1,5-2 év alatt valóban sokat változott a helyzet.

Köszönöm az észrevételeket!

1) ha syslog-ng OSE-t hasznalsz, senki nem akarja raderoltetni a PE-t, mert az esetek 99%-ban a Sales azt se tudja, hogy hasznalod. Es eroltetni egyebkent sem szoktak, emlekeim szerint. De ha tevedek akkor javits ki, az ilyen fajta visszajelzes hasznos lenne.

2) A syslog-ng OSE licenszelesevel az egyetlen "problema" az volt, hogy volt egy contributor agreement, es dual licenszelve volt. Ettol meg kb az osszes distroban benne volt, meg a leghaklisabban (hello, Debian) is. Kb 3-4 eve azonban mar GPL/LGPL tisztan, nem dual licensz, es CA sincsen. Olyan sose volt, hogy valamely distroba a licensz miatt ne kerult volna be.

3) A disztribuciokkal a BalaBit igen szorosan egyuttmukodik (es konferenciakon a kulonbozo distrok relevans embereitol tobbszor jott az a visszajelzes, hogy velunk lenyegesen konnyebb egyutt dolgozni :P), rengeteg mindent megcsinaltunk nekik amit kertek. Az, hogy egy ceg van mogotte, csak a CA/dual licensz miatt okozott gondot regebben, de az is mar jopar eve volt.

--
|8]

1) Volt rá példa, mikor botor módon megkerestük a sales-t, aztán nem igazán voltak hajlandóak békénhagyni. Két munkahellyel ezelőtt.

2. A RedHatnak konkrétan nem volt jó, lásd itt:
https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02385.ht…
Örülök, hogy ez azóta megoldódott - de a RHEL-ben még mindig nincs syslog-ng (pedig örülnék neki).

3. A RedHat meg a Novell annak idején mást mondott :-)

Egyébként félreértés ne essék ebben a threadben - nem áll szándékomban azt mondani, hogy bármelyik (rsyslog, syslog-ng, nxlog volt itt emlegetve, amivel több tapasztalatom van) log megoldás végletekig rossz lenne - de mindegyiknek vannak számomra kellemetlen korlátai.

2) Ez a defaultrol szol. Debian hasonlo okok miatt dontott rsyslog mellett. Ettol meg a distroba bekerulhetett volna, csak RHELnel az volt a mondas, hogy minek legyen ket syslogd? A licensz a defaultta valast akadalyozta, nem a bekerulest, az egy sajnalatos mellekhatas volt csak. :(

3) Az elmult 3 evben biztos nem (openSUSE pl ket GSoC helyet adott nekunk iden, annyira joban vagyunk ;), es jopar RedHates emberrel is jo viszonyt apolunk (pl a systemd-s arcokkal is, tobbek kozt). Korabban lehet hogy voltak problemai RH-nak meg Novellnek, de 3 evnel regebbi elsokezbol szarmazo infom sajnos nincs :(

--
|8]

( csardij v | 2013. 10. 20., v – 21:27 )

Az adott gépen ugyis csak arra kell a syslog daemon, hogy áttolja a dolgokat a központi syslog szervernek, így amit a disztró szállít és supportál.

Amúgymeg syslog-ng.

( bAndie9100 | 2013. 10. 23., sze – 21:30 )

nxlog

~~~~~~~~
Linux 3.2.0-4-486
Debian 7.1