[megoldva] syslog-ng migralas valami masra?

Segédprogramok

Barki balabitesnek aki oldalon fellelheto van e fogalma arrol, hogy a syslog-ng melyik verzioval kezd mukodni (ujra)?
Van-e ertelme varni ra?

Jelenleg 3.5.6-1 elorecsomagolt syslog-ng van hasznalatban nalam.

Gondoltam ertelmes valasztas lesz. SSL + client cert check volt a definialt sourceon, default beallitasokkal.
ez a default ami neten is volt:
tcp( ip(0.0.0.0) port(443) max-connections(2048) tls( key_file("/etc/syslog-ng/cert.d/serverkey.pem") cert_file("/etc/syslog-ng/cert.d/servercert.pem") ca_dir("/etc/syslog-ng/ca.d")) );

Tesztkent gepenkent 20 msg/sec ment ra, nem is volt baj vagy legalabbis nem neztem meg cput, mert nem felteteleztem szamit ennyinel. Egyetlen feladata volt, mindossze az, hogy kiirja fileba vagy tovabbitsa amit kapott.

Ez a hihetetlen 20msg/s nagyon remek, de elesben nagyjabol 2-2.5k msg/s (egyenkent 30-450 byte) kene gepenkent. De meg ez is olyan szam, hogy akar egy atomnak is el kene birnia.
Mivel ez csak logolas, meg keves is az adat, igy kukazott, regebbi gepeket kapott a szolgaltatas E5649-2.53 cpuval. Egeszen ~200req/s -ig jutott. Ekkorra mar 100% cpu.
Ahh mondom mind1, syslog-ngt megszoktam mar. Inkabb akkor kapjon erosebb gepet. Atraktam E5-2680v2-2.80GHzre. ~260 r/s nel jott el a 100% cpu. Mondom ez csak veletlen, de biztos ami biztos megprobalom E5-2697v3-al is. ~350 req/s volt eredmeny. Termeszetesen ez mind 1 magon ertendo, hiszen hogy varhato el egy mai programtol, hogy tobbszalu legyen? :D

Ez volt a kisebb gond, mert elinditottam volna syslog-ng t annyiszor ahany mag van es majd jol loadbalanceolom. Be is lottem. De ugy 30perc utan mar syslog-ng processenkent 16G ramot evett.

Ekkor visszakoltoztem kukazott fosgepekre. Osszehanytam egy perl daemont, hogy kideruljon, hogy a cpu-e ennyire fos? Ez birt 8900 message/s et. Aztan mondom ez nem lehet ilyen fos, mert meg ez is csak 2.5 MB/s koruli forgalom. Aztan c++ meg libevent pont ilyenre talaltak ki. Nem optimalizaltam semmit, tehat std::string mindenhova lustasagbol meg stb. Csak meg akartam nezni, hogy mennyit bir igy. 216k message/s ig tudtam tesztelni, mert 1 szalu volt a teszter program.
Privat kulcs meg cert minden maradt ugyan az, ami syslog-ng nel is volt.

Masik helyen UDP source + 22k message/s et kellett volna birnia. Talan 15k nal 100% cpu volt (e5-2660 - 2.2Ghz). Aztan ott most perl fut es fogadja udpn csomagokat. 0-5% cpu hasznalat mellett 1 szalon.

Tehat meg1x a kerdesem az az, hogy mi a fasz van ezzel a syslog-ngvel? Tele van rakva sleep-el? Vagy mi ez a lassusag, hogy meg egy perl daemon is sokkal gyorsabb (de nem csak, hogy sokkal gyorsabb, mert osszehasonlitani sem lehet, mert nem egy ligaban jatszanak. Erted egy perl script vs c kod ... A syslog-ng + ssl meg informatikai paralimpiara sem nevezhetne ilyen teljesitmennyel. Talan meg a vizesvodrot sem cipelhetne)? Meg mi ez a pusztito igenytelenseg releasenel, hogy ilyen durva memleakkel ki van engedve productionbe a kod?
Melyik verzio hozza el a megvaltast, amikor ujra lehet hasznalni ilyen dolgokra syslog-ngt?
(Engem az sem zavarna, ha fizetni kellene erte, hogy mukodjon, mert configfile formatuma tetszik meg kepessegei eleg jok lennenek ha mukodnenek.)
Tehat kedves balabit vagy annak kepviseloje: ne is szamitsak ra, hogy ez a syslog-ng valaha mukodo software lesz?

update - megoldva: valaszt megkaptam. Tehat syslog-ng elfelejtve, mert nem is igy van tervezve, hogy barmilyen fele logot tudjon logolni. Visszanezek ra, ha majd megjelenik vmelyik verzioban normalis buffereles is. De ettol meg a rovidke devlogos systemlogokra marad, arra megbizhato volt eddig is.

  • 6990 megtekintés

( eldar | 2016. 03. 01., k – 11:41 )

Szia,

par kerdes/megjegyzes:
* Milyen OS-en hasznalod, es honnan raktad fel a syslog-ng-t?
* Milyen konfigot hasznaltal, amikor 100%-on porgott a CPU?
* Probaltad SSL nelkul is? Ha igen, ugy is kitolta par szaz uzenet/sec a CPU-t? Ill. a perl scripted is hasznalt SSL-t?
* UDP-s esetben megprobaltad allitani a socket buffert? (Lasd https://www.balabit.com/documents/syslog-ng-ose-3.5-guides/en/syslog-ng… )
* A 3.5 is tud tobb szalon mukodni, csak alapbol nincs bekapcsolva. Illetve az, hogy mennyire skalazodnak a szalak, az fugg pl. a konfigtol es a kliensek szamatol is.
* Perl script reszeles elott probalkoztal ujabb verzioval?

* Milyen OS-en hasznalod, es honnan raktad fel a syslog-ng-t?
debian wheezy.
apt-get install al raktam fel

* Milyen konfigot hasznaltal, amikor 100%-on porgott a CPU?
source amit mutattam. destination meg mondjuk udpn mashova vagy fileba. parser nincs. filter nincs. 128K maxmessagesize. 65k rlimit nofile, ~500 kapcsolat.

* Probaltad SSL nelkul is? Ha igen, ugy is kitolta par szaz uzenet/sec a CPU-t? Ill. a perl scripted is hasznalt SSL-t?
ssl nelkul ahogy irtam birt joval tobbet de az is siralmas akar egy perlscripthez kepest is. A tcp tesztnel perl script is hasznalt sslt termeszetesen
* UDP-s esetben megprobaltad allitani a socket buffert? (Lasd https://www.balabit.com/documents/syslog-ng-ose-3.5-guides/en/syslog-ng… )
termeszetesen nem allitottam ilyet. Perlnel nem allitottam at defaultrol.
* Perl script reszeles elott probalkoztal ujabb verzioval?
Igen elsonek 3.3 volt aztan 3.5 lett.

debian jessiere meg nem frissitek. Ha ilyen systemd szeru fostengert szeretnek magamhoz beengedni (kiprobaltam nagyon jo volt, de meg nem production jessie wheezyhez kepest. wheezy telepites + config utan hasznalhato. Ha kiesik egyik disk mdraidbol tuljut initrdn. Ha hiba van vmi processel boot folyaman akkor kiirja kepernyore, stb. Ezen jessierol nem mondhatok el. Vagy mikor probaltam meg nem volt keszen.), akkor inkabb osszes gep gentoo lesz + binhost vagy valami uj ubuntu es akkor benyelem systemd-t.

De nekem csak garancia kellene arra, hogy 3.6.x re frissitsem fel es onnan garantaltan nincs memleak meg cput sem daralja csak ugy a semmire. Meg legyen olyan mod, hogy inkabb vesszen el uzenet, de ne egye mar meg osszes memet, ami gepben van.

* A 3.5 is tud tobb szalon mukodni, csak alapbol nincs bekapcsolva. Illetve az, hogy mennyire skalazodnak a szalak, az fugg pl. a konfigtol es a kliensek szamatol is.
Errol tudsz tobbet mondani? Tehat meg van csinalva akkor ezek szerint main process + worker forkok? Olyanra nem is gondolok, hogy ujabb kernel + SO_REUSEPORT.

( uid_194 | 2016. 03. 01., k – 12:27 )

A 3.5.6-1 debianban nagyon gaz tud lenni. Tudom, azt meg en csomagoltam. Sokszor akartam frissiteni debianban, de elfogyott a lendulet, es igy maradt.

Van upstream csomagolt 3.6/3.7, az nagysagrendekkel szebben muzsikal, erdemes elnezni arrafele, es remelni hogy valaki majd debianba is korrektul betol egy syslog-ng frissitest.

--
|8]

( czanik | 2016. 03. 01., k – 12:14 )

A syslog-ng.conf -ot légyszi elküldeni! Persze ha van benne bármi érzékeny adat (host/ip/stb), akkor azokat anonimizálva. Ill. milyen oprendszer és honnan van a csomag hozzá? Ennél egy ócska laptopon virtuális gépben többet kéne tudnia a syslog-ng -nek, de persze filterekkel, soronkénti log kiírással, rosszul beállított pufferekkel sokat lehet lassítani rajta :)

Ezt a fejezetet érdemes lehet elolvasnod a doksiból: https://www.balabit.com/sites/default/files/documents/syslog-ng-ose-3.7…

Először is, ahogy algernon is írta: érdemes frissíteni. Nem hivatalos Debian csomag elérhető a https://build.opensuse.org/project/show/home:laszlo_budai:syslog-ng címről.

De ha nem akarsz frissíteni, akkor is a threading-hez a globális opciók között fel kéne venni a threaded(yes) opciót. E nélkül egy szálon fut az egész syslog-ng. Itt olvasható róla dokumentáció: https://www.balabit.com/sites/default/files/documents/syslog-ng-ose-3.7…

A log_msg_size-ot érdemes a szükséges legalacsonyabb értéken tartani, mert ez fog felszorzódni mindenhol és erősen elszállhat tőle a RAM fogyasztás. Tényleg érkeznek 128k-s üzeneteid?

A max-connections-t szintén ha 500 kapcsolatod van, akkor szintén a 2048 overkill.

A log_fifo_size, log-iw-size, stb. beállításokat itt érdemes elolvasni: https://www.balabit.com/sites/default/files/documents/syslog-ng-ose-3.7…

igy van, hiszen adott verzional, amit hasznalok barmilyen beallitott ertek utan memleakel. nem veszi figyelembe limitet. Kiveve ha tul alacsony mert, akkor segfaultol is.

Aztan a legjobb cpukkal elert siralmas ertekek is biztosan az rtfm miatt vannak. Hiszen nem allitottam be, hogy log-cpu-percent-max(1)-et, es persze connectiononkent. nem?
Vagy nem allitottam be, hogy ne javavmbe futtassa syslogngt es tul alacsony xmx ezert 100% a cpu?

"A log_msg_size-ot érdemes a szükséges legalacsonyabb értéken tartani, mert ez fog felszorzódni mindenhol és erősen elszállhat tőle a RAM fogyasztás. Tényleg érkeznek 128k-s üzeneteid?"
log_msg_size 128k, mert atlag joval kisebb de van hogy jo nagy sor jon, ha ugy alakul. freestyle logrol van szo.

"A max-connections-t szintén ha 500 kapcsolatod van, akkor szintén a 2048 overkill."
50-60k kapcsolatom van egyidoben csak tobb gep meg tobb process. legszievsebben mindegyik gepen mondjuk 65k-ra raknam, mert mivan ha balancerbol kiveszem tobbi gepet es csak egyet akarok meghagyni vagy sajat magatol kiesik? Meg ennek nem kene jelentosegenek lenni. Nginxben beallitom 65k vagy haproxyban beallitom limitet, akkor az annyit tud normalisan. Nehogymar faszoznom kelljen meg mindig pont hatarra allitani.

Nekem az kell, hogy belovok egy global buffert 10G re mondjuk. Ossza be. es ne lepje tul. Ha ezt a global buffert ugy kell megadnom, hogy global_log_fifo_size(100000) meg global_log_msg_size(128K) akkor ugy.

De nem cska ezzel van igy. Ott a 128K ertek. Ha 512K vagy 1M uzenetekkel kezdem el bombazni, akkor mintha nem is lenne ott a limit befosik a gecibe es 10mp alatt megeszi osszes ramot vagy eppen segfaultol. Tehat erted mi a faszom?

De log_fifo_size(16) log_msg_size(1024) max-connections(10) re allitva is pont ugyan olyan gyorsan leakel, ha nem gyorsabban. Ha atteszem 10 bytera is 1 ora alatt betelik ram 3.5os verzioval

de mostmar tenyleg letoltom ezt a 3.7et es kirpobalom.
Ha az is fos lesz akkor meg nemtom mi legyen. De ezek utan erted, hogy bizzon az ember meg egy cegben ahol egy ilyen egyszeru feladat is nehezseget okoz?
Honnan tudjam, hogy a shellcontrolbox holnap nem fog beszarni, mert harommal tobb uzenetet irtam be?

Ilyen felhasználási környezetben nem igazán értem miért nem a syslog-ng PE-t használod (már csak a support miatt is), amit leírtál az igen extrém környezetnek számít (50-60k kapcsolat -> extrém nagyvállalati környezet ha ennyi kliens van, 1 MB-os log szintén, mi tud ekkora logot produkálni a szürke 50 árnyalatát küldözgeted logként? :))

