Freigeben über

Sammeln von Syslog-Ereignissen mit dem Azure Monitor-Agent

  • Artikel

Achtung

Dieser Artikel bezieht sich auf CentOS, eine Linux-Distribution, die sich dem End-of-Life-Status (EOL) nähert. Sie sollten Ihre Nutzung entsprechend planen. Weitere Informationen finden Sie im CentOS End-of-Life-Leitfaden.

Syslog ist ein gängiges Protokoll zur Ereignisprotokollierung für Linux. Sie können den in Linux-Geräten und -Appliances integrierten Syslog-Daemon verwenden, um lokale Ereignisse der von Ihnen angegebenen Typen zu sammeln. Anschließend können Sie diese Ereignisse an einen Log Analytics-Arbeitsbereich senden. Anwendungen senden Nachrichten, die auf dem lokalen Computer gespeichert oder an einen Syslog-Collector übermittelt werden können.

Wenn der Azure Monitor-Agent für Linux installiert ist, konfiguriert er den lokalen Syslog-Daemon, um Nachrichten an den Agent weiterzuleiten, wenn die Syslog-Sammlung in den Datensammlungsregeln (Data Collection Rules, DCRs) aktiviert ist. Der Azure Monitor-Agent sendet die Nachrichten dann an den Azure Monitor- oder Log Analytics-Arbeitsbereich, in dem ein entsprechender Syslog-Datensatz in der Syslog-Tabelle erstellt wird.

Diagramm: Syslog-Sammlung

Diagramm, das die Syslog-Daemon- und die Azure Monitor Agent-Kommunikation veranschaulicht.

Hinweis

Der Azure Monitor-Agent empfängt über einen TCP-Port Nachrichten von rsyslog oder syslog-ng. Wenn jedoch SELinux aktiviert ist und wir nicht in der Lage sind, Regeln für den TCP-Port mit semanage hinzuzufügen, verwenden wir Unix-Sockets.

Die folgenden Einrichtungen werden mit dem Syslog-Sammler unterstützt:

  • Keine
  • Kern
  • user
  • mail
  • daemon
  • auth
  • syslog
  • lpr
  • news
  • uucp
  • ftp
  • ntp
  • Überwachung
  • Warnung
  • markieren
  • local0
  • local1
  • local2
  • local3
  • local4
  • local5
  • local6
  • local7

Im Folgenden sind die Schweregrade der Ereignisse aufgeführt:

  • info
  • Hinweis
  • error
  • Warnung laden
  • Kritisch

Bei einigen Gerätetypen, welche die lokale Installation des Azure Monitor-Agents nicht zulassen, kann der Agent stattdessen auf einem dedizierten Linux-basierten Protokollweiterleiter installiert werden. Das Ursprungsgerät muss so konfiguriert sein, dass Syslog-Ereignisse an den Syslog-Daemon in dieser Weiterleitung statt an den lokalen Daemon gesendet werden. Weitere Informationen finden Sie im Sentinel-Tutorial.

Konfigurieren von Syslog

Der Azure Monitor-Agent für Linux sammelt nur Ereignisse mit den Einrichtungen und Schweregraden, die in ihrer Konfiguration angegeben sind. Sie können Syslog über das Azure-Portal oder durch die Verwaltung von Konfigurationsdateien für die Linux-Agents konfigurieren.

Konfigurieren von Syslog im Azure-Portal

Konfigurieren Sie Syslog über das Menü Datensammlungsregeln von Azure Monitor. Diese Konfiguration wird in der Konfigurationsdatei für jeden Linux-Agent bereitgestellt.

  1. Wählen Sie die Option Datenquelle hinzufügen.
  2. Wählen Sie unter Datenquellentyp, die Option Linux-Syslog aus.

Sie können Syslog-Ereignisse mit einer unterschiedlichen Protokollebene für jede Einrichtung sammeln. Standardmäßig werden alle Syslog-Einrichtungstypen gesammelt. Wenn Sie beispielsweise keine Ereignisse vom Typ auth sammeln möchten, wählen Sie im Listenfeld Minimale Protokollebene den Wert Keine für die auth-Einrichtung aus, und speichern Sie die Änderungen. Wenn Sie die Standardprotokollebene für Syslog-Ereignisse ändern und nur Ereignisse mit einer Protokollebene ab NOTICE oder einer höheren Priorität sammeln müssen, wählen Sie im Listenfeld Minimale Protokollebene die Option LOG_NOTICE aus.

Standardmäßig werden alle Konfigurationsänderungen automatisch per Push an alle Agents weitergegeben, die im DCR konfiguriert sind.

Erstellen einer Datensammlungsregel

Erstellen Sie eine Datensammlungsregel in derselben Region, in der sich auch Ihr Log Analytics-Arbeitsbereich befindet. Eine DCR ist eine Azure-Ressource, mit der Sie die Behandlung der Daten während der Erfassung im Arbeitsbereich definieren können.

  1. Melden Sie sich beim Azure-Portal an.

  2. Suchen und öffnen Sie Monitor.

  3. Wählen Sie unter Einstellungen die Option Datensammlungsregeln aus.

  4. Klicken Sie auf Erstellen.

    Screenshot zeigt den Bereich „Datensammlungsregeln“ mit der ausgewählten Option „Erstellen“.

Hinzufügen von Ressourcen

  1. Wählen Sie Ressourcen hinzufügen aus.

  2. Verwenden Sie die Filter, um die VM zu finden, die Sie zum Sammeln von Protokollen verwenden wollen.

    Screenshot zeigt die Seite zum Auswählen des Bereichs für die Datensammlungsregel.

  3. Wählen Sie den virtuellen Computer aus.

  4. Wählen Sie Übernehmen.

  5. Wählen Sie Weiter: Sammeln und übermitteln aus.

Hinzufügen einer Datenquelle

  1. Wählen Sie die Option Datenquelle hinzufügen.

  2. Wählen Sie unter Datenquellentyp, die Option Linux-Syslog aus.

    Screenshot zeigt die Seite zum Auswählen des Datenquellentyps und der minimalen Protokollebene.

  3. Übernehmen Sie für den Mindestprotokolliergrad die LOG_DEBUG-Standardwerte.

  4. Wählen Sie Weiter: Ziel aus.

Ziel hinzufügen

  1. Klicken Sie auf Ziel hinzufügen.

    Screenshot zeigt die Registerkarte „Ziel“ mit der ausgewählter Option „Ziel hinzufügen“.

  2. Geben Sie die folgenden Werte ein:

    Feld Wert
    Zieltyp Azure Monitor-Protokolle
    Subscription Wählen Sie das entsprechende Abonnement aus.
    Konto oder Namespace Auswählen des entsprechenden Log Analytics-Arbeitsbereichs

  3. Wählen Sie die Option Datenquelle hinzufügen.

  4. Klicken Sie auf Weiter: Überprüfen + erstellen.

Erstellen einer Regel

  1. Klicken Sie auf Erstellen.
  2. Warten Sie 20 Minuten, bevor Sie mit dem nächsten Abschnitt fortfahren.

Wenn auf Ihrer VM kein Azure Monitor-Agent installiert ist, löst die DCR-Bereitstellung die Installation des Agents auf der VM aus.

Konfigurieren von Syslog auf dem Linux-Agent

Wenn der Azure Monitor-Agent auf dem Linux-Computer installiert wird, installiert er eine Syslog-Standardkonfigurationsdatei, welche die Einrichtung und den Schweregrad der Nachrichten definiert, die gesammelt werden, wenn Syslog in einer DCR aktiviert ist. Die Konfigurationsdatei unterscheidet sich je nach dem Syslog-Daemon, den der Client installiert hat.

Rsyslog

Bei vielen Linux-Distributionen ist der rsyslogd-Daemon für das Abrufen, Speichern und Weiterleiten von Protokollnachrichten verantwortlich, die mit der Linux-Syslog-API gesendet werden. Der Azure Monitor-Agent verwendet das TCP Forward-Ausgabemodul (omfwd) in rsyslog, um Protokollnachrichten an den Azure Monitor-Agent weiterzuleiten.

Die Azure Monitor-Agent-Installation enthält Standardkonfigurationsdateien, die unter dem folgenden Verzeichnis abgelegt werden: /etc/opt/microsoft/azuremonitoragent/syslog/rsyslogconf/

Wenn Syslog einer DCR hinzugefügt wird, werden diese Konfigurationsdateien im etc/rsyslog.d-Systemverzeichnis abgelegt, und syslog-ng wird automatisch neu gestartet, damit die Änderungen wirksam werden. Diese Dateien werden von rsyslog verwendet, um das Ausgabemodul zu laden und die Ereignisse mithilfe definierter Regeln an den Daemon des Azure Monitor-Agents weiterzuleiten.

Ihr Standardinhalt wird im folgenden Beispiel gezeigt. In diesem Beispiel werden Syslog-Nachrichten erfasst, die der lokale Agent für alle Einrichtungen und alle Schweregrade gesendet hat.

$ cat /etc/rsyslog.d/10-azuremonitoragent-omfwd.conf
# Azure Monitor Agent configuration: forward logs to azuremonitoragent

template(name="AMA_RSYSLOG_TraditionalForwardFormat" type="string" string="<%PRI%>%TIMESTAMP% %HOSTNAME% %syslogtag%%msg:::sp-if-no-1st-sp%%msg%")
# queue.workerThreads sets the maximum worker threads, it will scale back to 0 if there is no activity
# Forwarding all events through TCP port
*.* action(type="omfwd"
template="AMA_RSYSLOG_TraditionalForwardFormat"
queue.type="LinkedList"
queue.filename="omfwd-azuremonitoragent"
queue.maxFileSize="32m"
action.resumeRetryCount="-1"
action.resumeInterval="5"
action.reportSuspension="on"
action.reportSuspensionContinuation="on"
queue.size="25000"
queue.workerThreads="100"
queue.dequeueBatchSize="2048"
queue.saveonshutdown="on"
target="127.0.0.1" Port="28330" Protocol="tcp")

Die folgende Konfiguration wird verwendet, wenn Sie SELinux verwenden und wir uns für Unix-Sockets entscheiden.

$ cat /etc/rsyslog.d/10-azuremonitoragent.conf
# Azure Monitor Agent configuration: forward logs to azuremonitoragent
$OMUxSockSocket /run/azuremonitoragent/default_syslog.socket
template(name="AMA_RSYSLOG_TraditionalForwardFormat" type="string" string="<%PRI%>%TIMESTAMP% %HOSTNAME% %syslogtag%%msg:::sp-if-no-1st-sp%%msg%") 
$OMUxSockDefaultTemplate AMA_RSYSLOG_TraditionalForwardFormat
# Forwarding all events through Unix Domain Socket
*.* :omuxsock: 

$ cat /etc/rsyslog.d/05-azuremonitoragent-loadomuxsock.conf
# Azure Monitor Agent configuration: load rsyslog forwarding module. 
$ModLoad omuxsock

Auf einigen Legacy-Systemen, z. B. CentOS 7.3, haben wir Probleme mit der rsyslog-Protokollformatierung festgestellt, wenn ein traditionelles Weiterleitungsformat verwendet wird, um Syslog-Ereignisse an den Azure Monitor-Agent zu senden. Für diese Systeme platziert der Azure Monitor-Agent stattdessen automatisch eine Legacy-Weiterleitervorlage:

template(name="AMA_RSYSLOG_TraditionalForwardFormat" type="string" string="%TIMESTAMP% %HOSTNAME% %syslogtag%%msg:::sp-if-no-1st-sp%%msg%\n")

Syslog-ng

Die Konfigurationsdatei für „syslog-ng“ befindet sich unter /etc/opt/microsoft/azuremonitoragent/syslog/syslog-ngconf/azuremonitoragent-tcp.conf. Wenn die Syslog-Sammlung einer DCR hinzugefügt wird, wird diese Konfigurationsdatei im /etc/syslog-ng/conf.d/azuremonitoragent-tcp.conf-Systemverzeichnis abgelegt, und syslog-ng wird automatisch neu gestartet, damit die Änderungen wirksam werden.

