Collecter des événements Syslog à partir d’un client de machine virtuelle avec Azure Monitor

Syslog est un protocole de journalisation des événements courant sur Linux. Vous pouvez utiliser le démon Syslog intégré aux périphériques et appliances 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. Collecter des événements Syslog à partir de machines virtuelles à l’aide d’une règle de collecte de données (DCR) avec une source de données Syslog Linux .

Conseil / Astuce

Pour collecter des données à partir d’appareils qui n’autorisent pas l’installation locale de l’agent Azure Monitor, configurez un redirecteur de journaux Linux dédié, comme décrit dans Transférer les données Syslog vers un espace de travail Log Analytics avec Microsoft Sentinel à l’aide de l’agent Azure Monitor.

Les détails de la création de la DCR sont fournis dans Collecter des données à partir du client de machine virtuelle avec Azure Monitor. Cet article fournit des détails supplémentaires pour le type de source de données Syslog Linux.

Remarque

Pour utiliser directement la définition DCR ou pour effectuer un déploiement avec d’autres méthodes telles que des modèles ARM, consultez les exemples de règle de collecte de données (DCR) dans Azure Monitor.

Créer le DCR

Créez la DCR en suivant le processus décrit dans Collecte des données à partir du client de machine virtuelle avec Azure Monitor.

Configurer la source de données Syslog

Sous l’onglet Collecter et remettre de la DCR, sélectionnez Syslog Linux dans la liste déroulante type de source de données .

Sélectionnez un niveau de journal minimal pour chaque installation ou NONE pour collecter aucun événement pour cette installation. Vous pouvez configurer plusieurs installations à la fois en cochant leur case, puis en sélectionnant un niveau de journal dans Définir le niveau minimal du journal pour les installations sélectionnées.

Tous les journaux avec le niveau de gravité sélectionné et supérieur sont collectés pour l’installation. Les niveaux de gravité pris en charge et leur gravité relative sont les suivants :

1. Débogage
2. Informations
3. Avis
4. Avertissement
5. Erreur
6. Essentiel
7. Alerte
8. Urgence

Ajouter des destinations

Les données Syslog ne peuvent être envoyées qu’à un espace de travail Log Analytics où elles sont stockées dans la table Syslog . Ajoutez une destination de type Journaux Azure Monitor et sélectionnez un espace de travail Log Analytics. Bien que vous puissiez ajouter plusieurs espaces de travail, sachez que cela envoie des données en double à chacune d’elles, ce qui entraîne un coût supplémentaire.

Vérifier la collecte de données

Pour vérifier que les données sont collectées, recherchez les enregistrements dans la table Syslog . À partir de la machine virtuelle ou de l’espace de travail Log Analytics dans le portail Azure, sélectionnez Journaux , puis cliquez sur le bouton Tables . Sous la catégorie Machines virtuelles, cliquez sur Exécuter à côté de Syslog.

Remarque

Lors de l’ingestion de données syslog à l’aide d’un redirecteur de journal, des incohérences peuvent survenir entre les champs TimeGenerated et EventTime.

• TimeGenerated reflète l’heure UTC pendant laquelle le message syslog a été traité par l’ordinateur hébergeant le redirecteur de journal ou le collecteur.
• EventTime est extrait de l’en-tête syslog, qui n’inclut pas d’informations de fuseau horaire et est converti en UTC à l’aide du décalage de fuseau horaire local du redirecteur/collecteur.

Cela peut entraîner des différences entre les deux champs lorsque le redirecteur/collecteur et l’appareil générant le journal se trouvent dans des fuseaux horaires différents.

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.

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).

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 les données Syslog à partir de 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	Aucun
1	Kern
2	utilisateur
3	courriel
4	démon
4	auth
5	syslog (système de journalisation)
6	lpr
7	nouvelles
8	uucp
9	FTP
10	ntp
11	contrôle financier
12	alerte
13	marque
14	local0
15	local1
16	local2
17	local3
18	local4
19	local5
20	local6
Vingt-et-un	local7

Étapes suivantes

• En savoir plus sur l’agent Azure Monitor
• En savoir plus sur les règles de collecte de données.