db306433d5
- Pas de stack dédiée : une instance Prometheus/Grafana existe déjà sur ce serveur pour les 5 autres projets. En déployer une seconde aurait dupliqué de la RAM sur une machine à 3.7 Go partagée, sans bénéfice - même raisonnement que pour Caddy en Phase 2. - Scrape job tripoli_edge (172.17.0.1:9000, même passerelle docker0 que Caddy) ajouté à la config Prometheus existante. - Règles d'alerte : TripoliEdgeDown (up == 0), HostDiskAlmostFull (< 10% d'espace libre sur / - au niveau de la machine, pas seulement de ce projet, puisqu'il n'y a qu'un disque pour tout le monde). - Sonde blackbox externe ajoutée pour https://tripoli.cloud/healthz. - Dashboard Grafana versionné (uid tripoli-cloud-edge), importé via l'API (POST /api/dashboards/db) pour rester reproductible, pas construit à la main dans l'UI. - Vérifié : tous les targets Prometheus up (dont tripoli_edge et la sonde tripoli.cloud), les deux règles d'alerte chargées et évaluées, les requêtes du dashboard retournent de vraies valeurs. - Limite assumée : les alertes se déclenchent dans Prometheus mais ne sont pas encore routées par email (pas d'Alertmanager, pas de policy de notification Grafana dédiée) - documenté comme prochain pas, pas fait pour éviter de modifier la politique de notification globale de l'instance partagée sans plus de tests. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| grafana-dashboard-tripoli-edge.json | ||
| prometheus-scrape-snippet.yml | ||
| README.md | ||
| tripoli-cloud-alerts.yml | ||
Observabilité
Pas de Prometheus/Grafana dédiés à Tripoli Cloud : une instance de chacun existe déjà sur ce serveur, partagée avec les 5 autres projets qui y tournent. En déployer une seconde aurait dupliqué de la RAM sur une machine à 3.7 Go déjà partagée, pour un bénéfice nul - même raisonnement que pour Caddy en Phase 2.
Ce qui a été ajouté à l'instance existante
- Scrape job
tripoli_edge(prometheus-scrape-snippet.yml, appliqué à/opt/monitoring/prometheus/prometheus.ymlsur le serveur) :172.17.0.1:9000/metrics- même passerelle docker0 que Caddy utilise pour joindre tripoli-edge. - Règles d'alerte (
tripoli-cloud-alerts.yml, montée dans le conteneur Prometheus) :TripoliEdgeDown:up{job="tripoli_edge"} == 0pendant 2 minutes.HostDiskAlmostFull: moins de 10% d'espace libre sur/pendant 10 minutes - une alerte au niveau de la machine, pas seulement de Tripoli Cloud, puisqu'il n'y a qu'un seul disque pour tous les projets hébergés.
- Sonde blackbox externe :
https://tripoli.cloud/healthzajoutée à la liste existante du jobblackbox_http(vérifie que le site répond réellement depuis l'extérieur, pas seulement que Prometheus arrive à le scraper en interne). - Dashboard Grafana (
grafana-dashboard-tripoli-edge.json,uid: tripoli-cloud-edge) : état up/down, requêtes en cours, latence moyenne, requêtes par classe de statut, et l'espace disque de l'hôte. Importé via l'API Grafana (POST /api/dashboards/db), pas par copier- coller dans l'UI - c'est ce qui permet de le garder versionné ici et de le réimporter à l'identique si besoin.
Ce qui n'a pas été fait
Les règles d'alerte existent et se déclenchent dans Prometheus (vérifiable
via /api/v1/rules), mais rien ne les notifie encore par email - pas
d'Alertmanager déployé, et pas de policy de notification Grafana
configurée pour ces alertes spécifiquement. Grafana a déjà un SMTP
fonctionnel (utilisé par d'autres projets sur cette instance) ; y
brancher les alertes de Tripoli Cloud est le prochain pas naturel, pas
fait dans cette passe pour éviter de modifier la politique de
notification globale de l'instance partagée sans plus de tests.
Vérifié
$ curl .../api/v1/targets -> tripoli_edge: up, blackbox tripoli.cloud/healthz: up
$ curl .../api/v1/rules -> groupe "tripoli-cloud" : TripoliEdgeDown, HostDiskAlmostFull
$ curl .../api/v1/query?query=up{job="tripoli_edge"} -> 1
Dashboard accessible sur https://grafana.belkacemi.me/d/tripoli-cloud-edge/.