rsyslog és MySQL

Linux-haladó

helló

Tudja valaki hogy hogyan lehet az rsyslog-t rávenni, hogy az új klienseket külön DB-n tárolja és minden programnak külön táblája legyen?

Azt gondotam hogy a templatek erre képesek de elolvasva a documentációt nem látom hogy ez lehetséges lenne. http://www.rsyslog.com/doc/rsyslog_conf_templates.html

Valami olyasmi kéne mint ami a fájloknál is van:
$template DailyPerHostLogs,"/var/log/syslog/%$YEAR%/%$MONTH%/%$DAY%/%HOSTNAME%/messages.log"

template(name="SQLTEMPLATEFORME" type="string" option.sql="on" string="insert into SystemEventsNEW (Message, Facility, FromHost, Priority, DeviceReportedTime, ReceivedAt, InfoUnitID, SysLogTag) values ('%msg%', %syslogfacility%, '%HOSTNAME%', %syslogpriority%, '%timereported:::date-mysql%', '%timegenerated:::date-mysql%', %iut%, '%syslogtag%')")

A SystemEventsNEW helyére menne a program név és a /usr/share/doc/rsyslog-mysql-8.2.2/createDB.sql futtatná ha nem talál DB (persze módosítva).

Igazából ha már tudna BASH script-t futtatni akkor 'job done' de azt hiszem ezt nem fogja Rainer elmondani hogy hogy is lehet ha lehet egyáltalán.

Ha nem tud DB létrehozni az sem baj, megoldom kézzel amikor hozzáadom az új klienst, de a táblák létrehozása minden egyes esetben már nagyon macerás.

Update:
nos a prózai ok hogy miért tárolom majd DB, az az hogy bárki hozzátudjon férni, könnyen. azaz írtam egy egyszerű php kódot, amit majd kicsit módosítanom kell, mert úgy néz ki hogy ez lesz a követendő DB szerkezet:
minden kliens egy külön DB
minden napnak lesz egy külön táblája

és egy cron script vagy trigger fogja karban tartani. -ez még kérdés.

  • 4291 megtekintés

( Kayapo | 2014. 07. 07., h – 18:17 )

A syslog-ng -re áttérés nem opció? Azzal ez könyedén meglenne

[update1]
A "Standard Template for write to the MySQL database" részből nekem nem kézenfekvő, hogy ezt nem lehet megetetni az rsyslog -gal: 


template(name="StdSQLformat" type="list" option.sql="on") {
        constant(value="insert into SystemEvents.%syslogtag% (Message, Facility, FromHost, Priority, DeviceReportedTime, ReceivedAt, InfoUnitID, SysLogTag)")
        constant(value=" values ('")
        property(name="msg")
        constant(value="', ")
        property(name="syslogfacility")
        constant(value=", '")
        property(name="hostname")
        constant(value="', ")
        property(name="syslogpriority")
        constant(value=", '")
        property(name="timereported" dateFormat="mysql")
        constant(value="', '")
        property(name="timegenerated" dateFormat="mysql")
        constant(value="', ")
        property(name="iut")
        constant(value=", '")
        property(name="syslogtag")
        constant(value="')")
        }

----
올드보이
http://molnaristvan.eu/

na ja, a dinamikus tábla kezelés még menne is szerintem, de hogy hozzam létre automatikusan a táblákat meg a DB ha kell?
a fő probléma hogy nem tudom hogyan lehet dinamikusra megcsinálni hogy ha jön az új kliens akkor mindenből újat hozzon létre.
--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/

mert syslog szervert szeretnék belőle konfigolni.

még abban is gondolkoztam, hogy egy DB és külön tábla minden kliensnek de ahhoz is kell SQL parancs futtatás.

bár valami olyat olvastam hogy a ^ jellel lehet külső progit meghívni. Ma kipróbálom. Ha megy akkor 'job done' mivel a DB/tábla vizsgálatot majd a külső progi hatja végre.
--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/

Áááááá így már értem.
Véleményem szerint ez nem épp a legüdvözítőbb megoldás, mivel a db szempontjából teljesen ireleváns, hogy milyen szerkezetben van tárolva a log. Azt se felejtsd el, hogy ezt majd jó lenne valahogyan elolvasni is. Igaz lehetne sql parancsokat futtatgatni, de ez messze nem kényelmes, ergó kell valami felület. Ha felület van akkor annak ezt az elég elasztikusan változó környezetet elég nehéz leképezni.

Ezek miatt én azt javaslom, hogy inkább használj egy db -t és abban egy táblát, a táblában egy egy oszlop a dátumnak és időpontlak, egy a facility, priority, tag és message paramétereknek. A többit úgy is a szűrés foglya megoldani. Ezt azért javaslom, mivel a logot szűrni fogod, hisz keresni kell benne. Gondolom nem akarsz, a több gépről befutó sok-sok ezer sor futásának látványában gyönyörködni.

Ha ez megvan érdemes keresgélni a neked tetsző felületek között és rájönni, hogy totál máshogy kellett volna az egésznek nekikezdeni (semmi pánik ez normális).

Végső soron azt javaslom, nézz szét az elasticsearch háza táján. Különösen a Kibana és a Logstash projecteket javaslom áttekintésre. Mind a kettő az elasticsearch által nyújtott kereső, indexelő rendszerre épít.

Függően a beérkező logsorok mennyiségétől javaslom, az sql helyett nosql -t hasnálni (az elasticsearch -nek a redish fexik igazán). Mindezek miatt és mert sokkal kezesebben konfolható én az rsyslog lecserélését is megfontolnám, syslog-ng -re.

Ha ezek a megoldások nem igazán tetszenek, akkor azt próbáld meg, hogy pl. Perl -ben, vagy Python -ban készítesz egy kicsi kis daemont, és annak adod tovább a logsorokat. A syslog protokol pofon egyszerű egysoros protokol. A logsort elolvasva rájön a progi, hogy ilyen hostot, programot nem látott még és megkreálja a db -t táblát.

----
올드보이
http://molnaristvan.eu/

Nem csináltam még ilyen átállást. Ha gondolod szívesen segítek, tervezésben kivitelezésben.
Volt dolgom nagy mennyiségű log kezelésével, fejlesztők segítésével. Akkor az volt a felállás, hogy van egy dev server, 2 test instance és vagy 3 tucat ami a kiszolgálásban vett részt.

Az igény kb az volt, hogy a fejlesztők (kb fél tucat) fejlesztették a saját dev architektúrájuk, ha hiba van az logot eredményez. Adott "alkalmazásban" (syslogtag) adott név alatt (domain név: joskapista.dev.csudaproject.example.net). A logsor attól függően, hogy mi az esemény jött megfelelő facility.priority alatt. Természetesen a megfelelő üzenet érkezett.

Pl.:

2012.07.21 14:32:20 joskapista.dev.csudaproject.example.net local7.error [Vizenjaras] Hatalmas hiba lepett fel a Csuda::Jezus::Vizenjaras fuggvenyben

Ezt aztán szertték volna szűrni, hogy mindenki csak a saját logsorait lássa adott esetben szűrve priority -re facility -re illetve egy szabad szavas keresés, hogy tudják azt is szűrni, amit éppen elrontanak.

Értelem szerint a rendszergazda is szeretne látni logokat, ha valamin éppen fejleszteni, cserélni szeretne, illetve, hogy egy adott dolgot jól állított-e be.

Na itt jött szóba a db -be logolás és a saját alkalmazás amivel lehet nézni a logokat, de gyorsan kiderült, hogy a saját fejlesztés sok energiát elvesz és nem is lehet mindenre gondolni. Így aztán a php-syslog-ng -t kezdtük használni (azóta LogZilla), később pedig a syslog-ng + elasticsearch + logstash szentháromságot ami aztán a Kibana -val egészült ki.

Mivel a loganalizer is hasonlóan működik, de a logstash jobb feature -öket kínál könnyű lesz az áttérés.

Első ütemben tedd mellé a loganalizernek (gondolom azért akarsz külön db -kbe logolni, hogy külön loganalizer instanceokkal tudj jogot adni, vagy nem adni felhasználóknak. A logstash -el tudsz létrehozni szűrőket, ezek külön urleket kapnak amikhez már tudsz jogot osztani), ha megy mind a kettő, lehet mutogatni a logstash -t, milyen shiny & sweet.

----
올드보이
http://molnaristvan.eu/

Részemről inkább textben (nagyobb mennyiségnél rotálva, tömörítve, archiválva külső adathordozóra) tárolnám és valami log elemző szoftverrel turkálnék benne. De ilyen feladványokkal nem volt korábban dolgom, nem tudom, mennyire életszerű ez napjainkban. (update: pl. azért, mert ha textbe megy, akkor tail -f segítségével tudom élőben követni, ami egy adatbázisba küldött log esetén nem működik, valamint lehet benne regexp-re keresni, ami RDBMS esetében nem tudom, mennyire elképzelhető)

Szóval engem is érdekelne az elfogadható megoldás.

Mondjuk (Kayapo hozzászólásán elgondolkodva) ha van hozzá valami komolyabb felület, amin a keresést meg lehet oldani, akkor _talán_ el tudom képzelni, hogy adatbázisba töltsem. Csakhát ha nincs indexelve, akkor nem sokat nyer vele az ember, ha meg indexelik, annak egy idő után elég jelentős erőforrásigénye lehet, ami kérdéses, hogy megéri-e.

Igen pl. elastichsearch eleg egyszeru clusterbe szervezni oket es igy kiszolgalni.

Vannak hozza nagyon jo frontendek graylog vagy logstash.

10-15k / sor / sec-t siman elvisz ha jol meg van csinalva.

Ezt MySQL-be is meglehet csinalni csak sokkal tobb eroforrasbb kerul. Plusz elasticba jsonbe tarolodnak a dolog igy eleg egyszer megjeleniteni is.

Itt egy leiras is:
https://bitly.com/1mFX1KA+

Mi is hasonlot csinaltunk.

--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer