Raccogliere eventi Syslog con l'agente di Monitoraggio di Azure
Eventi Syslog è una delle origini dati usate in una regola di raccolta dati (DCR). Ulteriori dettagli sulla creazione di DCR sono disponibili in Raccogliere dati con l'agente di Monitoraggio di Azure. Questo articolo fornisce dettagli aggiuntivi per il tipo di origine dati eventi Syslog.
Syslog è un protocollo di registrazione di eventi comunemente usato in Linux. È possibile usare il daemon Syslog integrato in dispositivi e appliance Linux per raccogliere gli eventi locali dei tipi specificati. Le applicazioni inviano messaggi che possono essere archiviati nel computer locale o recapitati a un agente di raccolta di Syslog.
Suggerimento
Per raccogliere dati di dispositivi che non consentono l'installazione locale dell'agente di Monitoraggio di Azure, configurare un apposito server d'inoltro dei log basato su Linux.
Prerequisiti
- Un'area di lavoro Log Analytics in cui si dispone almeno dei diritti di collaboratore. Gli eventi Syslog vengono inviati alla tabella Syslog.
- Un DCR nuovo o esistente descritto in Raccogliere dati con l'agente di Monitoraggio di Azure.
Configurare la raccolta di dati Syslog
Nel passaggio Raccogli e recapita del DCR, selezionare Syslog Linux dall'elenco a discesa Tipo di origine dati.
Con l'agente di raccolta Syslog sono supportate le funzionalità seguenti:
| Pri index | Pri Name |
|---|---|
| 0 | None |
| 1 | Kern |
| 2 | utente |
| 3 | |
| 4 | daemon |
| 5 | aut |
| 6 | syslog |
| 7 | lpr |
| 8 | news |
| 9 | uucp |
| 10 | ftp |
| 11 | ntp |
| 12 | controllo |
| 13 | avviso |
| 14 | clock |
| 15 | local0 |
| 16 | local1 |
| 17 | local2 |
| 18 | local3 |
| 19 | local4 |
| 20 | local5 |
| 21 | local6 |
| 22 | local7 |
Per impostazione predefinita, l'agente raccoglierà tutti gli eventi inviati dalla configurazione Syslog. Modificare il livello di log minimo per ogni funzionalità per limitare la raccolta di dati. Selezionare NONE per non raccogliere eventi per una particolare struttura.
Destinazioni
I dati Syslog possono essere inviati alle posizioni seguenti.
| Destinazione | Tabella / Spazio dei nomi |
|---|---|
| area di lavoro Log Analytics | Syslog |
Nota
Le versioni dell’agente Linux di Monitoraggio di Azure 1.15.2 e successive supportano i formati RFC Syslog, tra cui Cisco Meraki, Cisco ASA, Cisco FTD, Sophos XG, Juniper Networks, Corelight Zeek, CipherTrust, NXLog, McAfee e Common Event Format (CEF).
Configurare Syslog nell'agente Linux
Durante l’installazione dell'agente di Monitoraggio di Azure in un computer Linux, viene installato un file di configurazione Syslog predefinito che definisce la funzionalità e la gravità dei messaggi raccolti se Syslog è abilitato in un DCR. Il file di configurazione è diverso a seconda del daemon Syslog installato nel client.
Rsyslog
In molte distribuzioni Linux, il daemon rsyslogd è responsabile dell'utilizzo, dell'archiviazione e del routing dei messaggi di log inviati tramite l'API Syslog Linux. L'agente di Monitoraggio di Azure usa il modulo di output di inoltro TCP (omfwd) in rsyslog per inoltrare i messaggi di log.
L'installazione dell'agente di Monitoraggio di Azure include file di configurazione predefiniti che si trovano in /etc/opt/microsoft/azuremonitoragent/syslog/rsyslogconf/. Quando Syslog viene aggiunto a un DCR, questa configurazione viene installata nella directory di sistema etc/rsyslog.d e rsyslog viene riavviato automaticamente per rendere effettive le modifiche.
Nota
Nei sistemi basati su rsyslog, l'agente Linux di Monitoraggio di Azure aggiunge regole di inoltro al set di regole predefinito definito nella configurazione di rsyslog. Se vengono usati più set di regole, gli input associati a set di regole non predefiniti non vengono inoltrati all'agente di Monitoraggio di Azure. Per altre informazioni su più set di regole in rsyslog, vedere la documentazione ufficiale.
Di seguito è riportata la configurazione predefinita che raccoglie i messaggi Syslog inviati dall'agente locale per tutte le strutture con tutti i livelli di log.
$ 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")
La configurazione seguente viene utilizzata quando si usa SELinux e si decide di usare socket 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
In alcuni sistemi legacy potrebbero verificarsi problemi di formattazione del log rsyslog quando viene usato un formato di inoltro tradizionale per inviare eventi Syslog all'agente di Monitoraggio di Azure. Per questi sistemi, l'agente di Monitoraggio di Azure inserisce automaticamente un modello di server d'inoltro legacy:
template(name="AMA_RSYSLOG_TraditionalForwardFormat" type="string" string="%TIMESTAMP% %HOSTNAME% %syslogtag%%msg:::sp-if-no-1st-sp%%msg%\n")
Syslog-ng
L'installazione dell'agente di Monitoraggio di Azure include i file di configurazione predefiniti che si trovano in /etc/opt/microsoft/azuremonitoragent/syslog/syslog-ngconf/azuremonitoragent-tcp.conf. Quando Syslog viene aggiunto a un DCR, questa configurazione viene installata nella directory di sistema /etc/syslog-ng/conf.d/azuremonitoragent-tcp.conf e syslog-ng viene riavviato automaticamente per rendere effettive le modifiche.
Il contenuto predefinito è illustrato nell'esempio seguente. Questo esempio raccoglie i messaggi Syslog inviati dall'agente locale per tutte le funzionalità e tutti i livelli di gravità.
$ 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);
};
La configurazione seguente viene utilizzata quando si usa SELinux e si decide di usare socket 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);
};
Nota
Monitoraggio di Azure supporta la raccolta di messaggi inviati da rsyslog o syslog-ng, dove rsyslog rappresenta il daemon predefinito. Il daemon Syslog predefinito nella versione 5 di Red Hat Enterprise Linux e Oracle Linux (sysklog) non è supportato per la raccolta di eventi Syslog. Per raccogliere dati di SysLog da questa versione delle distribuzioni, è necessario installare e configurare il daemon rsyslog in modo da sostituire sysklog.
Se si modifica la configurazione di SysLog, è necessario riavviare il daemon SysLog per rendere effettive le modifiche.
Strutture supportate
Con l'agente di raccolta Syslog sono supportate le funzionalità seguenti:
| Pri index | Pri Name |
|---|---|
| 0 | None |
| 1 | Kern |
| 2 | utente |
| 3 | |
| 4 | daemon |
| 4 | aut |
| 5 | syslog |
| 6 | lpr |
| 7 | news |
| 8 | uucp |
| 9 | ftp |
| 10 | ntp |
| 11 | controllo |
| 12 | avviso |
| 13 | mark |
| 14 | local0 |
| 15 | local1 |
| 16 | local2 |
| 17 | local3 |
| 18 | local4 |
| 19 | local5 |
| 20 | local6 |
| 21 | local7 |
Proprietà dei record Syslog
I record Syslog sono di tipo Syslog e hanno le proprietà mostrate nella tabella seguente.
| Proprietà | Descrizione |
|---|---|
| Computer | Computer da cui è stato raccolto l'evento. |
| Struttura | Parte del sistema che ha generato il messaggio. |
| HostIP | Indirizzo IP del sistema che ha inviato il messaggio. |
| HostName | Nome del sistema che ha inviato il messaggio. |
| SeverityLevel | Livello di sicurezza dell'evento. |
| SyslogMessage | Testo del messaggio. |
| ProcessID | ID del processo che ha generato il messaggio. |
| EventTime | Data e ora in cui è stato generato l'evento. |
Query di log syslog campione
La tabella seguente mostra alcuni esempi di query di log che recuperano i record Syslog.
Tutti i SysLog
SyslogTutti i record Syslog con livello di gravità errore
Syslog | where SeverityLevel == "error"Tutti i record Syslog con tipo di funzionalità di autenticazione
Syslog | where facility == "auth"Numero di record Syslog per struttura.
Syslog | summarize AggregatedValue = count() by facility
Risoluzione dei problemi
Seguire questa procedura se non si stanno raccogliendo dati dal log JSON previsto.
- Verificare che i dati vengano scritti in Syslog.
- Vedere Verifica operazione per verificare se l'agente sia operativo e i dati vengano ricevuti.
Passaggi successivi
Altre informazioni su:
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per