Másfelől viszont, a konfigod nagyon rossz ezzel a logvesztés garantált, és a leakre is lenne pár tippem.
Ugyan nem láttam a teljes konfigodat, csak részenként osztasz meg infókat belőle, de a főbb részei saccra:

max-connections(2048), log_msg_size(128K).
Na már most, ehhez a syslog-ng 204800 (2048x100) log_iw_size-t fog beállítani automatikusan, ami azt jelenti hogy a log_fifo_size-nak is minimum ennyinek kell lennie, ennyit el kell tudni tárolnia a memóriában hogy ne legyen logvesztés.

Memóriaigényben ez 204800 * 128K = 25 GB memória használatot jelenthet teljesen normál üzemi körülmények között (feltéve hogy épp nem tud kiküldeni logot akkor ennyire felhizhat a syslog-ng memória használata).

És akkor a leakre pár tipp:
* ha a log fifo kisebb mint a fenti kalkuláció eredénye (vagy behelyetesítve a te számaidat) akkor a logok belül el lesznek (lehetnek) dobva, de ha bugos akkor lehet hogy nem szabadítja fel az üzenetet.
* Ha nagyobb üzenetek jönnek mint a beállított log_msg_size, akkor le lesz csapva a vége, akár ezt is el lehet leakelni

De ha van (vagy volt) is ilyen bug a syslog-ng-ben, simán lehet hogy újabb verzióban javítva van ezért is érdemes frissiteni.

Másfelől viszont, azért is éri meg issue-t nyitni, mert nem igaz az állítás hogy idézlek:
"annak rettentő kicsi a valószínűsége, hogy valami szoftverhiba csak itt, csak Magyaországon, csak egy ügyfélnél forduljon elő"

Ugyanis elég extrém beállításaid vannak ami extrém környezetet feltételez, ráadásul úgy tünik hogy a konfigod hozzáértés nélkül random van összerakva, gondolom innen-onnan copy paste és ahogy irtam a logvesztés pl. garantált a beállításaiddal.

Ami pedig azt jelenti hogy más felhasználó lehet hogy nem is szembesül ezekkel a problémákkal, mert pl. a leak a hibás konfignak köszönhető, és persze ettől még nem szép ha leakel, csak épp ha valaki helyes konfiggal használja akkor nem jön elő neki a hiba.

Egyszerüen rámutatva:
"De log_fifo_size(16) log_msg_size(1024) max-connections(10) re allitva is pont ugyan olyan gyorsan leakel, ha nem gyorsabban. Ha atteszem 10 bytera is 1 ora alatt betelik ram 3.5os verzioval"

max-connection(10) esetén a log_iw_size 10x100-ra áll be, amihez legalább log_fifo_size(1000) kell (feltéve hogy nincs más source-od csak ez az egy). a 16-os érték extrém rossz.

A müködésről pedig annyi hogyha a syslog-ng nem tud (vagy nem elég gyorsan) küldeni, akkor betesz 1 üzenetet a pufferbe (fifo-ba), és 1-el csökkenti a sourcehoz tartozó iw-t. Ha az iw eléri a 0-át, nem olvas be többet igy életbe lép a flow-control (belassítja a küldöt) miközben iw-nyi log lesz tárolva a pufferben.

A te esetedben viszont 16 lesz a pufferben miközben a beolvasó oldal azt hiszi hogy még 984 hely van és vigan olvassa be a többi logot a nagy semmibe.

A memleakre nincs mentseg. Nem lehet memleaket rossz configgal csinalni. De ha netan megis lehet ES meg raadasul meg is lehet indokolni, akkor meg a config parser a szar, hogy engedi elindulni. A cpu kihasznaltsagra szinten nincs mentseg. Persze biztos valami default cipher a fos (remelem, hgoy nem csak benchmarkot futtat unalmaban, hogy melegen tartsa a procit), de fasze nem valami mukodo es gyors van defaultnak odairva. Persze inkabb arra tippelek direkt van elbaszva, mert perlnel meg c/libevent sem allitottam semmit direkt, mert nem is erdekel. Felolem ellophatjak ami adat rajta atmegy, csak latszatbiztonsag kell audit miatt.

- 50-60k meg nem irrealis elvaras, akar 1 darabtol sem. Csak azert van szetszedve, hogy ha vmi geppel hiba van, lehessen fixalni es ne mindenki egyszerre essen ki. Es itt nem azt mondom, hogy 60k req/s es minden connectkor epitse fel ssl kapcsolatot minden uzenetnel, stb. Hanem bekapcsolodik ennyi ember 1x es szepen lassan irogatjak uzeneteiket.
Ami 1MB nem volt sosem, csak tesztkor. 128K nal mar volt tobb, de ez is ritka es szeretnem az eselyt megadni neki legalabb 128K nak.

"1 MB-os log szintén, mi tud ekkora logot produkálni a szürke 50 árnyalatát küldözgeted logként? "
- Nginxes pelda: location /upload { client_max_body_size 1G; }. Ha 99%ban 100kB ot toltenek fel, akkor nekem le kene csokkenteni limitet 101kB ra? Durva lenne. Persze mint irtam elveszhet log, tehat akar le is csokkenhetne 500 bytera, de nem fogok ugy nekindulni, hogy fos a syslog aztan beletorodok.

" Na már most, ehhez a syslog-ng 204800 (2048x100) log_iw_size-t fog beállítani automatikusan, ami azt jelenti hogy a log_fifo_size-nak is minimum ennyinek kell lennie, ennyit el kell tudni tárolnia a memóriában hogy ne legyen logvesztés."

Ez is az egyik baj igen, ratapintottal a lenyegre. Letezik egyaltalan olyan beallitas, ahol dinamikus egesz es nem ilyen fos? Tehat ahol azt mondom van global buffer az osszesen 100000 sor legyen. 1 sor maximum 128K de lehet 1 byte is, ha pont olyan adat jon. A global connection limit meg 65k mondjuk. Ha kifutok 100000 sorbol akkor meg dobja el. Kesz, ennyit szeretnek. Nem akarok connectiononkent allitani semmit. Nem akarok sourceonkent allitani most semmit. Nekem global kell. Es nem fix meretu csomagokat akarok kuldeni, hanem csak siman csomagokat akarok kuldeni. Logolni szeretnek, amiben nem mindig ugyan az a "hello world" szoveg van.

De ha nekem ideirod jo configokat az megjobb es kiprobalom. Aztan kiderul, hogy mukodik-e vegre.
Tehat
- _max_ 128K uzenet. Tehat 0 es 128k kozott, dobja el/vagja le ha nagyobb mint 128K. Tehat ne strcpyzze bele egy 128k charba a 512ks uzenetet.
- legyen max 100000 sor a buffer. Nem fixen, hanem _max_, tehat 0 es 100000 sor kozott.
- _max_ 65k ssl tcp connection tcpn. Ne fixen kelljen neki, hanem lehessen 0 is meg 65k is
- forward 1 destinationre, ami ha nem elerheto ne harakirit kovessen el a syslog-ng hanem nyugodjon le a fenebe.
- dobja el ha 100000 nel tobb sor varakozik bufferben vagy dobalja ki bufferbol regi cuccokat.
- es nem connectiononkent akarok 100000 sor buffert hanem osszesen, global, en bloc. ha 65kbol 1 osszehozza 100k t akkor igy jar a tobbi uzenet. Nem erdekel.

