Aller au contenu principal

4. Principes de Base

Le protocole syslog est conçu pour envoyer des messages de notification d'événements sur des réseaux IP. Il ne nécessite pas de livraison fiable. Le protocole est basé sur une architecture en couches qui permet l'utilisation de différents protocoles de transport.

Le protocole se compose de trois couches:

  1. syslog content (contenu syslog): Informations contenues dans un message syslog qui décrivent un événement.

  2. syslog application (application syslog): Le système qui génère, interprète, route ou stocke les messages syslog. Cela inclut les émetteurs, les relais et les collecteurs.

  3. syslog transport (transport syslog): Un protocole qui transporte les messages syslog. Plusieurs protocoles de transport peuvent être utilisés pour la transmission.

Ce document décrit le contenu syslog et les applications syslog. Les mappages de transport sont décrits mais les spécifications détaillées sont décrites dans des documents séparés.

4.1. Exemples de Scénarios de Déploiement

Plusieurs scénarios démontrent le déploiement flexible de syslog:

Déploiement Simple: Un émetteur envoie des messages directement à un collecteur. C'est le cas le plus simple et ressemble aux implémentations syslog traditionnelles.

Avec Relais: Un émetteur envoie des messages à un relais, qui les transmet ensuite à un collecteur. Ceci est utile lorsque l'émetteur ne peut pas atteindre directement le collecteur ou lorsque le filtrage/agrégation de messages est souhaité.

Collecteurs Multiples: Un émetteur ou un relais envoie des messages à plusieurs collecteurs simultanément. Cela fournit une redondance et permet à différents collecteurs d'effectuer différentes analyses.

Relais Enchaînés: Les messages passent par plusieurs relais avant d'atteindre un collecteur. Chaque relais peut effectuer des décisions de filtrage, d'agrégation ou de routage.

Réseau Complexe: Une combinaison des scénarios ci-dessus crée une infrastructure syslog flexible qui peut s'adapter aux exigences organisationnelles et réseau.

Dans tous les scénarios, le format de message reste cohérent, permettant l'interopérabilité entre différentes implémentations et modèles de déploiement.