Après plus de dix ans de présence discrète sur LinuxFr.org, tout juste marquée de quelques commentaires, je me décide enfin à proposer une dépêche.
Je souhaite vous présenter la version 1.0 de Pyruse, que j’ai développé sous licence GPL v3 pour mon propre usage en auto‐hébergement, car je sais que se promènent ici d’autres auto‐hébergeurs qui pourront être intéressés.
The Log File Navigator, ou lnav en plus court, est un outil en ligne de commande pour afficher des journaux, sous licence BSD. Par rapport aux classiques cat, grep ou less, il propose quelques fonctionnalités supplémentaires :
Le projet Lumberjack est une initiative de plusieurs développeurs de système de logs pour améliorer l'enregistrement d'événements par le système. Il a débuté lors d'une conférence dans les bureaux de Red Hat en République Tchèque avec un entretien entre Steve Gibbs (auditd), Lennart Poettering (systemd, journald), Rainer Gerhards (rsyslog), William Heinbockel (CEE, Mitre) et plusieurs autres développeurs Red Hat.
Le but est de standardiser le contenu des logs et d'améliorer leur création par les applications qui les génèrent. Pour cela, les développeurs vont suivre les spécifications Common Event Expression (CEE). Sur leur site, on peut déjà trouver le schéma XML des logs, ainsi qu'un exemple en XML et un autre en JSON.
NdA : Merci à Nÿco, olvierweb et Neox pour leur aide lors de la rédaction de cette dépêche.
En conversant avec un correspondant américain, je voulais parler de la bûche de Noël. Comment dire ça en anglais ? Je regarde dans Linguee : Yule log. Jamais entendu cette expression étrange : Yule ne sonne pas très anglais et log, je ne connais que dans le vocabulaire informatique. Elle est où ma bûche ? Mais bon, c'est Linguee qui le dit. Ca me reste en tête. Le jour de Noël, je regarde un reportage sur la Norvège (…)
Tout bon administrateur a un jour dû chercher une info à coup de grep, tail, awk dans les fichiers de logs des équipements qu'il gère.
Or la recherche est toujours un peu fastidieuse, avec les questions qui reviennent : "Où est-ce qu'ils sont ces logs ?", "Et c'est quoi le format déjà ?", "Tu connais le mot de passe pour se connecter sur le routeur ?".
Si on peut mettre en place une récupération des logs de façon centralisée avec des outils connus comme syslog, le trio Logstash, ElasticSearch et Kibana est un très bon candidat pour gérer et trouver efficacement des informations dans les milliers de lignes de traces que peuvent générer les divers services.
Vous vous souvenez peut-être d'une loi parue en 2004 nommée loi pour la confiance dans l'économie numérique (LCEN). Pour ceux qui ne se rappellent pas de son contenu, le texte est accessible ici : http://www.legifrance.gouv.fr/affichTexteArticle.do?idArticle=LEGIARTI000022469889&cidTexte=JORFTEXT000000801164&dateTexte=20110301
Bien entendu, les décret d'applications correspondants ne sont pas tous parus en 2004. Il a même fallut attendre pas mal de temps avant de les voir arriver. Le dernier en date est tout récent : il a été publié ce matin. Vous pouvez l'admirer ici (…)
Lorsqu'on gère un parc de serveur qui comprend malheureusement des serveurs Windows, on souhaite centraliser leurs logs, voir même recevoir des alertes en fonction du contenu. C'est simple à faire sous Linux avec rsyslog, avec lequel je transmets les syslogs vers l'excellent Graylog2. Par contre dans le monde Windows il n'y a pas de serveur syslog natif. J'avais donc trouvé MonitorWare Agent un impressionnant logiciel propriétaire qui permet de définir des services qui vont lire n'importe quel type (…)
Le précédent article de votre humble serviteur, intitulé "utiliser android de façon plus sécurisée" (lien), fut riche en requêtes réseau jusqu'à plus soif.
Comme l'ouvrage originale fut linké autant dans la partie forum, que journal et dépêche de LinuxFR: on peut en profiter pour tenter de visualiser un échantillon éphémère des mouvements réseaux engendré par ces links.
Nous n'allons certes pas découvrir la réponse à la grande question, mais découvrir que de simple liens peuvent (…)
Le 30 mars, le cercle de travail (AK Vorrat) a déposé un recours constitutionnel contre la « sauvegarde provisionnelle des données », qu'on dénomme en français conservation des données, qui va être imposée pour toutes les télécommunications en Autriche. À partir du premier avril, toutes les données de communications mobiles ou fixes devront être stockées de manière préventive pour six mois en Autriche.
À titre de comparaison dans l'Union Européenne, en France, la rétention obligatoire des données a été introduite pour une durée de 12 mois obligatoire en 2006, avec N. Sarkozy ministre de l'Intérieur. Les cours constitutionnelles de Bulgarie, de Roumanie et d'Allemagne ont jugé que la législation sur la conservation des données était inconstitutionnelle, tandis que l'Irlande a déposé plainte contre la directive de 2006 devant la Cour européenne de justice.
Plus de détails sur les contextes autrichiens et allemands dans le billet original.
Cher journal,
Je voudrais te présenter le logiciel que je développe en ce moment, à savoir fuse_kafka.
Il s'agit d'un agent de logging: il a pour but de permettre la centralisation de logs hétérogènes.
Il se fonde sur FUSE pour récupérer les écritures dans des fichiers dans des répertoires surveillés
et envoyer ces dernières dans la file de message kafka, dans un format fondé sur celui du système de gestion de log logstash.
Voici une session terminal ( (…)
Bonjour cher 'nal,
Comme toi, j'aime systemd, j'aime les jounaux binaires, j'aime la manière facile d'interroger le journal binaire, et j'aime que la machine travaille pour moi.
Faire des regex, c'est long, pas lisible, et chiant. La machine peut faire ça pour moi.
Chercher un symbole avec less, c'est pas pratique quand y'a des doublons.
grep n'est pas pratique sur un grand fichier, et multiplier les fichiers journaux c'est franchement pas génial pour avoir une organisation de ces fichiers bien (…)
PyLogsParser est un module Python qui facilite l'analyse des logs provenant de diverses sources.
Les logs sont dans des formats très divers. PyLogsParser simplifie cette analyse en implémentant un moteur puissant d'analyse de logs.
La version 0.1 apporte le support des formats de log suivants:
Pour ajouter des nouveaux formats, il suffit d'ajouter un fichier XML de description.
Le but du projet est de faciliter et de promouvoir l'utilisation des (…)
(C'est vendredi, mais ça n'en fait pas une obligation de troller.)
Si comme moi vous avez à gérer plusieurs serveurs Linux, si vous avez fait de la virtualisation ou si vous utilisez LTSP, vous vous retrouvez avec pleins de machines qui produisent chacune leurs logs. La gestion par fichiers dans /var/log arrive rapidement à ses limites.
Heureusement, les systèmes syslog modernes permettent facilement de centraliser les logs sur une machine et de les placer dans une base de données. La (…)
principalement en utilisant le log postfix au format par defaut au jour de publication de ce script
#!/bin/sh
#
# small script that search mail address within from or to
# and show the whole transaction log by email ID
case $# in
3)
count=0
sens=$1
motif=$2
file=$3
case $sens in
from)
search='from=<'$motif
;;
to)
search='to=<'$motif
;;
esac
for i in $(grep Bonjour,
Je cherche un outil capable d'analyser mes logs (si possible en temps réel), de filtrer le "bruit" et de remonter les éléments de type "alerte" ou "inconnus" et KISS-compliant
J'utilise actuellement logcheck, il remplit bien son rôle, mais la modification, l'ajout et la maintenance des règles (basées sur des regexp) est particulièrement pénible et chronophage.
J'ai regardé du coté logstash. C'est sympa, c'est joli, pratique pour recherches des infos dans les logs, mais à priori, ça ne (…)