quest for the log analysis tool - les contraintes selon moi

je pense qu'il faut laisser les systèmes logger sous la forme la plus pratique pour le déployeur; typiquement un log par machine virtuelle. Le déployeur doit pouvoir déployer, hum. Donc il souhaite facilement pouvoir constater que ça marche ou que ça pête quand il déploit, et ce n'est *que* déployer => format clair, lisible avec vi/emacs/tail/more. Pas de XML, pas d'émission par socket à un récepteur central.

bon henri me presse pour aller au pôt de Carl, et Carl c'est quand même le plus rock star des surfers de la Rue Victoire. On est parti (expression de chez nous)

post-edit: autre argument sur la contrainte du format "standard" lisible sans lecteur particulier; on a besoin de transmettre un log par mail ! c'est la donnée de base autour de laquelle va collaborer une communauté très hétérogène, des pilotes, des admins système, des devers, des experts. Le principe du paquet de ligne timestampé facile à copier coller est donc adatpé. Des outils comme JDbcIndight répondent à ce besoin en imposant le principe de snapshot transportable et de la gui gratuite et facile d'accès. Sans tout résoudre ; l'un souhaite mettre le focus sur un point particulier et fait donc une capture graphique... sous forme bitmap, et c'est parti pour un échange de mail qui coutera qqs dizaines de Mo à votre messagerie interne.