[Eisfair_dev] E1 rsyslog

Thomas Zweifel t2fel at gmx.net
Di Sep 13 16:54:17 CEST 2016


Hallo Ansgar

Am 13.09.2016 um 10:06 schrieb Ansgar Püster:
> Am 12.09.2016 um 00:25 schrieb Thomas Zweifel:
>> Sinnvoll wäre IMHO noch ein Test ob das angegebene File existiert und
>> einen Hinweis ausgibt falls nicht.
> 
> Dies dürfte aber höchsten eine Warnung sein!

Ein einfacher Hinweis reicht, so dass man es beim speichern einfach zu
sehen bekommt, dass etwas konfiguriert aber momentan nicht da ist.


> Das imfile Modul kann nämlich auch Dateien überwachen, die
> beim Start des rsyslogd noch _nicht_ vorhanden sind. Sobald
> die Datei erzeugt und gefüllt wird, wird imfile aktiv.
> Sogar ein Erzeugen/Füllen, dann Löschen und erneutes
> Erzeugen/Füllen wird unterstützt.

Das hatte ich auch in etwa so herausgeknobelt gehabt, deshalb der
Vorschlag mit dem Hinweis. ;-)


>>> Es werden eine Reihe von Templates angeboten.
>>> Man könnte auch ein User-defined Template hinzubasteln.
>>
>> Ich hab das momentan etwas an der Konfiguration vorbei in Betrieb:
>>
>> backup05 2.7.6 # ls -l *user*
>> -rw------- 1 root root  415 Sep  6 10:19 11_usertemplate.conf
>> -rw------- 1 root root   61 Sep  6 10:20 21_usertarget.conf
>>
>> backup05 2.7.6 # cat /etc/rsyslog.d/21_usertarget.conf
>> *.*       :ommysql:127.0.0.1,Syslog,User,Password;OurDBLog
>>
>> Da ich den rsyslog ca. 2008/9 mal auf dem Eis installiert hatte, mit DB
>> und Loganalyzer, habe ich zum Ausprobieren des Pakets den alten rsyslog
>> gelöscht, und den Rest einfach nur reaktiviert.
> 
> Ich mache zu einem USER_TEMPLATE mal einen Vorschlag, den
> wir dann mal diskutieren können.

Gerne.


>> Das einzige was mir beim rsyslog noch fehlt, ist eine Möglichkeit, der
>> Datenbank eine gezielte Schlankheitskur zu verpassen.
>>
>> Man definiert dazu mehrere Löschtermine:
>> z.B. 1 Tag, 30 Tage und 180 Tage
>>
>> Beim DBPURGE_KEEP_DAYS trägt man die 180 Tage ein
>> aktiviert DBPURGE_EXPERT=yes (oder so) und erstellt die weiteren Termine
>> samt Regelwerk.
>>
>> Für die einzelnen Löscheinträge sollte man jeweils aus Facility,
>> Severity, Syslogtag und msg seine Regeln Zusammenstellen können.
>> (so ähnlich wie beim Global Discard Filter)
>>
>> Das bewirkt einerseits, das die DB nicht unnötig gross und (vor allem)
>> träge wird, andererseits können interessante Sachen über einen längeren
>> Zeitraum verfügbar bleiben.
>>
>> Auch hier gilt dasselbe wie bei den Templates:
>> Es wäre Toll, wenn man es mit der CUI Konfiguration erledigen könnte,
>> notfalls lässt sich auch was selbst gebasteltes nutzen. (Das Paket ist
>> diesbezüglich ja sehr flexibel gestaltet. :-) )
> 
> Ob man das wirklich in die rsyslogd Konfiguration einbauen
> sollte? Das RSYSLOGD_DBPURGE war bisher als "Einfachlösung"
> gedacht. Ein umfangreicheres Housekeeping einer Datenbank
> incl. Sicherung/Auslagern etc. etc. sollte m.E. separat
> erstellt und konfiguriert werden.
> 
> Ich "hirne" noch mal.

Ein Umfangreiches "Housekeeping" muss es IMHO gar nicht sein, lediglich
die Möglichkeit bieten, z.B.:
alles mit Severity debug nach kurzer Zeit wieder loszuwerden....
Sachen mit 'foo' im Messagetest fallen dann ein paar Wochen später raus....
....

Meine Logfiles auf dem zentralen Loghost umfassen etwa 5GiB
(grösstenteils komprimiert), die LogDB ist dagegen mit rund 400MiB
(inkl. index) vergleichsweise schlank und die Abfragezeiten
dementsprechend kurz.

In Zusammenhang mit dem Loganalyzer hat sich das als sehr brauchbare
Lösung (für mich) erwiesen.



Gruss Thomas


Mehr Informationen über die Mailingliste Eisfair_dev