19 A\\
ET ENCORE
? APUn large éventail de systèmes de no琀椀昀椀ca琀椀ons : Mail , Telegram , RocketChat,Mail, Discord , Services de
SMS
, etc .
notamment pour les bases de données Open Source (PostgreSQL , MySQL ,
REDIS
…) .
A
noter qu’il existe aussi un type de sonde « Push » , des琀椀né à per r me琀琀re la surveillance des services inaccessibles (du fait de FireWall par exemple) par Kuma , ce sont alors ces services qui doivent signaler leur bonne marche en appelant régulièrement l’URL de push associée à la sonde .
Evidemment s’il manque le type de sonde précis dont vous rêvez , le GitHub est ouvert aux contribu琀椀ons .
A\\
COMMENT LE TESTER
? Avec
HELM
si on est sous Kubernetes , ou encore plus simplement en local via Docker : docker run -d --restart=always -p 3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:1 Si vous n’avez pas Docker ou êtes curieux , il y a la démo en ligne : h琀琀ps://up琀椀me.kuma.pet/
A\\
POURQUOI
C’EST
BIEN
? Simplicité et e昀케cacité : APUne
IHM
claire , intui琀椀ve et rapide .
Des concepts intui琀椀fs : sondes , no琀椀昀椀ca琀椀ons… APDes pages de statut claires et jolies APOpen source et populaire : le projet est très ac琀椀f sur GitHub avec plus de 33000 étoiles et plus de 300 contributeurs APPackagé sous forme de
HELM
si vous u琀椀lisez Kubernetes (mise en place en 15 minutes chrono) APEn bonus chaque sonde HTTPs peut signaler l’expira琀椀on prochaine du cer琀椀昀椀cat associé APL’enregistrement de l’historique de l’état des sondes permet , même si l’on ne souhaite pas être no琀椀昀椀é des pannes , d’avoir une mesure de la disponibilité de chaque service dans le temps avec une profondeur d’historique réglable globalement .
Cerise sur le gâteau , la fonc琀椀onnalité de maintenance permet de dé昀椀nir des plages excep琀椀onnelles ou récurrentes pendant les- quelles on ne souhaite pas surveiller telle ou telle sonde , ce qui permet d’éviter les fausses alertes et les sueurs froides associées .
… Bon monitoring ! 1 | Page de statut 2 | Ajout d’une sonde A\\ 2