Partage via


Collecter des événements Syslog avec l’agent Azure Monitor

Les événements Syslog sont l’une des sources de données utilisées dans une règle de collecte de données. Les détails de la création d’une règle de collecte de données sont fournis dans Collecter des données avec l’agent Azure Monitor. Cet article fournit des informations complémentaires sur le type de source de données des événements Syslog.

Syslog est un protocole de journalisation des événements courant sur Linux. Vous pouvez utiliser le démon Syslog intégré aux appareils et dispositifs Linux pour collecter les événements locaux des types que vous spécifiez. Les applications envoient des messages qui sont stockés sur la machine locale ou remis à un collecteur Syslog.

Conseil

Pour collecter les données d’appareils qui n’autorisent pas l’installation locale de l’agent Azure Monitor, configurez un redirecteur de journal dédié basé sur Linux.

Prérequis

Configurer la collecte de données Syslog

Au cours de l’étape Collecter et livrer de la règle de collecte de données, sélectionnez Syslog Linux dans la liste déroulante Type de source de données.

Les fonctionnalités suivantes sont prises en charge avec le collecteur Syslog :

Numéro d’index de priorité Nom de la priorité
{aucune} Aucune priorité
0 Kern
1 utilisateur
2 mail
3 daemon
4 auth
5 syslog
6 lpr
7 news
8 uucp
9 cron
10 authpriv
11 ftp
12 ntp
13 audit
14 alerte
15 clock
16 local0
17 local1
18 local2
19 local3
20 local4
21 local5
22 local6
23 local7

Capture d’écran de la page permettant de sélectionner le type de source de données et le niveau de journalisation minimal.

Par défaut, l’agent collecte tous les événements envoyés par la configuration Syslog. Modifiez le Niveau de consignation minimal pour chaque catégorie (« facility ») afin de limiter la collecte de données. Sélectionnez AUCUN pour ne collecter aucun événement pour une catégorie particulière.

Destinations

Vous pouvez envoyer les données Syslog aux emplacements suivants.

Destination Table / Espace de noms
Espace de travail Log Analytics Syslog

Remarque

L’agent Linux Azure Monitor versions 1.15.2 et ultérieures prennent en charge les formats RFC syslog, notamment Cisco Meraki, Cisco ASA, Cisco FTD, Sophos XG, Juniper Networks, Corelight Zeek, CipherTrust, NXLog, McAfee et CEF (Common Event Format).

Capture d’écran montrant la configuration d’une destination de journaux Azure Monitor dans une règle de collecte de données.

Configurer Syslog sur l’agent Linux

Quand l’agent Azure Monitor est installé sur une machine Linux, il installe un fichier de configuration Syslog par défaut qui définit l’installation et la gravité des messages collectés si Syslog est activé dans une règle de collecte de données. Le fichier de configuration est différent selon le démon Syslog installé par le client.

Rsyslog

Sur de nombreuses distributions Linux, le démon rsyslogd est responsable de la consommation, du stockage et du routage des messages de journal envoyés en utilisant l’API Syslog Linux. L’agent Azure Monitor utilise le module de sortie de transfert TCP (omfwd) dans rsyslog pour transférer les messages de journal.

L’installation de l’agent Azure Monitor inclut les fichiers config par défaut situés dans /etc/opt/microsoft/azuremonitoragent/syslog/rsyslogconf/. Quand Syslog est ajouté à une règle de collecte de données, cette configuration est installée sous le répertoire système etc/rsyslog.d et rsyslog est redémarré automatiquement pour que les modifications prennent effet.

Remarque

Sur les systèmes rsyslog, l’agent Linux Azure Monitor ajoute des règles de transfert au jeu de règles par défaut défini dans la configuration rsyslog. Si plusieurs jeux de règles sont utilisés, les entrées liées à des jeux de règles autres que ceux par défaut ne sont pas transférées à l’agent Azure Monitor. Pour plus d’informations sur les jeux de règles multiples dans rsyslog, consultez la documentation officielle.

