Přístup k logům mailserveru

Přístup k logům mailserveru
« kdy: 22. 03. 2022, 11:39:08 »
Ahoj,

z duvodu kompletni prestavby naseho mailoveho reseni potrebuji vyresit pristup logum mailserverum, aby z nich mohla nase aplikace tahat data. Jde zejmena o maximalni spolehlivost.

Momentalni nastaveni je takove, ze na mailserveru bezi skripty, ktere parsuji logy a predavaji to zpracovatelskemu serveru. Na ten zpracovatelsky server jsou pak navazany nase dalsi aplikace. Tech mailovych serveru bude mnohem vice, takze overuji cestu, zda to parsovani logu nepresunout z mailserveru primo na zpracovatelsky. Otazkou je, ale jak zajistit spolehlivy pristup. Logy postfixu jsou navic nepristupne beznemu uzivateli

Varianty co me napadaji (styl veskery obsah logu, at si to pak prefiltruji vyvojari):
a] ssh omezeny na "cat mail.log" - pull
b] neco ve stylu filebeat apod.  - push

Mala komplikace je, ze napr. filebeat jiz pouzivam pro graylog. A graylog tu mame v rezimu - kdyz to bezi, fajn, kdyz ne, nic se nedeje. Takze napojeni zpracovatelskeho systemu na graylog neni vhodne a filebeat tedy nevyuziju.

Jeste me napadlo logovani primo do db z postfixu, ale to jsem nikdy nezkousel. Jde o to, aby i ten redeployment serveru byl jednodussi nez doted (kontejnery nevedeme).

Diky za napady.
« Poslední změna: 22. 03. 2022, 12:49:58 od Petr Krčmář »


M Z

Re:Pristup k logum mailserveru
« Odpověď #1 kdy: 22. 03. 2022, 12:52:35 »
Ahoj,
mate nejaky duvod proc nepouzit standardni syslog? Napr. rsyslog umi lokalni frontu na klientu v pripade vypadku site/serveru a pres protokol REPL by melo byt zaruceno 100% doruceni logu na server.
Michal

Re:Pristup k logum mailserveru
« Odpověď #2 kdy: 22. 03. 2022, 13:33:18 »
Ahoj,
mate nejaky duvod proc nepouzit standardni syslog? Napr. rsyslog umi lokalni frontu na klientu v pripade vypadku site/serveru a pres protokol REPL by melo byt zaruceno 100% doruceni logu na server.
Michal

Přimlouvám se za rsyslog. A zlomit ho na logování přímo do DB je otázka chvilky.

Re:Pristup k logum mailserveru
« Odpověď #3 kdy: 22. 03. 2022, 13:58:34 »
Ahoj,
mate nejaky duvod proc nepouzit standardni syslog? Napr. rsyslog umi lokalni frontu na klientu v pripade vypadku site/serveru a pres protokol REPL by melo byt zaruceno 100% doruceni logu na server.
Michal

Přimlouvám se za rsyslog. A zlomit ho na logování přímo do DB je otázka chvilky.

Rsyslog me nenapadl, pro kriticke veci ho nepouzivame. Zatim bych preferoval cestu specifickych nastroju, ale zaradim to do moznosti.

M Z

Re:Přístup k logům mailserveru
« Odpověď #4 kdy: 22. 03. 2022, 19:51:23 »
To je zajimavy, kdybych neco takoveho resil mel bych to presne obracene. Na kriticke veci bych nasadil rsyslog a nejake blbosti v testu bych slepil z ssh, awk atd. :D


Re:Přístup k logům mailserveru
« Odpověď #5 kdy: 23. 03. 2022, 09:08:19 »

Re:Přístup k logům mailserveru
« Odpověď #6 kdy: 23. 03. 2022, 10:55:51 »
nxlog má funkci reliable delivery při přerušení tcp spojení až v placené verzi, to je povětšinou dost zásadní funkce a nechceš ztrácet logy při restartech servové části.

Proč chceš používat tyhle obskurní nástroje (ano, nxlog je prostě takový běžný enterprise SW, u nás ho třeba máme v rajfce) místo poměrně etablovaného a stabilního řešení v podobě rsyslogu? Stejně tak se tady nabízí ještě syslog-ng.

Ty moderní nástroje mají často problém se spolehlivostí, neumí se snadno vypořádat s pády, restarty, rotováním souborů a jinými neduhami.

