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
- Log Analytics-Arbeitsbereich, in dem Sie mindestens über die Berechtigung „Mitwirkender“ verfügen. Syslog-Ereignisse werden an die Syslog-Tabelle gesendet.
- Entweder eine neue oder vorhandene DCR (unter Sammeln von Daten mit dem Azure Monitor-Agent beschrieben)
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:
| Prioritätsindexnummer | Priorität Name |
|---|---|
| {keine} | Keine Priorität |
| 0 | Kern |
| 1 | user |
| 2 | |
| 3 | daemon |
| 4 | auth |
| 5 | syslog |
| 6 | lpr |
| 7 | news |
| 8 | uucp |
| 9 | cron |
| 10 | authpriv |
| 11 | ftp |
| 12 | ntp |
| 13 | Überwachung |
| 14 | Warnung |
| 15 | clock |
| 16 | local0 |
| 17 | local1 |
| 18 | local2 |
| 19 | local3 |
| 20 | local4 |
| 21 | local5 |
| 22 | local6 |
| 23 | local7 |
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)).
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"
queue.maxDiskSpace="1g"
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 | |
| 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
SyslogAlle 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: