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
- Un espace de travail Log Analytics dans lequel vous avez au minimum des droits de contributeur. Les événements Syslog sont envoyés à la table Syslog.
- Une règle de collecte de données (nouvelle ou existante) comme décrit dans Collecter des données avec l’agent Azure Monitor.
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 :
| Index PRI | Nom PRI |
|---|---|
| 0 | Aucune |
| 1 | Kern |
| 2 | utilisateur |
| 3 | |
| 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 |
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).
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"
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 | |
| 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
SyslogTous 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 :
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour