Vue lecture

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.

Sisu - Quand votre AWS devient un simple dossier sur votre disque

Vous passez vos journées à faire des aws iam list-users | jq '.Users[]' et autres trucs interminables pour juste trouver une info ?? Laissez tomber, j'ai le truc qui va vous changer la vie !

Ça s'appelle Sisu et c'est un petit outil en Go qui monte vos ressources AWS comme un système de fichiers local. Du coup, au lieu de taper des commandes AWS complexes, vous utilisez juste grep, cat, diff, vim... c'est à dire les outils Unix que vous connaissez déjà par cœur.

Vous lancez la commande sisu et hop, vos ressources AWS se retrouvent montées dans ~/.sisu/mnt/ ! Vos buckets S3, vos paramètres SSM, vos roles IAM, vos lambdas, vos instances EC2...etc. Tout ça organisé en dossiers par profil AWS et par région.

Ainsi, pour chercher tous vos utilisateurs IAM qui ont un accès admin, c'est aussi simple que :

grep -l "AdministratorAccess" */global/iam/users/*/policies.json

Pour comparer la config d'un rôle entre prod et staging :

diff prod/global/iam/roles/api/info.json staging/global/iam/roles/api/info.json

Et pour lire un secret ? Un simple cat default/us-east-1/secrets/myapp/database/value.

C'est bête comme Jordan mais ça change tout pour la maintenance au quotidien !

Et côté services supportés, Sisu gère pas mal de trucs tels que le S3 et SSM Parameter Store en lecture/écriture/suppression, et IAM, VPC, Lambda, EC2, Secrets Manager, Route 53 et CloudWatch Logs en lecture seule. Y'a même un truc sympa pour EC2 c'est que vous pouvez vous connecter à une instance via SSM Session Manager sans avoir besoin de clés SSH. Suffit d'exécuter le fichier connect qui se trouve dans le dossier de l'instance (à condition d'avoir l'agent SSM configuré sur l'instance et le plugin Session Manager côté client, évidemment).

Pour les logs CloudWatch, c'est bien aussi puisqu'ils sont streamés à la demande par batches de 100, donc vous pouvez faire un grep dessus sans tout charger en mémoire d'un coup.

Côté installation, c'est du Go classique :

go install github.com/semonte/sisu@latest

Faudra juste penser à installer FUSE avant sur votre système (apt install fuse sous Ubuntu/Debian, yum install fuse sous RHEL/CentOS) et c'est tout, y'a rien d'autre à configurer si vous avez déjà vos credentials AWS en place.

Après, l'outil cache les résultats pendant 5 minutes pour éviter de spammer l'API AWS à chaque ls, ce qui est plutôt indispensable pour limiter les appels et le temps de réponse.

Bref, si vous en avez marre de jongler avec jq pour parser du JSON AWS, Sisu va vous aider ! C'est open source sous licence MIT, et c'est par ici !

Cordon - L'outil qui trouve les aiguilles dans vos meules de logs

Vous avez déjà passé des heures à éplucher des fichiers de logs de plusieurs millions de lignes pour trouver ce qui cloche ? Genre une pauvre erreur bizarre qui se produit une fois sur 100 000, noyée dans un océan de messages répétitifs et d'infos inutiles ? Moi, oui plein de fois !

Mais ça c'était avant de tomber sur Cordon !

Cordon est un outil en Python qui utilise des modèles de transformers et du scoring k-NN pour détecter les anomalies sémantiques dans vos logs. En gros, au lieu de chercher des mots-clés comme un bourrin avec grep, Cordon comprend le sens des messages et repère ce qui sort de l'ordinaire.

Les patterns répétitifs sont alors considérés comme du bruit de fond normal, même si ce sont des erreurs parce que si vous avez la même erreur FATALE qui se répète 10 000 fois, c'est probablement un problème connu. Et vous, ce que vous voulez trouver, c'est l'événement rare, celui qui se produit une seule fois et qui est sémantiquement différent du reste.

L'installation est simple comme bonjour. Un petit pip install cordon et c'est réglé. Pour l'utilisation de base, vous balancez juste votre fichier de logs en argument :

cordon system.log

Et hop, Cordon va analyser tout ça et vous sortir uniquement les trucs intéressants. Par défaut, il garde les 10% les plus "anormaux" sémantiquement. Vous pouvez ajuster ce pourcentage avec --anomaly-percentile 0.05 pour être plus sélectif (top 5%).

Sous le capot, ça utilise le modèle all-MiniLM-L6-v2 de sentence-transformers pour vectoriser les logs. Le fichier est découpé en fenêtres de N lignes (4 par défaut), chaque fenêtre est transformée en vecteur, puis un score de densité k-NN est calculé. Les fenêtres qui ont des vecteurs très différents du reste sont marquées comme anomalies.

Et si vous avez un GPU, Cordon peut l'utiliser automatiquement avec l'option --device cuda. D'après les benchmarks, ça donne un speedup de 5 à 15x sur le scoring pour les gros datasets. Sur des logs HDFS de 1 à 5 millions de lignes, l'outil arrive à réduire le volume de 98%. Autant dire que ça filtre sévère.

Y'a aussi un mode "range" qui est pratique pour explorer par tranches. Genre si vous voulez exclure le top 5% (trop bizarre, probablement du garbage) mais garder le top 5-15%, vous faites :

cordon --anomaly-range 0.05 0.15 app.log

Ça permet d'affiner l'investigation de manière itérative.

Pour les environnements conteneurisés, Cordon propose également une image Docker avec un backend llama.cpp au lieu de sentence-transformers. Pratique si vous voulez utiliser des modèles GGUF ou si vous êtes dans un contexte où les dépendances PyTorch posent problème.

L'outil peut aussi s'utiliser comme bibliothèque Python si vous voulez l'intégrer dans vos propres scripts :

analyzer = SemanticLogAnalyzer()
output = analyzer.analyze_file(Path("system.log"))

C'est top moumoute pour le prétraitement de logs avant de les balancer à un LLM (pour réduire le contexte), le triage initial de fichiers de logs inconnus, ou la découverte de patterns inattendus. Par contre, si vous cherchez une erreur spécifique que vous connaissez déjà, grep reste votre ami. Et si vous avez besoin d'un historique complet pour la conformité, oubliez Cordon qui est volontairement "lossy".

Notez qu'au premier lancement, Cordon téléchargera le modèle d'embedding (environ 80 Mo) donc ce sera un peu lent, mais ensuite, ça sera quasi instantané car les lancements suivants utiliseront le cache. Et si vos logs sont très verbeux avec de longues lignes, le modèle par défaut (256 tokens max) risque de tronquer les lignes, dans ce cas, passez à un modèle plus costaud comme BAAI/bge-base-en-v1.5 qui supporte 512 tokens avec le paramètre --model-name.

Voilà, j'espère que ça vous sera utile ! C'est open source sous licence Apache 2.0 et ça se trouve sur GitHub .

❌