U postfixu se mi dlouhé roky osvědčuje používat syslog logování, dávat to do rsyslog relay s lokální cache a rovnou posílat na rsyslog server, z kterého se to poté již může distribuovat do různých grafických udělátek. Při výpadku konektivity se logy pošlou dodatečně, mohu jednoduše alertovat, když logy přestanou chodit, mám to jednotné s ostatními nástroji a infrastrukturou.

Z těch placených je poměrně solidní Splunk, umí se totiž asi nejlépe vypořádávat s rotováním souborů, jejich truncování po rotování, s přejmenováním a jinými operacemi, když už teda pustíš aplikaci, aby si mohla sama spravovat logy a sama do nich zapisovat.

Re:Přístup k logům mailserveru
« Odpověď #7 kdy: 23. 03. 2022, 12:42:40 »
nxlog má funkci reliable delivery při přerušení tcp spojení až v placené verzi, to je povětšinou dost zásadní funkce a nechceš ztrácet logy při restartech servové části.

Proč chceš používat tyhle obskurní nástroje (ano, nxlog je prostě takový běžný enterprise SW, u nás ho třeba máme v rajfce) místo poměrně etablovaného a stabilního řešení v podobě rsyslogu? Stejně tak se tady nabízí ještě syslog-ng.

Ty moderní nástroje mají často problém se spolehlivostí, neumí se snadno vypořádat s pády, restarty, rotováním souborů a jinými neduhami.

U postfixu se mi dlouhé roky osvědčuje používat syslog logování, dávat to do rsyslog relay s lokální cache a rovnou posílat na rsyslog server, z kterého se to poté již může distribuovat do různých grafických udělátek. Při výpadku konektivity se logy pošlou dodatečně, mohu jednoduše alertovat, když logy přestanou chodit, mám to jednotné s ostatními nástroji a infrastrukturou.

Z těch placených je poměrně solidní Splunk, umí se totiž asi nejlépe vypořádávat s rotováním souborů, jejich truncování po rotování, s přejmenováním a jinými operacemi, když už teda pustíš aplikaci, aby si mohla sama spravovat logy a sama do nich zapisovat.

Diky za zhodnoceni.
Ja pouzivam filebeat pro graylog, ktery s rotacemi logu a vypadky spojeni problem nema, tak jsem necekal u nxlogu, ze by to bylo v zakladni verzi problem. Ale protoze se mi automaticky konfiguruje z graylogu, tak ho jiz vyuzit nemuzu.

Duvodu, proc nepouzivam rsyslog na tyhle veci (pokud to z principu jinak nejde, napr. switche) je tento:
1] vice a vice se prechazi na journald
2] standarizace konfigurace/zabezpeceni/nahraditelnost aplikace nasaditelna defacto vsude, nez se prat s tim, jak to rsyslogem nekam poslat
3] nesnasim regexpy, je to neintuitivni, casovy zrout

Re:Přístup k logům mailserveru
« Odpověď #8 kdy: 23. 03. 2022, 13:13:57 »
rsyslogd má modul imjournal, který umí číst journald logy a ty případně poslat beztrátově někam ven, tak to i používám. Journald je spíše nástroj na čtení a pohled na logy než jejich dlouhodobé ukládání.

Filebeat se právě s rotováním nevypořádává dobře, viz https://www.elastic.co/guide/en/beats/filebeat/current/file-log-rotation.html, podporuje rotování, která třeba dělá logrorate, kdy se soubor přejmenuje a vytvoří místo něho nový, už ale nepodporuje truncatování souboru, gzipování atd. On to není špatný SW, ale od něčeho, co je pro mě kritické nečekám, že se bude aktualizovat několikrát do roka o nové funkce a rozbíjet ty staré, takže to chce pozorně testovat kažou novou verzi. Těch případů, kdy se data.json při aktualizaci promazal a poslalo to vše znovu nebo po pár dnech přestal logovat jsem už zažil až příliš.

rsyslogd používám tak 15 let, konfiguraci je přenosná, vše se chová stejně a stabilně, nejsou problémy s aktualizacemi a dostupnost je na všech platformách, nevadí tomu být případně spuštění někde v dockeru či standalone.

Na druhou stranu konfiguraci rsyslogd má plnou komentářů, protože do toho šahám tak málo, že si to nepamatuji, naopak tu u filebeat umím zapsat asi zpaměti, protože do toho šaháme pořád, pořád je potřeba něco luštit z dokumentace a debugovat.

