# Mise en place d'une synchronisation Zabbix - Uptime Kuma

# Contexte et objectif

Dans le cadre de mon travail, nous utilisons Zabbix comme outil de supervision afin de surveiller la disponibilité et la santé de plusieurs sites distants. Bien que Zabbix soit très complet, il n'est pas toujours adapté pour partager directement son interface avec des utilisateurs finaux ou des équipes non techniques.

**Problème** : comment fournir une **page de statut** simple et claire à ces utilisateurs (leur indiquant quels sites sont opérationnels ou en panne) **sans** devoir leur donner accès à Zabbix (et donc aux détails complets de la supervision) ?

La solution que j'ai trouvée était de déployer [Uptime Kuma](https://github.com/louislam/uptime-kuma) pour générer et publier une page de statut, puis le synchroniser avec Zabbix via un script Python qui récupère automatiquement la liste des hôtes et leur état.  
  
Pour installer Uptime Kuma, vous pouvez vous rendre sur [cette page](https://librenard.fr/wiki/books/mise-de-place-duptime-kuma)

# 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.

# Mise en service

## Mise en service automatique (systemd)

Pour exécuter le script à chaque démarrage du serveur Zabbix :

- Créer un fichier de service `zabbix-kuma-sync.service` dans `/etc/systemd/system/`, par exemple :

```bash
[Unit]
Description=Synchronisation Zabbix → Uptime Kuma
After=network.target

[Service]
Type=simple
ExecStart=/usr/bin/python3 [Chemin vers le script]
Restart=on-failure
User=appliance

[Install]
WantedBy=multi-user.target

```

<div class="contain-inline-size rounded-md border-[0.5px] border-token-border-medium relative bg-token-sidebar-surface-primary dark:bg-gray-950" id="bkmrk-activer-et-lancer-le"><div class="flex items-center text-token-text-secondary px-4 py-2 text-xs font-sans justify-between rounded-t-md h-9 bg-token-sidebar-surface-primary dark:bg-token-main-surface-secondary select-none">- Activer et lancer le service :

</div></div>```bash
sudo systemctl enable zabbix-kuma-sync.service
sudo systemctl start zabbix-kuma-sync.service
```

- Vérifier qu'il tourne correctement :

```bash
systemctl status zabbix-kuma-sync.service
```

### Configuration de la page de statut Uptime Kuma

Une fois les moniteurs créés automatiquement :

1. **Moniteurs** :
    
    
    - URL pointée : `http://nepaschanger.no/` (inexistante).
    - Intervalle de vérification : 260000 secondes.
    - Par défaut, le script active le mode inversé, donc l’hôte s’affiche “Up” même si l’URL est inaccessible.
2. **Status Page** :
    
    
    - Uptime Kuma propose la création d’une page de statut publique ou interne, consultable par les utilisateurs finaux.
    - Les hôtes y apparaissent Up ou Down suivant leur *mode inversé*.
3. **Personnalisation CSS** :
    
    
    - Pour n’afficher que les hôtes en **Down**, un CSS personnalisé masque ceux en **Up**. 
        - Cette personnalisation se fait dans les paramètres de la page de statut de Kuma (Settings → Status Page → Custom CSS).

```css
.monitor-list > .item:has(.bg-primary) {
    display: none !important;
}
```

De cette manière, les utilisateurs qui consultent la page de statut n’ont **pas** besoin d’accéder à Zabbix : ils voient uniquement la liste des hôtes impactés (en panne), ce qui remplit l’objectif d’une interface simple et dépouillée.

## Résultat et avantages

- **Page de statut** : indique clairement quels sites distants sont en panne sans exposer l’interface complexe de Zabbix.
- **Sécurité** : l’utilisateur “API” de Zabbix n’a accès qu’au groupe d’hôtes que je souhaite et à leurs déclencheurs, pas à l’ensemble du monitoring ou de la configuration.
- **Automatisation** : le script se lance au démarrage, met à jour Uptime Kuma sans intervention manuelle.
- **Performance** : les checks étant inversés et programmés sur un intervalle très long, la surcharge réseau est quasi inexistante.

Ce système répond parfaitement au besoin de “vitrine” ou de “tableau de bord” : une **page de statut** sur laquelle ne figurent que les pannes, gérée de manière automatique, tout en évitant la complexité de l’interface Zabbix et en protégeant les données sensibles de l’outil de supervision.