Voici la configuration par défaut qui collecte les messages Syslog envoyés à partir de l’agent local pour l’ensemble des catégories avec tous les niveaux de journalisation.

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

La configuration suivante est utilisée lorsque vous utilisez SELinux et décidez d’utiliser des sockets 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

Sur certains systèmes hérités, vous pouvez rencontrer des problèmes de mise en forme des journaux rsyslog lorsqu’un format de transfert traditionnel est utilisé pour envoyer des événements Syslog à l’agent Azure Monitor. Pour ces systèmes, l’agent Azure Monitor place automatiquement un modèle de redirecteur hérité à la place :

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

Syslog-ng

L’installation de l’agent Azure Monitor inclut les fichiers config par défaut situés dans /etc/opt/microsoft/azuremonitoragent/syslog/syslog-ngconf/azuremonitoragent-tcp.conf. Quand Syslog est ajouté à une règle de collecte de données, cette configuration est installée sous le répertoire système /etc/syslog-ng/conf.d/azuremonitoragent-tcp.conf et syslog-ng est redémarré automatiquement pour que les modifications prennent effet.

Son contenu par défaut est montré dans l’exemple suivant. Cet exemple collecte les messages Syslog envoyés depuis l’agent local pour toutes les installations et tous les niveaux de 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 configuration suivante est utilisée lorsque vous utilisez SELinux et décidez d’utiliser des sockets 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);
}; 

Remarque

Azure Monitor prend en charge la collecte de messages envoyés par rsyslog ou syslog-ng, sachant que rsyslog est le démon par défaut. Le démon Syslog par défaut sur la version 5 de Red Hat Enterprise Linux et Oracle Linux (sysklog) n’est pas pris pas en charge pour la collecte d’événements Syslog. Pour collecter des données Syslog avec cette version de ces distributions, le démon rsyslog doit être installé et configuré pour remplacer sysklog.

Si vous modifiez cette configuration Syslog, vous devez redémarrer le démon Syslog pour que les modifications prennent effet.

Catégories prises en charge

Les fonctionnalités suivantes sont prises en charge avec le collecteur Syslog :

Index PRI Nom PRI
0 Aucune
1 Kern
2 utilisateur
3 mail
4 daemon
4 auth
5 syslog
6 lpr
7 news
8 uucp
9 ftp
10 ntp
11 audit
12 alerte
13 mark
14 local0
15 local1
16 local2
17 local3
18 local4
19 local5
20 local6
21 local7

Propriétés d’enregistrement Syslog

Les enregistrements Syslog sont de type Syslog et ont les propriétés décrites dans le tableau suivant.

Propriété Description
Computer Ordinateur sur lequel l’événement a été collecté.
Facility Définit la partie du système qui a généré le message.
HostIP Adresse IP du système qui envoie le message.
HostName Nom du système qui envoie le message.
SeverityLevel Niveau de gravité de l’événement.
SyslogMessage Texte du message.
ProcessID ID du processus qui a généré le message.
EventTime Date et heure de génération de l’événement.

Exemples de requêtes de journal Syslog

Le tableau suivant fournit plusieurs exemples de requêtes de journaux qui extraient des enregistrements Syslog.

  • Tous les journaux Syslog

      Syslog
    
  • Tous les enregistrements Syslog avec la gravité error

      Syslog
      | where SeverityLevel == "error"
    
  • Tous les enregistrements Syslog avec le type de catégorie auth

      Syslog
      | where facility == "auth"
    
  • Nombre d’enregistrements Syslog par catégorie

      Syslog
      | summarize AggregatedValue = count() by facility
    

Dépannage

Si vous ne collectez pas les données attendues du journal JSON, effectuez les étapes suivantes.

  • Vérifiez que les données sont écrites dans Syslog.
  • Pour vérifier que l’agent est opérationnel et que les données sont reçues, consultez Vérifier l’opération.

Étapes suivantes

Pour en savoir plus :