Storeix : voir toute son infra en un seul endroit

Chez leboncoin, on gère une infrastructure distribuée de grande envergure. Des dizaines de microservices, des clusters Elasticsearch avec 127 nœuds, du Kafka managé sur MSK, des dizaines de bases RDS PostgreSQL, du Redis/Valkey, du Kubernetes…

Le problème quotidien : pour comprendre ce qui se passe sur un service, tu jonglais entre la console AWS, k9s, Kibana, Grafana, Datadog, et 3 CLI différentes. Chaque outil parle sa propre langue. Le contexte se perd entre chaque onglet.

J’ai construit Storeix pour ne plus jamais vivre ça.

Pourquoi “Storeix” ?

Le nom vient de “Storage” + le suffixe “-ix” (comme dans Unix, Linux…). Au départ le projet était centré sur les services de stockage que je gère : Elasticsearch, RDS, Redis, S3, Kafka. Puis le périmètre a grandi naturellement. Aujourd’hui c’est une platform interne complète.

Ce que Storeix couvre

L’idée centrale : un microservice n’est jamais isolé. Il tourne sur des pods Kubernetes, consomme une base RDS, publie sur des topics Kafka, lit depuis Redis, et génère des logs dans Elasticsearch. Storeix te permet de naviguer entre tout ça sans changer d’outil.

☁️ AWS

• Lister et inspecter toutes tes ressources EC2, RDS, ElastiCache, MSK (Kafka), S3, OpenSearch
• Explorer le réseau : VPC, subnets, security groups, transit gateways, route tables
• Auditer IAM : rôles, policies, trust policies
• Consulter les coûts en temps réel via Cost Explorer (FinOps)
• Chercher dans CloudTrail les événements d’audit

⎈ Kubernetes

• Voir tous tes pods, deployments, statefulsets, daemonsets par namespace
• Lire les logs d’un pod directement dans l’interface
• Ouvrir un terminal interactif dans un container (exec)
• Surveiller les métriques CPU/RAM via Thanos/Prometheus
• Inspecter les events K8s pour déboguer un crash

🗄️ Données & stockage

• Explorer une base RDS PostgreSQL : tables, index, requêtes actives, performances
• Parcourir les keys Redis d’un cluster ElastiCache
• Lister les topics Kafka, leurs offsets et partitions
• Naviguer dans les buckets S3

📋 Logs

• Recherche full-text dans Elasticsearch avec filtres temporels
• Vue logs par application ou par namespace Kubernetes
• Histogrammes de volume pour détecter les pics

🧩 Microservices

• Vue catalogue de tous les services découverts automatiquement depuis Elasticsearch
• Filtre par team (namespace K8s) et par vertical produit
• Depuis un service : accès direct à ses pods, ses logs, ses bases, son Redis, son Kafka

La puissance du “single pane of glass”

Voilà un workflow concret que Storeix rend trivial :

Scénario : alerte on-call, latence élevée sur le service search-api

1. Tu ouvres Storeix → Microservices → search-api
2. Tu vois ses pods K8s → un pod est en CrashLoopBackOff
3. Tu lis ses logs directement depuis l’interface
4. Tu vois qu’il essaie de se connecter à une RDS → tu cliques sur l’instance
5. Tu vérifies les métriques RDS : connections saturées
6. Tu regardes les requêtes actives depuis le Database Explorer intégré
7. Tu trouves une requête bloquante, tu kills la connexion

Tout ça sans changer d’outil. Sans perdre le contexte. En production, ça fait la différence entre un incident résolu en 5 minutes et un incident qui dure 1 heure.

Pourquoi Phoenix LiveView ?

J’aurais pu faire ça en React ou en Vue. Mais j’avais une contrainte forte : je voulais que l’UI soit réactive (logs en temps réel, métriques qui se rafraîchissent) sans avoir à gérer un backend API + un frontend séparés.

Phoenix LiveView résout exactement ça. Le serveur Elixir maintient une connexion WebSocket avec le navigateur. Les mises à jour sont envoyées en diff HTML — pas de JSON, pas de state management côté client.

Et Elixir/OTP gère les connexions concurrentes sans effort : chaque tab ouvert par chaque ingénieur est un processus léger supervisé par le runtime. Si une requête AWS timeout, ça ne bloque pas les autres.

Ce que j’ai appris

Construire Storeix m’a appris que la vraie valeur d’un outil interne n’est pas dans ses features. C’est dans les connexions qu’il crée entre les données.

Un pod K8s tout seul, c’est peu utile. Un pod K8s lié à sa base de données, ses logs, ses métriques et ses coûts — c’est la différence entre chercher et trouver.

Le projet continue d’évoluer. Prochaine étape : intégration avec Vault pour la gestion des secrets, et une vue réseau topologique pour visualiser les connexions entre services.