De, hogy ha nem is lehet ezt a configot produkalni, akkor kozelitse meg amennyire lehet es ne memleakeljen, akkor se ha tobb a connection, ha nagyobb az uzenet, ha kicsi az uzenet, ha null van benne, ha utf8 van benne, ha \r van csak sorvegen, vagy ha az sincs vegen, ha nem connection resettel vagy finnel lep ki user, ha ssl kapcsolat felepitese kozben lep ki, stb.

Ennyi a keres.
Persze jo lenne, ha byteban is meg lehetne adni a _maximalis_ global buffermeretet. Persze az mar nagy melo lenne, meg meg 1 hely ahol memleak lehet aztan azt megint fixalni kell majd. De mind1 is ...

Vagy ha kifizetem supportot vagy licenszdijat vagy az ugyeletes anyamkinjat, akkor kapok garanciat arra, hogy valami mukodni fog nagyjabol? Vagy csak arra kapok garanciat, hogy ugyan azok az emberek akik a nem fizetoset irtak 3.3 es 3.5ost mondjuk, fejlesztenek majd valamit valemennyi idon belul miutan felvettem ticketet es elbasztam meg telefonalgatassal emailezessel meg debugolassal x idot? Meg mivel nem emlitem majd meg, hogy kezeljenek le olyan lehetetlen helyzetet is ahol harom egesz darab "x" karakter van egymas mellett, ezert arra majd uj ticketet vegyek fel es kezdodik majd elolrol?

De az aktualis helyzet mar meg van oldva ugy, hogy syslog-ngket kikapcsoltam es sajat cuccot hasznalom 1-5% cpu es ~5-150MB memoria hasznalat mellett, mind1, hogy a kedves hekker nullokat kuld vagy lassan zarja kapcsolatot vagy 60kt terelek ra vagy 1 connectiont vagy tele lesz a buffer vagy eppen ures.
Egyszeruen orultem volna, ha batran tudnam hasznalni syslogngt systemlogokon kivul masra is, ha mar ennyi funkcio van benne. Es ne kezdjem minden ilyen projectet ugy, hogy na van uj syslogng yeah akkor hazsnaljuk hiszen 99%ban tudja amit akarok. Aztan 2 nap utan ugyis ujra kell irni nullarol egeszet es varni kovetkezo syslog-ng re vagy egy teljesen mas valamire, ami vegre mukodo logolast tud biztositani.
Es csak annyi lenne celom, hogy megtudjam, hogy pl 3.9.1-es verziotol tol ujra tudom majd hasznalni, mert configba nem kell irrealisan nagy ertekeket irogatni normalis hasznalat mellett.

Kedves kicca,

Abban egyetértek veled, hogy a memleakre nincs mentség.
Az bug, és ASAP fixálni kell.
Sok különböző hsz. érkezett már.

Hogy tiszta vizet öntsek a pohárba, a konfig amit írtál: valid.
Létezik olyan use-case, ahol pont olyan konfigurációra van szükség, mint amit te beállítottál.
(ergo, nincs olyan automata, ami ezt "szabályosan" ki tudná dobni, hogy "hülyeség".)

Viszont ilyen esetben a felhasználó alá is teszi azt a pár-tíz GB memóriát.
Ettől ez még nem lesz memleak.

Kérlek, azt lásd be, hogy a syslog-ng egy logot kezelő eszköz.
Ahhoz, hogy ezt a feladatát maradéktalanul el tudja látni,
és fel tudjon készülni az "átlag"-felhasználó elvárásaira,
amiben viszont rendszerint benne van az a kitétel,

hogy NE veszítsen logot,

kell neki ennyi erőforrás ilyen konfig mellett.

A log kezelésében benne van az, hogy azt fel kell parseolni az rfc-knek megfelelően.
Az esetlegesen az rfc-ket violáló mindenféle gyártók
(nem akarok most nagy hálózati-eszköz gyártó nevekkel dobálózni)
az rfc-ben írtakra jobbára csak hírből hasonlító log-szerűségeit is valahogyan kelenie kell.

Mindemellett, a logok között korreláció keresésére is fel kell készülnie
(ld. még patterndb nevű aktívan fejlesztett feature).
Arra is fel kell készülnie, hogy a "rendes" logformátum, ami az rfc5424,
az elég flexibilisre sikerült, és ennek a parseolásához,
valamint a logevent parsolása utáni nv-pairek tárolásához _sok_ memória kell.

Szóval és amennyiben valóban logról van szó, ez elképzelhető, hogy valóban igényel ennyi erőforrást,
és a leírás alapján még nem vagyok meggyőzve arról, hogy valóban van memleak a te verziódban.
A use-case megvalósításához szükséges erőforrások megtervezése külön szakma.
Nálunk evvel pl. a pre-sales mérnökök foglalkoznak.

Azt sem tagadom, hogy volt már a syslog-ng-ben memleak. Egyet én magam fogtam meg.
Pont file destination-ökhöz kapcsolódik, amikor nagyon sok különböző hostról jött log,
a dest fájl nevében benne volt a host név,
meg a lehetséges kimenetek száma még valamilyen másik mezőnek köszönhetően megsokszorozódott,
akkor valóban lehetett memóriafolyást előidézni.
Lehet, hogy a 3.5-ös ágban még benne is maradt ez a bug.
Az már sajnos nincs aktívan karbantartva.
Sajnos a debianban sem követik aktívan jelenleg a syslog-ng életét,
hogy az esetleges bugfixeket backportolják.
Az volt még a jó világ, amikor ez algernon kezében sok oldalról összefolyt.

Amit viszont meg tudok erősíteni, és már elhangzott:
A Budai Laci féle OBS repót használd bátran!

Kérlek azt is lásd, hogy amennyiben a megfelelő fórumon kérsz segítséget,
és a megoldást segítő információk átadásával hajlandó vagy segíteni,
az OSE verziónál is elkötelezett fejlesztők és felhasználók hajlandóak neked segíteni.
Gondolok most a megfelelő fórum alatt az OSE verzió felhasználói levelezőlistájára:
https://lists.balabit.hu/mailman/listinfo/syslog-ng
Valamint a kapcsolódó github projektre, ahol szintén tudsz issue-kat reportolni.

