Na čem stavět log server?

[Mirek Prýmek]

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.

[Reklama]

[andy]

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.

[Mirek Prýmek]

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.

[Mirek Prýmek]

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)

[Dzavy]

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.

[Reklama]

[andy]

Tak jenom pro pobavení - FortiGate sice podporuje RFC3195, ale prozatím to vypadá, že "reliable" je jenom v názvu protokolu...

[Zdenek Henek nereg]

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...