Documentation InfraWatts
Comprendre les données, les recommandations et les limites avant de décider quoi réduire, préparer ou conserver.
Fonctionnement du produit
InfraWatts rassemble les métriques de votre infrastructure pour détecter le gaspillage et prioriser des recommandations. La sonde identifie d’abord l’hôte Linux ou Windows, puis détecte indépendamment Docker et Kubernetes. Un hôte Linux reste un hôte Linux même lorsque ces runtimes sont présents.
Le tableau de bord, l’assistant, les alertes, les recommandations et les exports lisent le même état serveur. Les recommandations reposent sur les métriques observées et leur contexte ; un inventaire seul ne prouve pas un gain. La sonde sélectionnée reste le périmètre par défaut.
Périmètre de l’assistant
L’assistant utilise par défaut la sonde sélectionnée. Une question globale peut élargir l’analyse à plusieurs sondes ; une mention explicite d’une autre sonde peut changer le périmètre si elle appartient à votre compte.
Les commandes /infra, /alerts et /agent <name> permettent de préciser la demande. Le contexte visible peut inclure la sonde, les runtimes et l’état Kubernetes. Une recommandation d’action n’est pas une preuve d’exécution.
Détection des environnements
La plateforme hôte est identifiée avant les runtimes. Détection et disponibilité sont distinctes : Docker ou Kubernetes peuvent être détectés tout en étant indisponibles.
k8s_not_configured indique l’absence de contexte Kubernetes utilisable ; k8s_unreachable indique un cluster configuré mais inaccessible ; docker_unavailable indique un daemon Docker inaccessible. Ces avertissements restent visibles même en l’absence d’alerte critique.
Alertes et gravité
Les alertes critical signalent notamment une sonde hors ligne, un runtime configuré inaccessible ou un risque sévère. Les alertes warning couvrent les dégradations, la pression CPU ou mémoire et les problèmes de configuration. Les alertes info apportent des indications à faible risque.
Le centre d’alertes regroupe incidents et avertissements de runtime avec la sonde, la cause et les détails disponibles. L’absence d’alerte critique ne signifie pas l’absence de tout avertissement. Masquer une alerte ne corrige pas l’infrastructure.
Score d’efficacité
Le score de 0 à 100 combine l’utilisation CPU observée et la puissance estimée ou disponible pour aider à repérer le sous-usage, les zones efficaces et la surcharge. Un CPU très peu utilisé ou une consommation disproportionnée peut réduire le score.
Ce score aide à prioriser les pistes d’optimisation. Il ne remplace pas la validation des pics, de la mémoire, des dépendances et de la capacité nécessaire à votre charge.
Recommandations de dimensionnement
Les recommandations relient CPU, RAM, contexte d’hébergement et catalogue fournisseur lorsqu’il est disponible. Une recommandation générique reste possible sur un serveur physique ou lorsque le fournisseur est incertain.
La recommandation indique sa confiance, le profil cible, les limites et l’impact estimé disponible. L’instance affichée est un exemple de catalogue. Validez dépendances, pics, risque et retour arrière avant toute modification ; une économie estimée n’est pas une économie encaissée.
Rapports et exports
Les exports JSON, CSV et PDF partagent un jeu de données normalisé : hôtes, énergie cumulée, CO₂ cumulé et séries temporelles par sonde. Ils sont des supports de décision basés sur les données disponibles.
Vous pouvez choisir toutes les sondes ou un sous-ensemble et sélectionner la langue du rapport. Le PDF expose les hypothèses et les limites de mesure. La fenêtre observée, la fenêtre de décision et la fenêtre de stratégie sont distinctes.
API et OpenAPI
La documentation interactive est accessible sur /api/docs/ et le schéma sur /api/schema/. Les accès authentifiés restent soumis aux droits du compte.
Le périmètre /api/v1/ documenté comprend GET /api/v1/agents (sondes et résumé des alertes), GET /api/v1/metrics (métriques), GET /api/v1/alerts (alertes), GET /api/v1/recommendations (recommandations) et GET /api/v1/audit (jeu de données du rapport).