Ansible-Rolle: Rsyslog

Installiert und konfiguriert rsyslog auf Debian/Ubuntu-Servern.

Diese Rolle installiert und konfiguriert die neueste Version von rsyslog aus dem offiziellen APT-Repository (auf Debian) oder offiziellen PPA (auf Ubuntu). Standardmäßig übernimmt sie den Inhalt der Dateien /etc/rsyslog.conf und /etc/rsyslog.d/50-default.conf.

Anforderungen

Keine.

Rollenvariablen

Hier sind die verfügbaren Variablen mit ihren Standardwerten (wie in defaults/main.yml):

rsyslog_rules: []

Ein Array von Regeln für rsyslog. Jeder Eintrag erstellt eine separate Konfigurationsdatei, die $priority-$rule_name.conf genannt wird. Stellen Sie sicher, dass Sie defaults/main.yml auf kommentierte Beispiele mit allen verfügbaren Optionen überprüfen.

rsyslog_rules:
  - rule_name: "remote-udp"
    priority: 99
    ruleset: |
      module(load="omfwd")
      action(type="omfwd" target="central.server.local" port="514" protocol="udp")
    state: "present"

Hier ist ein Beispiel für einen vollständig ausgefüllten rsyslog_rules-Eintrag. Beachten Sie das | für die Blockdeklaration für das ruleset. Ab dort handelt es sich um die reine rsyslog-Konfigurationssyntax.

Alternativ zur Definition der rsyslog_rules auf regellierter Weise kann die rsyslog_extra_conf_options verwendet werden. Sie erweitert die Hauptkonfigurationsdatei /etc/rsyslog.conf mit zusätzlichen Optionen, anstatt neue Dateien in /etc/rsyslog.d zu erstellen.

rsyslog_extra_conf_options: |
  module(load="imudp")
  input(type="imudp" port="514")

Hier wird ebenfalls | für die Blockdeklaration verwendet, und der Code selbst ist eine reine rsyslog-Konfigurationssyntax. Es kann auch mit rsyslog_remove_default_rules: true kombiniert werden, was sicherstellt, dass /etc/rsyslog.d/ leer ist.

