veza/LOGGING_ISSUES.md

🔍 AUDIT COMPLET DU SYSTÈME DE LOGS VEZA

Date: 2025-01-27
Auditeur: Expert Observabilité
Version: 1.0

---

📋 RÉSUMÉ EXÉCUTIF

Le système de logs Veza présente plusieurs problèmes critiques qui impactent l'observabilité et le debugging :

• Problèmes critiques : 5
• Problèmes majeurs : 8
• Problèmes mineurs : 12
• Recommandations : 15

Impact global : 🔴 ÉLEVÉ - Les logs ne sont pas fiables, la corrélation entre services est absente, et le debugging en production est difficile.

---

1. AUDIT BACKEND GO (veza-backend-api)

1.1 Configuration du Logger

✅ Points Positifs

• Utilisation de zap (logger structuré performant)
• Support de l'agrégation de logs (Loki) via logger_aggregation.go
• Configuration basée sur l'environnement (dev/prod)
• Support des niveaux de log via LOG_LEVEL

❌ Problèmes Identifiés

PROBLÈME #1 : Double Initialisation du Logger

• Fichier : cmd/api/main.go:53 et internal/config/config.go:205
• Description : Le logger est initialisé deux fois :
  1. Dans main.go avec zap.NewProduction() (ligne 53)
  2. Dans config.NewConfig() avec zap.NewProduction() (ligne 205)
• Impact : Le logger de main.go est ignoré, gaspillage de ressources
• Solution : Supprimer l'initialisation dans main.go, utiliser uniquement celui de config.NewConfig()

PROBLÈME #2 : Logger Non Configuré selon LOG_LEVEL

• Fichier : internal/config/config.go:205
• Description : Le logger est créé avec zap.NewProduction() AVANT de lire LOG_LEVEL
• Code problématique :

  logger, err := zap.NewProduction()  // Ligne 205 - ignore LOG_LEVEL
  // ...
  logLevel := getEnv("LOG_LEVEL", "INFO")  // Ligne 221 - lu après
  

• Impact : Le niveau de log est toujours INFO même si LOG_LEVEL=DEBUG est défini
• Solution : Lire LOG_LEVEL AVANT d'initialiser le logger, ou utiliser NewLoggerWithAggregation qui respecte le niveau

PROBLÈME #3 : Logger Temporaire Non Utilisé Correctement

• Fichier : internal/config/config.go:205-340
• Description : Un logger temporaire est créé, puis potentiellement remplacé par un logger avec agrégation, mais les logs initiaux utilisent le mauvais logger
• Impact : Les logs de démarrage peuvent ne pas être envoyés à l'agrégation
• Solution : Initialiser directement le bon logger selon la configuration

PROBLÈME #4 : Sync() Non Garanti au Shutdown

• Fichier : cmd/api/main.go:57, internal/config/config.go:1120
• Description : defer logger.Sync() peut échouer silencieusement, et le flush final n'est pas garanti
• Impact : Perte de logs lors du shutdown
• Solution : Utiliser le ShutdownManager existant pour garantir le flush

1.2 Logs Non Structurés (fmt.Println)

❌ Problèmes Identifiés

PROBLÈME #5 : Utilisation de fmt.Println dans le Code

• Fichiers affectés : 12 fichiers avec fmt.Print*
• Exemples :
  • internal/core/auth/service.go:233 : fmt.Printf(">>> ERROR STRING: %s\n", result.Error.Error())
  • internal/handlers/auth.go:150-167 : Multiples logger.Info("=== DEBUG ===") avec messages de debug
• Impact :
  • Logs non structurés, difficiles à parser
  • Logs de debug en production (sécurité)
  • Pas de corrélation avec request_id
• Solution : Remplacer tous les fmt.Print* par des logs structurés avec zap

PROBLÈME #6 : Logs de Debug Excessifs

• Fichier : internal/handlers/auth.go:150-167
• Description : Logs de debug avec === REGISTER HANDLER CALLED === qui polluent les logs
• Impact : Performance et lisibilité
• Solution : Utiliser logger.Debug() au lieu de logger.Info() pour les logs de debug

1.3 Middleware de Logging HTTP

✅ Points Positifs

• Middleware RequestLogger bien structuré
• Support du request_id pour la corrélation
• Support de trace_id et span_id (T0025)
• Logs structurés avec contexte complet

❌ Problèmes Identifiés

PROBLÈME #7 : Middleware Logger Dupliqué

• Fichier : internal/middleware/logger.go et internal/middleware/request_logger.go
• Description : Deux middlewares de logging existent :
  1. middleware.Logger() - format texte simple (Gin standard)
  2. middleware.RequestLogger() - format structuré avec zap
• Impact : Confusion, logs dupliqués si les deux sont utilisés
• Solution : Supprimer middleware.Logger() (legacy), utiliser uniquement RequestLogger

PROBLÈME #8 : RequestLogger Non Appliqué Globalement

• Fichier : internal/api/router.go
• Description : Le RequestLogger n'est pas visible dans la configuration des routes
• Impact : Les requêtes peuvent ne pas être loggées correctement
• Solution : Vérifier et appliquer RequestLogger dans router.go

PROBLÈME #9 : Pas de Logging des Requêtes Lentes par Défaut

• Fichier : internal/middleware/request_logger.go
• Description : Les requêtes lentes ne sont pas identifiées automatiquement
• Impact : Difficulté à identifier les problèmes de performance
• Solution : Ajouter un seuil de latence configurable (ex: >1s = WARN)

1.4 Gestion des Erreurs

✅ Points Positifs

• Middleware ErrorHandler bien structuré
• Support du contexte (request_id, user_id)
• Intégration avec Sentry

❌ Problèmes Identifiés

PROBLÈME #10 : Erreurs Silencieuses

• Fichier : internal/core/auth/service.go et autres
• Description : Certaines erreurs sont loggées mais pas toutes
• Exemple : if err != nil { return err } sans log
• Impact : Perte d'information pour le debugging
• Solution : Logger toutes les erreurs avec contexte

PROBLÈME #11 : Pas de Corrélation avec les Services Rust

• Description : Le request_id n'est pas propagé vers les services Rust (chat-server, stream-server)
• Impact : Impossible de tracer une requête à travers tous les services
• Solution : Propager le request_id via headers HTTP ou RabbitMQ

---

2. AUDIT SERVICES RUST

2.1 Chat Server (veza-chat-server)

✅ Points Positifs

• Utilisation de tracing (framework moderne)
• Support JSON en production
• Support des spans pour le tracing distribué

❌ Problèmes Identifiés

PROBLÈME #12 : Configuration de Logging Incohérente

• Fichier : veza-chat-server/src/main.rs:84-101
• Description : La configuration du logging est faite directement dans main.rs au lieu d'utiliser veza-common/src/logging.rs
• Impact : Duplication de code, configuration incohérente
• Solution : Utiliser veza_common::logging::init() ou init_with_config()

PROBLÈME #13 : Pas de Corrélation avec Backend Go

• Description : Le request_id du backend Go n'est pas propagé au chat server
• Impact : Impossible de tracer une requête complète
• Solution : Extraire X-Request-ID des headers WebSocket/HTTP et l'utiliser dans les spans

PROBLÈME #14 : Pas de Rotation des Logs

• Fichier : veza-chat-server/src/structured_logging.rs
• Description : Les logs sont envoyés vers stdout mais pas vers des fichiers avec rotation
• Impact : Risque de perte de logs, difficulté de debugging
• Solution : Utiliser tracing-appender pour la rotation

2.2 Stream Server (veza-stream-server)

✅ Points Positifs

• Utilisation de tracing
• Format JSON en production

❌ Problèmes Identifiés

PROBLÈME #15 : Configuration de Logging Dupliquée

• Fichier : veza-stream-server/src/main.rs:18-28
• Description : Même problème que chat-server, configuration dupliquée
• Solution : Utiliser veza-common::logging

PROBLÈME #16 : Pas de Corrélation avec Backend Go

• Même problème que chat-server

2.3 Veza Common (veza-common)

✅ Points Positifs

• Module logging.rs centralisé avec configuration
• Support JSON et texte
• Support de la rotation (configuré mais pas utilisé)

❌ Problèmes Identifiés

PROBLÈME #17 : Module Non Utilisé

• Description : Les services Rust n'utilisent pas veza-common::logging
• Impact : Code dupliqué, configuration incohérente
• Solution : Refactoriser pour utiliser le module commun

---

3. AUDIT FRONTEND REACT (apps/web)

3.1 Système de Logging

✅ Points Positifs

• Logger conditionnel dans utils/logger.ts
• Filtrage selon l'environnement (dev/prod)

❌ Problèmes Identifiés

PROBLÈME #18 : Utilisation Massive de console.log

• Statistique : 192 occurrences de console.log/error/warn dans 72 fichiers
• Impact :
  • Logs non structurés
  • Pas de corrélation avec le backend
  • Difficile à parser et analyser
• Solution : Migrer vers un logger structuré avec corrélation

PROBLÈME #19 : Pas de Logger Structuré

• Fichier : apps/web/src/utils/logger.ts
• Description : Le logger actuel est juste un wrapper autour de console.*
• Impact : Pas de format structuré (JSON), pas de corrélation
• Solution : Implémenter un logger structuré avec :
  • Format JSON optionnel
  • Corrélation avec request_id
  • Envoi vers un endpoint de logging (optionnel)

PROBLÈME #20 : Pas d'Error Tracking

• Description : Pas d'intégration avec Sentry ou autre service d'error tracking
• Impact : Erreurs frontend non trackées
• Solution : Intégrer Sentry pour le frontend

PROBLÈME #21 : Logs de Debug en Production

• Fichier : apps/web/src/utils/logger.ts:21-24
• Description : Les logs debug et info sont filtrés en prod, mais warn et error sont toujours loggés
• Impact : Pollution des logs en production
• Solution : Configurer un niveau de log via variable d'environnement

PROBLÈME #22 : Pas de Corrélation avec Backend

• Description : Les logs frontend n'incluent pas le request_id du backend
• Impact : Impossible de corréler les logs frontend/backend
• Solution : Extraire X-Request-ID des réponses API et l'inclure dans les logs

---

4. PROBLÈMES TRANSVERSAUX

4.1 Corrélation entre Services

PROBLÈME #23 : Pas de Propagation du Request ID

• Description : Le request_id n'est pas propagé entre :
  • Backend Go → Chat Server (Rust)
  • Backend Go → Stream Server (Rust)
  • Backend → Frontend (dans les logs frontend)
• Impact : CRITIQUE - Impossible de tracer une requête complète
• Solution :
  • Propager X-Request-ID via headers HTTP
  • Propager via RabbitMQ (metadata)
  • Utiliser OpenTelemetry pour le tracing distribué

4.2 Configuration des Niveaux de Log

PROBLÈME #24 : Configuration Incohérente

• Backend Go : LOG_LEVEL (INFO, DEBUG, WARN, ERROR)
• Services Rust : RUST_LOG (info, debug, warn, error, trace)
• Frontend : Pas de configuration (hardcodé)
• Impact : Difficile de configurer les niveaux globalement
• Solution : Standardiser sur LOG_LEVEL pour tous les services

4.3 Format des Logs

PROBLÈME #25 : Formats Incohérents

• Backend Go : JSON en prod, console en dev
• Services Rust : JSON en prod, texte en dev
• Frontend : Console (texte)
• Impact : Difficile d'agréger les logs
• Solution : Standardiser sur JSON pour tous les services en production

4.4 Agrégation de Logs

PROBLÈME #26 : Agrégation Non Configurée par Défaut

• Fichier : internal/logging/logger_aggregation.go
• Description : L'agrégation vers Loki existe mais est désactivée par défaut
• Impact : Logs dispersés, difficile à analyser
• Solution : Activer l'agrégation par défaut en production

---

5. PROBLÈMES DE PERFORMANCE

PROBLÈME #27 : Logs Synchrones

• Description : Tous les logs sont synchrones (bloquants)
• Impact : Performance dégradée sous charge
• Solution : Utiliser des buffers asynchrones pour les logs non critiques

PROBLÈME #28 : Pas de Sampling

