Fórum Root.cz
Hlavní témata => Server => Téma založeno: Franta Fň 15. 12. 2015, 16:50:23
-
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.
-
rsyslog?
-
Michal Strnad - Centrální logování (SUT SH)
https://www.youtube.com/watch?v=MqaZHSVgxK4
-
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.
-
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í...
-
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 :-/
-
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.
-
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í.
-
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.
-
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.
-
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).
-
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.
-
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...
-
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
-
... 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 ;)
-
teď momentálně implementuju RFC3080.
Jako pro logování? Proč?
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 ;)
Ono to je něco jinýho než o čem jsem mluvil. Když máš systém, který doručení opravdu garantuje, tak v nejhorším myslitelném případě ten server fakt skončí swapováním, protože nic jinýho mu nezbude. A to se u rsyslogu prostě nestane, protože prostě jeho primární účel není stoprocentně reliabilní doručení. To byla ta pointa, okolo které tady už několik příspěvků kroužíme :)
Takže ten default změněný nemám, nejspíš proto, že jsem se s tímhle problémem nikdy nepotkal, protože 1. na přerušení logovací trasy mám aktivní checky, takže není úplně reálný, že by byla trasa přerušená třeba týden bez povšimnutí, 2. pokud to jde (a ono to nějak jde vždycky), snažím se aplikace umravnit tak, aby při normálních podmínkách logovaly normální množství zpráv. Ta situace, která mi leží v žaludku, není normální provoz, ale situace, kdy ti třeba padne konektivita, nějaký soft se zblázní, začne zběsile logovat, syslog by to všechno ochotně absorboval, garantovaně ukládal a tím spustil dominový efekt, při kterém by úplně zbytečně popadaly další služby. Tohohle jsem se chtěl vyvarovat - a rsyslog to v defaultním nastavení splňuje perfektně - jeho vývojáři prostě mají zkušenosti, nejsou to žádní hipsteři a nastavili dobře sane defaults.
-
Jako pro logování? Proč?
Protože RFC3195 a jisté celkem populární firewallové krabičky to umí a zákazník to bude chtít. Bohužel to pochází z doby, kdy si lidi mysleli, že XML je cool a protokoly oplývající maximálním kvantem vlastností jsou cool....
A to se u rsyslogu prostě nestane, protože prostě jeho primární účel není stoprocentně reliabilní doručení. To byla ta pointa, okolo které tady už několik příspěvků kroužíme
Začne to throttlovat a pokud máš třeba nginx nastavený, aby logoval do syslogu, tak bude dodávat 1 request/2 vteřiny. http://lists.adiscon.net/pipermail/rsyslog/2012-November/031107.html
(teda pokud to nemají v nějaké nové verzi líp vyřešené, možná ten discarding byl aspoň částečná reakce na tyhle problémy) Možná to nastane jen v nějaké shodě náhod, ale hooodně blbě se dohledává, v čem je problém.
-
a pokud máš třeba nginx nastavený, aby logoval do syslogu
Což právě nemám, protože access log Nginxu nesplňuje tu podmínku:
aby při normálních podmínkách logovaly normální množství zpráv.
-
Mimochodem, ten odkazovaný mail obsahuje výborně popsaný ten problém, kterému se právě snažím vyhnout:
and also meant that if the disk filled
up you would not be able to login to fix it (since login or su would try and
create a log message, which could not be written to disk, so the login or su
would never complete)
-
Zkusenost s TCP syslogem muzu potvrdit, taky nam mrtvej syslog server zpusobil vypadek/extra divny chovani aplikacniho serveru. Mozna to jde nejak poladit, nevim, ale od ty doby jsme na UDP.
-
Tak jenom pro pobavení - FortiGate sice podporuje RFC3195, ale prozatím to vypadá, že "reliable" je jenom v názvu protokolu...
-
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.
Ahoj,
zalezi co chces s logama delat a kolik jich mas.
Pouzivame logstash,elasticsearch a kibana. Operations zacali pouzivat elasticsearch jako hlavni databazi na temer veskera data, ktera se jim dostanou pod ruku :).
V soucasne dobe mame dva servery kazyd quad core Xeon s 32gb ram. Na jednom jede logstash process a elasticsearch node a na druhym je redis a elasticsearch node. Logy tady drzime 3 mesice pak jsou k dispozici uz jen na disku bez uprav provedenych v logstash processu.
Pry mame v elasticsearch clusteru par set gb logu blizko 1TB.
Toto nemusi byt idealni reseni, pokud potrebujes opravdu jen archivovat logy. Ja povazuji za neocenitelnou pomoc, ze logstash muze zpracovat log zpravu a rozsekat ji na polozky, ktere pak v kibana/elasticsearch muzu pekne filtrovat.
Grep je super, ale vse ma najednou uplne jiny rozmer, kdyz tech serveru je vic:). Mame u kazdeho requestu definovane request id, takze si muzu filtrovat logy, ktere vyprodukuje jen ten jeden request, kazdy zakaznik v nasi aplikaci ma sve oznaceni, takze muzu filtrovat jen logy, ktere vyprodukoval ten jeden zakaznik atd...