Zbieranie zdarzeń dziennika systemowego za pomocą agenta usługi Azure Monitor
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. Demona dziennika systemowego wbudowanego w urządzenia i urządzenia z systemem Linux można używać do zbierania lokalnych zdarzeń określonego typu. Następnie możesz wysłać te zdarzenia do obszaru roboczego usługi Log Analytics. 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 Azure Monitor dla systemu Linux konfiguruje lokalnego demona dziennika systemowego w celu przekazywania komunikatów do agenta, gdy zbieranie dzienników syslog jest włączone w regułach zbierania danych (DCRs). Następnie agent usługi Azure Monitor wysyła komunikaty do obszaru roboczego usługi Azure Monitor lub Log Analytics, w którym w tabeli Syslog jest tworzony odpowiedni rekord dziennika systemowego.
Uwaga
Agent usługi Azure Monitor używa portu TCP do odbierania komunikatów wysyłanych przez rsyslog lub syslog-ng, jednak w przypadku włączenia protokołu SELinux i nie możemy użyć semanage do dodawania reguł dla portu TCP, użyjemy gniazd systemu Unix.
Następujące obiekty są obsługiwane przez moduł zbierający Syslog:
- Brak
- Kern
- Użytkownik
- poczta
- Daemon
- auth
- syslog
- Lpr
- Wiadomości
- Uucp
- ftp
- Ntp
- inspekcje
- alert
- znacznik
- local0
- local1
- local2
- local3
- local4
- local5
- local6
- local7
W przypadku niektórych typów urządzeń, które nie zezwalają na lokalną instalację agenta usługi Azure Monitor, agent można zainstalować zamiast tego na dedykowanym usłudze przesyłania dalej dzienników opartego na systemie Linux. Urządzenie źródłowe musi być skonfigurowane do wysyłania zdarzeń dziennika systemowego do demona dziennika systemowego na tym module przesyłania dalej zamiast lokalnego demona. Aby uzyskać więcej informacji, zobacz samouczek usługi Sentinel.
Konfigurowanie dziennika systemowego
Agent usługi Azure Monitor dla systemu Linux 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 Reguły zbierania danych w usłudze Azure Monitor. Ta konfiguracja jest dostarczana do pliku konfiguracji na każdym agencie systemu Linux.
- Wybierz Dodaj źródła danych.
- W polu Typ źródła danych wybierz pozycję Dziennik systemu Linux.
Zdarzenia dziennika systemowego można zbierać z innym poziomem dziennika dla każdego obiektu. Domyślnie zbierane są wszystkie typy obiektów syslog. Jeśli nie chcesz zbierać, na przykład zdarzenia auth
typu, wybierz pozycję NONE w polu Lista Minimalny poziom dziennika dla auth
obiektu i zapisz zmiany. Jeśli musisz zmienić domyślny poziom dziennika dla zdarzeń dziennika systemowego i zbierać tylko zdarzenia z poziomem dziennika rozpoczynającym się od powiadomienia lub wyższym priorytetem, wybierz LOG_NOTICE w polu Lista Minimalny poziom dziennika.
Domyślnie wszystkie zmiany konfiguracji są automatycznie wypychane do wszystkich agentów skonfigurowanych w kontrolerze domeny.
Tworzenie reguły zbierania danych
Utwórz regułę zbierania danych w tym samym regionie co obszar roboczy usługi Log Analytics. DcR to zasób platformy Azure, który umożliwia zdefiniowanie sposobu obsługi danych w miarę pozyskiwania ich do obszaru roboczego.
Zaloguj się w witrynie Azure Portal.
Wyszukaj i otwórz pozycję Monitor.
W obszarze Ustawienia wybierz pozycję Reguły zbierania danych.
Wybierz pozycję Utwórz.
Dodawanie zasobów
Wybierz pozycję Dodaj zasoby.
Użyj filtrów, aby znaleźć maszynę wirtualną, której chcesz użyć do zbierania dzienników.
Wybierz maszynę wirtualną.
Wybierz Zastosuj.
Wybierz pozycję Dalej: zbierz i dostarczyj.
Dodawanie źródła danych
Wybierz Dodaj źródła danych.
W polu Typ źródła danych wybierz pozycję Dziennik systemu Linux.
W obszarze Minimalny poziom dziennika pozostaw wartości domyślne LOG_DEBUG.
Wybierz pozycję Dalej: Miejsce docelowe.
Dodawanie miejsca docelowego
Wybierz Dodaj lokalizację docelową.
Wprowadź następujące wartości:
Pole Wartość Typ docelowy Dzienniki usługi Azure Monitor Subskrypcja Wybierz odpowiednią subskrypcję Konto lub przestrzeń nazw Wybieranie odpowiedniego obszaru roboczego usługi Log Analytics Wybierz Dodaj źródła danych.
Wybierz pozycję Dalej: Przeglądanie i tworzenie.
Tworzenie reguły
- Wybierz pozycję Utwórz.
- Poczekaj 20 minut, zanim przejdziesz do następnej sekcji.
Jeśli maszyna wirtualna nie ma zainstalowanego agenta usługi Azure Monitor, wdrożenie dcR wyzwala instalację agenta na maszynie wirtualnej.
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 przesyłania dalej TCP () womfwd
programie rsyslog do przekazywania komunikatów dziennika do agenta usługi Azure Monitor.
Instalacja agenta usługi Azure Monitor zawiera domyślne pliki konfiguracji, które są umieszczane w następującym katalogu: /etc/opt/microsoft/azuremonitoragent/syslog/rsyslogconf/
Po dodaniu dziennika systemowego do kontrolera domeny te pliki konfiguracji są instalowane w etc/rsyslog.d
katalogu systemowym, a narzędzie rsyslog zostanie automatycznie uruchomione ponownie, aby zmiany zaczęły obowiązywać. Te pliki są używane przez narzędzie rsyslog do ładowania modułu wyjściowego i przekazywania zdarzeń do demona agenta usługi Azure Monitor przy użyciu zdefiniowanych reguł.
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 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 decydujemy 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, takich jak CentOS 7.3, widzieliśmy 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
Plik konfiguracji syslog-ng jest zainstalowany pod adresem /etc/opt/microsoft/azuremonitoragent/syslog/syslog-ngconf/azuremonitoragent-tcp.conf
. Po dodaniu kolekcji syslog do kontrolera domeny ten plik konfiguracji jest umieszczany w /etc/syslog-ng/conf.d/azuremonitoragent-tcp.conf
katalogu systemowym, a plik syslog-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 decydujemy 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 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.
Jeśli edytujesz konfigurację dziennika systemowego, musisz ponownie uruchomić demona dziennika systemowego, aby zmiany zaczęły obowiązywać.
Wymagania wstępne
Należy wykonać:
- Obszar roboczy usługi Log Analytics, w którym masz co najmniej prawa współautora.
- Punkt końcowy zbierania danych.
- Uprawnienia do tworzenia obiektów DCR w obszarze roboczym.
- Komunikaty dziennika systemowego muszą być zgodne ze standardami RFC (RFC5424 lub RFC3164)
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 | where Facility == "auth" | Wszystkie rekordy dziennika systemu z typem obiektu uwierzytelniania |
Dziennik systemowy | summarize AggregatedValue = count() by Facility | Liczba rekordów dziennika systemowego według obiektu |
Następne kroki
Dowiedz się więcej na następujące tematy: