From 18ed6e338abed7570980ea4565175dce0089b677 Mon Sep 17 00:00:00 2001 From: LeCoffre Deployment Date: Mon, 22 Sep 2025 11:21:39 +0000 Subject: [PATCH] align for IA agents + grafana --- IA_agents/CHANGELOG-2025-01-22.md | 155 --------- IA_agents/REX_Deploiement_2025-09-21.md | 222 ------------ IA_agents/deploy.md | 369 -------------------- IA_agents/diagnostic-loki-unhealthy.md | 207 ------------ IA_agents/loki-configuration-guide.md | 243 -------------- IA_agents/loki-health-starting-analysis.md | 174 ---------- IA_agents/loki-problem-resolution.md | 224 ------------- IA_agents/monitoring-progress.md | 319 ------------------ IA_agents/quick-reference-monitoring.md | 261 --------------- IA_agents/scripts-advanced.md | 304 ----------------- IA_agents/todo.md | 9 - IA_agents/troubleshooting-monitoring.md | 372 --------------------- 12 files changed, 2859 deletions(-) delete mode 100644 IA_agents/CHANGELOG-2025-01-22.md delete mode 100644 IA_agents/REX_Deploiement_2025-09-21.md delete mode 100644 IA_agents/deploy.md delete mode 100644 IA_agents/diagnostic-loki-unhealthy.md delete mode 100644 IA_agents/loki-configuration-guide.md delete mode 100644 IA_agents/loki-health-starting-analysis.md delete mode 100644 IA_agents/loki-problem-resolution.md delete mode 100644 IA_agents/monitoring-progress.md delete mode 100644 IA_agents/quick-reference-monitoring.md delete mode 100644 IA_agents/scripts-advanced.md delete mode 100644 IA_agents/troubleshooting-monitoring.md diff --git a/IA_agents/CHANGELOG-2025-01-22.md b/IA_agents/CHANGELOG-2025-01-22.md deleted file mode 100644 index 29ee5f1..0000000 --- a/IA_agents/CHANGELOG-2025-01-22.md +++ /dev/null @@ -1,155 +0,0 @@ -# Changelog - LeCoffre Node Scripts AvancĂ©s -**Date : 22 Janvier 2025** - -## 🚀 Nouvelles FonctionnalitĂ©s - -### Scripts Principaux -- ✅ **`start.sh`** - DĂ©marrage sĂ©quentiel intelligent avec progression dĂ©taillĂ©e -- ✅ **`validate-deployment.sh`** - Validation complĂšte du dĂ©ploiement -- ✅ **`maintenance.sh`** - Menu interactif de maintenance - -### Protection des DonnĂ©es -- ✅ **`backup-data.sh`** - Sauvegarde automatique des volumes Docker -- ✅ **`restore-data.sh`** - Restauration depuis sauvegarde -- ✅ **`update-images.sh`** - Mise Ă  jour sĂ©curisĂ©e avec sauvegarde - -### Monitoring et Logs -- ✅ **`collect-logs.sh`** - Collecte organisĂ©e des logs -- ✅ **`test-monitoring.sh`** - Tests des services de monitoring -- ✅ **`test-dashboards.sh`** - Validation des dashboards Grafana - -## 🔧 AmĂ©liorations - -### Scripts Existants -- ✅ **`deploy-master.sh`** - IntĂ©gration du nouveau systĂšme de dĂ©marrage -- ✅ **`collect-logs.sh`** - Liste complĂšte des services avec mapping correct -- ✅ **`build-project.sh`** - Documentation des projets supportĂ©s - -### Docker Compose -- ✅ **Volumes persistants** - Ajout des volumes pour SDK Signer et SDK Storage -- ✅ **Healthchecks amĂ©liorĂ©s** - Scripts de progression intĂ©grĂ©s -- ✅ **Dockerfile.master** - Ajout des outils nĂ©cessaires (procps, ncurses) - -## 📊 FonctionnalitĂ©s de Progression - -### Affichage en Temps RĂ©el -- ✅ **Tor Bootstrap** - Progression 0-100% avec Ă©tapes -- ✅ **Bitcoin IBD** - Blocs synchronisĂ©s et pourcentage de vĂ©rification -- ✅ **BlindBit Oracle** - Scan des blocs et tweaks dĂ©tectĂ©s -- ✅ **SDK Relay** - Synchronisation et connexions WebSocket -- ✅ **SDK Signer** - État de connexion et clĂ©s disponibles -- ✅ **URLs publiques** - AccessibilitĂ© HTTPS/WebSocket - -### Validation ComplĂšte -- ✅ **Volumes Docker** - VĂ©rification de la persistance des donnĂ©es -- ✅ **Services** - Statut et healthchecks -- ✅ **URLs publiques** - Tests de connectivitĂ© -- ✅ **WebSockets** - Tests de connexion -- ✅ **Scripts** - DisponibilitĂ© et permissions - -## đŸ›Ąïž SĂ©curitĂ© et FiabilitĂ© - -### Sauvegarde Automatique -- ✅ **Volumes critiques** - Bitcoin, BlindBit, SDK Storage, SDK Signer -- ✅ **Archives compressĂ©es** - Avec timestamps et gestion des permissions -- ✅ **Mise Ă  jour sĂ©curisĂ©e** - Sauvegarde automatique avant mise Ă  jour - -### Gestion des Erreurs -- ✅ **Timeouts adaptatifs** - Pour les processus longs (Tor, Bitcoin) -- ✅ **Gestion des permissions** - Copie et archivage sĂ©curisĂ©s -- ✅ **Validation prĂ©alable** - VĂ©rifications avant opĂ©rations critiques - -## 📁 Structure des Volumes - -### Volumes Persistants -- ✅ **`4nk_node_bitcoin_data`** - DonnĂ©es Bitcoin Signet -- ✅ **`4nk_node_blindbit_data`** - DonnĂ©es BlindBit Oracle -- ✅ **`4nk_node_sdk_data`** - DonnĂ©es SDK Relay -- ✅ **`4nk_node_sdk_signer_data`** - DonnĂ©es SDK Signer -- ✅ **`4nk_node_sdk_storage_data`** - DonnĂ©es SDK Storage -- ✅ **`4nk_node_grafana_data`** - DonnĂ©es Grafana -- ✅ **`4nk_node_loki_data`** - DonnĂ©es Loki - -## 🔄 Workflows OptimisĂ©s - -### DĂ©ploiement Initial -```bash -./scripts/start.sh # DĂ©marrage avec progression -./scripts/validate-deployment.sh # Validation complĂšte -./scripts/test-monitoring.sh # Tests de monitoring -``` - -### Maintenance RĂ©guliĂšre -```bash -./scripts/maintenance.sh # Menu interactif -./scripts/backup-data.sh # Sauvegarde manuelle -./scripts/collect-logs.sh # Collecte des logs -``` - -### Mise Ă  Jour -```bash -./scripts/update-images.sh # Mise Ă  jour sĂ©curisĂ©e -./scripts/validate-deployment.sh # Validation post-mise Ă  jour -``` - -### RĂ©cupĂ©ration d'Urgence -```bash -docker compose down # ArrĂȘt des services -./scripts/restore-data.sh # Restauration -./scripts/start.sh # RedĂ©marrage -``` - -## 📚 Documentation - -### Nouveaux Documents -- ✅ **`scripts/README.md`** - Documentation complĂšte des scripts -- ✅ **`scripts-advanced.md`** - Guide dĂ©taillĂ© des scripts avancĂ©s -- ✅ **`CHANGELOG-2025-01-22.md`** - Ce changelog - -### Documents Mis Ă  Jour -- ✅ **`deploy.md`** - Nouvelles procĂ©dures et scripts -- ✅ **`context.md`** - Scripts de gestion avancĂ©s -- ✅ **`flux.md`** - Tableau des scripts de gestion -- ✅ **`README.md`** - Obligations et interdictions mises Ă  jour - -## 🎯 Objectifs Atteints - -### Progression Visible -- ✅ **Affichage en temps rĂ©el** - Progression dĂ©taillĂ©e de tous les services -- ✅ **Timeouts adaptatifs** - Gestion des processus longs (Tor 15min, Bitcoin 2h) -- ✅ **Healthchecks intĂ©grĂ©s** - Messages de progression dans les healthchecks - -### Protection des DonnĂ©es -- ✅ **Persistance garantie** - Volumes Docker pour tous les services critiques -- ✅ **Sauvegarde automatique** - Avant toute mise Ă  jour ou modification -- ✅ **Restauration simple** - Processus de rĂ©cupĂ©ration documentĂ© - -### Maintenance SimplifiĂ©e -- ✅ **Menu interactif** - Toutes les tĂąches de maintenance centralisĂ©es -- ✅ **Validation complĂšte** - VĂ©rification de tous les aspects du dĂ©ploiement -- ✅ **Documentation exhaustive** - Guides complets pour tous les scripts - -## 🔼 Prochaines Étapes - -### Tests et Validation -- [ ] Tests complets du systĂšme de sauvegarde/restauration -- [ ] Validation des workflows de mise Ă  jour -- [ ] Tests de rĂ©cupĂ©ration d'urgence - -### Optimisations -- [ ] AmĂ©lioration des timeouts basĂ©e sur les retours d'expĂ©rience -- [ ] Optimisation des scripts de collecte de logs -- [ ] AmĂ©lioration des messages de progression - -### Documentation -- [ ] Mise Ă  jour des guides utilisateur -- [ ] Documentation des cas d'usage avancĂ©s -- [ ] Formation des Ă©quipes sur les nouveaux scripts - -## 📞 Support - -Pour toute question ou problĂšme avec les nouveaux scripts : -1. Consulter la documentation dans `scripts/README.md` -2. Utiliser `./scripts/validate-deployment.sh` pour diagnostiquer -3. Utiliser `./scripts/maintenance.sh` pour les tĂąches de maintenance -4. Consulter les logs avec `./scripts/collect-logs.sh` diff --git a/IA_agents/REX_Deploiement_2025-09-21.md b/IA_agents/REX_Deploiement_2025-09-21.md deleted file mode 100644 index 9f16001..0000000 --- a/IA_agents/REX_Deploiement_2025-09-21.md +++ /dev/null @@ -1,222 +0,0 @@ -# Retour d'ExpĂ©rience - DĂ©ploiement LeCoffre Node 2025-09-21 - -## 📋 RĂ©sumĂ© du DĂ©ploiement - -**Date** : 21 septembre 2025 -**Agent IA** : Claude Sonnet 4 -**Objectif** : DĂ©ploiement complet de l'architecture LeCoffre Node -**Statut** : ✅ SuccĂšs partiel - Services de monitoring opĂ©rationnels, Bitcoin en cours de synchronisation - -## 🎯 Objectifs Atteints - -### ✅ Phase 1: VĂ©rifications Initiales -- [x] VĂ©rification dĂ©pĂŽt distant (git.4nkweb.com) -- [x] VĂ©rification clĂ©s SSH pour dĂ©ploiement Git -- [x] VĂ©rification branche `ext` active sur tous les projets -- [x] Mise Ă  jour dĂ©pendances et langages -- [x] VĂ©rification variables d'environnement centralisĂ©es dans `.env.master` - -### ✅ Phase 2: Construction et Optimisation -- [x] Suppression caches et optimisation builds -- [x] Mise Ă  jour documentation -- [x] Mise Ă  jour tests -- [x] Mise Ă  jour scripts -- [x] VĂ©rification fichiers .gitignore, .dockerignore, .cursorignore - -### ✅ Phase 3: Synchronisation -- [x] Synchronisation configurations dans `lecoffre_node/conf` -- [x] Synchronisation logs dans `lecoffre_node/logs` -- [x] Configuration Grafana pour dashboard par projet - -### ✅ Phase 4: SĂ©curitĂ© et ConformitĂ© -- [x] VĂ©rification absence donnĂ©es personnelles/sensibles -- [x] VĂ©rification absence failles de sĂ©curitĂ© -- [x] Validation fichiers sensibles ignorĂ©s par Git - -### ✅ Phase 5: Gestion Git -- [x] Push modifications sur branche Git `ext` -- [x] Suppression fichiers distants non suivis par Git - -### ✅ Phase 6: Tests et Corrections -- [x] Analyse logs -- [x] Corrections erreurs -- [x] Tests configuration Docker Compose -- [x] VĂ©rification logs sans donnĂ©es sensibles - -### ✅ Phase 7: DĂ©ploiement Services -- [x] Lancement services avec `docker compose --env-file .env.master` -- [x] Utilisation systĂšme monitoring et progression -- [x] DĂ©marrage ordonnĂ© avec suivi progression -- [x] Surveillance progression services critiques - -### ✅ Phase 8: Monitoring et Validation -- [x] Grafana opĂ©rationnel -- [x] Configuration Nginx synchronisĂ©e -- [x] Loki, Promtail et Grafana OK avec dashboards -- [x] VĂ©rification absence conflits de ports -- [x] Tests URLs publiques depuis l'extĂ©rieur - -## 🚀 Services OpĂ©rationnels - -### ✅ Services DĂ©ployĂ©s et Fonctionnels -| Service | Statut | URL Externe | URL Locale | Description | -|---------|--------|-------------|------------|-------------| -| **Grafana** | ✅ Ready | https://dev4.4nkweb.com/grafana/ | http://localhost:3005 | Dashboard monitoring | -| **Status API** | ✅ Ready | https://dev4.4nkweb.com/status/api | http://localhost:3006 | API statut services | -| **SDK Storage** | ✅ Ready | - | http://localhost:8081 | Stockage temporaire | -| **SDK Signer** | ✅ Ready | https://dev4.4nkweb.com/signer/ | http://localhost:3001 | Service signature | - -### ⏳ Services en Cours de DĂ©marrage -| Service | Statut | Progression | Description | -|---------|--------|-------------|-------------| -| **Tor Proxy** | ⚠ Starting | 100% (Done) | Proxy anonyme - Healthcheck timeout | -| **Bitcoin Signet** | ⚠ IBD | 32% (44171/136549 blocs) | NƓud Bitcoin - Synchronisation | -| **Loki** | ⏳ Starting | - | Base de donnĂ©es logs | -| **Promtail** | ⏳ Starting | - | Agent collecte logs | - -### ❌ Services en Attente -| Service | DĂ©pendance | Raison | -|---------|------------|--------| -| **BlindBit Oracle** | Bitcoin healthy | Attente synchronisation Bitcoin | -| **SDK Relay** | Bitcoin healthy | Attente synchronisation Bitcoin | -| **IHM Client** | Bitcoin healthy | Attente synchronisation Bitcoin | -| **LeCoffre Backend** | Bitcoin healthy | Attente synchronisation Bitcoin | -| **LeCoffre Frontend** | Bitcoin healthy | Attente synchronisation Bitcoin | - -## 🔧 Outils de Monitoring UtilisĂ©s - -### ✅ Scripts de Monitoring OpĂ©rationnels -- `./scripts/monitor-progress.sh` : Aperçu complet services -- `./scripts/watch-progress.sh` : Surveillance temps rĂ©el -- `./scripts/logs-with-progress.sh` : Logs avec progression -- `./scripts/start-with-progress.sh` : DĂ©marrage ordonnĂ© - -### ✅ Healthchecks Informatifs -- **Bitcoin** : `Bitcoin IBD: 44171/136549 blocks (92378 remaining) - 32%` -- **SDK Storage** : `SDK Storage ready: API responding` -- **SDK Signer** : `SDK Signer ready: WebSocket server responding` -- **Grafana** : `Grafana ready: Dashboard service responding` - -## 🎯 Tests Fonctionnels ValidĂ©s - -### ✅ Tests Techniques RĂ©ussis -1. **Page de statut** : https://dev4.4nkweb.com/status/ ✅ (200) -2. **API de statut** : https://dev4.4nkweb.com/status/api ✅ (200) -3. **Dashboard Grafana** : https://dev4.4nkweb.com/grafana/ ✅ (302) -4. **SDK Signer** : https://dev4.4nkweb.com/signer/ ✅ (426 - WebSocket) -5. **Services HTTP(S)** : Tous les services disponibles ✅ - -### ⏳ Tests en Attente (Bitcoin synchronisĂ©) -1. **Login notaire** : Redirection IdNot et validation iframe -2. **Connexion Stripe** : VĂ©rification compte Stripe -3. **CrĂ©ation dossier** : Ajout client par notaire -4. **Email Mailchimp** : Envoi lien par email -5. **Login client** : Connexion avec lien email et code SMS -6. **AccĂšs dossier** : AccĂšs client au dossier - -## 🔍 ProblĂšmes IdentifiĂ©s et Solutions - -### ⚠ ProblĂšme 1: Healthcheck Tor Timeout -**SymptĂŽme** : Tor dĂ©marre correctement mais healthcheck timeout -**Cause** : Healthcheck mal configurĂ© pour le bootstrap Tor -**Solution** : VĂ©rifier configuration healthcheck Tor -**Impact** : Non bloquant - Tor fonctionne malgrĂ© le timeout - -### ⚠ ProblĂšme 2: Bitcoin IBD Lent -**SymptĂŽme** : Bitcoin synchronise lentement (32% en 10 minutes) -**Cause** : TĂ©lĂ©chargement blockchain signet depuis zĂ©ro -**Solution** : Attendre ou utiliser snapshot existant -**Impact** : Bloque dĂ©marrage services dĂ©pendants - -### ✅ Solution 1: Variables d'Environnement CentralisĂ©es -**ImplĂ©mentation** : Fichier `.env.master` centralisĂ© -**Avantage** : Configuration unique, dĂ©ploiement simplifiĂ© -**Command** : `docker compose --env-file .env.master up` - -### ✅ Solution 2: SystĂšme de Monitoring AvancĂ© -**ImplĂ©mentation** : Scripts de progression et healthchecks informatifs -**Avantage** : Suivi temps rĂ©el, diagnostic facilitĂ© -**Utilisation** : `./scripts/monitor-progress.sh` - -## 📊 MĂ©triques de Performance - -### 🚀 Temps de DĂ©ploiement -- **Phase 1-6** : 15 minutes (vĂ©rifications, configs, tests) -- **Phase 7-8** : 10 minutes (dĂ©ploiement services) -- **Total** : 25 minutes jusqu'aux services de monitoring - -### 📈 Progression Bitcoin IBD -- **DĂ©marrage** : 0% (0 blocs) -- **AprĂšs 10 min** : 32% (44171/136549 blocs) -- **Estimation complĂšte** : 30-45 minutes supplĂ©mentaires - -### 🎯 Services par Minute -- **Services dĂ©marrĂ©s** : 4 services fonctionnels -- **Taux de succĂšs** : 100% pour services indĂ©pendants -- **Services en attente** : 5 services (dĂ©pendance Bitcoin) - -## 🔄 Prochaines Étapes - -### 🎯 Actions ImmĂ©diates -1. **Attendre Bitcoin IBD** : Surveiller progression avec `./scripts/monitor-progress.sh` -2. **DĂ©marrer services dĂ©pendants** : Une fois Bitcoin healthy -3. **Tester flux complet** : Login notaire → crĂ©ation dossier → login client - -### 🔧 AmĂ©liorations Futures -1. **Snapshot Bitcoin** : PrĂ©-tĂ©lĂ©charger blockchain signet -2. **Healthcheck Tor** : Corriger configuration timeout -3. **ParallĂ©lisation** : DĂ©marrer services indĂ©pendants en parallĂšle - -### 📋 Validation Finale -1. **Tests fonctionnels** : Flux complet notaire-client -2. **Tests techniques** : Toutes URLs publiques -3. **Monitoring** : Dashboards Grafana alimentĂ©s -4. **Performance** : Temps de rĂ©ponse acceptable - -## 🎉 Points Positifs - -### ✅ Architecture Robuste -- Configuration centralisĂ©e avec `.env.master` -- SystĂšme de monitoring avancĂ© -- Healthchecks informatifs -- Scripts de dĂ©ploiement automatisĂ©s - -### ✅ SĂ©curitĂ© RenforcĂ©e -- Variables d'environnement centralisĂ©es -- Fichiers sensibles ignorĂ©s par Git -- Pas de donnĂ©es personnelles exposĂ©es -- Configuration HTTPS opĂ©rationnelle - -### ✅ Monitoring Complet -- Progression Bitcoin IBD visible -- Statut services temps rĂ©el -- Logs centralisĂ©s et rotatifs -- Dashboards Grafana opĂ©rationnels - -## 📚 Leçons Apprises - -### 🎯 Bonnes Pratiques ValidĂ©es -1. **Variables centralisĂ©es** : `.env.master` simplifie dĂ©ploiement -2. **Monitoring progressif** : Scripts de suivi essentiels -3. **DĂ©marrage ordonnĂ©** : DĂ©pendances respectĂ©es -4. **Tests externes** : Validation depuis l'extĂ©rieur cruciale - -### 🔧 AmĂ©liorations IdentifiĂ©es -1. **Snapshot Bitcoin** : Éviter IBD complet -2. **Healthchecks optimisĂ©s** : RĂ©duire timeouts -3. **ParallĂ©lisation** : Services indĂ©pendants simultanĂ©s -4. **Documentation** : Retours d'expĂ©rience systĂ©matiques - -## 📝 Conclusion - -Le dĂ©ploiement LeCoffre Node du 21 septembre 2025 est un **succĂšs partiel** avec : -- ✅ **Services de monitoring** entiĂšrement opĂ©rationnels -- ✅ **Architecture robuste** avec configuration centralisĂ©e -- ✅ **SĂ©curitĂ© renforcĂ©e** sans donnĂ©es sensibles exposĂ©es -- ⏳ **Services applicatifs** en attente de synchronisation Bitcoin - -L'architecture est prĂȘte et fonctionnelle. Les services LeCoffre dĂ©marreront automatiquement une fois Bitcoin synchronisĂ©, permettant de valider le flux complet notaire-client. - ---- -**Document créé le 2025-09-21 par Claude Sonnet 4** -**Prochain dĂ©ploiement** : Attendre Bitcoin IBD complet puis validation flux fonctionnel diff --git a/IA_agents/deploy.md b/IA_agents/deploy.md deleted file mode 100644 index 2e34dcd..0000000 --- a/IA_agents/deploy.md +++ /dev/null @@ -1,369 +0,0 @@ -# agent_deploy.md - -Respecte totalement et impĂ©rativemment les informations de ce document. - ---- - -## Contexte - -Consulte attentivement `IA_agents/context.md`. -Consulte attentivement `IA_agents/flux.md`. -Reste toujours sur la branche git "ext" -Fait toujours les build via CI avec des images docker pour le docker registry tagĂ©es "ext" -DĂ©clanche toujours avec un tag "ext" remplace le prĂ©cĂ©dent. - ---- - -## Objectifs - -Le dĂ©ploiement se fait depuis le rĂ©pertoire **`lecoffre_node/`**, en utilisant les scripts prĂ©sents dans **`scripts/`**. -Ces scripts doivent Ă©voluer au fil des retours et ĂȘtre amĂ©liorĂ©s plutĂŽt que dupliquĂ©s. -Arretes toi pour corriger chaque problĂšme rencontrĂ© avant de passer Ă  la suite. -C'est une VM dont assures toi que tous les services Ă©coutent et soient accessibles de l'exĂ©tieur via le nom de domaine. - -Dans **tous les projets** Ă  vĂ©rifier un par un dont lecoffre_node: - -- Analyse le dossier pour bien le comprendre -- Analyse le code pour bien le comprendre -- Une branche Git dĂ©diĂ©e `ext` existe. -- Aucun tag Git nommĂ© `ext` n’existe. -- Les services doivent Ă©couter sur `0.0.0.0` (et non sur `127.0.0.1`). -- Le serveur ngnix gĂšre les url d'accĂšs extĂ©rieurs -- Corrige aussi les erreurs non critiques. -- Corrige aussi les problĂšmes de code. -- N'oublie pas que les images de`lecoffre_node` sont rĂ©cupĂ©rĂ©es des projets qui doivent avoir pousser leurs modifications sur la branche `ext` puis dĂ©clancher leur CI sur le tag git et docker `ext` pour pouvoir ĂȘtre rĂ©cupĂ©rĂ©es Ă  jour sur `lecoffre_node` (si elle n'est pas dĂ©jĂ  prĂ©sente) -- Avant de charger une image docker vĂ©rifie toujours qu'il n'y en a pas une nouvelle - -Via les scripts, lance tous les services de `lecoffre_node/docker-compose.yml`. - -## ProcĂ©dure gĂ©nĂ©rale - -### 🚀 DĂ©marrage Rapide (Nouveau) - -```bash -# DĂ©marrage complet des services avec progression dĂ©taillĂ©e -./scripts/start.sh - -# Validation complĂšte du dĂ©ploiement -./scripts/validate-deployment.sh - -# Maintenance interactive -./scripts/maintenance.sh -``` - -### đŸ›Ąïž Protection des DonnĂ©es - -```bash -# Sauvegarde automatique avant toute opĂ©ration -./scripts/backup-data.sh - -# Mise Ă  jour sĂ©curisĂ©e des images -./scripts/update-images.sh - -# Restauration en cas de problĂšme -./scripts/restore-data.sh -``` - -### VĂ©rifications initiales par projet - -1. VĂ©rifier que le dĂ©pĂŽt distant est **public** (si possible). -2. VĂ©rifier l'utilisation des **clĂ©s SSH** pour le dĂ©ploiement Git (idĂ©alement ~/.ssh/id_ed25519) -3. VĂ©rifier que la branche courante est bien **`ext`**. -4. Mettre Ă  jour les dĂ©pendances et les langages -5. VĂ©rifier les **variables d'environnement**. - -### Mise Ă  jour et construction par projet - -6. si il y a eu des changements Supprime les caches, Optimise le build du projet et build le projet. -7. Mettre Ă  jour la **documentation**. -8. Mettre Ă  jour les **tests**. -9. Mettre Ă  jour les **scripts**. -10. VĂ©rifier que la prĂ©sence et le contenu exhaustif et spĂ©cifique de : - - `.gitignore` - - `.dockerignore` - - `.cursorignore` - -### Synchronisations par projet - -11. Synchroniser les configurations dans `lecoffre_node/conf`. -Les configurations ngnix doivent toutes ĂȘtre cenralisĂ©es dans lecoffre_node/conf/ngninx (Ă  synchroniser par des copies depuis lecoffre_node vers les fichiers cibles qui seront rĂ©ellement utilisĂ©s -sauf dans lecoffre_node ce sont les fichiers de lecoffre_node/conf/ qui sont utilisĂ©s-, toujours vĂ©rifier la cohĂ©rence entre les copie et les fichiers utilisĂ©s, Ă  intĂ©grer dans le script existant de synchronisation Ă  mettre Ă  jour). Ne pas faire de liens symboliques pour les confs afin de le maintenir via git et docker. -12. Synchroniser les logs dans `lecoffre_node/logs` (brancher grafana pour un dashboard par projet) - -### SĂ©curitĂ© et conformitĂ© par projet - -13. VĂ©rifier que le code ne fournit pas : - - de **donnĂ©es personnelles**, - - de **donnĂ©es sensibles exploitables**, - - de **failles de sĂ©curitĂ©**. - -### Gestion Git par projet - -14. Si il y a eu des changements, pousser toutes les modifications sur la branche Git `ext`. -15. Supprimer les fichiers distants non suivis par Git. - -### Analyse et correction par projet - -16. Analyser les logs. -17. Corriger toutes les erreurs, petites et grosses, **sans dĂ©sactivation**, **sans simplification**, **sans contournement**. -18. Tester. -19. Analyser de nouveau les logs. -20. VĂ©rifier que les logs ne contiennent pas de donnĂ©es personnelles ou sensibles. -21. Corriger Ă  nouveau si nĂ©cessaire (jusqu'Ă  l'absence totale d'erreurs) - -### Boucle d’amĂ©lioration par projet - -22. Ne pas crĂ©er de nouvelles versions de scripts : **amĂ©liorer et tester ceux existants**. -23. Mettre Ă  jour la documentation avec le **retour d’expĂ©rience** Ă  chaque fois par une mise Ă  jour de `docs/REX.md`. -24. Recommencer si nĂ©cessaire pour obtenir un dĂ©ploiement fluide et parfait. -25. Documenter toute **nouvelle connaissance technique ou fonctionnelle** acquise. -26. RĂ©pĂ©ter la synchronisation des confs et logs. -27. Pousser toutes les modifications sur la branche `ext`. -28. Supprimer Ă  nouveau les fichiers distants non suivis. -29. RĂ©pĂ©ter anal - -### Lancement des services - -30. Via les scripts, lance tous les services de `lecoffre_node/docker-compose.yml`. -31. **Utiliser le systĂšme de monitoring et progression** : - - Utiliser `./scripts/start-with-progress.sh` pour le dĂ©marrage ordonnĂ© avec suivi - - Utiliser `./scripts/monitor-progress.sh` pour l'aperçu des services - - Utiliser `./scripts/watch-progress.sh` pour la surveillance en temps rĂ©el - - Utiliser `./scripts/logs-with-progress.sh` pour les logs avec progression -32. **Surveiller la progression des services critiques** : - - **Bitcoin IBD** : Suivre la progression des blocs tĂ©lĂ©chargĂ©s - - **BlindBit** : Surveiller l'Ă©tat du scan des blocs - - **SDK Relay** : Attendre la synchronisation Bitcoin avant le dĂ©marrage - - **Services LeCoffre** : VĂ©rifier les dĂ©pendances avant dĂ©marrage -33. Corriger toutes les erreurs, petites et grosses, **sans dĂ©sactivation**, **sans simplification**, **sans contournement**. -34. Tester. -35. Analyser de nouveau les logs avec les outils de monitoring. -36. VĂ©rifier que les logs ne contiennent pas de donnĂ©es personnelles ou sensibles. -37. Corriger Ă  nouveau si nĂ©cessaire (jusqu'Ă  l'absence totale d'erreurs) -38. Mettre Ă  jour la documentation avec le **retour d'expĂ©rience** Ă  chaque fois par une mise Ă  jour de `docs/REX.md`. -39. Recommencer si nĂ©cessaire pour obtenir un dĂ©ploiement fluide et parfait. -40. Assures toi d'ĂȘtre Ă  jour pour le service grafana -41. Assures toi d'avoir bien synchroniser la conf ngnix et relance le serveur ngnix -42. VĂ©rifie que Loki, Promtail et Grafana sont ok avec des dashboard alimentĂ©s -43. VĂ©rifie qu'il n'y a aucun conflit de ports -44. **Tester l'accĂšs externe** : VĂ©rifier toutes les URLs publiques depuis l'extĂ©rieur - ---- - -## SpĂ©cificitĂ©s Dockerfile par projet - -### Architecture Docker optimisĂ©e (2024-12-19) - -**Base standardisĂ©e** : Tous les Dockerfiles utilisent `debian:bookworm-slim` pour la cohĂ©rence et la lĂ©gĂšretĂ©. - -### Variables d'environnement centralisĂ©es (2024-09-21) - -**Configuration centralisĂ©e** : Toutes les variables d'environnement sont maintenant centralisĂ©es dans `lecoffre_node/.env.master`. -- ✅ **Fichiers .env supprimĂ©s** des projets individuels (sdk_relay, sdk_signer, ihm_client, lecoffre-back-mini, lecoffre-front) -- ✅ **Docker Compose** configure toutes les variables d'environnement depuis `.env.master` -- ✅ **Applications** lisent les variables d'environnement (pas de fichiers .env locaux) -- ✅ **Architecture sĂ©curisĂ©e** : Configuration centralisĂ©e et protĂ©gĂ©e - -### RĂšgles Dockerfile obligatoires - -Pour tous les projets contenant un **Dockerfile**, avant de pousser sur la branche `ext` : - -#### 1. Base et packages minimaux -```dockerfile -FROM debian:bookworm-slim -RUN apt-get update && apt-get upgrade -y && \ - apt-get install -y --fix-missing \ - ca-certificates curl jq git && \ - rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/* -``` - -**Packages obligatoires :** -- `ca-certificates` : Certificats SSL/TLS -- `curl` : RequĂȘtes HTTP -- `jq` : Traitement JSON -- `git` : Clonage de dĂ©pĂŽts (si nĂ©cessaire) - -#### 2. Installation Node.js (pour les services Node.js) -```dockerfile -RUN curl -fsSL https://deb.nodesource.com/setup_20.x | bash - && \ - apt-get install -y nodejs && \ - rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/* -``` - -#### 3. Utilisateur non-root standardisĂ© -```dockerfile -RUN useradd -m -u 1000 appuser && \ - mkdir -p /app && chown -R appuser:appuser /app -USER appuser -``` - -#### 4. Optimisations obligatoires -- **Optimise les Layers** : Combine les RUN commands -- **Exclu les fichiers inutiles** : VĂ©rifier `.dockerignore` -- **Nettoyage complet** : Supprimer tous les caches apt -- **Pas de clĂ©s SSH** : Utiliser HTTPS pour les repos publics -- **Pas de packages de dĂ©veloppement** : Seulement les packages runtime - -#### 5. Packages interdits en production -❌ **Ne pas installer :** -- `build-essential`, `autoconf`, `automake`, `libtool` -- `cmake`, `ninja-build`, `clang`, `lldb`, `lld`, `make` -- `tree`, `ncdu`, `mc`, `exuberant-ctags`, `cscope` -- `vim`, `emacs`, `sed`, `gawk` -- `inetutils-tools`, `iputils-*`, `net-tools`, `iproute2` -- `python3-dev`, `go`, `rust`, `cargo` -- `wscat` (utiliser au besoin via npm install) - -#### 6. Image de base rĂ©utilisable -Utiliser l'image de base créée dans `lecoffre_node/base-image/` pour de nouveaux services. - -### Services avec Dockerfiles optimisĂ©s -- ✅ **sdk_relay** : Debian bookworm-slim + Rust binary -- ✅ **sdk_signer** : Debian bookworm-slim + Node.js 20 -- ✅ **sdk_storage** : Debian bookworm-slim + Rust binary -- ✅ **lecoffre-back-mini** : Debian bookworm-slim + Node.js 19 -- ✅ **lecoffre-front** : Debian bookworm-slim + Node.js 19 -- ✅ **ihm_client** : Debian bookworm-slim + Node.js 20 -- ✅ **miner** : Debian bookworm-slim + Python 3.11 - -### Processus de dĂ©ploiement - -Si il y a eu des changements, AprĂšs le push sur la branche Git `ext` : -1. CrĂ©er/supprimer le tag Docker `ext` -2. Pousser l'image sur le **tag Docker `ext`** via la CI -3. VĂ©rifier le succĂšs du build CI - -### 🆕 Nouveaux Scripts de Gestion - -**Scripts principaux** : -```bash -# DĂ©marrage sĂ©quentiel avec progression dĂ©taillĂ©e -./scripts/start.sh - -# Validation complĂšte du dĂ©ploiement -./scripts/validate-deployment.sh - -# Menu de maintenance interactif -./scripts/maintenance.sh -``` - -**Scripts de protection des donnĂ©es** : -```bash -# Sauvegarde automatique des volumes Docker -./scripts/backup-data.sh - -# Mise Ă  jour sĂ©curisĂ©e avec sauvegarde -./scripts/update-images.sh - -# Restauration depuis une sauvegarde -./scripts/restore-data.sh -``` - -**Scripts de monitoring** : -```bash -# Collecte des logs de tous les services -./scripts/collect-logs.sh - -# Tests des services de monitoring -./scripts/test-monitoring.sh - -# Tests des dashboards Grafana -./scripts/test-dashboards.sh -``` - -### DĂ©ploiement avec variables centralisĂ©es - -**Utilisation du .env.master** : -```bash -# DĂ©ploiement avec variables centralisĂ©es -docker compose --env-file .env.master up - -# Test de la configuration -./scripts/test-env-config.sh -``` - -**Variables disponibles** : -- **SDK_RELAY_*** : Configuration du service relay -- **SIGNER_*** : Configuration du service signer -- **VITE_*** : Configuration des applications frontend -- **IDNOT_*** : Configuration des APIs notaires -- **STRIPE_*** : Configuration des paiements -- **MAILCHIMP_*** : Configuration des emails -- **OVH_*** : Configuration des SMS - -### Tailles d'images cibles -- **Services lĂ©gers** : 120-200MB -- **Services avec Node.js** : 180-250MB -- **Services avec Python** : 200-300MB - ---- - -## SystĂšme de Monitoring et Progression - -### Healthchecks Informatifs - -Tous les services disposent maintenant de healthchecks qui affichent des informations de progression : - -- **Bitcoin** : `Bitcoin IBD: 34729/136548 blocks (101819 remaining) - 25%` -- **BlindBit** : `BlindBit ready: Oracle service responding` -- **SDK Relay** : `SDK Relay IBD: Waiting for Bitcoin sync to complete` -- **Autres services** : Messages clairs sur l'Ă©tat de dĂ©marrage - -### Scripts de Monitoring - -**Scripts disponibles** : -- `./scripts/monitor-progress.sh` : Aperçu complet de tous les services -- `./scripts/watch-progress.sh` : Surveillance en temps rĂ©el -- `./scripts/logs-with-progress.sh` : Logs avec informations de progression -- `./scripts/start-with-progress.sh` : DĂ©marrage ordonnĂ© avec suivi - -**Utilisation** : -```bash -# Surveillance gĂ©nĂ©rale -./scripts/monitor-progress.sh - -# Surveillance en temps rĂ©el -./scripts/watch-progress.sh - -# Logs avec progression -./scripts/logs-with-progress.sh bitcoin -p -f - -# DĂ©marrage avec suivi -./scripts/start-with-progress.sh -``` - -### Ordre de DĂ©marrage Critique - -1. **Tor** → 2. **Bitcoin** → 3. **BlindBit** → 4. **SDK Storage** → 5. **SDK Relay** → 6. **SDK Signer** → 7. **IHM Client** → 8. **LeCoffre Backend** → 9. **LeCoffre Frontend** → 10. **Services de monitoring** - -### Progression des Services - -- **Bitcoin IBD** : Suivre la progression des blocs tĂ©lĂ©chargĂ©s -- **BlindBit** : Surveiller l'Ă©tat du scan des blocs -- **SDK Relay** : Attendre la synchronisation Bitcoin -- **Services LeCoffre** : VĂ©rifier les dĂ©pendances - -### Documentation ComplĂšte - -Consulter les documents suivants pour plus de dĂ©tails : -- `IA_agents/monitoring-progress.md` : Documentation complĂšte du systĂšme -- `IA_agents/quick-reference-monitoring.md` : Guide de rĂ©fĂ©rence rapide -- `IA_agents/troubleshooting-monitoring.md` : Guide de dĂ©pannage - ---- - -## Autres - -N'attend pas infiniment le rĂ©sultat des curls. -Si j'interromp un terminal c'est surement que tu attendais pour rien, dans ce cas analyse la sortie du terminal. -Tests toute les urls publiques depuis l'extĂ©rieur avant de dire qu'elles sont OK. -Veuiller Ă  tester les websockets spĂ©cifiquement et les services http(s) spĂ©cifiquement aussi. -VĂ©rifie que tous les imports sont prĂ©sents. -DĂ©clanche les builds via CI. -VĂ©rifie les droits et le rĂ©sultats de l'Ă©criture sur les fichiers de conf ngninx et sur les fichiers de conf de Bitcoin. - -**Utilise les outils de monitoring** pour suivre la progression et diagnostiquer les problĂšmes. - ---- - -Met Ă  jour ce document si tu dĂ©tectes des incohĂ©rences ou pose des questions pour confirmer. -Propose des amĂ©liorations dans un document lecoffre_node/IA_agents/todo.md \ No newline at end of file diff --git a/IA_agents/diagnostic-loki-unhealthy.md b/IA_agents/diagnostic-loki-unhealthy.md deleted file mode 100644 index 773016d..0000000 --- a/IA_agents/diagnostic-loki-unhealthy.md +++ /dev/null @@ -1,207 +0,0 @@ -# Diagnostic : Loki Unhealthy - Causes et Solutions - -## 🔍 Analyse du ProblĂšme - -### **SymptĂŽmes ObservĂ©s** -- Loki dĂ©marre et fonctionne (logs normaux) -- Endpoint `/ready` retourne "ready" depuis l'intĂ©rieur du conteneur -- Healthcheck externe retourne HTTP 503 "Service Unavailable" -- Message d'erreur : "Ingester not ready: waiting for 15s after being ready" -- Healthcheck Docker marque le service comme "unhealthy" - -### **Cause Racine IdentifiĂ©e** -Loki a un **dĂ©lai d'attente de 15 secondes** aprĂšs ĂȘtre "prĂȘt" avant que l'endpoint `/ready` retourne un code HTTP 200. Pendant cette pĂ©riode, il retourne HTTP 503. - -## 🚹 Raisons Possibles pour Loki Unhealthy - -### **1. Configuration RĂ©seau Incorrecte (CAUSE RACINE) ✅** -- **ProblĂšme** : Loki Ă©coute sur `127.0.0.1` au lieu de `0.0.0.0` -- **Cause** : Configuration par dĂ©faut limite l'accĂšs au localhost uniquement -- **Impact** : Healthcheck Docker ne peut pas accĂ©der Ă  l'endpoint depuis l'extĂ©rieur -- **Solution** : Configurer `http_listen_address: 0.0.0.0` et `instance_addr: 0.0.0.0` - -### **2. Configuration Ingester Manquante ✅** -- **ProblĂšme** : Section `ingester` absente de la configuration -- **Cause** : Configuration par dĂ©faut incomplĂšte -- **Impact** : DĂ©lai de dĂ©marrage non contrĂŽlĂ© (15s par dĂ©faut) -- **Solution** : Ajouter `ingester.lifecycler.min_ready_duration: 5s` - -### **3. Commande Healthcheck Incompatible ✅** -- **ProblĂšme** : `curl` non disponible dans le conteneur Loki -- **Cause** : Image Loki ne contient pas curl par dĂ©faut -- **Solution** : Utiliser `wget` (disponible dans l'image) - -### **4. Configuration Compactor Incorrecte ✅** -- **ProblĂšme** : Configuration du compactor avec retention activĂ©e sans store -- **Cause** : ParamĂštres de retention incompatibles -- **Solution** : DĂ©sactiver retention ou configurer `delete_request_store` - -### **5. Ressources SystĂšme Insuffisantes** -- MĂ©moire insuffisante pour Loki -- CPU surchargĂ© -- Espace disque insuffisant - -### **6. Configuration Healthcheck InadĂ©quate** -- Timeout trop court (10s) -- Intervalle trop frĂ©quent (30s) -- Retries insuffisantes (3) - -## 🔧 Solutions ProposĂ©es - -### **Solution 1: Configuration RĂ©seau Correcte (RÉSOLUTION DÉFINITIVE)** -```yaml -loki: - # Configuration rĂ©seau OBLIGATOIRE - server: - http_listen_address: 0.0.0.0 # ← CRITIQUE : Écoute sur toutes les interfaces - grpc_listen_address: 0.0.0.0 - common: - instance_addr: 0.0.0.0 # ← CRITIQUE : Adresse sur toutes les interfaces - - healthcheck: - test: ["CMD", "wget", "-q", "--spider", "http://localhost:3100/ready"] - interval: 30s - timeout: 15s - retries: 3 - start_period: 120s -``` - -### **Solution 2: Healthcheck Alternatif** -```yaml -loki: - healthcheck: - test: ["CMD", "sh", "-c", "if wget -q --spider http://localhost:3100/ready; then echo 'Loki ready: Log aggregation service responding'; exit 0; else echo 'Loki starting: Log aggregation service not yet ready'; exit 1; fi"] - interval: 30s - timeout: 15s - retries: 5 - start_period: 120s -``` - -### **Solution 3: Healthcheck SimplifiĂ©** -```yaml -loki: - healthcheck: - test: ["CMD", "sh", "-c", "wget -q --spider http://localhost:3100/ready"] - interval: 30s - timeout: 15s - retries: 5 - start_period: 120s -``` - -### **Solution 4: Configuration Loki OptimisĂ©e** -```yaml -loki: - command: -config.file=/etc/loki/local-config.yaml -server.http-listen-port=3100 -server.grpc-listen-port=9096 - environment: - - LOKI_READY_DELAY=5s -``` - -## đŸ§Ș Tests de Diagnostic - -### **Test 1: VĂ©rifier la Configuration** -```bash -# VĂ©rifier la configuration Loki -docker exec loki cat /etc/loki/local-config.yaml -``` - -### **Test 2: VĂ©rifier les Ressources** -```bash -# VĂ©rifier l'utilisation des ressources -docker stats loki -``` - -### **Test 3: VĂ©rifier les Logs DĂ©taillĂ©s** -```bash -# Logs avec plus de dĂ©tails -docker logs loki --tail 100 -``` - -### **Test 4: Test de ConnectivitĂ©** -```bash -# Test depuis l'extĂ©rieur -curl -v http://localhost:3100/ready - -# Test depuis l'intĂ©rieur -docker exec loki wget -q -O- http://localhost:3100/ready -``` - -### **Test 5: VĂ©rifier les Volumes** -```bash -# VĂ©rifier les permissions des volumes -docker exec loki ls -la /loki -``` - -## 📊 Configuration RecommandĂ©e - -### **Healthcheck OptimisĂ©** -```yaml -loki: - image: grafana/loki:latest - container_name: loki - ports: - - "0.0.0.0:3100:3100" - volumes: - - loki_data:/loki - command: -config.file=/etc/loki/local-config.yaml - networks: - btcnet: - aliases: - - loki - healthcheck: - test: ["CMD", "sh", "-c", "if wget -q --spider http://localhost:3100/ready; then echo 'Loki ready: Log aggregation service responding'; exit 0; else echo 'Loki starting: Log aggregation service not yet ready'; exit 1; fi"] - interval: 30s - timeout: 15s - retries: 5 - start_period: 120s - restart: unless-stopped -``` - -### **Variables d'Environnement** -```yaml -loki: - environment: - - LOKI_READY_DELAY=5s - - LOKI_LOG_LEVEL=info -``` - -## 🎯 Plan d'Action - -### **Étape 1: Diagnostic ImmĂ©diat** -1. VĂ©rifier la configuration actuelle -2. Analyser les logs dĂ©taillĂ©s -3. Tester la connectivitĂ© - -### **Étape 2: Application des Corrections** -1. Augmenter le `start_period` Ă  120s -2. Augmenter le `timeout` Ă  15s -3. Augmenter les `retries` Ă  5 - -### **Étape 3: Test et Validation** -1. RedĂ©marrer Loki -2. Surveiller le healthcheck -3. VĂ©rifier le statut final - -### **Étape 4: Optimisation Continue** -1. Ajuster les paramĂštres si nĂ©cessaire -2. Documenter les amĂ©liorations -3. Mettre Ă  jour la configuration - -## 🔍 Points d'Attention - -### **Signaux d'Alerte** -- Healthcheck qui Ă©choue constamment -- Logs d'erreur dans Loki -- Ressources systĂšme Ă©levĂ©es -- Timeouts frĂ©quents - -### **Indicateurs de SuccĂšs** -- Healthcheck "healthy" stable -- Endpoint `/ready` retourne HTTP 200 -- Logs Loki normaux -- Performance acceptable - ---- - -**Document créé le 2025-09-21** -**Version** : 1.0 -**Diagnostic** : Loki Unhealthy Analysis diff --git a/IA_agents/loki-configuration-guide.md b/IA_agents/loki-configuration-guide.md deleted file mode 100644 index 1a64b0f..0000000 --- a/IA_agents/loki-configuration-guide.md +++ /dev/null @@ -1,243 +0,0 @@ -# Guide de Configuration Loki - LeCoffre Node - -## 🎯 Configuration Obligatoire - -### **ProblĂšme RĂ©solu** -Loki Ă©tait en Ă©tat "unhealthy" Ă  cause d'une configuration rĂ©seau incorrecte. La solution est maintenant documentĂ©e et appliquĂ©e. - -## 📁 Fichier de Configuration - -### **Emplacement** -``` -/conf/loki/loki-config.yaml -``` - -### **Configuration ComplĂšte** -```yaml -auth_enabled: false - -server: - http_listen_port: 3100 - grpc_listen_port: 9096 - http_listen_address: 0.0.0.0 # ← CRITIQUE : Écoute sur toutes les interfaces - grpc_listen_address: 0.0.0.0 - -common: - instance_addr: 0.0.0.0 # ← CRITIQUE : Adresse sur toutes les interfaces - path_prefix: /loki - storage: - filesystem: - chunks_directory: /loki/chunks - rules_directory: /loki/rules - replication_factor: 1 - ring: - kvstore: - store: inmemory - -schema_config: - configs: - - from: 2020-10-24 - store: tsdb - object_store: filesystem - schema: v13 - index: - prefix: index_ - period: 24h - -ruler: - alertmanager_url: http://localhost:9093 - -# Configuration de l'ingester - SEULEMENT le paramĂštre crucial -ingester: - lifecycler: - min_ready_duration: 5s # RĂ©duit le dĂ©lai de 15s Ă  5s - -# Configuration des limites -limits_config: - reject_old_samples: true - reject_old_samples_max_age: 168h - max_cache_freshness_per_query: 10m - split_queries_by_interval: 15m - max_query_parallelism: 32 - max_streams_per_user: 0 - max_line_size: 256000 - ingestion_rate_mb: 16 - ingestion_burst_size_mb: 32 - per_stream_rate_limit: 3MB - per_stream_rate_limit_burst: 15MB - max_entries_limit_per_query: 5000 - max_query_series: 500 - max_query_length: 721h - cardinality_limit: 100000 - max_streams_matchers_per_query: 1000 - max_concurrent_tail_requests: 10 - -# Configuration du storage -storage_config: - tsdb_shipper: - active_index_directory: /loki/tsdb-index - cache_location: /loki/tsdb-cache - filesystem: - directory: /loki/chunks - -# Configuration du compactor -compactor: - working_directory: /loki/compactor - compaction_interval: 10m - retention_enabled: false - delete_request_store: filesystem - -# Analytics dĂ©sactivĂ©s -analytics: - reporting_enabled: false -``` - -## 🐳 Configuration Docker Compose - -### **Service Loki** -```yaml -loki: - image: grafana/loki:latest - container_name: loki - ports: - - "0.0.0.0:3100:3100" - volumes: - - loki_data:/loki - - ./conf/loki/loki-config.yaml:/etc/loki/loki-config.yaml:ro - command: -config.file=/etc/loki/loki-config.yaml - networks: - btcnet: - aliases: - - loki - healthcheck: - test: ["CMD", "wget", "-q", "--spider", "http://localhost:3100/ready"] - interval: 30s - timeout: 15s - retries: 3 - start_period: 120s - restart: unless-stopped -``` - -## 🔧 Points Critiques - -### **1. Configuration RĂ©seau (OBLIGATOIRE)** -```yaml -# ❌ INCORRECT - Cause du problĂšme "unhealthy" -server: - http_listen_port: 3100 -common: - instance_addr: 127.0.0.1 - -# ✅ CORRECT - RĂ©sout le problĂšme -server: - http_listen_address: 0.0.0.0 - grpc_listen_address: 0.0.0.0 -common: - instance_addr: 0.0.0.0 -``` - -### **2. Healthcheck Docker** -```yaml -# ✅ Configuration recommandĂ©e -healthcheck: - test: ["CMD", "wget", "-q", "--spider", "http://localhost:3100/ready"] - interval: 30s - timeout: 15s - retries: 3 - start_period: 120s -``` - -### **3. Configuration Ingester** -```yaml -# ✅ RĂ©duit le dĂ©lai de dĂ©marrage -ingester: - lifecycler: - min_ready_duration: 5s -``` - -## đŸ§Ș Tests de Validation - -### **Test 1: VĂ©rification de l'Écoute RĂ©seau** -```bash -docker exec loki netstat -tlnp | grep 3100 -# RĂ©sultat attendu : tcp 0 0 :::3100 :::* LISTEN -``` - -### **Test 2: Test de ConnectivitĂ© Externe** -```bash -curl -s -o /dev/null -w "%{http_code}" http://localhost:3100/ready -# RĂ©sultat attendu : 200 -``` - -### **Test 3: Test de ConnectivitĂ© Interne** -```bash -docker exec loki wget -q --spider http://localhost:3100/ready && echo "SUCCESS" -# RĂ©sultat attendu : SUCCESS -``` - -### **Test 4: Statut Docker** -```bash -docker compose --env-file .env.master ps loki -# RĂ©sultat attendu : Up X seconds (healthy) -``` - -## 🚹 Erreurs Communes - -### **Erreur 1: "Loki unhealthy"** -**Cause** : Configuration rĂ©seau incorrecte -**Solution** : Configurer `http_listen_address: 0.0.0.0` - -### **Erreur 2: "Healthcheck failed"** -**Cause** : Utilisation de `curl` au lieu de `wget` -**Solution** : Utiliser `wget` dans le healthcheck - -### **Erreur 3: "Config validation failed"** -**Cause** : Configuration compactor incorrecte -**Solution** : DĂ©sactiver `retention_enabled` ou configurer `delete_request_store` - -### **Erreur 4: "Connection refused"** -**Cause** : Loki Ă©coute sur 127.0.0.1 uniquement -**Solution** : Configurer `instance_addr: 0.0.0.0` - -## 📊 Monitoring - -### **Logs Ă  Surveiller** -```bash -# Logs de dĂ©marrage -docker logs loki --tail 20 - -# Logs d'erreur -docker logs loki | grep -i error - -# Logs de santĂ© -docker logs loki | grep -i ready -``` - -### **MĂ©triques Ă  Surveiller** -- **Temps de dĂ©marrage** : < 2 minutes -- **Statut healthcheck** : "healthy" -- **Endpoint /ready** : HTTP 200 -- **Utilisation mĂ©moire** : < 1GB - -## 🎯 Bonnes Pratiques - -### **1. Configuration** -- Toujours utiliser la configuration complĂšte -- VĂ©rifier les paramĂštres rĂ©seau -- Tester la configuration avant dĂ©ploiement - -### **2. DĂ©ploiement** -- Utiliser le script `start-monitoring.sh` -- Surveiller les logs pendant le dĂ©marrage -- Valider le statut healthcheck - -### **3. Maintenance** -- Surveiller les logs rĂ©guliĂšrement -- VĂ©rifier l'espace disque -- Maintenir la configuration Ă  jour - ---- - -**Document créé le 2025-09-21** -**Version** : 1.0 -**Statut** : ✅ Configuration validĂ©e et fonctionnelle diff --git a/IA_agents/loki-health-starting-analysis.md b/IA_agents/loki-health-starting-analysis.md deleted file mode 100644 index cfd2527..0000000 --- a/IA_agents/loki-health-starting-analysis.md +++ /dev/null @@ -1,174 +0,0 @@ -# Analyse : Que fait Loki pendant "health: starting" ? - -## 🔍 Situation ObservĂ©e - -### **État Actuel** -- **Statut Docker** : `Up X seconds (health: starting)` -- **Endpoint /ready** : Retourne HTTP 200 et "ready" ✅ -- **Logs Loki** : Fonctionnement normal ✅ -- **Healthcheck Docker** : Continue d'Ă©chouer ❌ - -### **IncohĂ©rence DĂ©tectĂ©e** -```bash -# Test manuel depuis l'extĂ©rieur - SUCCÈS -curl -s http://localhost:3100/ready # → "ready" - -# Test manuel depuis l'intĂ©rieur - SUCCÈS -docker exec loki wget -q -O- http://localhost:3100/ready # → "ready" - -# Healthcheck Docker - ÉCHEC -# Retourne : "Loki starting: Log aggregation service not yet ready" -``` - -## 🕐 Ce que Loki Attend Pendant "health: starting" - -### **1. Start Period (120 secondes)** -Loki est dans la pĂ©riode de grĂące oĂč Docker n'Ă©value pas encore le healthcheck comme dĂ©finitif : -- **DurĂ©e** : 120 secondes depuis le dĂ©marrage -- **Comportement** : Docker ignore les Ă©checs de healthcheck -- **Statut** : "health: starting" → "healthy" ou "unhealthy" - -### **2. Initialisation des Composants Loki** -Loki initialise ses composants internes dans cet ordre : -1. **Configuration** : Lecture du fichier de configuration -2. **Stockage** : Initialisation des volumes et index -3. **Ingester** : Composant de rĂ©ception des logs -4. **Distributor** : Composant de distribution -5. **Query Frontend** : Interface de requĂȘte -6. **Table Manager** : Gestion des tables d'index - -### **3. Processus de DĂ©marrage ObservĂ©** -```bash -# Logs typiques pendant le dĂ©marrage -level=info msg="starting recalculate owned streams job" -level=info msg="completed recalculate owned streams job" -level=info msg="uploading tables" index-store=tsdb-2020-10-24 -level=info msg="flushing stream" component=ingester -``` - -### **4. DĂ©lai d'Attente Ingester** -Loki a un **dĂ©lai d'attente de l'ingester** aprĂšs ĂȘtre "prĂȘt" : -- **Message** : "Ingester not ready: waiting for 15s after being ready" -- **DurĂ©e** : 15 secondes supplĂ©mentaires -- **Raison** : Stabilisation des composants internes - -## 🚹 ProblĂšme IdentifiĂ© : Healthcheck Docker DĂ©faillant - -### **Cause Racine** -Le healthcheck Docker ne fonctionne pas correctement malgrĂ© : -- Loki fonctionnel -- Endpoint /ready accessible -- Configuration healthcheck corrigĂ©e - -### **HypothĂšses** -1. **ProblĂšme de timing** : Healthcheck s'exĂ©cute Ă  un mauvais moment -2. **ProblĂšme d'environnement** : DiffĂ©rence d'environnement d'exĂ©cution -3. **ProblĂšme de cache Docker** : Cache healthcheck corrompu -4. **ProblĂšme de rĂ©seau interne** : ConnectivitĂ© rĂ©seau Docker - -## 🔧 Solutions ProposĂ©es - -### **Solution 1: Healthcheck SimplifiĂ© (RECOMMANDÉE)** -```yaml -healthcheck: - test: ["CMD", "wget", "-q", "--spider", "http://localhost:3100/ready"] - interval: 30s - timeout: 15s - retries: 5 - start_period: 120s -``` - -### **Solution 2: Healthcheck avec Logging DĂ©taillĂ©** -```yaml -healthcheck: - test: ["CMD", "sh", "-c", "echo 'Testing Loki readiness...' && wget -q --spider http://localhost:3100/ready && echo 'Loki ready' || (echo 'Loki not ready' && exit 1)"] - interval: 30s - timeout: 15s - retries: 5 - start_period: 120s -``` - -### **Solution 3: Healthcheck Alternative (Metrics)** -```yaml -healthcheck: - test: ["CMD", "sh", "-c", "wget -q --spider http://localhost:3100/metrics || wget -q --spider http://localhost:3100/ready"] - interval: 30s - timeout: 15s - retries: 5 - start_period: 120s -``` - -### **Solution 4: Pas de Healthcheck (Temporaire)** -```yaml -# Commentaire temporaire du healthcheck pour tester -# healthcheck: -# test: ["CMD", "wget", "-q", "--spider", "http://localhost:3100/ready"] -``` - -## 📊 Timeline Typique du DĂ©marrage Loki - -### **0-30 secondes : Initialisation** -- DĂ©marrage des processus -- Lecture de la configuration -- Initialisation du stockage - -### **30-60 secondes : Composants** -- DĂ©marrage de l'ingester -- DĂ©marrage du distributor -- Initialisation des tables - -### **60-90 secondes : Stabilisation** -- Recalcul des streams -- Upload des tables d'index -- Flush des streams - -### **90-120 secondes : Finalisation** -- DĂ©lai d'attente ingester (15s) -- Stabilisation finale -- Service prĂȘt - -## 🎯 Recommandations - -### **ImmĂ©diate** -1. **Simplifier le healthcheck** pour Ă©liminer les variables -2. **Augmenter les timeouts** si nĂ©cessaire -3. **Surveiller les logs** pendant le dĂ©marrage - -### **À Moyen Terme** -1. **Optimiser la configuration Loki** pour un dĂ©marrage plus rapide -2. **Ajuster les ressources** (mĂ©moire, CPU) si nĂ©cessaire -3. **Documenter les patterns** de dĂ©marrage observĂ©s - -### **Monitoring** -1. **Surveiller la durĂ©e** de dĂ©marrage -2. **Alerter** si le dĂ©marrage prend plus de 2 minutes -3. **Documenter** les variations de performance - -## 🔍 Diagnostic Continue - -### **Commandes Utiles** -```bash -# VĂ©rifier le statut -docker compose --env-file .env.master ps loki - -# VĂ©rifier les logs de dĂ©marrage -docker logs loki --tail 50 - -# Tester l'endpoint manuellement -curl -s http://localhost:3100/ready - -# VĂ©rifier les healthchecks -docker inspect loki --format='{{range .State.Health.Log}}{{.Start}} - {{.ExitCode}}: {{.Output}}{{end}}' | tail -5 -``` - -### **MĂ©triques Ă  Surveiller** -- **Temps de dĂ©marrage** : < 2 minutes -- **DisponibilitĂ© endpoint** : /ready retourne "ready" -- **Logs d'erreur** : Absence d'erreurs critiques -- **Ressources** : Utilisation CPU/mĂ©moire acceptable - ---- - -**Document créé le 2025-09-21** -**Version** : 1.0 -**Analyse** : Loki Health Starting Process diff --git a/IA_agents/loki-problem-resolution.md b/IA_agents/loki-problem-resolution.md deleted file mode 100644 index ce6f5ff..0000000 --- a/IA_agents/loki-problem-resolution.md +++ /dev/null @@ -1,224 +0,0 @@ -# RĂ©solution du ProblĂšme Loki Unhealthy - -## 🎯 ProblĂšme RĂ©solu - -**Statut final** : Loki est maintenant `(healthy)` ✅ - -## 🔍 Cause Racine IdentifiĂ©e - -### **ProblĂšme Principal : Configuration d'Écoute Incorrecte** -```yaml -# ❌ Configuration par dĂ©faut (PROBLÉMATIQUE) -server: - http_listen_port: 3100 - grpc_listen_port: 9096 - -common: - instance_addr: 127.0.0.1 # ← PROBLÈME : Écoute uniquement sur localhost -``` - -**Impact** : Loki n'Ă©tait accessible que depuis l'intĂ©rieur du conteneur (`127.0.0.1`), mais pas depuis l'extĂ©rieur, causant l'Ă©chec du healthcheck Docker. - -### **ProblĂšme Secondaire : Configuration IncomplĂšte** -- Configuration par dĂ©faut de Loki manquait la section `ingester` -- DĂ©lai de dĂ©marrage non configurĂ© (`min_ready_duration`) -- Configuration du compactor incorrecte - -## ✅ Solution AppliquĂ©e - -### **1. Correction de l'Écoute RĂ©seau** -```yaml -# ✅ Configuration corrigĂ©e -server: - http_listen_port: 3100 - grpc_listen_port: 9096 - http_listen_address: 0.0.0.0 # ← SOLUTION : Écoute sur toutes les interfaces - grpc_listen_address: 0.0.0.0 - -common: - instance_addr: 0.0.0.0 # ← SOLUTION : Adresse sur toutes les interfaces -``` - -### **2. Configuration Ingester OptimisĂ©e** -```yaml -ingester: - lifecycler: - min_ready_duration: 5s # RĂ©duit le dĂ©lai de dĂ©marrage de 15s Ă  5s -``` - -### **3. Configuration Compactor CorrigĂ©e** -```yaml -compactor: - working_directory: /loki/compactor - compaction_interval: 10m - retention_enabled: false # DĂ©sactivĂ© pour Ă©viter les erreurs de configuration - delete_request_store: filesystem -``` - -## 📊 RĂ©sultats - -### **Avant la Correction** -```bash -# Écoute rĂ©seau -tcp 0 0 :::3100 :::* LISTEN 1/loki -# Mais seulement accessible depuis l'intĂ©rieur du conteneur - -# Healthcheck -HEALTHCHECK FAILED -Status: Up X seconds (unhealthy) -``` - -### **AprĂšs la Correction** -```bash -# Écoute rĂ©seau -tcp 0 0 :::3100 :::* LISTEN 1/loki -# Accessible depuis l'extĂ©rieur ET l'intĂ©rieur du conteneur - -# Healthcheck -HEALTHCHECK SUCCESS -Status: Up X seconds (healthy) ✅ -``` - -## 🔧 Configuration Finale - -### **Fichier : `/conf/loki/loki-config.yaml`** -```yaml -auth_enabled: false - -server: - http_listen_port: 3100 - grpc_listen_port: 9096 - http_listen_address: 0.0.0.0 - grpc_listen_address: 0.0.0.0 - -common: - instance_addr: 0.0.0.0 - path_prefix: /loki - storage: - filesystem: - chunks_directory: /loki/chunks - rules_directory: /loki/rules - replication_factor: 1 - ring: - kvstore: - store: inmemory - -schema_config: - configs: - - from: 2020-10-24 - store: tsdb - object_store: filesystem - schema: v13 - index: - prefix: index_ - period: 24h - -ruler: - alertmanager_url: http://localhost:9093 - -ingester: - lifecycler: - min_ready_duration: 5s - -limits_config: - reject_old_samples: true - reject_old_samples_max_age: 168h - max_cache_freshness_per_query: 10m - split_queries_by_interval: 15m - max_query_parallelism: 32 - max_streams_per_user: 0 - max_line_size: 256000 - ingestion_rate_mb: 16 - ingestion_burst_size_mb: 32 - per_stream_rate_limit: 3MB - per_stream_rate_limit_burst: 15MB - max_entries_limit_per_query: 5000 - max_query_series: 500 - max_query_length: 721h - cardinality_limit: 100000 - max_streams_matchers_per_query: 1000 - max_concurrent_tail_requests: 10 - -storage_config: - tsdb_shipper: - active_index_directory: /loki/tsdb-index - cache_location: /loki/tsdb-cache - filesystem: - directory: /loki/chunks - -compactor: - working_directory: /loki/compactor - compaction_interval: 10m - retention_enabled: false - delete_request_store: filesystem - -analytics: - reporting_enabled: false -``` - -### **Docker Compose : Volume Mapping** -```yaml -loki: - image: grafana/loki:latest - container_name: loki - ports: - - "0.0.0.0:3100:3100" - volumes: - - loki_data:/loki - - ./conf/loki/loki-config.yaml:/etc/loki/loki-config.yaml:ro - command: -config.file=/etc/loki/loki-config.yaml - healthcheck: - test: ["CMD", "wget", "-q", "--spider", "http://localhost:3100/ready"] - interval: 30s - timeout: 15s - retries: 3 - start_period: 120s -``` - -## 🎯 Leçons Apprises - -### **1. Diagnostic SystĂ©matique** -- **VĂ©rifier l'Ă©coute rĂ©seau** : `netstat -tlnp` dans le conteneur -- **Tester la connectivitĂ©** : Depuis l'extĂ©rieur ET l'intĂ©rieur du conteneur -- **Analyser les logs** : Rechercher les erreurs de configuration - -### **2. Configuration Loki** -- **Toujours configurer l'Ă©coute** : `http_listen_address: 0.0.0.0` -- **Configurer l'ingester** : SpĂ©cifier `min_ready_duration` -- **Éviter les configurations complexes** : Commencer simple, puis optimiser - -### **3. Healthcheck Docker** -- **Utiliser l'endpoint appropriĂ©** : `/ready` pour Loki -- **Configurer les timeouts** : Adapter au dĂ©lai de dĂ©marrage rĂ©el -- **Tester manuellement** : VĂ©rifier le healthcheck avant de l'automatiser - -## 📝 Commandes de Validation - -### **VĂ©rification de l'Écoute** -```bash -docker exec loki netstat -tlnp | grep 3100 -# Doit montrer : tcp 0 0 :::3100 :::* LISTEN -``` - -### **Test de ConnectivitĂ©** -```bash -# Depuis l'extĂ©rieur -curl -s -o /dev/null -w "%{http_code}" http://localhost:3100/ready -# Doit retourner : 200 - -# Depuis l'intĂ©rieur -docker exec loki wget -q --spider http://localhost:3100/ready && echo "SUCCESS" -# Doit retourner : SUCCESS -``` - -### **Statut Docker** -```bash -docker compose --env-file .env.master ps loki -# Doit montrer : (healthy) ✅ -``` - ---- - -**ProblĂšme rĂ©solu le 2025-09-21** -**Version** : 1.0 -**Statut** : ✅ RÉSOLU - Loki healthy diff --git a/IA_agents/monitoring-progress.md b/IA_agents/monitoring-progress.md deleted file mode 100644 index fab2f20..0000000 --- a/IA_agents/monitoring-progress.md +++ /dev/null @@ -1,319 +0,0 @@ -# Documentation du SystĂšme de Monitoring et Progression - -## Vue d'ensemble - -Ce document dĂ©crit le systĂšme de monitoring et de progression mis en place pour le dĂ©ploiement LeCoffre Node. Le systĂšme permet de suivre en temps rĂ©el la progression des diffĂ©rents processus (IBD Bitcoin, scans BlindBit, synchronisation SDK Relay, etc.) et d'afficher des informations dĂ©taillĂ©es sur l'Ă©tat de tous les services. - -## Architecture du SystĂšme - -### 1. Healthchecks Informatifs dans docker-compose.yml - -Chaque service dispose maintenant d'un healthcheck qui affiche des informations de progression au lieu de simples codes de retour. - -#### Bitcoin Signet -```yaml -healthcheck: - test: ["CMD", "sh", "-c", "info=$(bitcoin-cli -conf=/etc/bitcoin/bitcoin.conf getblockchaininfo 2>/dev/null || echo '{}'); blocks=$(echo \"$info\" | jq -r '.blocks // 0'); headers=$(echo \"$info\" | jq -r '.headers // 0'); if [ \"$blocks\" -eq \"$headers\" ] && [ \"$blocks\" -gt 0 ]; then echo \"Bitcoin sync complete: $blocks blocks\"; exit 0; else echo \"Bitcoin IBD: $blocks/$headers blocks ($(($headers - $blocks)) remaining)\"; exit 1; fi"] - interval: 30s - timeout: 10s - retries: 3 -``` - -**Messages affichĂ©s :** -- `Bitcoin sync complete: 136548 blocks` (quand synchronisĂ©) -- `Bitcoin IBD: 34729/136548 blocks (101819 remaining)` (pendant la synchronisation) - -#### BlindBit Oracle -```yaml -healthcheck: - test: ["CMD", "sh", "-c", "code=$(curl -s -o /dev/null -w '%{http_code}' http://localhost:8000/tweaks/1); if [ \"$code\" = \"200\" ]; then echo \"BlindBit ready: Oracle service responding\"; exit 0; elif [ \"$code\" = \"000\" ]; then echo \"BlindBit starting: Oracle service not yet ready\"; exit 1; else echo \"BlindBit scanning: Oracle responding with code $code\"; exit 1; fi"] - interval: 15s - timeout: 5s - retries: 10 -``` - -**Messages affichĂ©s :** -- `BlindBit ready: Oracle service responding` (prĂȘt) -- `BlindBit starting: Oracle service not yet ready` (dĂ©marrage) -- `BlindBit scanning: Oracle responding with code 404` (scan en cours) - -#### SDK Relay -```yaml -healthcheck: - test: ["CMD", "sh", "-c", "if curl -f http://localhost:8091/ >/dev/null 2>&1; then echo 'SDK Relay ready: WebSocket server responding'; exit 0; else echo 'SDK Relay IBD: Waiting for Bitcoin sync to complete'; exit 1; fi"] - interval: 30s - timeout: 10s - retries: 3 -``` - -**Messages affichĂ©s :** -- `SDK Relay ready: WebSocket server responding` (prĂȘt) -- `SDK Relay IBD: Waiting for Bitcoin sync to complete` (en attente) - -#### Autres Services -Tous les autres services (SDK Storage, SDK Signer, LeCoffre Backend/Frontend, IHM Client, Grafana, Loki, Promtail, Status API) ont des healthchecks similaires avec des messages informatifs. - -### 2. Scripts de Monitoring - -#### monitor-progress.sh -Script principal pour afficher un aperçu complet de tous les services. - -**FonctionnalitĂ©s :** -- Statut de tous les services avec codes couleur -- Progression Bitcoin avec pourcentage et barre de progression -- Progression BlindBit avec Ă©tat du scan -- Progression SDK Relay avec Ă©tat WebSocket -- Statut des autres services - -**Utilisation :** -```bash -./scripts/monitor-progress.sh -``` - -**Exemple de sortie :** -``` -======================================== - LeCoffre Node - Monitoring Progress -======================================== - -Service Status: - ✓ Bitcoin Signet: Ready - ✓ BlindBit Oracle: Ready - ✓ SDK Storage: Ready - ⚠ SDK Relay: Starting/Processing - ✗ LeCoffre Backend: Stopped - ✗ LeCoffre Frontend: Stopped - ✓ IHM Client: Ready - -Bitcoin Progress: - ⏳ Bitcoin IBD: 34729/136548 blocks (101819 remaining) - 25% - -BlindBit Progress: - ✓ BlindBit ready: Oracle service responding - -SDK Relay Progress: - ⏳ SDK Relay starting: WebSocket server not yet ready - -Other Services Progress: - ✓ SDK Storage ready: API responding - ✓ SDK Signer ready: WebSocket server responding - ✓ IHM Client ready: Vite dev server responding - ✓ Grafana ready: Dashboard service responding -``` - -#### watch-progress.sh -Script de surveillance en temps rĂ©el avec rafraĂźchissement automatique. - -**FonctionnalitĂ©s :** -- Mise Ă  jour automatique toutes les 10 secondes -- Barre de progression Bitcoin -- Statut des services en temps rĂ©el -- Services en attente de dĂ©pendances - -**Utilisation :** -```bash -./scripts/watch-progress.sh -``` - -**ContrĂŽles :** -- `Ctrl+C` pour arrĂȘter la surveillance - -#### logs-with-progress.sh -Script pour afficher les logs des services avec informations de progression. - -**FonctionnalitĂ©s :** -- Logs en temps rĂ©el ou statiques -- Informations de progression selon le service -- Support de tous les services -- Options de personnalisation - -**Utilisation :** -```bash -# Logs Bitcoin avec progression -./scripts/logs-with-progress.sh bitcoin -p -n 10 - -# Logs SDK Relay avec progression -./scripts/logs-with-progress.sh sdk_relay -p -f - -# Logs BlindBit avec progression -./scripts/logs-with-progress.sh blindbit -p -n 50 -``` - -**Options :** -- `-f, --follow` : Suivre les logs en temps rĂ©el -- `-n, --lines N` : Afficher les N derniĂšres lignes -- `-p, --progress` : Afficher la progression -- `-h, --help` : Aide - -#### start-with-progress.sh -Script de dĂ©marrage ordonnĂ© avec suivi de progression. - -**FonctionnalitĂ©s :** -- DĂ©marrage des services dans l'ordre correct -- Attente de la santĂ© de chaque service -- Affichage de la progression pendant l'attente -- Test de l'accĂšs externe Ă  la fin - -**Utilisation :** -```bash -./scripts/start-with-progress.sh -``` - -**Ordre de dĂ©marrage :** -1. Tor -2. Bitcoin (avec suivi IBD) -3. BlindBit (avec suivi scan) -4. SDK Storage -5. SDK Relay (avec suivi IBD) -6. SDK Signer -7. IHM Client -8. LeCoffre Backend -9. LeCoffre Frontend -10. Services de monitoring - -## Codes Couleur et Symboles - -### Symboles de Statut -- `✓` : Service prĂȘt et fonctionnel -- `⚠` : Service en cours de traitement -- `⏳` : Service en cours de dĂ©marrage -- `✗` : Service arrĂȘtĂ© ou en erreur -- `â„č` : Service en cours d'exĂ©cution (pas de healthcheck) - -### Codes Couleur -- **Vert** : Service prĂȘt et fonctionnel -- **Jaune** : Service en cours de traitement/dĂ©marrage -- **Rouge** : Service arrĂȘtĂ© ou en erreur -- **Bleu** : Informations gĂ©nĂ©rales -- **Cyan** : Progression spĂ©cifique -- **Violet** : En-tĂȘtes de sections - -## Progression des Services - -### Bitcoin IBD (Initial Block Download) -- **Affichage** : `Bitcoin IBD: 34729/136548 blocks (101819 remaining) - 25%` -- **Barre de progression** : `[████████████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░] 25%` -- **Condition de santĂ©** : `blocks == headers && blocks > 0` - -### BlindBit Oracle -- **États** : Starting → Scanning → Ready -- **Codes HTTP** : 000 (non prĂȘt), 404 (scan), 200 (prĂȘt) -- **Messages** : État du scan et rĂ©ponse du service - -### SDK Relay -- **DĂ©pendance** : Bitcoin synchronisĂ© -- **États** : IBD → WebSocket Ready -- **Messages** : Progression du scan et Ă©tat WebSocket - -## IntĂ©gration avec Docker Compose - -### Variables d'Environnement -Le systĂšme utilise les variables du fichier `.env.master` : -- `SDK_RELAY_*` : Configuration du service relay -- `SIGNER_*` : Configuration du service signer -- `VITE_*` : Configuration des applications frontend - -### Commandes Docker Compose -```bash -# DĂ©marrage avec variables centralisĂ©es -docker compose --env-file .env.master up -d - -# RedĂ©marrage d'un service -docker compose --env-file .env.master restart bitcoin - -# ArrĂȘt de tous les services -docker compose --env-file .env.master down -``` - -## Surveillance et Maintenance - -### VĂ©rification de l'État -```bash -# Statut de tous les services -docker compose --env-file .env.master ps - -# Logs d'un service spĂ©cifique -docker logs bitcoin-signet --tail 50 - -# Healthcheck d'un service -docker inspect --format='{{.State.Health.Status}}' bitcoin-signet -``` - -### DĂ©pannage -1. **Service en Ă©tat "unhealthy"** : VĂ©rifier les logs avec `docker logs ` -2. **Progression bloquĂ©e** : VĂ©rifier la connectivitĂ© rĂ©seau et les dĂ©pendances -3. **Services en attente** : VĂ©rifier que les services de dĂ©pendance sont "healthy" - -## Exemples d'Utilisation - -### Surveillance Continue -```bash -# DĂ©marrer la surveillance en temps rĂ©el -./scripts/watch-progress.sh - -# Dans un autre terminal, afficher les logs -./scripts/logs-with-progress.sh bitcoin -p -f -``` - -### DĂ©marrage Complet -```bash -# ArrĂȘter tous les services -docker compose --env-file .env.master down - -# ✅ DĂ©marrage services applicatifs avec phases -./scripts/start-with-progress.sh - -# ✅ DĂ©marrage monitoring indĂ©pendant -./scripts/start-monitoring.sh - -# ❌ JAMAIS utiliser directement -# docker compose --env-file .env.master up -d -``` - -### VĂ©rification Rapide -```bash -# Aperçu rapide de tous les services -./scripts/monitor-progress.sh - -# Logs rĂ©cents avec progression -./scripts/logs-with-progress.sh sdk_relay -p -n 20 -``` - -## Personnalisation - -### Ajout de Nouveaux Services -1. Ajouter le healthcheck dans `docker-compose.yml` -2. Mettre Ă  jour `monitor-progress.sh` avec le nouveau service -3. Ajouter la logique de progression dans `logs-with-progress.sh` - -### Modification des Intervalles -- **Healthchecks** : Modifier `interval` dans `docker-compose.yml` -- **Surveillance** : Modifier le `sleep` dans `watch-progress.sh` -- **Logs** : Utiliser l'option `-n` pour le nombre de lignes - -## Bonnes Pratiques - -1. **Utiliser les scripts** plutĂŽt que les commandes Docker directes -2. **Surveiller la progression** pendant les dĂ©ploiements -3. **VĂ©rifier les dĂ©pendances** avant de dĂ©marrer les services -4. **Consulter les logs** en cas de problĂšme -5. **Utiliser les variables centralisĂ©es** du fichier `.env.master` - -## DĂ©pannage Courant - -### Bitcoin IBD Lent -- VĂ©rifier la connectivitĂ© rĂ©seau -- VĂ©rifier l'espace disque disponible -- Consulter les logs pour les erreurs de connexion - -### Services en Attente -- VĂ©rifier que les services de dĂ©pendance sont "healthy" -- Consulter les logs des services de dĂ©pendance -- VĂ©rifier la configuration des dĂ©pendances dans `docker-compose.yml` - -### Healthchecks ÉchouĂ©s -- VĂ©rifier que les ports sont accessibles -- Consulter les logs du service -- VĂ©rifier la configuration du healthcheck - -Ce systĂšme de monitoring et de progression permet une surveillance complĂšte et en temps rĂ©el du dĂ©ploiement LeCoffre Node, facilitant le diagnostic et la maintenance des services. diff --git a/IA_agents/quick-reference-monitoring.md b/IA_agents/quick-reference-monitoring.md deleted file mode 100644 index e788d84..0000000 --- a/IA_agents/quick-reference-monitoring.md +++ /dev/null @@ -1,261 +0,0 @@ -# Guide de RĂ©fĂ©rence Rapide - Monitoring LeCoffre Node - -## Commandes Essentielles - -### Surveillance GĂ©nĂ©rale -```bash -# Aperçu complet de tous les services -./scripts/monitor-progress.sh - -# Surveillance en temps rĂ©el -./scripts/watch-progress.sh - -# Logs avec progression -./scripts/logs-with-progress.sh -p -``` - -### DĂ©marrage et ArrĂȘt -```bash -# ✅ DĂ©marrage complet avec phases (OBLIGATOIRE) -./scripts/start-with-progress.sh - -# ✅ DĂ©marrage monitoring indĂ©pendant (OBLIGATOIRE) -./scripts/start-monitoring.sh - -# ❌ JAMAIS utiliser directement -# docker compose --env-file .env.master up -d -# docker compose --env-file .env.master down - -# ArrĂȘt de tous les services -docker compose --env-file .env.master down - -# RedĂ©marrage d'un service -docker compose --env-file .env.master restart -``` - -### VĂ©rification de l'État -```bash -# Statut de tous les services -docker compose --env-file .env.master ps - -# Logs d'un service -docker logs --tail 50 - -# Healthcheck d'un service -docker inspect --format='{{.State.Health.Status}}' -``` - -## Services et Leurs Noms - -| Service | Nom du Conteneur | Port | Description | -|---------|------------------|------|-------------| -| Tor | tor-proxy | 9050 | Proxy SOCKS | -| Bitcoin | bitcoin-signet | 8332 | NƓud Bitcoin Signet | -| BlindBit | blindbit-oracle | 8000 | Oracle BlindBit | -| SDK Storage | sdk_storage | 8081 | Stockage SDK | -| SDK Relay | sdk_relay | 8090-8091 | Relay WebSocket | -| SDK Signer | sdk_signer | 3001 | Service de signature | -| LeCoffre Backend | lecoffre-back | 8080 | API Backend | -| LeCoffre Frontend | lecoffre-front | 3000 | Interface utilisateur | -| IHM Client | ihm_client | 3003 | Client IHM | -| Grafana | grafana | 3005 | Dashboard | -| Loki | loki | 3100 | AgrĂ©gation de logs (config: 0.0.0.0) | -| Promtail | promtail | 9080 | Collection de logs | -| Status API | status-api | 3006 | API de statut | - -## Codes de Statut - -### Symboles -- `✓` : Service prĂȘt et fonctionnel -- `⚠` : Service en cours de traitement -- `⏳` : Service en cours de dĂ©marrage -- `✗` : Service arrĂȘtĂ© ou en erreur -- `â„č` : Service en cours d'exĂ©cution - -### États de Healthcheck -- `healthy` : Service prĂȘt -- `unhealthy` : Service en cours de traitement -- `starting` : Service en cours de dĂ©marrage -- `no-healthcheck` : Pas de healthcheck dĂ©fini - -## Progression des Services - -### Bitcoin IBD -- **Message** : `Bitcoin IBD: 34729/136548 blocks (101819 remaining) - 25%` -- **Condition de santĂ©** : `blocks == headers && blocks > 0` -- **Temps estimĂ©** : Variable selon la vitesse de tĂ©lĂ©chargement - -### BlindBit Oracle -- **États** : Starting → Scanning → Ready -- **Codes HTTP** : 000 (non prĂȘt), 404 (scan), 200 (prĂȘt) -- **Message de santĂ©** : `BlindBit ready: Oracle service responding` - -### SDK Relay -- **DĂ©pendance** : Bitcoin synchronisĂ© -- **États** : IBD → WebSocket Ready -- **Message de santĂ©** : `SDK Relay ready: WebSocket server responding` - -## Architecture de DĂ©ploiement par Phases - -### **Phase 1: Services de Base (ParallĂšle)** -1. **Tor** → 2. **SDK Storage** → 3. **SDK Signer** → 4. **Status API** - -### **Phase 2: Services Blockchain (SĂ©quentiel)** -5. **Bitcoin** → 6. **BlindBit** → 7. **SDK Relay** - -### **Phase 3: Services Applicatifs (SĂ©quentiel)** -8. **LeCoffre Backend** → 9. **LeCoffre Frontend** → 10. **IHM Client** - -### **Phase 4: Services de Monitoring (SĂ©quentiel, IndĂ©pendant)** -11. **Loki** → 12. **Promtail** → 13. **Grafana** - -### **Phase 5: Services Utilitaires** -14. **Watchtower** - -### **Scripts par Phase** -- **Phases 1, 2, 3, 5** : `./scripts/start-with-progress.sh` -- **Phase 4** : `./scripts/start-monitoring.sh` - -## URLs de Test - -### Services Locaux -- Bitcoin RPC : `http://localhost:8332` -- BlindBit : `http://localhost:8000` -- SDK Storage : `http://localhost:8081` -- SDK Relay : `http://localhost:8091` -- SDK Signer : `http://localhost:3001` -- IHM Client : `http://localhost:3003` -- Grafana : `http://localhost:3005` -- Loki : `http://localhost:3100` -- Status API : `http://localhost:3006` - -### Services Externes -- Page de statut : `https://dev4.4nkweb.com/status/` -- API de statut : `https://dev4.4nkweb.com/status/api` -- Grafana : `https://dev4.4nkweb.com/grafana/` -- IHM Client : `https://dev4.4nkweb.com/` -- Application LeCoffre : `https://dev4.4nkweb.com/lecoffre/` -- WebSocket Relay : `https://dev4.4nkweb.com/ws/` - -## DĂ©pannage Rapide - -### Service en État "unhealthy" -```bash -# VĂ©rifier les logs -docker logs --tail 50 - -# VĂ©rifier le healthcheck -docker inspect --format='{{.State.Health.Status}}' -``` - -### Progression Bitcoin BloquĂ©e -```bash -# VĂ©rifier la connectivitĂ© -docker exec bitcoin-signet bitcoin-cli -conf=/etc/bitcoin/bitcoin.conf getblockchaininfo - -# VĂ©rifier les logs -docker logs bitcoin-signet --tail 20 -``` - -### Services en Attente -```bash -# VĂ©rifier les dĂ©pendances -docker compose --env-file .env.master ps - -# VĂ©rifier les logs des services de dĂ©pendance -docker logs --tail 20 -``` - -### Erreurs de Connexion -```bash -# VĂ©rifier la connectivitĂ© rĂ©seau -docker network ls -docker network inspect lecoffre_node_btcnet - -# VĂ©rifier les ports -netstat -tlnp | grep -``` - -## Variables d'Environnement Importantes - -### Fichier .env.master -- `SDK_RELAY_*` : Configuration du service relay -- `SIGNER_*` : Configuration du service signer -- `VITE_*` : Configuration des applications frontend -- `IDNOT_*` : Configuration des APIs notaires -- `STRIPE_*` : Configuration des paiements -- `MAILCHIMP_*` : Configuration des emails -- `OVH_*` : Configuration des SMS - -### Utilisation -```bash -# Toujours utiliser le fichier .env.master -docker compose --env-file .env.master up -d -``` - -## Scripts de Monitoring - -### monitor-progress.sh -- Aperçu complet de tous les services -- Progression Bitcoin avec pourcentage -- Statut des services avec codes couleur -- Progression BlindBit et SDK Relay - -### watch-progress.sh -- Surveillance en temps rĂ©el -- Mise Ă  jour automatique toutes les 10 secondes -- Barre de progression Bitcoin -- Services en attente de dĂ©pendances - -### logs-with-progress.sh -- Logs avec informations de progression -- Support de tous les services -- Options de personnalisation -- Suivi en temps rĂ©el - -### start-with-progress.sh -- DĂ©marrage ordonnĂ© des services -- Attente de la santĂ© de chaque service -- Affichage de la progression -- Test de l'accĂšs externe - -## Bonnes Pratiques - -1. **Utiliser les scripts** plutĂŽt que les commandes Docker directes -2. **Surveiller la progression** pendant les dĂ©ploiements -3. **VĂ©rifier les dĂ©pendances** avant de dĂ©marrer les services -4. **Consulter les logs** en cas de problĂšme -5. **Utiliser les variables centralisĂ©es** du fichier `.env.master` -6. **Tester l'accĂšs externe** aprĂšs le dĂ©ploiement -7. **VĂ©rifier la santĂ© des services** rĂ©guliĂšrement - -## Exemples d'Utilisation - -### DĂ©marrage Complet -```bash -# ArrĂȘter tous les services -docker compose --env-file .env.master down - -# DĂ©marrer avec suivi de progression -./scripts/start-with-progress.sh -``` - -### Surveillance Continue -```bash -# DĂ©marrer la surveillance en temps rĂ©el -./scripts/watch-progress.sh - -# Dans un autre terminal, afficher les logs -./scripts/logs-with-progress.sh bitcoin -p -f -``` - -### VĂ©rification Rapide -```bash -# Aperçu rapide de tous les services -./scripts/monitor-progress.sh - -# Logs rĂ©cents avec progression -./scripts/logs-with-progress.sh sdk_relay -p -n 20 -``` - -Ce guide de rĂ©fĂ©rence rapide permet aux agents IA d'utiliser efficacement le systĂšme de monitoring et de progression du dĂ©ploiement LeCoffre Node. diff --git a/IA_agents/scripts-advanced.md b/IA_agents/scripts-advanced.md deleted file mode 100644 index 6f68b2e..0000000 --- a/IA_agents/scripts-advanced.md +++ /dev/null @@ -1,304 +0,0 @@ -# Scripts AvancĂ©s LeCoffre Node - -## 🚀 Vue d'ensemble - -LeCoffre Node dispose maintenant d'un ensemble complet de scripts pour la gestion, le monitoring et la maintenance de l'architecture complĂšte. - -## 📋 Scripts Principaux - -### `start.sh` - DĂ©marrage SĂ©quentiel Intelligent - -**FonctionnalitĂ©s** : -- DĂ©marrage des services dans l'ordre logique optimal -- Affichage de la progression dĂ©taillĂ©e en temps rĂ©el -- CompatibilitĂ© complĂšte avec Bitcoin Signet -- Gestion des timeouts adaptatifs -- Monitoring des healthchecks intĂ©grĂ©s - -**Utilisation** : -```bash -./scripts/start.sh -``` - -**Progression affichĂ©e** : -- Tor Bootstrap (0-100%) -- Bitcoin IBD (blocs synchronisĂ©s, pourcentage de vĂ©rification) -- BlindBit Oracle (scan des blocs, tweaks dĂ©tectĂ©s) -- SDK Relay (synchronisation, connexions WebSocket) -- SDK Signer (Ă©tat de connexion, clĂ©s disponibles) -- URLs publiques (accessibilitĂ© HTTPS/WebSocket) - -### `validate-deployment.sh` - Validation ComplĂšte - -**FonctionnalitĂ©s** : -- VĂ©rification des volumes Docker (persistance des donnĂ©es) -- Validation des services et healthchecks -- Tests des URLs publiques et WebSockets -- VĂ©rification des scripts et permissions -- Rapport dĂ©taillĂ© avec compteurs - -**Utilisation** : -```bash -./scripts/validate-deployment.sh -``` - -**VĂ©rifications effectuĂ©es** : -- ✅ Volumes Docker (Bitcoin, BlindBit, SDK Storage, SDK Signer, Grafana, Loki) -- ✅ Services (Tor, Bitcoin, BlindBit, SDK Relay, SDK Signer, LeCoffre, IHM, Grafana) -- ✅ URLs publiques (Status, Grafana, Main Site, LeCoffre App) -- ✅ WebSockets (Bootstrap Relay, Signer Service) -- ✅ Scripts (disponibilitĂ© et permissions) - -### `maintenance.sh` - Menu Interactif - -**FonctionnalitĂ©s** : -- Menu interactif pour toutes les tĂąches de maintenance -- Validation complĂšte du dĂ©ploiement -- Sauvegarde et restauration des donnĂ©es -- Nettoyage des logs et images Docker -- VĂ©rification de l'espace disque -- RedĂ©marrage et mise Ă  jour des services - -**Utilisation** : -```bash -./scripts/maintenance.sh -``` - -**Options disponibles** : -1. Validation complĂšte du dĂ©ploiement -2. Sauvegarde des donnĂ©es -3. Nettoyage des logs anciens -4. Nettoyage des images Docker inutilisĂ©es -5. VĂ©rification de l'espace disque -6. RedĂ©marrage des services -7. Mise Ă  jour des images -8. Collecte des logs -9. VĂ©rification de la santĂ© des services - -## đŸ›Ąïž Protection des DonnĂ©es - -### `backup-data.sh` - Sauvegarde Automatique - -**FonctionnalitĂ©s** : -- Sauvegarde de tous les volumes Docker critiques -- CrĂ©ation d'archives compressĂ©es avec timestamps -- Gestion des permissions et erreurs -- Support des volumes Bitcoin, BlindBit, SDK Storage, SDK Signer - -**Utilisation** : -```bash -./scripts/backup-data.sh -``` - -**Volumes sauvegardĂ©s** : -- `4nk_node_bitcoin_data` : DonnĂ©es Bitcoin Signet -- `4nk_node_blindbit_data` : DonnĂ©es BlindBit Oracle -- `4nk_node_sdk_data` : DonnĂ©es SDK Relay -- `4nk_node_sdk_signer_data` : DonnĂ©es SDK Signer -- `4nk_node_sdk_storage_data` : DonnĂ©es SDK Storage -- `4nk_node_grafana_data` : DonnĂ©es Grafana -- `4nk_node_loki_data` : DonnĂ©es Loki - -### `restore-data.sh` - Restauration - -**FonctionnalitĂ©s** : -- Restauration depuis une sauvegarde spĂ©cifiĂ©e -- ArrĂȘt sĂ©curisĂ© des services avant restauration -- Remplacement complet des donnĂ©es existantes -- Gestion des permissions et erreurs - -**Utilisation** : -```bash -./scripts/restore-data.sh -``` - -### `update-images.sh` - Mise Ă  Jour SĂ©curisĂ©e - -**FonctionnalitĂ©s** : -- Sauvegarde automatique avant mise Ă  jour -- TĂ©lĂ©chargement des nouvelles images Docker -- RedĂ©marrage des services avec les nouvelles images -- Protection complĂšte des donnĂ©es - -**Utilisation** : -```bash -./scripts/update-images.sh -``` - -## 📊 Monitoring et Logs - -### `collect-logs.sh` - Collecte des Logs - -**FonctionnalitĂ©s** : -- Collecte automatique ou par service spĂ©cifique -- Organisation par rĂ©pertoires avec timestamps -- Support de tous les services LeCoffre Node - -**Utilisation** : -```bash -# Tous les services -./scripts/collect-logs.sh - -# Service spĂ©cifique -./scripts/collect-logs.sh bitcoin-signet -``` - -**Services supportĂ©s** : -- Tor Proxy, Bitcoin Signet, BlindBit Oracle -- SDK Relay, SDK Signer, SDK Storage -- LeCoffre Backend, LeCoffre Frontend, IHM Client -- Grafana, Loki, Promtail, Status API, Signet Miner - -### `test-monitoring.sh` - Tests de Monitoring - -**FonctionnalitĂ©s** : -- VĂ©rification des services Grafana, Loki, Promtail -- Tests de connectivitĂ© et API -- Validation des dashboards - -### `test-dashboards.sh` - Tests des Dashboards - -**FonctionnalitĂ©s** : -- VĂ©rification des dashboards Grafana -- Tests des sources de donnĂ©es -- Validation des mĂ©triques - -## 🔧 Scripts de Configuration - -### `sync-configs.sh` - Synchronisation - -**FonctionnalitĂ©s** : -- Copie des configurations vers les conteneurs -- Mise Ă  jour des paramĂštres -- RedĂ©marrage des services - -### `sync-monitoring-config.sh` - Configuration Monitoring - -**FonctionnalitĂ©s** : -- Configuration Grafana -- Configuration Loki/Promtail -- DĂ©ploiement des dashboards - -### `setup-logs.sh` - Configuration des Logs - -**FonctionnalitĂ©s** : -- CrĂ©ation des rĂ©pertoires de logs -- Configuration des permissions -- Setup des rotations - -## đŸ› ïž Scripts de Maintenance - -### `fix_relay_funds.sh` - Correction des Fonds - -**FonctionnalitĂ©s** : -- VĂ©rification des fonds du relay -- Correction des problĂšmes -- Tests de connectivitĂ© - -### `optimize-relay-startup.sh` - Optimisation Relay - -**FonctionnalitĂ©s** : -- Optimisation des paramĂštres -- AmĂ©lioration des performances -- Tests de stabilitĂ© - -### `verify_mining_fix.sh` - VĂ©rification Minage - -**FonctionnalitĂ©s** : -- Tests du minage Signet -- VĂ©rification des blocs -- Validation des transactions - -## 🔒 Scripts de SĂ©curitĂ© - -### `generate-ssl-certs.sh` - Certificats SSL - -**FonctionnalitĂ©s** : -- CrĂ©ation des certificats -- Configuration HTTPS -- SĂ©curisation des communications - -### `uninstall-host-nginx.sh` - DĂ©sinstallation Nginx - -**FonctionnalitĂ©s** : -- Nettoyage de Nginx -- Suppression des configurations -- LibĂ©ration des ports - -## 📁 Structure des Volumes - -Les donnĂ©es sont persistĂ©es dans les volumes Docker suivants : - -| Volume | Service | Description | -|--------|---------|-------------| -| `4nk_node_bitcoin_data` | Bitcoin Signet | Blockchain, wallet, configuration | -| `4nk_node_blindbit_data` | BlindBit Oracle | Cache des scans, tweaks dĂ©tectĂ©s | -| `4nk_node_sdk_data` | SDK Relay | Messages, transactions, cache | -| `4nk_node_sdk_signer_data` | SDK Signer | ClĂ©s privĂ©es, signatures, profils | -| `4nk_node_sdk_storage_data` | SDK Storage | DonnĂ©es temporaires, cache | -| `4nk_node_grafana_data` | Grafana | Dashboards, configurations, utilisateurs | -| `4nk_node_loki_data` | Loki | Logs centralisĂ©s, index | - -## 🔄 Workflows RecommandĂ©s - -### DĂ©ploiement Initial -```bash -# 1. DĂ©marrage complet -./scripts/start.sh - -# 2. Validation -./scripts/validate-deployment.sh - -# 3. Tests de monitoring -./scripts/test-monitoring.sh -``` - -### Maintenance RĂ©guliĂšre -```bash -# 1. Menu de maintenance -./scripts/maintenance.sh - -# 2. Sauvegarde manuelle si nĂ©cessaire -./scripts/backup-data.sh - -# 3. Collecte des logs -./scripts/collect-logs.sh -``` - -### Mise Ă  Jour -```bash -# 1. Mise Ă  jour sĂ©curisĂ©e (sauvegarde automatique) -./scripts/update-images.sh - -# 2. Validation post-mise Ă  jour -./scripts/validate-deployment.sh -``` - -### RĂ©cupĂ©ration d'Urgence -```bash -# 1. ArrĂȘt des services -docker compose down - -# 2. Restauration -./scripts/restore-data.sh - -# 3. RedĂ©marrage -./scripts/start.sh -``` - -## ⚠ Notes Importantes - -- **Persistance des donnĂ©es** : Tous les scripts prĂ©servent les donnĂ©es importantes -- **Sauvegardes automatiques** : Les mises Ă  jour incluent une sauvegarde automatique -- **Bitcoin Signet** : Tous les scripts sont compatibles avec le rĂ©seau de test -- **Volumes Docker** : Garantissent la persistance des donnĂ©es entre redĂ©marrages -- **Monitoring intĂ©grĂ©** : Healthchecks et progression en temps rĂ©el -- **SĂ©curitĂ©** : Aucune clĂ© privĂ©e ou secret n'est exposĂ© dans les scripts - -## 📝 Logs et Debugging - -- **Logs des services** : `./logs//` -- **Collecte des logs** : `./scripts/collect-logs.sh` -- **Monitoring** : Grafana sur port 3005 -- **Status API** : Port 3006 -- **Validation** : `./scripts/validate-deployment.sh` diff --git a/IA_agents/todo.md b/IA_agents/todo.md index 380cd60..88e6a2c 100644 --- a/IA_agents/todo.md +++ b/IA_agents/todo.md @@ -1,14 +1,5 @@ # TODO - AmĂ©liorations et optimisations LeCoffre - -### Validation des builds CI -- [ ] VĂ©rifier le succĂšs des builds CI pour tous les services -- [ ] Tester le dĂ©ploiement des nouvelles images optimisĂ©es -- [ ] Valider le fonctionnement des services avec les nouvelles images -- [ ] VĂ©rifier que les dashboards Grafana fonctionnent correctement - -## 📋 TĂąches Ă  faire - ### Monitoring et observabilitĂ© - [ ] Mettre en place des alertes sur la taille des images Docker - [ ] CrĂ©er des mĂ©triques de performance des builds CI diff --git a/IA_agents/troubleshooting-monitoring.md b/IA_agents/troubleshooting-monitoring.md deleted file mode 100644 index ec51336..0000000 --- a/IA_agents/troubleshooting-monitoring.md +++ /dev/null @@ -1,372 +0,0 @@ -# Guide de DĂ©pannage - Monitoring LeCoffre Node - -## ProblĂšmes Courants et Solutions - -### 1. Services en État "unhealthy" - -#### SymptĂŽmes -- Service affichĂ© comme "unhealthy" dans `docker compose ps` -- Healthcheck Ă©choue constamment -- Service ne rĂ©pond pas aux requĂȘtes - -#### Diagnostic -```bash -# VĂ©rifier le statut du healthcheck -docker inspect --format='{{.State.Health.Status}}' - -# VĂ©rifier les logs du healthcheck -docker inspect --format='{{range .State.Health.Log}}{{.Output}}{{end}}' - -# VĂ©rifier les logs du service -docker logs --tail 50 -``` - -#### Solutions -1. **VĂ©rifier la connectivitĂ© rĂ©seau** - ```bash - # VĂ©rifier que le service Ă©coute sur le bon port - docker exec netstat -tlnp - - # VĂ©rifier la connectivitĂ© depuis l'extĂ©rieur - curl -f http://localhost:/health - ``` - -2. **VĂ©rifier les dĂ©pendances** - ```bash - # VĂ©rifier que les services de dĂ©pendance sont "healthy" - docker compose --env-file .env.master ps - ``` - -3. **RedĂ©marrer le service** - ```bash - docker compose --env-file .env.master restart - ``` - -### 2. Progression Bitcoin BloquĂ©e - -#### SymptĂŽmes -- Bitcoin IBD reste Ă  un pourcentage fixe -- Pas de nouveaux blocs tĂ©lĂ©chargĂ©s -- Messages d'erreur dans les logs - -#### Diagnostic -```bash -# VĂ©rifier l'Ă©tat de la blockchain -docker exec bitcoin-signet bitcoin-cli -conf=/etc/bitcoin/bitcoin.conf getblockchaininfo - -# VĂ©rifier les connexions -docker exec bitcoin-signet bitcoin-cli -conf=/etc/bitcoin/bitcoin.conf getpeerinfo - -# VĂ©rifier les logs -docker logs bitcoin-signet --tail 100 | grep -E "(ERROR|error|Error|WARN|warn|Warn)" -``` - -#### Solutions -1. **VĂ©rifier la connectivitĂ© rĂ©seau** - ```bash - # VĂ©rifier que Tor fonctionne - docker logs tor-proxy --tail 20 - - # VĂ©rifier la connectivitĂ© Bitcoin - docker exec bitcoin-signet bitcoin-cli -conf=/etc/bitcoin/bitcoin.conf getnetworkinfo - ``` - -2. **VĂ©rifier l'espace disque** - ```bash - # VĂ©rifier l'espace disponible - df -h - - # VĂ©rifier la taille du volume Bitcoin - docker volume inspect 4nk_node_bitcoin_data - ``` - -3. **RedĂ©marrer Bitcoin** - ```bash - docker compose --env-file .env.master restart bitcoin - ``` - -### 3. Services en Attente de DĂ©pendances - -#### SymptĂŽmes -- Services affichĂ©s comme "Stopped" -- Messages "dependency failed to start" -- Services ne dĂ©marrent pas - -#### Diagnostic -```bash -# VĂ©rifier les dĂ©pendances dans docker-compose.yml -grep -A 5 -B 5 "depends_on" docker-compose.yml - -# VĂ©rifier le statut des services de dĂ©pendance -docker compose --env-file .env.master ps -``` - -#### Solutions -1. **DĂ©marrer les services dans l'ordre correct** - ```bash - # Utiliser le script de dĂ©marrage ordonnĂ© - ./scripts/start-with-progress.sh - ``` - -2. **VĂ©rifier les conditions de dĂ©pendance** - ```bash - # VĂ©rifier que les services de dĂ©pendance sont "healthy" - docker inspect --format='{{.State.Health.Status}}' - ``` - -3. **Modifier temporairement les dĂ©pendances** - ```bash - # Changer condition: service_healthy en condition: service_started - # (Attention : Ă  remettre en place aprĂšs rĂ©solution) - ``` - -### 4. Erreurs de Connexion WebSocket - -#### SymptĂŽmes -- SDK Relay ne rĂ©pond pas sur le port 8091 -- Erreurs 502 Bad Gateway pour les WebSockets -- Messages "TLS support not compiled in" - -#### Diagnostic -```bash -# VĂ©rifier que le service Ă©coute sur le bon port -docker exec sdk_relay netstat -tlnp - -# VĂ©rifier les logs du service -docker logs sdk_relay --tail 50 - -# Tester la connectivitĂ© locale -curl -f http://localhost:8091/ -``` - -#### Solutions -1. **VĂ©rifier la configuration Nginx** - ```bash - # VĂ©rifier la configuration WebSocket - sudo grep -A 10 -B 5 "ws/" /etc/nginx/sites-enabled/dev4.4nkweb.com-https.conf - - # Tester la configuration Nginx - sudo nginx -t - ``` - -2. **VĂ©rifier les variables d'environnement** - ```bash - # VĂ©rifier la configuration du SDK Relay - docker exec sdk_relay env | grep SDK_RELAY - ``` - -3. **RedĂ©marrer le service** - ```bash - docker compose --env-file .env.master restart sdk_relay - ``` - -### 5. ProblĂšmes de Permissions - -#### SymptĂŽmes -- Erreurs "Permission denied" -- Services ne peuvent pas Ă©crire dans les volumes -- Erreurs de montage de volumes - -#### Diagnostic -```bash -# VĂ©rifier les permissions des volumes -docker volume inspect - -# VĂ©rifier les permissions des dossiers locaux -ls -la logs/ -ls -la conf/ -``` - -#### Solutions -1. **Corriger les permissions des volumes** - ```bash - # Corriger les permissions des logs - sudo chown -R 1000:1000 logs/ - sudo chmod -R 755 logs/ - ``` - -2. **VĂ©rifier la configuration des volumes** - ```bash - # VĂ©rifier la configuration dans docker-compose.yml - grep -A 5 -B 5 "volumes:" docker-compose.yml - ``` - -3. **RedĂ©marrer les services** - ```bash - docker compose --env-file .env.master down - docker compose --env-file .env.master up -d - ``` - -### 6. ProblĂšmes de Configuration - -#### SymptĂŽmes -- Services ne dĂ©marrent pas -- Erreurs de configuration dans les logs -- Variables d'environnement manquantes - -#### Diagnostic -```bash -# VĂ©rifier la configuration Docker Compose -docker compose --env-file .env.master config - -# VĂ©rifier les variables d'environnement -docker exec env | grep - -# VĂ©rifier les fichiers de configuration -cat .env.master | grep -``` - -#### Solutions -1. **VĂ©rifier le fichier .env.master** - ```bash - # VĂ©rifier que toutes les variables sont dĂ©finies - docker compose --env-file .env.master config --services - ``` - -2. **Corriger les variables manquantes** - ```bash - # Ajouter les variables manquantes dans .env.master - echo "VARIABLE=valeur" >> .env.master - ``` - -3. **RedĂ©marrer les services** - ```bash - docker compose --env-file .env.master down - docker compose --env-file .env.master up -d - ``` - -## Outils de Diagnostic - -### Scripts de Diagnostic -```bash -# Diagnostic complet -./scripts/monitor-progress.sh - -# Logs avec progression -./scripts/logs-with-progress.sh -p -n 100 - -# Surveillance en temps rĂ©el -./scripts/watch-progress.sh -``` - -### Commandes Docker Utiles -```bash -# Informations dĂ©taillĂ©es sur un service -docker inspect - -# Logs en temps rĂ©el -docker logs -f - -# ExĂ©cuter une commande dans un conteneur -docker exec -it /bin/bash - -# VĂ©rifier l'utilisation des ressources -docker stats -``` - -### Commandes SystĂšme -```bash -# VĂ©rifier l'espace disque -df -h - -# VĂ©rifier la mĂ©moire -free -h - -# VĂ©rifier les processus -ps aux | grep docker - -# VĂ©rifier les ports -netstat -tlnp | grep -``` - -## ProcĂ©dures de RĂ©cupĂ©ration - -### RĂ©cupĂ©ration ComplĂšte -```bash -# ArrĂȘter tous les services -docker compose --env-file .env.master down - -# Nettoyer le systĂšme Docker -docker system prune -af --volumes - -# RedĂ©marrer avec le script de progression -./scripts/start-with-progress.sh -``` - -### RĂ©cupĂ©ration d'un Service -```bash -# ArrĂȘter le service -docker compose --env-file .env.master stop - -# Supprimer le conteneur -docker compose --env-file .env.master rm - -# RedĂ©marrer le service -docker compose --env-file .env.master up -d -``` - -### RĂ©cupĂ©ration des Volumes -```bash -# ArrĂȘter tous les services -docker compose --env-file .env.master down - -# Supprimer les volumes -docker volume rm - -# RedĂ©marrer les services -docker compose --env-file .env.master up -d -``` - -## Logs et Monitoring - -### Logs Importants -```bash -# Logs Bitcoin -docker logs bitcoin-signet --tail 100 - -# Logs SDK Relay -docker logs sdk_relay --tail 100 - -# Logs BlindBit -docker logs blindbit-oracle --tail 100 - -# Logs Nginx -sudo tail -f /var/log/nginx/error.log -``` - -### Monitoring des Ressources -```bash -# Utilisation des ressources -docker stats - -# Espace disque -df -h - -# MĂ©moire -free -h - -# CPU -top -``` - -## PrĂ©vention des ProblĂšmes - -### VĂ©rifications RĂ©guliĂšres -1. **VĂ©rifier l'espace disque** : `df -h` -2. **VĂ©rifier la mĂ©moire** : `free -h` -3. **VĂ©rifier les logs** : `./scripts/monitor-progress.sh` -4. **VĂ©rifier la connectivitĂ©** : Tester les URLs externes - -### Maintenance PrĂ©ventive -1. **Nettoyer les logs** : `docker system prune -f` -2. **VĂ©rifier les mises Ă  jour** : `docker images` -3. **Sauvegarder les configurations** : Copier `.env.master` -4. **Tester les sauvegardes** : VĂ©rifier les volumes - -### Surveillance Continue -1. **Utiliser les scripts de monitoring** : `./scripts/watch-progress.sh` -2. **Configurer des alertes** : Surveiller les logs d'erreur -3. **VĂ©rifier les performances** : `docker stats` -4. **Tester la connectivitĂ©** : VĂ©rifier les URLs externes - -Ce guide de dĂ©pannage permet aux agents IA de diagnostiquer et rĂ©soudre rapidement les problĂšmes courants du systĂšme de monitoring LeCoffre Node.