• Description : Tous les logs sont envoyés, même les plus verbeux
• Impact : Coût élevé en stockage et bande passante
• Solution : Implémenter un sampling pour les logs DEBUG/INFO

---

6. PROBLÈMES DE SÉCURITÉ

PROBLÈME #29 : Logs de Debug en Production

• Fichier : internal/handlers/auth.go:150-167
• Description : Logs de debug avec === DEBUG === en production
• Impact : Fuite d'information, performance
• Solution : Utiliser logger.Debug() et désactiver en prod

PROBLÈME #30 : Secrets Potentiellement Loggés

• Description : Risque de logger des secrets (tokens, passwords) dans les erreurs
• Impact : CRITIQUE - Fuite de secrets
• Solution : Implémenter un filtre de secrets dans le logger

---

7. RÉSUMÉ DES PROBLÈMES PAR PRIORITÉ

🔴 CRITIQUE (P0)

1. PROBLÈME #23 : Pas de propagation du Request ID entre services
2. PROBLÈME #30 : Risque de logger des secrets
3. PROBLÈME #2 : Logger non configuré selon LOG_LEVEL

🟠 MAJEUR (P1)

4. PROBLÈME #5 : Utilisation de fmt.Println (12 fichiers)
5. PROBLÈME #18 : 192 console.log dans le frontend
6. PROBLÈME #12 : Configuration de logging incohérente (Rust)
7. PROBLÈME #7 : Middleware logger dupliqué
8. PROBLÈME #26 : Agrégation non configurée par défaut

🟡 MOYEN (P2)

9. PROBLÈME #6 : Logs de debug excessifs
10. PROBLÈME #10 : Erreurs silencieuses
11. PROBLÈME #19 : Pas de logger structuré frontend
12. PROBLÈME #24 : Configuration incohérente des niveaux

🟢 MINEUR (P3)

13. PROBLÈME #1 : Double initialisation du logger
14. PROBLÈME #4 : Sync() non garanti
15. PROBLÈME #9 : Pas de logging des requêtes lentes
16. PROBLÈME #20 : Pas d'error tracking frontend

---

8. MÉTRIQUES D'IMPACT

Impact sur le Debugging

• Temps moyen pour tracer une requête : ⚠️ IMPOSSIBLE (pas de corrélation)
• Temps pour identifier une erreur : 🔴 ÉLEVÉ (logs dispersés)
• Visibilité des erreurs : 🟡 MOYENNE (certaines erreurs silencieuses)

Impact sur la Performance

• Overhead de logging : 🟡 MOYEN (logs synchrones)
• Stockage des logs : 🟠 ÉLEVÉ (pas de sampling, agrégation désactivée)

Impact sur la Sécurité

• Risque de fuite de secrets : 🔴 ÉLEVÉ (pas de filtre)
• Logs de debug en prod : 🟠 MOYEN (présents mais limités)

---

9. RECOMMANDATIONS PRIORITAIRES

Phase 1 : Corrections Critiques (1-2 semaines)

1. ✅ Implémenter la propagation du Request ID entre tous les services
2. ✅ Corriger la configuration du logger selon LOG_LEVEL
3. ✅ Implémenter un filtre de secrets dans le logger
4. ✅ Remplacer tous les fmt.Println par des logs structurés

Phase 2 : Standardisation (2-3 semaines)

5. ✅ Standardiser la configuration de logging (Rust)
6. ✅ Implémenter un logger structuré frontend
7. ✅ Activer l'agrégation de logs par défaut en production
8. ✅ Standardiser les formats de logs (JSON en prod)

Phase 3 : Améliorations (3-4 semaines)

9. ✅ Implémenter le sampling des logs
10. ✅ Ajouter l'error tracking frontend (Sentry)
11. ✅ Implémenter la rotation des logs (Rust)
12. ✅ Ajouter le logging asynchrone pour les logs non critiques

---

10. PROCHAINES ÉTAPES

1. Valider ce rapport avec l'équipe
2. Prioriser les problèmes selon les besoins business
3. Créer des tickets pour chaque problème prioritaire
4. Implémenter les corrections par phase
5. Valider les corrections avec des tests d'intégration

---

Fin du rapport d'audit