Hello world !
Avec un peu de retard, voici l’article d’avril 😉
Surveiller la disponibilité de ses services web est essentiel, que l’on soit développeur, administrateur système ou simplement passionné d’infrastructure. Il existe une multitude de solutions professionnelles et/ou open source comme Nagios, Centreon, Zabbix. Ce sont des solutions très complètes mais assez lourde à mettre en œuvre, et donc pas forcément adaptées à des besoins simples (home lab, infra TPE, etc…)
Et c’est là qu’entre en jeu Uptime Kuma ☺
Qu’est ce qu’Uptime Kuma ?
Uptime Kuma est un outil de monitoring libre et open-source, pensé pour être à la fois simple à utiliser et puissant.
Décrit comme l’alternative auto-hébergée à des solutions comme UptimeRobot, Uptime Kuma permet de surveiller facilement l’état de vos sites web, serveurs, API ou encore ports réseau. Il propose une interface web moderne, des notifications via de nombreux canaux (Discord, Telegram, email, etc.), et une installation rapide grâce à Docker.
Uptime Kuma est particulièrement apprécié pour sa facilité de déploiement, ses fonctionnalités complètes sans abonnement, et sa communauté active.
Comment déployer Uptime Kuma rapidement et facilement ?
Le plus simple reste d’utiliser Docker avec Portainer. Je ne vais pas rentrer dans le détail sur « comment installer Portainer chez soi« , il existe moult tutoriels sur Internet 😉
Sur Portainer, créer un volume dédié à Uptime Kuma
Ensuite, créer un nouveau container
Configurer les paramètres suivants :
- Image : louislam/uptime-kuma
- Add additional port : choisir un port TCP libre et le mapper au port 3001 du container
Dans les paramètres avancés, section « Volumes »
- Mapper le volume créé à l’étape précédente sur le chemin /app/data
- (optionnel) Mapper le chemin /var/run/docker.sock si vous souhaitez superviser les conteneurs de l’hôte docker
Et déployer 🙂
Il vous sera demandé au boot de choisir un login et mot de passe admin, et un type de base de données (choisir SQlite si petit besoin)
Créer sa première sonde
On commence par ajouter une nouvelle sonde.
On va faire simple : un PING. Comme on peut voir, c’est très simple à configurer : un nom, une IP ou un nom d’hôte, un intervalle de tests, et le nombre de tests consécutifs avant de considérer la sonde comme « down »
On a ensuite possibilité de configurer une notification, et là on a l’embarras du choix !
- SMTP classique
- Services en ligne de SMS
- Services de tchat : Telegram, Signal, Discord, Teams, …
- Services en ligne de notification : Ntfy, Pushover, Pushbullet, …
Ici on va faire avec un service accessible publiquement : Ntfy.sh
Et voilà, vous avez votre première sonde qui fonctionne. Et voici le résultat après avoir généré volontairement une panne furtive :
Monitorer le FortiGate en API
Si on veut récupérer des infos précises, le mieux est de le faire en API. Tout est bien documenté sur le FNDN.
En préambule, il faut créer un compte API REST sur le FortiGate.
On précise le compte API, les droits et l’IP du serveur Uptime Kuma
On obtient une clé API, qu’on garde précieusement de côté !
Reste plus qu’à récupérer de l’info. On va ici faire un exemple avec des tests de santé SD-WAN. La requête API permettant de récupérer les informations est /api/v2/monitor/virtual-wan/health-check
Si on l’insère dans le navigateur, on obtient directement le résultat JSON.
La réponse souhaitée est dans results > nom du test de santé > interface WAN. Pour l’exemple ci-dessous on va s’intéresser à un test de santé qui s’appelle « Internet_IPV4 » et qui inclue notamment l’interface « wan1 ».
On revient à Uptime Kuma, on ajoute une sonde de type HTTP(s) – Requête JSON. On insère notre URL « https://x.x.x.x/api/v2/monitor/virtual-wan/health-check«
Au niveau du champ « requête JSON », il faut préciser comment on doit analyser la réponse. Pour cela Uptime Upma utilise JSONata, et dans notre cas la syntaxe est « results.Internet_IPV4.wan1.status » (on récupère l’état de « wan1 » sur le test de santé « Internet_IPV4 ») et la valeur attendue est « up ».
La requête nécessitant notre clé API, on va la préciser dans les headers de la requête comme suit :
{
"Authorization": "Bearer tj58fGmbz.............6jbpbN4"
}
Reste à décocher la case pour la vérification des certificats si vous utilisez un auto-signé :
Jouer avec JSONata pour analyser des données
JSONata contient plein de filtres bien documentés, mais si on veut faire un cas d’usage concret, on peut lever une alarme si un lien WAN est en panne quel que soit le lien. Pour cela on va demander à JSONata de :
- Pour chaque lien WAN du health check « Internet_IPV4 », récupérer la clé « status » et copier la valeur dans une liste
- Filtrer cette liste pour ne garder que les valeurs égales à « down »
- Compter le nombre d’entrées dans la liste résultante
- Retourner un booléen « vrai » si égal à 0
$count($filter(results.Internet_IPV4.*.status, function($v) { $v = "down" })) = 0Ce qui donne dans Uptime Kuma :
A noter que les valeurs de status sont « up », « down » ou « error » (le health check ne monitore pas le lien sélectionné) –> Donc compter le nombre d’occurences de « down » suffit 😊)
Il vous reste plus qu’à découvrir l’API puis à traiter les données à superviser comme bon vous semble !
A noter une limitation assez gênante, chaque sonde est indépendante, il n’est pas possible d’avoir des variables globales (une clé API par exemple) partagée entre plusieurs sondes…
Pour aller plus loin…
FortiManager en mode proxy
Il est également possible d’utiliser un FortiManager en tant que Proxy pour récupérer les informations sur un FortiGate cible.
Cela va nécessiter quelques adaptations
- On va requêter sur /jsonrpc sur le FortiManager
- On va envoyer ce qu’on souhaite récupérer dans le corps de la requête, au format json
- Le token à soumettre pour l’authentification est celui du FortiManager, il n’est pas nécessaire d’avoir un compte API sur le FortiGate
- Attention les requêtes adressées au FMG sont de type POST
Voici un exemple de requête à adapter à votre contexte
{
"id": 42,
"jsonrpc": "1.0",
"method": "exec",
"params": [
{
"data": {
"action": "get",
"resource": "/api/v2/monitor/virtual-wan/health-check",
"target": [
"adom/root/device/NOM_DU_FW_SUR_LE_FMG"
]
},
"url": "/sys/proxy/json"
}
]
}Et voici comment récupérer le résultat avec JSONata
result[0].data[0].response.results.Internet_IPV4.wan1.status
Construire une supervision automatique
Uptime Kuma est pilotable en API, il est donc possible de créer ou mettre à jour des sondes automatiquement via un script. On peut imaginer un outil qui ajouterait des nouvelles sondes à partir d’une source de vérité (un FortiManager contenant des FortiGate) et un canvas de sondes à construire par équipement… une idée à creuser 😉