Il faut juste une structure XML/JSON qui accepte
- Les blobs binaires (pas trop dur, c'est pas si compliqué que ça à échapper/convertir en ascii)
- des erreurs avec des morceaux de XML/JSON dedans (Une fois de plus on peut toujours échapper, à moins que le caractère d'échapemment ne soit lui aussi dans l'erreur auquel cas on le double échappe à moins que le double échappement ne soit aussi dans ….)
- des trames réseaux brutes (cf blobs binaires) qui soient analysables par un outil genre tcpdump (ben on a qu'à convertir les logs à la volée si c'est accédé via une certaine option du parser) et rejouables (gna gna gna) en mode parallèle (tee et cat tu connais ?) en spoofant/modifiant un paramètre (tu prend ton log, tu le parse comme tu veux, tu rediriges le résultat vers un fichier que tu appelles vieux_format.log et tu fais pas chier !)
- Un système qui dise que le message précédent a été répété 27 fois (ça ça devrait passer)
Ensuite je veux un parseur qui puisse parser tout ça en traitant les éléments par ordre chronologique réel système y compris quand l'horloge corrige un drift NTP de 40 minutes juste avant le passage à l'heure d'été mais après que le système ait corrigé la date bios en date UTC.
Bien entendu il faut que le parseur soit linké statiquement et utilisable en mode mono utilisateur pour l'analyse après panne, sans pour autant occuper trop de mémoire (si ça se trouve c'est une barrette qui déconne qui est à l'origine de la panne).
Je plaisante bien sur, même si vous me donnez tout ça je vais rester sur mes vieux outils, mais si vous passez sous ce système un jour je veux bien que vous me racontiez comment vous analysez les logs d'une authentification SIP qui foire au niveau de la gateway pour cause de SSO/Kerberos/SASL qui déconne.
# C'est une bonne idée ça de structurer les logs
Posté par Kaane . En réponse à la dépêche Projet Lumberjack. Évalué à 3.
Il faut juste une structure XML/JSON qui accepte
- Les blobs binaires (pas trop dur, c'est pas si compliqué que ça à échapper/convertir en ascii)
- des erreurs avec des morceaux de XML/JSON dedans (Une fois de plus on peut toujours échapper, à moins que le caractère d'échapemment ne soit lui aussi dans l'erreur auquel cas on le double échappe à moins que le double échappement ne soit aussi dans ….)
- des trames réseaux brutes (cf blobs binaires) qui soient analysables par un outil genre tcpdump (ben on a qu'à convertir les logs à la volée si c'est accédé via une certaine option du parser) et rejouables (gna gna gna) en mode parallèle (tee et cat tu connais ?) en spoofant/modifiant un paramètre (tu prend ton log, tu le parse comme tu veux, tu rediriges le résultat vers un fichier que tu appelles vieux_format.log et tu fais pas chier !)
- Un système qui dise que le message précédent a été répété 27 fois (ça ça devrait passer)
Ensuite je veux un parseur qui puisse parser tout ça en traitant les éléments par ordre chronologique réel système y compris quand l'horloge corrige un drift NTP de 40 minutes juste avant le passage à l'heure d'été mais après que le système ait corrigé la date bios en date UTC.
Bien entendu il faut que le parseur soit linké statiquement et utilisable en mode mono utilisateur pour l'analyse après panne, sans pour autant occuper trop de mémoire (si ça se trouve c'est une barrette qui déconne qui est à l'origine de la panne).
Je plaisante bien sur, même si vous me donnez tout ça je vais rester sur mes vieux outils, mais si vous passez sous ce système un jour je veux bien que vous me racontiez comment vous analysez les logs d'une authentification SIP qui foire au niveau de la gateway pour cause de SSO/Kerberos/SASL qui déconne.