Annak alapján amit írsz, felmerül bennem a kérdés,
hogy biztosan log érkezik neked abban az ssl csatornában?
Kérlek azt lásd be, hogy még az rfc5424-nél,
ahol flexibilisen sok mezőbe már kvázi elő-emésztett log érkezik, SEM szokványos,
hogy egy logevent 128k nagy legyen.

Ha hajlandó vagy részleteket megosztani velem, nagyon szívesen segítek a probléma feltárásában,
amennyiben valóban log-ról van szó, illetve ha nem a syslog-ng a te use-casedre való eszköz,
akkor alternatív javaslat megtételében.
Azt biztosan, és most meg tudom mondani neked, hogy azok a fajta elvárások, amiket írtál,
hogy a "terhelés" és az "aktuális log mérete" alapján dinamikusan legyen a pufferek foglalva,
erre a termék nem alkalmas, nem is erre lett tervezve, valamint a háttérben lévő C memória-allokátor libek sem alkalmasak ilyen use-case-re.
Ha kvázi "feldolgozatlan" / emésztetlen véletlenhosszú "stringek" beolvasására kell egy eszköz ssl csatornáról,
akkor valóban jó irányban indultál el, erre a use-casere egy célirányosan megírt perl script, a nyelv és a stringkezelésének adottságai miatt alkalmasabb lehet.

Ha mégis logkezelésről van szó, és ezt kellene "megfaragni" a te esetedhez,
akkor javaslom ennek az eszköznek a használatát:
https://github.com/balabit/syslog-ng/blob/master/contrib/README.syslog-…
https://github.com/balabit/syslog-ng/blob/master/contrib/syslog-debun
Kérlek körültekintéssel használd: arra még nincs felkészítve,
hogy ha a syslog-ng konfig könyvtárán belül ott egy ssl kulcs privát fele,
akkor azt ne mentse bele a debug .tgz-be. Ez a fajta user-behaviour csak nemrégiben tűnt fel nekem is,
és még nem volt érkezésem reagálni rá.
Valamint mikor van egy "első körös" debug bundle-d, akkor bátran vedd fel velem a kapcsolatot.

Pásztor György
System Engineer
Support
Balabit-Europe Kft.

Az obs repom-hoz segitseg...

Install
-------

example: Debian 8.0

1. get release key
wget -qO - http://download.opensuse.org/repositories/home:/laszlo_budai:/syslog-ng… | sudo apt-key add -

2. add repo to APT sources
eg.: /etc/apt/sources.list.d/syslog-ng-obs.list
deb http://download.opensuse.org/repositories/home:/laszlo_budai:/syslog-ng… ./

Then `apt-get update` and `apt-get install syslog-ng-core=3.7.2-2`

You can replace Debian_8.0 to
* Debian_7.0
* xUbuntu_12.04,
* xUbuntu_14.04
* xUbuntu_14.10
* xUbuntu_15.04

( vl v | 2016. 03. 01., k – 15:56 )

Én 3.4.8-at használok. Teljes megelégedéssel. Jelenleg figyel egy mask a >=3.5-re, nehogy véletlenül bármi abból a szériából kinőjön nálam.

Amikor a 3.6 először felkerült, akkor két hétig kerestem, hogy mitől áll be az openldap rövid használat után úgy, hogy csak kill -9 segít neki... amióta visszamentem a 3.4-es szériára azóta a probléma nincs. Nem óhajtom debuggolgatni más szarát...

Persze. Erre nekem van egy klasszikus mondásom, amit az előző munkahelyemen egy időben a szervíz egyik prominens emberétől hallottam: annak rettentő kicsi a valószínűsége, hogy valami szoftverhiba csak itt, csak Magyaországon, csak egy ügyfélnél forduljon elő. Ergó ha a hiba az én készülékemben van, akkor így jártam. Ha meg nem, akkor majd reportolja/megtalálja a bugot más.

Nyilván nem így állnék neki, ha "picit" egyszerűbben reprodukálható lenne a hiba. Sajnos nem az, érdemi forgalom kell neki, a laptopomon napok alatt sem jött elő, az éles rendszeren pár óra kellett neki. És ha megáll, akkor minden megáll, lévén az authentikáció nem megy, tehát kurvagyorsan nyomja az ember a resetet, nem debuggolgat meg keresgél, hogy mi lehet a hiba. Nyilván elő lehet állítani csak a reprodukálás dokumentálására egy tesztkörnyezetet, abban megfelelő forgalmat generálva.

"annak rettentő kicsi a valószínűsége, hogy valami szoftverhiba csak itt, csak Magyaországon, csak egy ügyfélnél forduljon elő. Ergó ha a hiba az én készülékemben van, akkor így jártam. Ha meg nem, akkor majd reportolja/megtalálja a bugot más."

Ezt úgy hívják, hogy rossz hozzáállás. Vársz a sült galambra? Így nem is fogsz előre jutni, sem a konkrét probléma megoldásában, sem a másban.

http://www.hrportal.hu/hr/proaktivitas-a-titkos-fegyver-20120213.html

http://agilemethodology.org/

Ezek az írások segíthetnek neked.

--
Where do you want to go today?
[nobody@salcay:~]$_

Hát, nem.
Nem várok a sült galambra, hanem alkalmazom ezt az alapelvet:

"Simplicity—the art of maximizing the amount of work not done—is essential"

A probléma megoldásához nem feltétlenül szükséges az, hogy az adott szoftver hibáját kijavítsák. Bőven elegendő megoldás az is, ha másik syslog implementációra váltunk, az meg úgy sacc/kb. nem több 1-2 óránál. Vagy a régi verziót megtartani még ennél is kevesebb energia, ez elsőkörös megoldásnak bőven megteszi.

Ezt az alapelvet kicsit önösen sikerült értelmezned, nem opensource közösségbe való módon.
Ha kizárólag a saját problémáid gyors megoldása a cél, akkor neked nem opensource közösségben van a helyed, ebben ugyanis benne van a kontribúció is. Ha még egy hibajelentést is büdös elküldeni, akkor megérdemled. Te dolgod.

--
Where do you want to go today?
[nobody@salcay:~]$_

Nem, én pontosan jól értelmeztem az elvet: megnézem, hogy mennyibe kerül a közösség számára hasznos hibabejelentés, és ha ez a projektet nem segíti annyival, mint amennyibe kerül, akkor a _projekt_ szemszögéből nézve ez nem indokolható. A közösség szempontjából pedig eldöntöm, hogy van-e erre ennyi szabadidőm, _nekem_, magánszemélyként.

Én nem küldözgetek használhatatlan hibabejelentéseket. Ha leírom, hogy nálam mi nem megy, az valóban 5 perc, de abból sosem reprodukálják a hibát, ha náluk nem jelentkezik egyébként. A nem reprodukálható hibával pedig nem sok mindent lehet kezdeni, ez kb. axióma.

Meggyőzni nem foglak tudni. A _magánszemély_ valóban nem opensource közösség, igazad van. Ha manager szempontból akarod nézni, akkor pedig a GNU/GPL licensz szövegét javaslom.

A "mennyibe kerül a közösség számára hasznos hibabejelentés" nem egy technikai szempont, hanem egy managereknek értelmezhető _anyagi_ megfontolás, és ez nem simplicity elv, hanem profit maximalizálás. Ez egy nagyon egyszerű "nekem mi éri meg, a többi le van...". HA és amennyiben egy opensource csapat is így működne, nem érne semmit az egész.

Az a feltételezés, hogy a nálad jelentkező hibákat úgysem lehet reprodukálni, az akkor igaz, ha nem adsz elegendő információt a hibajelentésben, és később sem vagy hajlandó megosztani semmiféle információt. A "nem működik bzmg" jellegű hibajelentés pedig valóban nettó időpazarlás. Csakhogy ez a dolog rajtad múlik, és hogy mennyire vagy együttműködő. Ha semennyire, akkor valóban nem lehet mit kezdeni a problémáddal. Ez is kb. axióma.

A hibák megkerülését a kijavítás helyett úgy hívják, hogy workaround. Ha pedig ebből hegyeket építesz, az hosszútávon neked nagyon rossz lesz.

Ennek a beszélgetésnek szerintem nem itt van a helye. Ha szeretnél válaszolni, akkor már inkább privátban tedd! Köszi.

--
Where do you want to go today?
[nobody@salcay:~]$_

Persze, hogy nem tudsz meggyőzni, hiszen szerintem nincs is igazad :D

az akkor igaz, ha nem adsz elegendő információt a hibajelentésben

Az információt valakinek elő kell ásnia. Ha csak leírom 6 mondatban, hogy mi a környezet, és tessék, kedves vendor, csinálj magadnak ilyet odahaza, és nézegessed, mikor jön elő a probléma, akkor a vendor változatos módon fogja megunni/visszapattintani a történetet (nem azért, mert nem képes megcsinálni, hanem mert _neki_ sokba kerül). Ez pláne egy opensource (nem fizetős) projektnél amúgy is irreális dolog. Ha pedig cookbookot/scriptet adok hozzá, az csak úgy megy, ha én is megcsinálom odahaza nulláról, akkor meg én melóztam vele sokat.

Ezzel csak az a baj, hogy mire leomlik, addigra a tákoló az esetek bő 90%-ban már nem ott dolgozik, de legalább elérni sem lehet. Ilyenkor jön az, hogy más fejére omlik - de ez már őt ugyebár nem zavarja. Pont emiatt tákol is - és az *ő* szemszögéből, *neki* valóban ez a legköltséghatékonyabb megoldás. Az utód és a cég szempontjából már kevésbé.

Szia,

Ebben teljesen meg tudom érteni az álláspontod.
Ha nagyon "szőrösszívű manager" fejjel gondolkodunk, ahogy Salcay kolléga fogalmazna,
akkor lehet olyan szitu, amikor egy felhasználó (cég / magánszemély most mindegy) csak "kivesz" az opensource-ból,
nem akar visszafelé csorgatni semmilyen szinten.

Mitöbb: A GPL/stb. szabad szoftveres licencek ezt is lehetővé teszik, hogy csak használd és pénzt termelj vele.
Evvel nincs is baj.

Ami az én extra .02€-m a témában:
Ha egy open source vagy akár fizetős termék "versenyezni" akar felhasználókért, akkor megkönnyítheti a hibabejelentés folyamatát.
Figyeljük csak meg a tendenciát, hogy a windowsban is bizonyos körülmények esetén egy ideje (jópár éve) felugrik az ablak, hogy "juj-juj fáj, elküldhetem-e a Microsoftnak?"
Ugyanennek akár Ubuntun is látni jóideje a saját megfelelőjét.

Sőtt, mivel én magam is úgy gondolom pl. az sng esetén, hogy adott esetben egy felhasználói jelentés,
meg infó a _valódi felhasználó_ környezetéről
segíti a fejlesztést is olyan irányba, hogy ne csak pár fejlesztő laborasztalon kitalált use-casei legyenek megvalósítva,
de figyelembe vegyenek real-life igényeket és példákat is.
Na ezért kezdtem el írni a fent emlegetett syslog-debun nevű toolt.
-end-of-blog- :)

Üdv,
Gyu

Mi akadályoz meg abban, hogy a probléma fennállása közben csinálj egy stack trace-t (arról, hogy a program épp a hangelés pillanatában hol áll), illetve esetleg kimentsd annak a memóriáját -> gdb, attach $PID, bt ; dump binary memory
Ez általában kevesebb mint 5-10 perc alatt megvan, aztán rakhatod is vissza az előző -jól működő- verziót amivel nem volt ilyen szopás. Viszont az elötte készített adatokból meg egy fejlesztő elég esélyekkel el tud kezdeni egy sima invesztigációt, hogy hol is lehet a gáz esetleg a kódban*
* Jó, tény, hogy utána még lehet kelleni fog neki 1-2 infó, ami a te drága idődet rabolja, de a végén szerintem bőven kevesebb időt fog igénybe venni, mint amennyit te belegondolsz. A végén meg talán még lenne egy működő verziód is...
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Kizártnak tartom, hogy bárki assemblyben szeretné a saját programját debuggolgatni. Egy production-ready módon fordított binárisnál kb. ennyi infó van a stack/memory dumpban. De ha valami miatt mégis szeretnék friss(ebb) syslog-ng-t, és adok neki majd egyszer esélyt, akkor meggondolom, amit javasoltál.

Nálam ez bevett gyakorlat. Nem mondom, hogy minden esetben működik, de volt már amikor pont ez segített a fejlesztőnek megtalálni egy problémát (igaz az commercial termék volt). A semminél viszont jóval több, és a félinformációk helyett tényleges adatokkal tudsz szolgálni a problémád természetéről.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Amennyiben distro package (vagy PE) kerult fel, tobb mint valoszinu, hogy debug symbolok megvannak detacholva, es egy core alapjan melle lehet tenni. Nemegy problemat oldottunk meg anno BalaBit supporton ilyen modon: user kuld coret a stripelt, optimalizalt binaristol, debug symbol melle belso repobol, es maris sokkal okosabb az ember. Nem tokeletes, es messze elmarad egy debug buildtol, de ennek ellenere sokat tud lokni az ugyon.

--
|8]

LOL!
az ilyen hozzaallasu szervizt/ceget is messze el kell kerulni.

en mar 2 olyan freebsd bug-ot fogtam, ami 10gbit halozatkezelessel kapcsolatos, halokartya driver is ennek segitsegevel lett kijavitva hozza.
igaz, par ejszakat eltoltottem vele, hogy olyan bugreportot adjak, ami minden krotulmenyt leir, es 3-4 valtozatban prezentalom a reprodukaciot.
jol esett amugy az is, hogy ennek hatasara tobb komoly rendszer uzemeltetoje vette fel velem a kapcsoaltot, s kerdezte meg, hogy tudok-e valami workaroundot? volt, akinek tudtam segiteni, volt, akinek nem.

viszont - igaz, hogy cca. 8 honap alatt-, de kijavitottak, megfixeltek a dolgot!

szoval a bizonyos szerviz embere hiaba prominens, mert egy korlatolt f.sz.

( hawk | 2016. 03. 02., sze – 12:54 )

128k meg 1Mbyte egy log message-ben ... valami tervezési hiba nem csúszott bele itt a dologba?

ui: big respect a Balabites srácoknak a kultúrált válaszokért és segítőkészségért... pedig a kérdező mindent megtett, hogy .....

"128k meg 1Mbyte egy log message-ben ... valami tervezési hiba nem csúszott bele itt a dologba?"
Te valami analfabeta vagy? Nem tudtad ertelmezni a commenteket? Csak azt lattad, hogy mennek a betuk aztan jovan irsz valamit a vegen? 1MB a test volt, meg mindig.
Atlag kis uzenetek jonnek. neha hosszabb a log es lehet 128K is(ha debugmodeba lesz kapcsolva illeto akkor lehet neha ilyen hosszu 1-1 uzenet). Igy lett tervezve elejetol. Tehat ugy lett tervezve, hogy logolas lesz. Szabad szoveges logolas (persze gzip+base64 de azon belul szabad szavas). Nem fix meretu egyen-szovegek. Ha egyszer egy szoveg hosszabb akkor hosszabb. Ez ilyen. Lehetne HTTP/HTTPS-en is postolni a logokat, stb. De ennel egyszerubb format nincs mint a syslog. Es felteteleztem, hogy mukodni fog, mert ilyen kicsi forgalom mellett, ez elvarhato lenne. De egyrezst mar megoldodott masreszt a valasz alapjan ami fentebb van, egyertelmu, hogy rosszul feleteleztem. Es syslog-ngvel kisebbre kellene allitani mindent max tobb uzenetet kuldeni es utolag osszerakni.

A stilus meg egyreszt azert is ilyen, mert egy kibaszott paraszt vagyok.
Masreszt meg azert ilyen, mert debian squeeze ota megy syslog-ngvel a szopas. Tehat barmi masra kezdtem el hasznalni, mint systemlog, vagy esetleg lvs tcpchecket raktam ra, stb akkor bedolt a gecibe. Elotte meg mukodott.
Squeeze elott a rendszerben mentek adatok syslogon olyan is ami nem csak logolas volt, hanem rendes production adat. Majd debian squeezenel elkezdtek eltunni adatok. wheezyre upgrade elott meg inkabb el volt kuldve 5x adat. Mostanra ezek szepen ki lettek irtva es http/stbre lettek cserelve.
Es alapbol nem az votl a cel, hogy minositsek barkit is munkaja miatt, csak igy alakult. Es nem totalban balabitet akartam minositeni, hanem azt aki dolgozott syslog-ng-n talan 3.3 as verziotol meg azt aki tervezte funkcionalitasat, meg aki jovahagyta ezt igy. Remelem atalakitjak bufferelest vagy adnak masra is lehetoseget a jovoben.

A syslog-ng open source project... vannak felhasznalok, akiknek ha problemajuk van,
* nyitnak egy github issue-t,
* irnak a levlistankra,
* megkeresnek bennunket gitter-en,
stb... persze lehet igy is, probaljuk mindig szakmai szempontbol megkozeliteni a problemakat.

Minden jobbito javaslatot szivesen veszunk, barki
* nyithat feature proposal-t,
* fejleszthet a syslog-ng-be,
* segithet Debian csomagolasban
* irhat blogpost-ot, hogy egy felmerult problemat mi modon sikerult megoldani, ezzel is segitve a tobbi felhasznalot
* sot, Google Summer of Code temat, valamint szakdolgozati es szakmai gyakorlati temat is lehet ajanlani

A "remelem atalakitjak a bufferelest" kapcsan pl. nyithatnal egy feature proposal-t...

Az, hogy "így lett tervezve" az ott bukik, hogy a logforrás oldal lett tervezve, a gyűjtése/tárolása viszont nem. Ha azt is megterveztétek volna, akkor nem futsz bele ilyen problémába.

Ha paraszt vagy, akkor kapa, kasza, meg az eke szarva való neked - nekik ezek a munkaeszközeik, nem pedig a számítógép. Egyébiránt meg Le style, c'est l'homme, ahogy anno Buffon mondta...

Szerintem értelmes ember már elkönyvelt téged hisztis, mocskos szájú libának (ha már az adatlapodon "nő"-t adtál meg), és bevágott hupperben troll listára. Én is ezt teszem.

-- OFF --
"Te valami analfabeta vagy? Nem tudtad ertelmezni a commenteket? Csak azt lattad, hogy mennek a betuk aztan jovan irsz valamit a vegen?"
Analfabéta, diszlexiás, figyelemzavaros, antiszociális, szociopata, skizofrén meg még kitudja mi vagyok de ez más lapra tartozik.

"A stilus meg egyreszt azert is ilyen, mert egy kibaszott paraszt vagyok."
Legalább tisztában vagy pozitív jellemvonásaiddal. Azért szerintem a földművelőket inkább hagyjuk
ki a dologból mert ők ilyenre már kaszát, kapát rántanak és ütnek.

-- ON --
Csak hogy szakmázzunk is ...
128k-s "log message" nekem már nem standard LOG. Még a Ringyóws se dobálózik ekkora logokkal....
Én a helyedben nézelődnék más alternatív megoldások után. pl: Logstash
Nem mondom azt, hogy ez a tuti és biztos bírni fogja, de egy kis olvasgatás és tanulás sose árt.

Egy elég combos példa, hogy bírja a strapát:
https://www.elastic.co/blog/using-elasticsearch-and-logstash-to-serve-b…

( Jason v | 2016. 03. 03., cs – 13:53 )

"Tehat syslog-ng elfelejtve, mert nem is igy van tervezve, hogy barmilyen fele logot tudjon logolni."

Hogy MI?!?! :D

Osszefoglalva:

