Discussion :

[jedema]

Et bien c'est un switch cisco catalyst donc nomalement il respecte totalement la norme syslog.
Et tous les logs sont comme ça. J'ai aussi récupéré des messages syslog d'un onduleur APC. L'un des ces messages est comme ça :

<44><1295424801000>192.168.9.2 UPS:192.168.9.2 UPS: Started a reboot process. 0x0117


Je trouve ça bizarre. En tous cas merci pour les réponses car je ne trouve pas la réponse et que je rédige ma note de synthèse de BTS informatique.

[Invité]

Ces données sont des "extra sequence numbers" générés par l'IOS Cisco.

Ils servent surtout pour le "troubleshooting" en permettant de suivre certains fsm ou algorithmes pas-à-pas quand des problèmes sont escaladés vers l'engineering. Ces messages peuvent être désactivés par la commande globale 'no service sequence-numbers'.

Steph

[ciscowarrior]

Steph,

service sequence-numbers est surtout utilisé pour vérifier que les logs n'ont pas été bidouillés( certains messages éffacés) car dans ce cas il y aurait des numéros de séquence manquants.
Et par défaut ce service n'est pas activé.

Alain

[Invité]

service sequence-numbers est surtout utilisé pour vérifier que les logs n'ont pas été bidouillés( certains messages éffacés) car dans ce cas il y aurait des numéros de séquence manquants.

Oui, tu as raison. De plus, ils permettront de savoir si des messages ont été droppés dans le réseau lorsqu'ils sont envoyés vers un serveur Syslog.
A fortiori, puisqu'on est certains de ne pas louper un message système en activant ce service, c'est très utile lorsqu'on collecte des debugs outputs dans le logfile (couplé bien sûr à service timestamps debug date local msec qui a parfois tendance à collecter plusieurs lignes de debug dans la même milliseconde).

Et par défaut ce service n'est pas activé.

Exact. Dans mon post j'avais donné la commande pour le désactiver parce qu'apparemment le Catalyst de hallbid implémentait ce service.

Steph

[boboss123]

bonjour,

Ce "sequence-number" m'interpelle : vu qu'il ne semble pas être défini par la norme, ça veut dire qu'on ne peut pas récupérer ce type de message sur un serveur syslog standard ?
Syslog est le protocole pour gestion de journalisation la plus rependue ? ... Ce protocole semble avoir pas mal de défauts (gestion des dates) : il y a mieux ?

EDIT :
Je viens de me rendre compte que le document est ancien. La norme Syslog a évoluée depuis (notamment au niveau de la date) :
http://tools.ietf.org/html/rfc5424#section-6.2.1
http://tools.ietf.org/html/rfc3164

[Invité]

Je n'ai pas constaté de problèmes sur les serveurs syslog tels que ceux de SolarWinds ou HPOV par exemple. Si le serveur syslog ne peut pas interpréter les sequence-numbers, je suppose qu'il les ignore simplement

Syslog est le protocole pour gestion de journalisation la plus rependue ?

Oui, c'est le standard.
Il doit certainement exister encore des approches propriétaires mais ça fait très longtemps que je n'en ai pas vues... Il faut aussi comprendre que c'est du client/serveur. Ce serait bcp de $$ à dépenser en R&D pour réinventer une roue qui tourne déjà pas mal

Steph

[boboss123]

Merci pour les infos.

Avec la dernière mise à jour de la RFC, le protocole syslog (en TCP) me semble complet car ses principaux défauts sont corrigés (dommage, l'article avait été rédigé juste avant la modification de la norme ) :
- Maintenant, il gère les séquences numbers : voir paramêtre sequenceId
- Maintenant, il gère les années et le temps au format UTC : voir paramêtre TIMESTAMP

[Throne55]

Bonjour,

Il semble qu'il existe une nouvelle version de la norme syslog qui corrige les failles citées dans votre article, qui est très bien fait au passage:

https://tools.ietf.org/html/rfc5424#section-6.2.3

Cordialement,