rsyslog filterezés [MEGOLDVA]

Fórumok

A kliensen van egy template (a lényege, hogy beteszi a LOGX stringet az üzenetbe):
$template REMOTELOG,"LOGX %hostname% %programname% %msg%\n"

-------
A szerveren a konfig:
$template TLOGX,"/var/log/%programname%.%$YEAR%.%$MONTH%.%$DAY%.log"

:msg, contains, "LOGX" ?TLOGX
& ~

$template DailyLogFile,"/var/log/messages.%$YEAR%.%$MONTH%.%$DAY%.log"
*.* ?DailyLogFile

-------
A probléma: a fenti szabály ellenére a TLOGX template által megadott log file-ba semmi nem kerül (mintha nem match-elne), ellenben a DailyLogFile nevű syslogba minden bekerül.

Próbáltam "contains" helyett regex, ".*LOGX.*" -ot megadni, de az se match-elt.

Tud valaki tippet adni?

Hozzászólások

rsyslogd -N1 mit mond? (ha van megadva verzio vagy egyeb opcio is defaultban akkor azt is ird utanna)

--
Don't Panic if you see me laughing,
that's not a bug, just a feature.

Az rsyslog.conf -ban nincs semmi, csak pár ModLoad meg a szabályok.

$ rsyslogd -N1
rsyslogd: version 5.8.10, config validation run (level 1), master config /etc/rsyslog.conf
rsyslogd: WARNING: rsyslogd is running in compatibility mode. Automatically generated config directives may interfer with your rsyslog.conf settings. We suggest upgrading your config and adding -c5 as the first rsyslogd option.
rsyslogd: Warning: backward compatibility layer added to following directive to rsyslog.conf: ModLoad immark
rsyslogd: Warning: backward compatibility layer added to following directive to rsyslog.conf: MarkMessagePeriod 1200
rsyslogd: Warning: backward compatibility layer added to following directive to rsyslog.conf: ModLoad imuxsock
rsyslogd: End of config validation run. Bye.

Ez esetben is ugyanaz a lenyeg akkor: "rsyslogd -N1 -c5" -el ha nem ad hibat akkor szintaktikailag jo.
Egyebkent nemigazan ertem miert is jo ez hogy kliens oldalon teszel bele egy szoveget amire szursz, miert van erre szukseg?
--
Don't Panic if you see me laughing,
that's not a bug, just a feature.

$ service rsyslog start
Starting system logger: rsyslogd: version 5.8.10, config validation run (level 1), master config /etc/rsyslog.conf
rsyslogd: End of config validation run. Bye.

A hozzáadott extra szöveg: sok szerverről sok alkalmazás logját kell gyűjteni. Jelenleg egy gyűjtő szerver lesz a PRO és nem PRO környezeteknek. A gyűjtött logok 'alkalmazasnev.datum.log' célfile-ba kerülnek (tehát ha 4-5 hostról is jön ugyanannak az alkalmazásnak a logja, akkor azok egy file-ba gyűlnek össze). Az alkalmazásokat ugyanúgy hívják PRO és nem PRO környezetekben, tehát ha nem akarom keverni az éles/nem éles logokat, akkor mellé kell még tennem valamit, ami megkülönbözteti őket egymástól. A hostnév mint filter nem opció, mert nem akarok minden (több száz) hostot felvenni, majd karbantartani a gyűjtő szerver rsyslog.conf -jában.

Röfögés: így 40 év után újra kellene deisgn-olni a UNIX és UNIX-like OS-eket, hogy a kőkorszaki hordalékok eltűnjenek végre. Példa: nem lehet custom syslog facility-t definiálni, abból a néhányból kell főzni, ami van.

Szintaktikailag rendben van akkor, bar ennyibol nem tudom igy hirtelen mi lehet a baja, hogy nem szuri le sajnos.

Mindenesetre tovabbra se tartom tul szerencsesnek ezt hogy kliensoldalon modositgatod a logok tartalmat hogy ezzel kulonboztesd meg. Nincsenek mondjuk tartomannyal megkulonboztetve a pro es nem pro kliensek, vagy hostnevben valami utalas amire lehetne szurni, vagy te honnan tudod a tobb szaz kozul hogy melyik milyen?
De meg ha ilyennel nem is lehet megkulonboztetni akkor is egyszerubbnek erzem hogy pro normal portra kuldi a logot, mig a masik egy eltero portra, vagy ha nincs es nem is lesz 2-nel tobb tipus akkor egyik udp masik tcp es rsyslog szerveren csak ennyit nezni hogy hol jott be a log.

A megkulonboztetesre: jobb helyeken, foleg ahol 100-nal is tobb gep van, van valami webes nyilvantarto cucc, amiben lehet keresni. Gondolom az rsyslog annyira meg nem okos, hogy ilyen API-kat tudna hasznalni a gepek megkulonboztetesere. En peldaul az elozo munkahelyemen onnan tudtam, hogy melyik gep mit csinal, hogy oda volt irva a nyilvantartoban kommentben.

A TCP/UDP megkulonboztetes azert nem jo, mert szerveroldalon lehet, hogy nem mindig lesz ott rsyslog, es nem biztos, hogy egy masik syslog szerver tud mindket fajta protokollon figyelni (foleg a custom implementaciok kuzdenek ezzel a problemaval). Ugyanez a ket kulonbozo portra is.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Jobb helyeken attol hogy van egy nyilvantartasod a gepekrol, meg egyebkent is meg vannak kulonboztetve pl hostnev, ip tartomany/vlan vagy egyebbel, mert nem csak arra van szukseg hogy te tudd melyiken mi van, hanem azok hozafereset, elereset es egyebeket is limitalni kell altalaban amit sokkal egyszerubb ha van egy logika ami alapjan csoportositani lehet es nem egyessevel kell legeneralni minden gephez es minden valtozas utan.
Amugy lehet irni pluginokat rsysloghoz, te esetedben annyi kellene kb hogy bejovo log eseten lekerdezze adatbazisbol melyik csoporthoz tartozik az a host, annyi hogy valami cache-elest erdemes lenne beletenni, hogy mondjuk csak orankent kerdezgesse ezt es ne minden egyes log eseten.
De ha nem igy gondoltad, hanem csak a logok kozt tudj keresni arra pedig siman jo lehet ugyanaz amire a graylog-ot is emlitetted, rsyslog is tud adatbazisba menteni a webes felulet meg csak egy frontend ezekhez.

A megoldás: $msg helyett $rawmsg:

if $rawmsg contains 'string' then ?TEMPLATNÉV
& ~

Mindenkinek köszi a ráfordított időt.