Die Standardinhalte werden im folgenden Beispiel gezeigt. Dieses Beispiel sammelt Syslog-Nachrichten, die der lokale Agent für alle Einrichtungen und alle Schweregrade gesendet hat.

$ cat /etc/syslog-ng/conf.d/azuremonitoragent-tcp.conf 
# Azure MDSD configuration: syslog forwarding config for mdsd agent
options {};

# during install time, we detect if s_src exist, if it does then we
# replace it by appropriate source name like in redhat 's_sys'
# Forwrding using tcp
destination d_azure_mdsd {
	network("127.0.0.1" 
	port(28330)
	log-fifo-size(25000));			
};

log {
	source(s_src); # will be automatically parsed from /etc/syslog-ng/syslog-ng.conf
	destination(d_azure_mdsd);
	flags(flow-control);
};

Die folgende Konfiguration wird verwendet, wenn Sie SELinux verwenden und wir uns für Unix-Sockets entscheiden.

$ cat /etc/syslog-ng/conf.d/azuremonitoragent.conf 
# Azure MDSD configuration: syslog forwarding config for mdsd agent options {}; 
# during install time, we detect if s_src exist, if it does then we 
# replace it by appropriate source name like in redhat 's_sys' 
# Forwrding using unix domain socket 
destination d_azure_mdsd { 
	unix-dgram("/run/azuremonitoragent/default_syslog.socket" 
	flags(no_multi_line) ); 
};
 
log {
	source(s_src); # will be automatically parsed from /etc/syslog-ng/syslog-ng.conf 
	destination(d_azure_mdsd);
};

Hinweis

Azure Monitor unterstützt die Sammlung der von „rsyslog“ oder „syslog-ng“ gesendeten Nachrichten, wobei „rsyslog“ der Standarddaemon ist. Der Standard-Syslog-Daemon in Version 5 von Red Hat Enterprise Linux, CentOS und Oracle Linux-Version (sysklog) wird für die Syslog-Ereigniserfassung nicht unterstützt. Der rsyslog-Daemon sollte installiert und so konfiguriert werden, dass er sysklog ersetzt, um Syslog-Daten von dieser Version dieser Distributionen zu sammeln.

Wenn Sie die Syslog-Konfiguration bearbeiten, müssen Sie den Syslog-Daemon neu starten, damit die Änderungen wirksam werden.

Voraussetzungen

Erforderlich:

Eigenschaften der Syslog-Datensätze

Syslog-Datensätze sind vom Typ Syslog und besitzen die in der folgenden Tabelle aufgeführten Eigenschaften:

Eigenschaft BESCHREIBUNG
Computer Computer, auf dem das Ereignis gesammelt wurde.
Facility Definiert den Teil des Systems, der die Meldung generiert hat.
HostIP IP-Adresse des Systems, das die Nachricht sendet.
HostName Name des Systems, das die Nachricht sendet.
SeverityLevel Schweregrad des Ereignisses.
SyslogMessage Text der Nachricht.
ProcessID ID des Prozesses, der die Meldung generiert hat.
EventTime Datum und Uhrzeit der Ereignisgenerierung.

Protokollieren von Abfragen mit Syslog-Datensätzen

Die folgende Tabelle zeigt verschiedene Beispiele für Protokollabfragen, die Syslog-Protokolldatensätze abrufen.

Abfrage BESCHREIBUNG
syslog Alle Syslog-Datensätze
Syslog | where SeverityLevel == "error" Alle Syslog-Datensätze mit Fehlerschweregrad
Syslog | where Facility == "auth" Alle Syslog-Datensätze mit Authentifizierungseinrichtungstyp
Syslog | summarize AggregatedValue = count() by Facility Anzahl der Syslog-Datensätze je Einrichtung

Nächste Schritte

Weitere Informationen: