Discussion :

[ram-0000]

Présentation du protocole Syslog

Le protocole Syslog est un protocole réseau qui permet de transporter les messages de journalisation générés par les applications vers une machine hébergeant un serveur Syslog. Ce document a pour but de présenter le protocole Syslog.

A vos commentaires !

[jabbounet]

pour le chapitre facilité et sévérité tu parle d'une RFC sans en préciser le numéro. peu être faut il indiquer des le départ les rfc qui définissent le protocole et comme ça tu es tranquile

Autrement si facilité est la traduction de facility, facility est un faux amis en anglais
http://www.wordreference.com/enfr/facility

tu as le choix en fonction des cas pour la traduction entre fonction/fonctionnalité/équipement/....

[ram-0000]

Corrigé, merci pour la remarque sur le faux ami, j'utilise maintenant "fonctionnalité" au lieu de "facilité"

[AkH]

La référence du monde Linux tend à devenir Rsyslog et non Syslog-NG. Rsyslog est disponible de base sur Debian/RedHat/Fedora et packagé sur CentOS et autres distributions.

De plus, pour compléter ton article tu peux parler du traitement des évènements (messages) syslog par des applications tierces (Splunk, PHPLogCon, PHP-Syslog-NG, SEC (Simple Event Correlator), ......)

[ram-0000]

La référence du monde Linux tend à devenir Rsyslog et non Syslog-NG. Rsyslog est disponible de base sur Debian/RedHat/Fedora et packagé sur CentOS et autres distributions.

Effectivement, de base maintenant, sur ces distrib on trouve rsyslog et plus syslog (c'est assez récent comme changement).

J'ai préféré privilégier syslog-ng pour les raisons suivantes :

• je le connais, j'ai donc plus de facilités pour parler de syslog-ng.
• pour une fois qu'un éditeur fait quelque chose de gratuit, autant louer l'effort
• il y a une offre commerciale de support autour de syslog-ng. Cela a peut être peu d'importance à la maison mais dans le monde pro, cela fait la différence et participe au choix.

PS : je ne suis absolument pas lié avec Balabit IT.

De plus, pour compléter ton article tu peux parler du traitement des évènements (messages) syslog par des applications tierces (Splunk, PHPLogCon, PHP-Syslog-NG, SEC (Simple Event Correlator), ......)

Je ne voulais pas en parler dans cette présentation car le domaine de la corrélation est très vaste. Par contre, il est prévu un prochian tuto qui en parle.

[guitariste]

Salut.

J'ai installé syslog-ng sur ubuntu, sur deux machine (un client et un serveur)
je veux savoir où stocke syslog-ng les log localement (client) et s'il y a un moyen de les modifier. car j'utilise erlang et je veux creer une sorte de client syslog pour ce langage car j'en ai pas trouvé.

Merci

[ram-0000]

... je veux savoir où stocke syslog-ng les log localement...

Je ne sais pas, il faut regarder les clauses "destination" et "log" du fichier de configuration de ton syslog-ng.

[guitariste]

salut

Pour le moment c'est configuré pour une application rails :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
log {    source(s_sys); 
    filter(f_rails_apps); 
    destination(log_server); 
    flags(final); };

et pour destination j'ai le serveur de log

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
destination log_server { 
    udp("192.168.10.98" port(514)); 
};

mais je me demandais si syslog stocke les messages d'une manière temporaire en local.
j'ai vu qu'il y a la commande linux syslog()...ca peut m'aider je pense ....mais je vois pas comment je peux l'utiliser

Merci

[ram-0000]

Effectivement, dans ce cas, les logs ne sont pas stockés en local, ils sont envoyés sur le réseau.

Peut être en ajoutant une 2eme destination :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
destination log_server { 
   udp("192.168.10.98" port(514)); 
   file("/var/log/syslog/syslog-ng.log"); 
};

ou quelque chose comme cela

[64XAVIER64]

Il me semble que tu ne parle pas trop de la fonctionnalité de transfert TLS (anciennement appelé SSL).
A mon avis le transfert de log est plus facile et intuitif avec syslog-ng qu'avec rsyslog...

[ram-0000]

Il me semble que tu ne parle pas trop de la fonctionnalité de transfert TLS (anciennement appelé SSL).

Je n'en parle pas car SSL (ou TLS) se fait sur du TCP et que le mode TCP n'est pas "natif" sur syslog (même s'il fonctionne quand même).

Mais je rajouterai un § à ce sujet à l'occasion

A mon avis le transfert de log est plus facile et intuitif avec syslog-ng qu'avec rsyslog...

C'est une histoire de goût (que je partage)

[boboss123]

bonjour,

Cet article est pas mal mais ça aurait été sympa d'avoir un comparatif (pas forcément dans les détails) entre les différentes solutions existantes pour la journalisation d'évènements

Par exemple, je dois faire une application (coté client) qui doit pouvoir informer un serveur s'il y a des erreurs sur le système. Au départ j'étais parti sur du SNMP (avec l'utilisation de traps) mais après avoir lu cet article je me dis que syslog (en TCP ou SSL selon l'appli) pourrait être plus fiable (et facile à mettre en place ?).

A votre avis quel protocole devrais-je utiliser (SNMP, syslog, autre ...) sachant que ce n'est pas moi qui impose le logiciel de supervision utilisé sur le serveur (je dois donc pouvoir m'interfacer avec le maximum de systèmes différents possibles... donc les protocoles dis propriétaires sont à éviter) ?
Est-ce que vous supervisez des appareils (autre que PC) sur vos réseau et si oui, quel protocole utilisez-vous pour la gestion des alarmes ?

Si le réseau est encombré pendant un long moment, que se passe t-il ? Est-ce que des messages sont perdus même si on est en TCP ?
Est-ce que syslog prévoit de pouvoir envoyer les messages à plusieurs serveurs au cas ou il y ai en un qui plante ?

[ram-0000]

Si le réseau est encombré pendant un long moment, que se passe t-il ? Est-ce que des messages sont perdus même si on est en TCP ?

Peut être que tu perdras des messages mais l'avantage avec TCP (ou SSL sur TCP), c'est que tu sauras que tu as perdu des paquets alors qu'en UDP, c'est du Best effort et tu n'en sauras rien.

Est-ce que syslog prévoit de pouvoir envoyer les messages à plusieurs serveurs au cas ou il y ai en un qui plante ?

Syslog ne prévoit rien à ce sujet. Par contre cette fonctionnalité est implémentée sur certains serveur syslog. Je sais par exemple qu'avec Sylog-ng, il est possible d'envoyer les logs à destination de plusieurs serveurs.

[boboss123]

merci pour ces éclaircissements

Est-ce que le serveur peut interroger un client pour lui envoyer des demandes ?
=> par exemple, est-ce qu'il existe une commande permettant au serveur de demander au client de renvoyer toutes les infos à partir d'une date précise ou d'un nombre max d'entrée ? ... j'ai l'impression que ce n'est que le client qui peut envoyer des infos au serveur et pas l'inverse, non (je parle pour une utilisation standard pas de méthode type bidouille que personne n'utilise) ?


sinon j'attends avec impatience vos retours d'expériences au sujet des points abordés au début de mon précédent post

PS : peut-être que je ne devrais pas poster ici ?

[ram-0000]

Est-ce que le serveur peut interroger un client pour lui envoyer des demandes ?

NON, le protocole syslog est à un seul sens, du générateur de log au récepteur du log et c'est tout.

sinon j'attends avec impatience vos retours d'expériences au sujet des points abordés au début de mon précédent post

En ce moment, je n'ai pas trop de temps mais il est très possible d'apporter des modifications à ce tutoriel pour y ajouter tes expériences.

PS : peut-être que je ne devrais pas poster ici ?

Pourquoi, c'est bien ici

[Cybher]

A votre avis quel protocole devrais-je utiliser (SNMP, syslog, autre ...) sachant que ce n'est pas moi qui impose le logiciel de supervision utilisé sur le serveur (je dois donc pouvoir m'interfacer avec le maximum de systèmes différents possibles... donc les protocoles dis propriétaires sont à éviter) ?
Est-ce que vous supervisez des appareils (autre que PC) sur vos réseau et si oui, quel protocole utilisez-vous pour la gestion des alarmes ?

salut,

si c'est de la supervision que tu veux faire, pour moi, c'est plus vers le SNMP que tu devrais te tourner. Car tu peux envoyer des traps sur certains critères et donc être prévenu en cas de problème.

Le syslog, c'est plus la journalisation de logs, donc tu vas récupérer plus d'évènement. Cela sera plus simple par contre, pour étudier une erreur arrivée dans le passé puisque tu gardes plus de logs et d'évènements. Par contre tu perds la possibilité de faire des traps, qui est un élément non négligeable dans la supervision.

enfin, ce n'est que mon avis

[ram-0000]

enfin, ce n'est que mon avis

Et je le partage

Syslog journalisation
SNMP supervision.

2 fonctionnalités différentes et 2 métiers différents.

[boboss123]

si c'est de la supervision que tu veux faire, pour moi, c'est plus vers le SNMP que tu devrais te tourner. Car tu peux envoyer des traps sur certains critères et donc être prévenu en cas de problème.

Les logiciels de supervisions ne savent pas déclencher des actions (alarmes) en fonction du niveau de sévérité des messages sysLog ?

Après les avantages que je vois pour le SNMP sont :
- On peut configurer le produit
=> mais d'après les retours que j'ai eu, c'est très peu utiliser car pas pratique du tout. Mieux vaut pouvoir configurer le système par page Web et gérer le chargement de fichier de configuration pour automatiser les taches.

- On peut interroger le produit pour avoir son état (permet par exemple en faisant du pooling, de faire de jolies graphiques). Mais là encore l'utilisation d'un mini serveur web embarqué sur le module pour afficher l'état du module me semble mieux adapté.



Donc pour mon système, je partirais bien sur :
- 1 mini serveur web embarqué qui affiche l'état du module, permet de configurer le module et permet de charger/appliquer un fichier de configuration (faut t-il prévoir d'autres protocoles autre que le HTTP pour cette fonction ?)
- 1 client sysLog qui envoie (à un ou plusieurs serveurs sysLog) les messages d'informations/alarmes
=> pour l'utilisateur, ça me semble simple à utiliser/configurer et intéressant pour le debug.

Vous en pensez quoi ? pour vous, il ferait quoi le produit parfait ? ... Le but étant de pouvoir configurer, récupérer les erreurs pour le debug et afficher l'état de manière automatisée ou manuelle (et que tout ça soit facilement intégrable dans un logiciel de supervision)

[jedema]

Salut, j'avais une question.
Je m'étais basé sur tout ce qui était dit dans ce tuto mais le début de mes messages syslog est bizzare. Voici un message syslog que je reçoit.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<189><1296747593000>LINEPROTO-5-UPDOWN:17: *Mar  1 00:01:19.549: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1, changed state to up

A quoi correspondent les champs ?
Je m'attendais à :
189><Feb 11 15:47:00>LINEPROTO-5-UPDOWN:17: *Mar 1 00:01:19.549: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1, changed state to up
Est-ce que ça fait partie de ce que tu dit : "Un contenu de champ HOSTNAME "flou"."

Enfin bref je comprend le <189> mais pas du tout le <1296747593000>. Pouvez-vous me l'expliquer ? Merci.


PS : Vous remarquerez que c'est mon commutateur Cisco qui m'a envoyé ce log.

[ram-0000]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<189><1296747593000>LINEPROTO-5-UPDOWN:17: *Mar  1 00:01:19.549: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1, changed state to up

Soit c'est un équipement qui ne respecte pas du tout le protocole Syslog, soit tu as eu un télécopage dans le démon syslog de 2 trames.

J'ai l'impression que ce qui est en rouge dans le message est en trop et qu'il manque la partie "Hostname" et que le champs horaire est mal formé (il y a ".549:" en trop)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<189><1296747593000>LINEPROTO-5-UPDOWN:17: *Mar  1 00:01:19.549: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1, changed state to up

Est ce que tout tes logs de cet équipement sont comme cela ou bien est-ce que c'est un accident ?