Udostępnij za pośrednictwem


Zbieranie zdarzeń dziennika systemowego za pomocą agenta usługi Azure Monitor

Zdarzenia dziennika systemowego to jedno ze źródeł danych używanych w regule zbierania danych (DCR). Szczegółowe informacje na temat tworzenia kontrolera domeny znajdują się w temacie Zbieranie danych za pomocą agenta usługi Azure Monitor. Ten artykuł zawiera dodatkowe szczegóły dotyczące typu źródła danych zdarzeń dziennika systemowego.

Syslog to protokół rejestrowania zdarzeń, który jest wspólny dla systemu Linux. Demona dziennika systemowego wbudowanego w urządzenia z systemem Linux i urządzeń można używać do zbierania lokalnych zdarzeń określonego typu. Aplikacje wysyłają komunikaty przechowywane na komputerze lokalnym lub dostarczane do modułu zbierającego syslog.

Napiwek

Aby zbierać dane z urządzeń, które nie zezwalają na lokalną instalację agenta usługi Azure Monitor, skonfiguruj dedykowany moduł przesyłania dalej dzienników oparty na systemie Linux.

Wymagania wstępne

Konfigurowanie zbierania danych dziennika systemowego

W kroku Collect and deliver of the DCR (Zbieranie i dostarczanie) wybierz pozycję Linux Syslog (Dziennik systemu Linux) z listy rozwijanej Typ źródła danych.

Następujące obiekty są obsługiwane przez moduł zbierający Syslog:

Numer indeksu priorytetu Nazwa priorytetu
{none} Brak pri
0 Kern
1 Użytkownik
2 poczta
3 Daemon
100 auth
5 syslog
6 Lpr
7 wiadomości
8 Uucp
9 cron
10 authpriv
11 ftp
12 Ntp
13 inspekcje
14 alert
15 zegar
16 local0
17 local1
18 local2
19 local3
20 local4
21 local5
22 local6
23 local7

Zrzut ekranu przedstawiający stronę w celu wybrania typu źródła danych i minimalnego poziomu dziennika.

Domyślnie agent będzie zbierał wszystkie zdarzenia wysyłane przez konfigurację dziennika systemowego. Zmień minimalny poziom dziennika dla każdego obiektu, aby ograniczyć zbieranie danych. Wybierz pozycję BRAK , aby zebrać żadne zdarzenia dla określonego obiektu.

Miejsca docelowe

Dane dziennika systemowego można wysyłać do następujących lokalizacji.

Element docelowy Tabela/przestrzeń nazw
Obszar roboczy usługi Log Analytics Syslog

Uwaga

Agent systemu Linux usługi Azure Monitor w wersji 1.15.2 i nowszej obsługuje formaty RFC dziennika systemu, w tym Cisco Meraki, Cisco ASA, Cisco FTD, Sophos XG, Juniper Networks, Corelight Zeek, CipherTrust, NXLog, McAfee i Common Event Format (CEF).

Zrzut ekranu przedstawiający konfigurację miejsca docelowego dzienników usługi Azure Monitor w regule zbierania danych.

Konfigurowanie dziennika systemowego na agencie systemu Linux

Gdy agent usługi Azure Monitor jest zainstalowany na maszynie z systemem Linux, instaluje domyślny plik konfiguracji syslog, który definiuje obiekt i ważność komunikatów, które są zbierane, jeśli usługa Syslog jest włączona w kontrolerze domeny. Plik konfiguracji różni się w zależności od demona dziennika systemowego zainstalowanego przez klienta.

Rsyslog

W wielu dystrybucjach systemu Linux demon rsyslogd jest odpowiedzialny za korzystanie, przechowywanie i routing komunikatów dziennika wysyłanych przy użyciu interfejsu API dziennika systemu Linux. Agent usługi Azure Monitor używa modułu wyjściowego przekazywania TCP (omfwd) w programie rsyslog do przekazywania komunikatów dziennika.

Instalacja agenta usługi Azure Monitor obejmuje domyślne pliki konfiguracji znajdujące się w programie /etc/opt/microsoft/azuremonitoragent/syslog/rsyslogconf/. Po dodaniu dziennika systemowego do kontrolera domeny ta konfiguracja jest instalowana w etc/rsyslog.d katalogu systemowym, a program rsyslog zostanie automatycznie uruchomiony ponownie, aby zmiany zaczęły obowiązywać.

Uwaga

W systemach opartych na rsyslog agent systemu Linux usługi Azure Monitor dodaje reguły przekazywania do domyślnego zestawu reguł zdefiniowanego w konfiguracji rsyslog. Jeśli jest używanych wiele zestawów reguł, dane wejściowe powiązane z zestawami reguł innych niż domyślne nieprzekazywane do agenta usługi Azure Monitor. Aby uzyskać więcej informacji na temat wielu zestawów reguł w programie rsyslog, zobacz oficjalną dokumentację.

