Áááááá í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/