Freigeben über


Sammeln von Syslog-Ereignissen mit dem Azure Monitor-Agent

Syslog-Ereignisse sind eine der Datenquellen, die in einer Datensammlungsregel (Data Collection Rule, DCR) verwendet werden. Details zur Erstellung der DCR finden Sie unter Sammeln von Daten mit dem Azure Monitor-Agent. Dieser Artikel enthält weitere Details zum Datenquellentyp für Syslog-Ereignisse.

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

Tipp

Um Daten von Geräten zu sammeln, die die lokale Installation des Azure Monitor-Agents nicht zulassen, konfigurieren Sie eine dedizierte Linux-basierte Protokollweiterleitung.

Voraussetzungen

Konfigurieren der Erfassung von Syslog-Daten

Wählen Sie im Schritt Sammeln und übermitteln der DCR die Option Linux-Syslog aus der Dropdownliste Datenquellentyp aus.

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

Pri-Index Pri-Name
0 Keine
1 Kern
2 user
3 mail
4 daemon
4 auth
5 syslog
6 lpr
7 news
8 uucp
9 ftp
10 ntp
11 Überwachung
12 Warnung
13 markieren
14 local0
15 local1
16 local2
17 local3
18 local4
19 local5
20 local6
21 local7

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

Standardmäßig erfasst der Agent alle Ereignisse, die von der Syslog-Konfiguration gesendet werden. Ändern Sie den Mindestprotokolliergrad für jede Einrichtung, um die Datenerfassung einzuschränken. Wählen Sie KEINE aus, um keine Ereignisse für eine bestimmte Einrichtung zu sammeln.

Destinations

Syslog-Daten können an die folgenden Speicherorte gesendet werden.

Destination Tabelle/Namespace
Log Analytics-Arbeitsbereich Syslog

Hinweis

Die Linux-Agent-Version 1.15.2 von Azure Monitor und höhere Versionen unterstützen Syslog-RFC-Formate (einschließlich Cisco Meraki, Cisco ASA, Cisco FTD, Sophos XG, Juniper Networks, Corelight Zeek, CipherTrust, NXLog, McAfee und Common Event Format (CEF)).

Screenshot: Konfiguration eines Azure Monitor-Protokollziels in einer Datensammlungsregel

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-Weiterleitungsausgabemodul (omfwd) in rsyslog zum Weiterleiten von Protokollnachrichten.

Die Installation des Azure Monitor-Agents umfasst Standardkonfigurationsdateien, die sich in /etc/opt/microsoft/azuremonitoragent/syslog/rsyslogconf/ befinden. Wenn Syslog einer DCR hinzugefügt wird, wird diese Konfiguration unter dem Systemverzeichnis etc/rsyslog.d installiert, und rsyslog wird automatisch neu gestartet, damit die Änderungen wirksam werden.

Hinweis

Auf rsyslog-basierten Systemen fügt der Azure Monitor Linux-Agent Weiterleitungsregeln zu dem in der rsyslog-Konfiguration definierten Standardregelsatz hinzu. Wenn mehrere Regelsätze verwendet werden, werden Eingaben, die an nicht standardmäßige Regelsätze gebunden sind, nicht an den Azure Monitor-Agent weitergeleitet. Weitere Informationen zu mehreren Regelsätzen in „rsyslog“ finden Sie in der offiziellen Dokumentation.

Es folgt die Standardkonfiguration, die Syslog-Nachrichten sammelt, die vom lokalen Agent für alle Einrichtungen mit allen Protokolliergraden gesendet werden.

$ 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 sich für die Nutzung von 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

Bei einigen Legacysystemen treten bei der rsyslog-Protokollformatierung möglicherweise Probleme auf, wenn ein herkömmliches 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 Installation des Azure Monitor-Agents umfasst Standardkonfigurationsdateien, die sich in /etc/opt/microsoft/azuremonitoragent/syslog/syslog-ngconf/azuremonitoragent-tcp.conf befinden. Wenn Syslog einer DCR hinzugefügt wird, wird diese Konfiguration unter dem Systemverzeichnis /etc/syslog-ng/conf.d/azuremonitoragent-tcp.conf installiert, 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 sich für die Nutzung von 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 Syslog-Standarddaemon in Version 5 von Red Hat Enterprise Linux und der 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.

Unterstützte Einrichtungen

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

Pri-Index Pri-Name
0 Keine
1 Kern
2 user
3 mail
4 daemon
4 auth
5 syslog
6 lpr
7 news
8 uucp
9 ftp
10 ntp
11 Überwachung
12 Warnung
13 markieren
14 local0
15 local1
16 local2
17 local3
18 local4
19 local5
20 local6
21 local7

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.

Beispiel für Syslog-Protokollabfragen

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

  • Alle Syslogs

      Syslog
    
  • Alle Syslog-Datensätze mit Fehlerschweregrad

      Syslog
      | where SeverityLevel == "error"
    
  • Alle Syslog-Datensätze mit Einrichtungstyp

      Syslog
      | where facility == "auth"
    
  • Anzahl der Syslog-Datensätze je Einrichtung

      Syslog
      | summarize AggregatedValue = count() by facility
    

Problembehandlung

Führen Sie die folgenden Schritte aus, wenn Sie nicht die erwarteten Daten aus dem JSON-Protokoll sammeln.

  • Überprüfen Sie, ob Daten in Syslog geschrieben werden.
  • Unter Vorgang überprüfen können Sie überprüfen, ob der Agent funktioniert und Daten empfangen werden.

Nächste Schritte

Weitere Informationen: