Zbieranie źródeł danych dziennika systemowego za pomocą agenta usługi Log Analytics

  • Artykuł

Uwaga

W tym artykule odwołuje się do systemu CentOS — dystrybucji systemu Linux, która zbliża się do stanu zakończenia życia (EOL). Rozważ odpowiednie użycie i planowanie. Aby uzyskać więcej informacji, zobacz wskazówki dotyczące zakończenia życia systemu CentOS.

Syslog to protokół rejestrowania zdarzeń, który jest wspólny dla systemu Linux. Aplikacje wysyłają komunikaty, które mogą być przechowywane na komputerze lokalnym lub dostarczane do modułu zbierającego syslog. Po zainstalowaniu agenta usługi Log Analytics dla systemu Linux program konfiguruje lokalnego demona dziennika systemowego w celu przekazywania komunikatów do agenta. Następnie agent wysyła komunikaty do usługi Azure Monitor, w której jest tworzony odpowiedni rekord.

Ważne

Starszy agentusługi Log Analytics zostanie wycofany do sierpnia 2024 r. Po tej dacie firma Microsoft nie będzie już zapewniać żadnej pomocy technicznej dla agenta usługi analizy dzienników. Przeprowadź migrację do agenta usługi Azure Monitor przed sierpniem 2024 r., aby kontynuować pozyskiwanie danych.

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 systemu Red Hat Enterprise Linux, CentOS 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.

Diagram przedstawiający kolekcję Syslog.

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

  • Kern
  • Użytkownik
  • poczta
  • Daemon
  • auth
  • syslog
  • Lpr
  • Wiadomości
  • Uucp
  • Cron
  • authpriv
  • ftp
  • local0-local7

W przypadku każdej innej funkcji skonfiguruj źródło danych dzienników niestandardowych w usłudze Azure Monitor.

Konfigurowanie dziennika systemowego

Agent usługi Log Analytics dla systemu Linux będzie zbierał tylko zdarzenia z obiektami i ważnościami określonymi w konfiguracji. Dziennik systemu można skonfigurować za pośrednictwem witryny Azure Portal lub zarządzać plikami konfiguracji na agentach systemu Linux.

Konfigurowanie dziennika systemowego w witrynie Azure Portal

Skonfiguruj dziennik syslog z menu Konfiguracja agenta dla obszaru roboczego usługi Log Analytics. Ta konfiguracja jest dostarczana do pliku konfiguracji na każdym agencie systemu Linux.

Możesz dodać nowy obiekt, wybierając pozycję Dodaj obiekt. Dla każdego obiektu będą zbierane tylko komunikaty o wybranych ważnościach. Wybierz ważność dla określonego obiektu, który chcesz zebrać. Nie można podać żadnych innych kryteriów filtrowania komunikatów.

Zrzut ekranu przedstawiający konfigurowanie dziennika systemowego.

Domyślnie wszystkie zmiany konfiguracji są automatycznie wypychane do wszystkich agentów. Jeśli chcesz ręcznie skonfigurować dziennik syslog dla każdego agenta systemu Linux, wyczyść pole wyboru Zastosuj poniższą konfigurację do moich maszyn .

Konfigurowanie dziennika systemowego w agencie systemu Linux

Po zainstalowaniu agenta usługi Log Analytics na kliencie systemu Linux jest instalowany domyślny plik konfiguracji usługi Syslog, który definiuje obiekt i ważność zbieranych komunikatów. Możesz zmodyfikować ten plik, aby zmienić konfigurację. Plik konfiguracji różni się w zależności od demona dziennika systemowego zainstalowanego przez klienta.

Uwaga

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

Rsyslog

Plik konfiguracji programu rsyslog znajduje się w lokalizacji /etc/rsyslog.d/95-omsagent.conf. Jego domyślna zawartość 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 z poziomem ostrzeżenia lub wyższym.

kern.warning       @127.0.0.1:25224
user.warning       @127.0.0.1:25224
daemon.warning     @127.0.0.1:25224
auth.warning       @127.0.0.1:25224
syslog.warning     @127.0.0.1:25224
uucp.warning       @127.0.0.1:25224
authpriv.warning   @127.0.0.1:25224
ftp.warning        @127.0.0.1:25224
cron.warning       @127.0.0.1:25224
local0.warning     @127.0.0.1:25224
local1.warning     @127.0.0.1:25224
local2.warning     @127.0.0.1:25224
local3.warning     @127.0.0.1:25224
local4.warning     @127.0.0.1:25224
local5.warning     @127.0.0.1:25224
local6.warning     @127.0.0.1:25224
local7.warning     @127.0.0.1:25224

Obiekt można usunąć, usuwając jego sekcję pliku konfiguracji. Można ograniczyć ważność, które są zbierane dla określonego obiektu, modyfikując wpis tego obiektu. Aby na przykład ograniczyć obsługę użytkowników do komunikatów o ważności błędu lub wyższym, należy zmodyfikować ten wiersz pliku konfiguracji na następujący przykład:

user.error    @127.0.0.1:25224

syslog-ng

Plik konfiguracji syslog-ng znajduje się w lokalizacji /etc/syslog-ng/syslog-ng.conf. Jego domyślna zawartość jest wyświetlana w tym 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.

#
# Warnings (except iptables) in one file:
#
destination warn { file("/var/log/warn" fsync(yes)); };
log { source(src); filter(f_warn); destination(warn); };

#OMS_Destination
destination d_oms { udp("127.0.0.1" port(25224)); };

#OMS_facility = auth
filter f_auth_oms { level(alert,crit,debug,emerg,err,info,notice,warning) and facility(auth); };
log { source(src); filter(f_auth_oms); destination(d_oms); };

#OMS_facility = authpriv
filter f_authpriv_oms { level(alert,crit,debug,emerg,err,info,notice,warning) and facility(authpriv); };
log { source(src); filter(f_authpriv_oms); destination(d_oms); };

#OMS_facility = cron
filter f_cron_oms { level(alert,crit,debug,emerg,err,info,notice,warning) and facility(cron); };
log { source(src); filter(f_cron_oms); destination(d_oms); };

#OMS_facility = daemon
filter f_daemon_oms { level(alert,crit,debug,emerg,err,info,notice,warning) and facility(daemon); };
log { source(src); filter(f_daemon_oms); destination(d_oms); };

#OMS_facility = kern
filter f_kern_oms { level(alert,crit,debug,emerg,err,info,notice,warning) and facility(kern); };
log { source(src); filter(f_kern_oms); destination(d_oms); };

#OMS_facility = local0
filter f_local0_oms { level(alert,crit,debug,emerg,err,info,notice,warning) and facility(local0); };
log { source(src); filter(f_local0_oms); destination(d_oms); };

#OMS_facility = local1
filter f_local1_oms { level(alert,crit,debug,emerg,err,info,notice,warning) and facility(local1); };
log { source(src); filter(f_local1_oms); destination(d_oms); };

#OMS_facility = mail
filter f_mail_oms { level(alert,crit,debug,emerg,err,info,notice,warning) and facility(mail); };
log { source(src); filter(f_mail_oms); destination(d_oms); };

#OMS_facility = syslog
filter f_syslog_oms { level(alert,crit,debug,emerg,err,info,notice,warning) and facility(syslog); };
log { source(src); filter(f_syslog_oms); destination(d_oms); };

#OMS_facility = user
filter f_user_oms { level(alert,crit,debug,emerg,err,info,notice,warning) and facility(user); };
log { source(src); filter(f_user_oms); destination(d_oms); };

Obiekt można usunąć, usuwając jego sekcję pliku konfiguracji. Można ograniczyć ważność zbieraną dla określonego obiektu, usuwając je z listy. Aby na przykład ograniczyć funkcję użytkownika do ostrzegania tylko o krytycznych komunikatach, należy zmodyfikować sekcję tego pliku konfiguracji, jak pokazano w poniższym przykładzie:

#OMS_facility = user
filter f_user_oms { level(alert,crit) and facility(user); };
log { source(src); filter(f_user_oms); destination(d_oms); };

Zbieranie danych z innych portów dziennika systemowego

Agent usługi Log Analytics nasłuchuje komunikatów dziennika systemowego na lokalnym kliencie na porcie 25224. Po zainstalowaniu agenta jest stosowana domyślna konfiguracja dziennika systemowego i znajduje się w następującej lokalizacji:

  • Rsyslog: /etc/rsyslog.d/95-omsagent.conf
  • Syslog-ng: /etc/syslog-ng/syslog-ng.conf

Numer portu można zmienić, tworząc dwa pliki konfiguracji: plik konfiguracji FluentD i plik rsyslog-or-syslog-ng w zależności od zainstalowanego demona dziennika systemowego.

  • Plik konfiguracji FluentD powinien być nowym plikiem znajdującym się w /etc/opt/microsoft/omsagent/conf/omsagent.d pliku i zastąpić wartość we wpisie port numerem portu niestandardowego.

    <source>
    type syslog
    port %SYSLOG_PORT%
    bind 127.0.0.1
    protocol_type udp
    tag oms.syslog
</source>
<filter oms.syslog.**>
    type filter_syslog

  • W przypadku programu rsyslog należy utworzyć nowy plik konfiguracji znajdujący się w /etc/rsyslog.d/ pliku i zastąpić wartość %SYSLOG_PORT% numerem portu niestandardowego.

    Uwaga

    Jeśli zmodyfikujesz tę wartość w pliku 95-omsagent.confkonfiguracji , zostanie ona zastąpiona, gdy agent zastosuje konfigurację domyślną.

    # OMS Syslog collection for workspace %WORKSPACE_ID%
kern.warning              @127.0.0.1:%SYSLOG_PORT%
user.warning              @127.0.0.1:%SYSLOG_PORT%
daemon.warning            @127.0.0.1:%SYSLOG_PORT%
auth.warning              @127.0.0.1:%SYSLOG_PORT%

  • Konfiguracja syslog-ng powinna zostać zmodyfikowana przez skopiowanie przykładowej konfiguracji pokazanej następnego i dodanie niestandardowych zmodyfikowanych ustawień na końcu pliku konfiguracji znajdującego syslog-ng.conf się w /etc/syslog-ng/lokalizacji . Nie używaj etykiety %WORKSPACE_ID%_oms domyślnej ani %WORKSPACE_ID_OMS. Zdefiniuj etykietę niestandardową, aby ułatwić odróżnienie zmian.

    Uwaga

    Jeśli zmodyfikujesz wartości domyślne w pliku konfiguracji, zostaną one zastąpione, gdy agent zastosuje konfigurację domyślną.

    filter f_custom_filter { level(warning) and facility(auth; };
destination d_custom_dest { udp("127.0.0.1" port(%SYSLOG_PORT%)); };
log { source(s_src); filter(f_custom_filter); destination(d_custom_dest); };

Po zakończeniu zmian uruchom ponownie dziennik syslog i usługę agenta usługi Log Analytics, aby upewnić się, że zmiany konfiguracji zostaną zastosowane.

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.

Zapytania dzienników z rekordami dziennika systemowego

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

Query opis
Dziennik systemu Wszystkie dzienniki systemowe
Dziennik systemowy | where SeverityLevel == "error" Wszystkie rekordy dziennika systemowego o ważności błędu
Dziennik systemowy | summarize AggregatedValue = count() by Computer Liczba rekordów dziennika systemowego według komputera
Dziennik systemowy | summarize AggregatedValue = count() by Facility Liczba rekordów dziennika systemowego według obiektu

Następne kroki

  • Dowiedz się więcej o zapytaniach dzienników w celu analizowania danych zebranych ze źródeł danych i rozwiązań.
  • Użyj pól niestandardowych do analizowania danych z rekordów syslog do poszczególnych pól.
  • Konfigurowanie agentów systemu Linux w celu zbierania innych typów danych.