Poniżej znajduje się domyślna konfiguracja, która zbiera komunikaty dziennika systemowego wysyłane z lokalnego agenta dla wszystkich obiektów ze wszystkimi poziomami dziennika.

$ 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")

Poniższa konfiguracja jest używana podczas korzystania z programu SELinux i decydujesz się na użycie gniazd systemu Unix.

$ 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

W niektórych starszych systemach mogą wystąpić problemy z formatowaniem dziennika rsyslog, gdy tradycyjny format przekazywania jest używany do wysyłania zdarzeń dziennika systemowego do agenta usługi Azure Monitor. W przypadku tych systemów agent usługi Azure Monitor automatycznie umieszcza starszy szablon usługi przesyłania dalej:

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

Syslog-ng

Instalacja agenta usługi Azure Monitor obejmuje domyślne pliki konfiguracji znajdujące się w programie /etc/opt/microsoft/azuremonitoragent/syslog/syslog-ngconf/azuremonitoragent-tcp.conf. Po dodaniu dziennika systemowego do kontrolera domeny ta konfiguracja jest instalowana w /etc/syslog-ng/conf.d/azuremonitoragent-tcp.conf katalogu systemowym, a systemlog-ng zostanie automatycznie uruchomiony ponownie, aby zmiany zaczęły obowiązywać.

Zawartość domyślna jest wyświetlana w poniższym przykładzie. W tym przykładzie zbierane są komunikaty dziennika systemowego wysyłane z agenta lokalnego dla wszystkich obiektów i wszystkich ważności.

$ 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);
};

Poniższa konfiguracja jest używana podczas korzystania z programu SELinux i decydujesz się na użycie gniazd systemu Unix.

$ 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);
}; 

Uwaga

Usługa Azure Monitor obsługuje zbieranie komunikatów wysyłanych przez rsyslog lub syslog-ng, gdzie rsyslog jest domyślnym demonem. Domyślny demon dziennika systemowego w wersji 5 systemów Red Hat Enterprise Linux i Oracle Linux (sysklog) nie jest obsługiwany w przypadku zbierania zdarzeń syslog. Aby zebrać dane dziennika systemowego z tej wersji tych dystrybucji, demon rsyslog powinien zostać zainstalowany i skonfigurowany do zastąpienia dziennika sysklog.

Jeśli edytujesz konfigurację dziennika systemowego, musisz ponownie uruchomić demona dziennika systemowego, aby zmiany zaczęły obowiązywać.

Obsługiwane obiekty

Następujące obiekty są obsługiwane przez moduł zbierający Syslog:

Indeks pri Nazwa pri
0 Brak
1 Kern
2 Użytkownik
3 poczta
100 Daemon
100 auth
5 syslog
6 Lpr
7 wiadomości
8 Uucp
9 ftp
10 Ntp
11 inspekcje
12 alert
13 znacznik
14 local0
15 local1
16 local2
17 local3
18 local4
19 local5
20 local6
21 local7

Właściwości rekordu dziennika systemowego

Rekordy dziennika systemowego mają typ dziennika systemowego i mają właściwości pokazane w poniższej tabeli.

Właściwości opis
Komputer Komputer, z którego zostało zebrane zdarzenie.
Pomieszczenie Definiuje część systemu, która wygenerowała komunikat.
HostIP Adres IP systemu wysyłającego komunikat.
HostName Nazwa systemu wysyłającego komunikat.
WażnośćLevel Poziom istotności zdarzenia.
SyslogMessage Tekst wiadomości.
ProcessId Identyfikator procesu, który wygenerował komunikat.
EventTime Data i godzina wygenerowania zdarzenia.

Przykładowe zapytania dziennika syslogu

W poniższej tabeli przedstawiono różne przykłady zapytań dziennika, które pobierają rekordy dziennika systemowego.

  • Wszystkie dzienniki systemowe

      Syslog
    
  • Wszystkie rekordy dziennika systemowego o ważności błędu

      Syslog
      | where SeverityLevel == "error"
    
  • Wszystkie rekordy dziennika systemu z typem obiektu uwierzytelniania

      Syslog
      | where facility == "auth"
    
  • Liczba rekordów dziennika systemowego według obiektu

      Syslog
      | summarize AggregatedValue = count() by facility
    

Rozwiązywanie problemów

Wykonaj poniższe kroki, jeśli nie zbierasz danych z oczekiwanego dziennika JSON.

  • Sprawdź, czy dane są zapisywane w usłudze Syslog.
  • Zobacz Weryfikowanie operacji , aby sprawdzić, czy agent działa, a dane są odbierane.

Następne kroki

Dowiedz się więcej na następujące tematy: