Na čem stavět log server?

[Franta Fň]

Ahoj, potřebuji postavit centrální logovací úložitě máte někdo rady na jakém programu to postavit?
Potřebuji to provozovat na Centos 6.5.
Syslog-ng 3.2.5 jsem si vyzkoušel, ale je to peklo ... pořád nějký bug...teď jsem skončil na tom, že mi nechce vytvářet složky dle datumu a sypat to tam.

[Reklama]

[losdebilos]

rsyslog?

[karel]

Michal Strnad - Centrální logování (SUT SH)

https://www.youtube.com/watch?v=MqaZHSVgxK4

[Lol Phirae]

Abych ti pravdu rekl, tak je to vsechno uplne na hovno. Jestli se ti jedna o archivaci, tak si proste kopiruj zrotovane soubory s logama.

[andy]

Kibana + ElasticSearch + něco jiného než logstash.

Logstash je na houby a většina podobných nástrojů taky. Skončil jsem tak, že si píšu vlastní, ale bude to komerční...

[Reklama]

[Franta Fň]

Asi testnu ještě rsyslog, nevíte náhodou jaké to má limity?
Domnívám se, že denní úhrn logů by mohl přesáhnout i na 500GB.

karel-> díky za odkaz, je to poučné

andy-> přesně to jsem slyšet nechtěl :-/

[Dzavy]

My pouzivame v produkci rsyslog -> Splunk. S rsyslogem v podstate zadnej problem (verze co je v RHEL), Splunk je bezkonkurencni (akorat placenej), da se pouzit i jako agent/forwarder a cely logovani resit jenom s nim.

[Mirek Prýmek]

Jedna věc je přenos logů, druhá věc je nějaká jejich analýza a třetí je zobrazování výsledků analýzy. Na tu první věc bych doporučil rsyslog+TCP transport+framing: http://www.freebsd.cz/listserv/archive/users-l/2015q4/029164.html

Řešení druhé a třetí věci záleží na požadavcích a na tom, jak moc jsi hipster a jak moc chceš spravovat logování místo správy serverů. Možný je všechno, co tady zaznělo - Logstash, Elasticsearch, Kibana, Splunk... ...a ještě asi miliarda jiných možností.

[andy]

4. rozumna spolehlivost - nespravuju systemy, kde by kvuli ztracenemu
zaznamu nekdo umrel, ale nastvalo by me, kdyby server neposkytoval
sluzby jenom kvuli tomu, ze se logovaci system zblaznil, protoze se mu
nedari dorucit logy

Na tu první věc bych doporučil rsyslog

Heh... já vím, že to je asi standardním nastavením, ale zrovna asi před měsícem se jednomu zákazníkovi zbláznil server (doslova), protože měl v rsyslogu nakonfigurované 2 TCP logovací servery a jeden byl vypnutý.... volání "syslog" (např. v logger) trvalo asi 2 vteřiny, no a běžel (no..nakonec spíš couval) na tom nějaký systémový soft, který docela rád logoval.... chvilku trvalo, než jsme přišli na to, co tomu je.

[Mirek Prýmek]

Heh... já vím, že to je asi standardním nastavením, ale zrovna asi před měsícem se jednomu zákazníkovi zbláznil server (doslova), protože měl v rsyslogu nakonfigurované 2 TCP logovací servery a jeden byl vypnutý.... volání "syslog" (např. v logger) trvalo asi 2 vteřiny, no a běžel (no..nakonec spíš couval) na tom nějaký systémový soft, který docela rád logoval.... chvilku trvalo, než jsme přišli na to, co tomu je.

Uplne nerozumim tomu, v cem byl problem, ale jestli rsyslog nebezel, tak to asi nebyl jeho problem - spis te odesilaci strany

V tom, co citujes, jsem chtel rict to, ze systemy, ktere _garantuji_ doruceni, se obcas muzou snazit dorucut i za cenu ohrozeni serveru. V rsyslogu se daji nastavit vsechny potrebne veci - delka fronty, rate limiting atd. - tj. rsyslog je ochotny zpravy za nejakych podminek _zahodit_, nezarucuje doruceni za jakekoliv situace, coz mne vyhovuje.

[gamer]

Apache Kafka: http://kafka.apache.org/

Je to ale poměrně nová věc a umí to víc věcí, než požaduješ (což může být i výhoda).

[Mirek Prýmek]

Apache Kafka: http://kafka.apache.org/

Je to ale poměrně nová věc a umí to víc věcí, než požaduješ (což může být i výhoda).

PUBSUB systémů je bambilion. Když už nějaký použít, přimlouval bych se spíš za MQTT.

[andy]

Uplne nerozumim tomu, v cem byl problem, ale jestli rsyslog nebezel, tak to asi nebyl jeho problem - spis te odesilaci strany

V tom, co citujes, jsem chtel rict to, ze systemy, ktere _garantuji_ doruceni, se obcas muzou snazit dorucut i za cenu ohrozeni serveru. V rsyslogu se daji nastavit vsechny potrebne veci - delka fronty, rate limiting atd. - tj. rsyslog je ochotny zpravy za nejakych podminek _zahodit_, nezarucuje doruceni za jakekoliv situace, coz mne vyhovuje.

Nene, problém byl v tom, že default nastavení rsyslogu je nezahazovat, takže když se ti vypne přijímací server, tak po určitém kvantu logů začne operace "syslog" trvat hodně dlouho...

[Mirek Prýmek]

Nene, problém byl v tom, že default nastavení rsyslogu je nezahazovat, takže když se ti vypne přijímací server, tak po určitém kvantu logů začne operace "syslog" trvat hodně dlouho...

To není přesný. Tcp transport není by design reliabilní[1], všechny fronty mají by default limit na velikost [2], zpomalení zasílání zpráv je feature, ne bug [3], z principu je možné jenom pro některé inputy a není pravda, že by byl rsyslog by default reliabilní. Jenom se o to rozumnými prostředky snaží, ale ne za každou cenu [4].

Takže jo, máš pravdu, k téhle situaci může dojít, ale není to vlivem toho, že by narostly fronty, stroj začal swapovat apod.

[1] http://blog.gerhards.net/2008/04/on-unreliability-of-plain-tcp-syslog.html
[2] All queues, including disk queues, have a limit of the number of elements they can enqueue. http://www.rsyslog.com/doc/v8-stable/concepts/queues.html#limiting-the-queue-size
[3] http://www.rsyslog.com/doc/v8-stable/concepts/queues.html#filled-up-queues
[4] During throtteling, a disk-assisted queue continues to write to disk and messages are also discarded based on severity http://www.rsyslog.com/doc/v8-stable/concepts/queues.html

[andy]

... já tohle všechno vím - jednak jsem si tu dokumentaci po odhalení problémů přečet, druhak mimo jiné proto, že teď momentálně implementuju RFC3080. Ale faktem je, že pokud rsyslog v default konfiguraci namíříš na mrtvý TCP server, tak po určitém kvantu logů začne pěkný 2vteřinový throttling na syslog - a pokud tvoje aplikace loguje přes syslog (nebo něco, co se chová podobně), tak je to docela problém. Otázka tedy zní, jestli ten default máš na svých serverech změněný, když Ti jde o to, aby ti nefunkční log server nesundal produkci