Ez lett volna:
kliens -> LVS -[syslog formatolt uzenet 0-128K msg, avg(500 byte), debug modeban neha elofordulhat max 100-120K]-> [syslog-ng mint relay ssl] -> LVS -> udp aggregatorok
- Ha 1 aggregatort hagyok meg akkor annak 3 percnyi memoriaban levo uzenete 250MB. (3 perc utan vagy 500MB elerese utan irja ki.)
- Ez alatt a 3 perc alatt a 6 syslog-ng-bol darabonkent tehat az uzenetek hatoda altal lefoglalt adat meg 800MB es folymatosan nol.
- 1 szalu syslog-ng 200 message/sec nel mar 100% cpu (ssl eseten. anelkul persze joval tobb)
- aggregatorban azert itt is stimmelt kliens altal reportolt kuldott logok szama es a feldolgozottak szama
- elonye, hogy nem nekem kellett volna ssl+tcp t irni aggregatorban. (aggregator mar kesz volt masik dolog kapcsan)
- masik elonye, hogy lehetne fitlereket alapbol tobb destinationt kezelni barmilyen fejlesztes nelkul. meg elvileg erre lett kitalalva.

Ez helyett ez lett:
kliens -> LVS -> udp aggregator helyett ugye tcp+ssl
- Igy most 6 helyett 1 gep is elviszi egeszet barmennyi kapcsolattal kb(nofile 65k). 1-5% cpu es nem kell ujrainditgatni semmit, mert nem fogy el a memoria.
- aggregatorban itt is stimmelt kliens altal reportolt kuldott logok szama es a feldolgozottak szama

Tehat a syslog mint relay amire akartam hasznalni alkalmatlan, tehat erre irtam, hogy valaszokbol ugy derult ki, hogy nem arra lett tervezve, hogy barmilyen fajta logot lehessen kuldeni barmennyi sourcerol. Tehat arra van tervezve, hogy keves sourcerol keves es kicsi logot tudjon tovabbitani, mert akkor meg realis hw igenye van es a tobbseg ugyis igy hasznalja.

A leírtakból nekem egy valami nem világos:

A syslog-ng hogy jött a képbe? Ha csak arra kell, hogy fogadja a beérkező logokat aztán etesse az agregáló entitásokat, talán jobb ötlet lett volna (egy bármi más ;) ) haproxy -t esetleg nginx -et használni. Igaz így problémás az udp connection -ök kezelése (az nginx -el nem is lőnék erre), cserébe haproxy -t konfigurálni pofon egyszerű.

----
올드보이

Mar egy csomo minden ilyen modon lett megoldva belso rendszereknel, hogy fogja syslog() hivassal le lett rakva log, aztan tovabbitva lett az aggregatoroknak/feldolgozoknak/kozponti logtarolokba. De belso rendszerekben minden udpn ment es joval tobb syslog-ngre oszlott szet es igy mem fogyas nem problema/nem latszik.
Syslogot megtartva nem kellett volna hozzanyulni aggregatorhoz, csak kintre is egy syslog es ugyan olyan modon eljutottatni uzenetet.

Haproxy volt masik tipp de ugye akkoris tcpre kellett volna valtani. Nalam ugyis modositassal jart volna szoval egy +ssl meg tcp melle libeventtel +10 perc melo. Meg so_reuseportot ki akartam mar amugyis probalni elesben, hogy mennyivel gyorsabb, mint sima single accept/lock+multiaccept.

"Tehat arra van tervezve, hogy keves sourcerol keves es kicsi logot tudjon tovabbitani, mert akkor meg realis hw igenye van es a tobbseg ugyis igy hasznalja."

Ez persze hülyeség. Elég sűrün látok olyan rendszereket ahol a syslog-ng fél millió msg/sec-es tempóval dolgozza fel az adatokat, meg olyanokat is ahol több ezer source-ból jönnek az adatok. Én magam is számtalanszor mértem már ki a saját laptopomon(laptop érted...) 200k EPS tempót syslog-ng-vel, szóval még csak azt sem lehet mondani hogy valami borzasztóan bika gép alá és ehhez gyakorlatilag baromi egyszerü konfig kell.

Arról nem a syslog-ng tehet hogy valaki lusta elolvasni a dokumentációt, hogy gyakorlatilag telibe sz@rja az összes jóindulatú, segítő választ, és hogy nagy mellénnyel minősíthetetlen stílusban pocskondiáz egy terméket amiről fogalma sincs hogy hogy müködik...

És persze lehet hogy a te esetedre nem a syslog-ng való, de ez esetben meg ez kb. olyan mintha nyitnál egy topicot hogy mekkora sz@r a Ferrari mert nem tudja elvontatni az ekevasat a szántáson... Inkább nyiss egy topicot hogy ezt szeretnéd csinálni, mit ajánlotok, annak több értelme lenne..

/off/
Megjegyzem, számomra egyre inkább úgy tünik hogy neked itt egy célod van, a syslog-ng pocskondiázása, lejáratása amit akár be is fejezhetnél. És talán elgondolkodhatnál azon hogyha mindenki szembe jön az autópályán, akkor ki is megy szembe a forgalommal...

"Elég sűrün látok olyan rendszereket ahol a syslog-ng fél millió msg/sec-es tempóval dolgozza fel az adatokat"
Tehat pzolee unittest megtortent -> build|passing. Tovabbi teszteles nem szukseges. Mehet productionbe. Igy ertheto akkor.

"Megjegyzem, számomra egyre inkább úgy tünik hogy neked itt egy célod van, a syslog-ng pocskondiázása, lejáratása"
Valami valtozas elerese a cel. A lejaratast mar ~3.3 korul elkedtek a syslog-ng fejlesztok.

"És persze lehet hogy a te esetedre nem a syslog-ng való, de ez esetben meg ez kb. olyan mintha nyitnál egy topicot hogy mekkora sz@r a Ferrari mert nem tudja elvontatni az ekevasat a szántáson..."
Tehat szerinted is akkor a log relay funkcio a syslognak olyan, mint a ferrarinak a szantas. En is ugyan ezt mondom. Es ezt kene fixalni. Orulok, hogy ezt egy balabites is kimondja es belatja.

"Arról nem a syslog-ng tehet hogy valaki lusta elolvasni a dokumentációt, hogy gyakorlatilag telibe sz@rja az összes jóindulatú, segítő választ, és hogy nagy mellénnyel minősíthetetlen stílusban pocskondiáz egy terméket amiről fogalma sincs hogy hogy müködik..."
Sajna 3.3 elott meg mukodott a dokumentacio parseolasom utana eltort ugy tunik. Es utana hirtelen a linger 0-s closera torteno memleak is dokumentacio nem-olvasasa okozta. Ilyen dolog ez a dokumentacio :) Vagy ez direkt ilyen trukkos fajta doksi es tuti valahol le van benne irva, hogy a forrasban a kipontozott helyekre irjam be a free() ket. es akkor tenyleg jogos rtfm.
De tenyleg lusta vagyok amugy olvasgatni doksit, de azert anyazas elott, szoktam probalgatni es allitgatni ertekeket arra, amit javasol. De persze legtobb programnal az van, hogy default config kicsit lassabb, mint a fine-tuneolt verzio. Itt ugy tunik, hogy inkabb fejreall tole.