Zusätzlich gibt es derzeit drei vorkonfigurierte rsyslog-Regeln. Alle haben spezielle, dedizierte Vorlagen (templates/*.conf.j2). Nur eine von ihnen ist standardmäßig aktiviert und heißt einfach default. Sie übernimmt die Definition der Datei /etc/rsyslog.d/50-default.conf. Sie kann leicht deaktiviert werden, indem state: "absent" angegeben wird.

rsyslog_rule_default:
  rule_name: "default"
  priority: 50
  template: "default.conf.j2"

Die zweite ist docker, die Protokolle für die Docker-Container auf dem jeweiligen Host verarbeitet. Sie wird in der Datei /etc/rsyslog.d/20-docker.conf definiert.

rsyslog_rule_docker:
  rule_name: "docker"
  priority: 20
  template: "docker.conf.j2"
rsyslog_rule_docker_tag_all: true

Es wird /var/log/docker erstellt und Protokolldateien dort mit dem Namensschema $CONTAINER_NAME.log platziert. Es wird erwartet, dass der $syslogtag docker/ im Namen hat (siehe das Beispiel unten), andernfalls werden alle Protokolle in /var/log/docker/no_tag.log gespeichert. Zudem gibt es eine rsyslog_rule_docker_tag_all, die eingeschaltet werden kann, wenn mehr als ein Container auf dem Host läuft und es ermöglicht, eine Datei mit Protokollen aus allen von ihnen in /var/log/docker/all.log zu aggregieren (Hinweis: Dies verdoppelt den benötigten Speicherplatz für die Containerprotokolle). Sie können meine Rolle hadret.containers für ein Beispiel zur Containerdefinition mit aktivierter Syslog-Unterstützung überprüfen.

containers:
  - name: cadvisor
    image: "google/cadvisor:latest"
    state: started
    log_driver: journald
    log_options:
      tag: docker/cadvisor

journald wird heutzutage automatisch von rsyslog verwendet.

Zu guter Letzt ist da noch das Handling von remote. Ich wollte eine schlüsselfertige Lösung für die Bearbeitung sowohl der Client- als auch der Serverseite erstellen. Remote-Logging ist derzeit sehr rudimentär und grundlegend, funktioniert aber sofort mit einer minimalen Konfiguration.

rsyslog_rule_remote:
  rule_name: "remote"
  role: server
  priority: 99
  template: "remote.conf.j2"
  ruleset_name: "remote"

Mindestens ein Remote-Protokoll (relp/tcp/udp) muss angegeben werden (Hinweis: Es gibt keinen Standard und die Angabe von rsyslog_rule_remote allein wird fehlschlagen). Die serverseitige Handhabung erfordert eine definierte ruleset_name, da es ruleset ist, das die tatsächliche Aktion des Schreibens der Protokolle ausführt (über omfile) und vordefinierte Vorlagen anwendet. Diese sind so konfiguriert, dass sie den "gewöhnlichen" Regeln so ähnlich wie möglich sind, mit den folgenden vordefinierten Ausgaben: auth.log, syslog.log, rsyslog.log, kern.log und mail.log.

rsyslog_rule_remote_relp:
  port: 514

Derzeit unterstützt nur relp die TLS-Konfiguration.

rsyslog_rule_remote_relp:
  address: 0.0.0.0
  port: 514
  tls: true
  tls_cacert: "/tls-certs/ca.pem"
  tls_mycert: "/tls-certs/cert.pem"
  tls_myprivkey: "/tls-certs/key.pem"
  tls_authmode: "fingerprint"

Bei tcp und udp kann derzeit nur die address (optional im Server-Modus), das target (erforderlich im Client-Modus) und der port (erforderlich in beiden Modi) angegeben werden.

rsyslog_rule_remote_tcp:
  address: 0.0.0.0
  port: 514

rsyslog_rule_remote_udp:
  address: 0.0.0.0
  port: 514

Bitte beachten Sie, dass Sie alle drei definieren können, mit unterschiedlichen Adressen und Ports (aber jede nur einmal). Alle Konfigurationen landen standardmäßig in /etc/rsyslog.d/99-remote.conf (sowohl Server als auch Client). Es ist derzeit unmöglich, dass eine einzelne Maschine sowohl als Server als auch als Client fungiert, wenn nur rsyslog_rule_remote_relp verwendet wird, aber es ist möglich, eine zusätzliche Regel mit entweder rsyslog_extra_conf_options oder rsyslog_rules anzugeben.

rsyslog_rule_remote:
  rule_name: "server"
  role: server
  priority: 99
  template: "remote.conf.j2"
  ruleset_name: "server"

rsyslog_rule_remote_udp:
  port: 514

rsyslog_rules:
  - rule_name: "client"
    priority: 99
    ruleset: |
      module(load="omfwd")
      action(type="omfwd" target="central.server.local" port="514" protocol="tcp")

Hinweis: Alle drei dieser zusätzlich vorkonfigurierten rsyslog-Regeln sind Wörterbücher, keine Arrays. Nur rsyslog_rules erlaubt mehrere Regeldefinitionen.

Erweitern und Ersetzen von Vorlagen

Ich erkenne, dass nicht alles mit Variablen abgedeckt ist und es viele verschiedene mögliche Konfigurationsoptionen gibt. Deshalb verwende ich Vorlagen für alle Regeln, die leicht erweiterbar sind, Blockersetzungen (via Jinja2-Vorlagenvererbung) oder den vollständigen Austausch von Vorlagen ermöglichen, um den Bedürfnissen gerecht zu werden, an die ich nicht gedacht habe.

rsyslog_conf_template: "rsyslog.conf.j2"
rsyslog_rules_template: "rules.conf.j2"

Es kann auch regelweise geändert werden.

rsyslog_rule_default:
  rule_name: "default"
  priority: 50
  template: "{{ playbook_dir }}/templates/custom-default.conf.j2"

rsyslog_rule_docker:
  rule_name: "docker"
  priority: 20
  template: "{{ playbook_dir }}/templates/custom-docker.conf.j2"

rsyslog_rules:
  - rule_name: "remote-udp"
    priority: 90
    template: "{{ playbook_dir }}/templates/custom-udp.conf.j2"
  - rule_name: "remote-tcp"
    priority: 91
    template: "{{ playbook_dir }}/templates/custom-tcp.conf.j2"

Beispiel: Module-Block im Hauptkonfigurationsdatei erweitern

rsyslog_conf_template muss auf die neue Datei in Ihrem Playbook-Verzeichnis gesetzt werden.

rsyslog_conf_template: "{{ playbook_dir }}/templates/custom-rsyslog.conf.j2"

Die benutzerdefinierte Vorlagendatei muss relativ zu Ihrem playbook.yml platziert werden.

{% extends 'roles/external/hadret.rsyslog/templates/rsyslog.conf.j2' %}

{% block modules %}
$ModLoad imuxsock
$ModLoad imklog
$ModLoad immark

$ModLoad imudp
$UDPServerRun 514

$ModLoad imtcp
$InputTCPServerRun 514
{% endblock %}

Das obige Beispiel ersetzt/erweitert den modules-Block in der Hauptkonfigurationsdatei von rsyslog.

Abhängigkeiten

Keine.

Beispiel-Playbook

hosts: all
  roles:
    - hadret.rsyslog

Lizenz

MIT.

Autoren

Diese Rolle wurde 2019 von Filip Chabik zusammengestellt.