Le fait que le format des messages soit tout à fait libre et sans conventions rend le parsing impossible.
Ça n'a aucune importance: chaque log doit être analysé selon l'application qui l'a généré. Quelque soit le système que tu utilises, tu ne peux pas utiliser le même outil pour analyser les logs de SUDO, de ton serveur MAIL, de ton serveur HTPP, SMTP, ou FTP, tout simplement parceque ce sont des applications complètement différentes. Le fait de créer un format commun pour les parser n'a pas de gros intérêt parceque de toutes façons l'analyse des contenus doit dépendre de l'application. L'idéal serait que chaque application écrivant des LOGs fournissent aussi un parser pour ses logs. En l'absence de tel parser on survit bien en utilisant les outils UNIX habituels. Utiliser un format structuré complexe nécessiterait donc d'avoir des équivalents de SED, AWK, PERL, SORT, CUT, PASTE, JOIN etc., etc. capables de travailler directement sur ce format, sinon on se retrouve avec une perte de fonctionnalité et une plus grande complexité à l'analyse des fichiers: avantage 0, inconvénients ÉNORMES.
La lecture des fichiers log est totalement inefficace, il est impossible d'accéder rapidement au 100e message par exemple, ou d'avoir les messages à un moment donné.
C'est complètement impertinent. Ce qui t'intéresse quand tu lis des logs c'est de lire tous les LOGS et de les filtrer selon certains critères (GREP ou AWK) comme la date, le programme, le client, etc., pour extraire l'information souhaitée. Le numéro de ligne est un atefact qui ne sert à rien.
Les logs prennent vraiment énormément de place. Un petit problème dans postfix (genre un relai défaillant) et on se retrouve vite avec un fichier log de 1GO juste avec les essais ratés de transmission.
Le bonne solution à ce problème est d'embaucher un vrai admin système.
La solution existante (SYSLOG) est bien dans l'esprit de UNIX: un système ultra simple que tu peux étendre comme tu veux. Par exemple, tu peux déporter les logs sur un PIPE nommé pour les faire traiter par le programme que tu veux et qui peux te remplir toutes les tables SQL que tu veux.
On peut, par configuration et avec l'aide de logrotate, forcer une rotation quand un fichier dépasse une certaine taille.
Sur FreeBSD avec syslogd, on peut, par configuration et avec l'aide de logrotate forcer une rotation quand un fichier dépasse une certaines taille.
Par ailleurs, je ne comprends pas non plus pourquoi il développe ça dans le cadre de systemd, plutôt que de faire un projet séparé. Pour minimiser la maintenance peut-être ?
À mon avis c'est plutôt parcequ'il ne comprend rien à UNIX.
[^] # Re: Problèmes de Syslog
Posté par Michaël (site web personnel) . En réponse au journal Lennart casse les logs!. Évalué à 9.
Ça n'a aucune importance: chaque log doit être analysé selon l'application qui l'a généré. Quelque soit le système que tu utilises, tu ne peux pas utiliser le même outil pour analyser les logs de SUDO, de ton serveur MAIL, de ton serveur HTPP, SMTP, ou FTP, tout simplement parceque ce sont des applications complètement différentes. Le fait de créer un format commun pour les parser n'a pas de gros intérêt parceque de toutes façons l'analyse des contenus doit dépendre de l'application. L'idéal serait que chaque application écrivant des LOGs fournissent aussi un parser pour ses logs. En l'absence de tel parser on survit bien en utilisant les outils UNIX habituels. Utiliser un format structuré complexe nécessiterait donc d'avoir des équivalents de SED, AWK, PERL, SORT, CUT, PASTE, JOIN etc., etc. capables de travailler directement sur ce format, sinon on se retrouve avec une perte de fonctionnalité et une plus grande complexité à l'analyse des fichiers: avantage 0, inconvénients ÉNORMES.
C'est complètement impertinent. Ce qui t'intéresse quand tu lis des logs c'est de lire tous les LOGS et de les filtrer selon certains critères (GREP ou AWK) comme la date, le programme, le client, etc., pour extraire l'information souhaitée. Le numéro de ligne est un atefact qui ne sert à rien.
Le bonne solution à ce problème est d'embaucher un vrai admin système.
La solution existante (SYSLOG) est bien dans l'esprit de UNIX: un système ultra simple que tu peux étendre comme tu veux. Par exemple, tu peux déporter les logs sur un PIPE nommé pour les faire traiter par le programme que tu veux et qui peux te remplir toutes les tables SQL que tu veux.
Sur FreeBSD avec syslogd, on peut, par configuration et avec l'aide de logrotate forcer une rotation quand un fichier dépasse une certaines taille.
À mon avis c'est plutôt parcequ'il ne comprend rien à UNIX.