Když už máš rád tyhle nové věci, možná ještě mrkni na fluentbit, je to tenké, konfigurace je čitelná, je možné jí různě řetězit, dobře testovat přes sample inputy, má to exporty metrik v prometheu formátu a umíš konfiguraci přímo přikompilovat do kódu, takže můžeš mít jednu distribuční binárku, kterou stačí spustit a obsahuje vše.


Re:Přístup k logům mailserveru
« Odpověď #9 kdy: 23. 03. 2022, 18:54:12 »
Jednoznačne sa prikláňam k rsyslog / syslog-ng . Sú to veľmi spoľahlivé aplikácie, nemajú divné stavy - raz sa nakonfigurujú a už sa na ne nemusí nikdy siahať. Konfigurácia napríklad oproti filebeatu je až primitívne jednoduchá a jasná.

Syslog-ng mám produkčne vyskúšaný aj v roli central log servera a absolútna spokojnosť.

Re:Přístup k logům mailserveru
« Odpověď #10 kdy: 24. 03. 2022, 09:22:14 »
No holt to budu muset odzkouset, zda se.
Prave ze u tech non-rsyslog nastroju mi vyhovuje, ze to jde napojit primo na cteni souboru (kdyz zatim existuji), takze rekonfigurace/restarty techto sluzeb se umi "vratit na posledni bod". Reseni s rsyslogd tohle ale "zpetne" nedela...

Ono jde i o vykon, na tom starem serveru jedeme i 20 tisic mailu za hodinu, tady ocekavame zrychleni zprocesovani...

Re:Přístup k logům mailserveru
« Odpověď #11 kdy: 24. 03. 2022, 09:39:16 »
ten pattern se dělá ale jiný, logy posíláš na syslog daemona (buď socket nebo localhost udp, postfix podporuje), tím daemonem je rsyslogd a ten vytváří soubor, posílá data jinám a routuje to. Hlavní důvod je, že prostě nechceš nechat plný přístup na logy pro aplikaci, v případě průniku by totiž útočník mohl logy promazat, chyba v aplikaci smaže logy atd., to jsou vše rizika a lepší je se jim vyhnout.

Pokud chceš číst soubor, rsyslogd má modul imfile a ten umí pokračovat ve čtení po restartu, viz dokumentace https://www.rsyslog.com/doc/v8-stable/configuration/modules/imfile.html a věta "When rsyslogd is stopped while monitoring a text file, it records the last processed location and continues to work from there upon restart"

20 tis emailů za hodinu není velké číslo, rsyslogem na na produkcích teče tohle množství každou vteřinu. Asi všechny tyhle nástroje zvládnou 20 tis / hod bez komplikací.

Re:Přístup k logům mailserveru
« Odpověď #12 kdy: 24. 03. 2022, 09:50:06 »
Syslog-ng mám produkčne vyskúšaný aj v roli central log servera a absolútna spokojnosť.

U nas tiez pouzivame syslog-ng ako centralny log server. Syslog-ng sype logy do Kafka clusteru a cunsumery si uz z Kafiek sosaju data podla potreby. Krasne, blbu vzdorne, vypadku vzdorne riesenie, ktore nam nie raz zachranilo zadeke.

syslog-ng sme uprednostnili pred rsyslog koli lepsiemu a citatelnejsiemu konfigu, lepsej dokumentacii a tak isto koli lepsej moznosti pre-processingu a integracii s Kafka na syslog-ng serveroch.

Re:Přístup k logům mailserveru
« Odpověď #13 kdy: 24. 03. 2022, 12:10:27 »
No tak my tu nemame ani kafku, s elastikem experimentujeme teprve takze...nam zbyva jen prenos textovych logu nebo to sypat rovnou do db.

20t/hod je vykonovy limit soucasneho serveru, kdyz dojde k jeho zahlceni (cca 7k per postfix instance, je jich tam vic), realne posilame objemy i nad sto tisic. To vlastne si jeste musime rict, zda to budeme prenaset davkove ci realtime...

Nemluve o pripadne zatezi "ciloveho" log serveru.

Re:Přístup k logům mailserveru
« Odpověď #14 kdy: 24. 03. 2022, 20:31:18 »
Skus pozret Vector od datadog https://vector.dev/ je to dost lightweight, vie to transformaciu a posiela to na rozne outputy (aj na viacere naraz)