# Préparatifs

### Création d'un utilisateur et d'un groupe "API" dans Zabbix

Pour laisser le script accéder à Zabbix sans exposer d’autres informations :

1. **Créer un utilisateur** dédié : 
    - Nom : `API`
    - Groupe : `API`
    - Rôle : `API` (lecture seule).
2. **Permissions** : limitées uniquement au groupe d’hôtes que je souhaite récupérer 
    - L’utilisateur `API` peut lire la liste des hôtes et des déclencheurs (*Triggers*) pour ces hôtes spécifiques.  
        Cela me permettra notamment de voir les hôtes ayant une alerte "critique" et donc de détecter quel hôte est réellement "Down" ou non.

### Script Python de synchronisation (Zabbix -> Uptime Kuma)

J'ai ensuite crée un script Python qui effectue les opérations suivantes :

- **Connexion** à l’API de Zabbix avec l’utilisateur `API`.
- **Récupération** de tous les hôtes du groupe que je souhaite récupérer
- **Nettoyage** du nom de l’hôte en retirant le préfixe “Site <ip>” spécifique a mon entreprise pour obtenir un libellé plus lisible.
- **Création ou mise à jour** du moniteur correspondant dans Uptime Kuma via la librairie python [uptime-kuma-api](https://github.com/lucasheld/uptime-kuma-api)
- **Vérification** s’il existe un déclencheur de niveau 5 (critique) actif pour chaque hôte : 
    - S’il y a un déclencheur critique → le moniteur sera forcé en mode *Down* dans Uptime Kuma.
    - Sinon → le moniteur est en mode “inversé” (toujours Up en apparence).

**Pourquoi “Mode Inversé” ?**  
Parce que nous pointons chaque moniteur vers une URL inexistante, ce qui le mettrait automatiquement en échec (Down). Activer le “mode inversé” dans Uptime Kuma permet de considérer ce faux échec comme un Up “normal”.

- En clair, **pas de problème** = *Mode inversé* activé → Affiché Up.
- **Problème critique** = on désactive le *Mode inversé* → Affiché Down.

### Intervalle de vérification (3 jours)

Pour éviter de “polluer” inutilement le réseau et le serveur Uptime Kuma avec un check qui n’a pas de raison d’être réel, on a défini un intervalle de **260000 secondes (environ trois jours)**. Ainsi, Uptime Kuma ne fera pratiquement jamais de requête significative (car la cible `http://nepaschanger.no/` est fictive), mais cela reste suffisant pour maintenir la configuration voulue.