[Eisfair_dev] E1 rsyslog

[Thomas Zweifel]

Hallo Ansgar

Am 11.09.2016 um 14:06 schrieb Ansgar Püster:
> Am 10.09.2016 um 19:40 schrieb Thomas Zweifel:
>> Da wäre noch ein Check fällig der das abfängt und eine Meldung beim
>> Speichern ausspuckt:
>>
> Warnung:
> "No active file input definition - RSYSLOGD_FILE_INPUT='yes'
> will be ignored"
> 
> Kommt mit der nächsten Version!

Sinnvoll wäre IMHO noch ein Test ob das angegebene File existiert und
einen Hinweis ausgibt falls nicht.

Beim Umzug von Diensten geht gerne mal vergessen wo man noch zusätzliche
Einträge hinterlassen hat. ;-)



>> Das probehalber verfütterte squid access.log hat er akzeptiert und
>> munter die Datenbank befüllt (und das messages zugegemüllt) :-)
>
> Du kannst auch SQUID_LOG_ACCESS='syslog' setzen, dann werden
> die Meldungen als user.info direkt an Syslog übergeben.
> Start/Stop des Squid wird als local4.notice übergeben.

Das war nur mal zum Testen genommen, da man ja quasi selbst bestimmen
kann, wann und wieviel geloggt wird - einfach Ideal.



>> Ein kleiner Wunsch hätt ich da noch:
>>
>> Wäre es möglich, beim Template zwischen 'syslogtag' und 'programname' zu
>> wählen?
>>
>>  %iut%, '%syslogtag%', '%procid:
>> Today 18:30:22 NEWS INFO backup05 fetchnews[17983]: 17983 Syslog ...
>>
>>  %iut%,'%programname%', '%procid:
>> Today 16:41:47 NEWS INFO backup05 fetchnews 13849 Syslog ...
>>
>>
>> Das ermöglicht einem gezielt nach z.B. smartd zu filtern - was mit der
>> angehängten pid nur eingeschränkt Resultate liefert. :-(
> 
> Verstehe ich so adhoc nicht.
> Bei welchem Template soll diese Wahl möglich sein?
> In welchem Kontext (imfile)?

Sorry, das war wohl etwas zu kurz ausgefallen. :-(

Gemeint ist das Template für die mariadb.

Nachdem ich mir das nochmals durch den Kopf hab gehen lassen, finde ich,
dass man es gar nicht konfigurierbar machen muss.
Die PID (sofern vorhanden) steht im Loganalyzer ohnehin im nächsten Feld
zum Filtern zur Verfügung.

Ich meine deshalb, das man im DB-Template das '%syslogtag%' einfach
durch den '%programname%' ersetzen sollte.



> 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.


Auch wenn man es recht einfach am "CUI" vorbei realisieren kann, wäre
ein Benutzerdefiniertes Template durchaus eine nette Sache. ;-)



Die Datenbank löschen und (neu) erstellen werde ich demnächst noch
ausprobieren.



>> Falls mir noch was auffällt melde ich mich wieder. ;-)
> Gerne.

Zum Thema mit den fehlenden MARK Meldungen:
Das Problem sass definitiv *vor* dem Bildschirm, mit Riesentomaten auf
den Augen!  ;-)




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. :-) )




Gruss Thomas