Français
Uptime Kuma Hébergement
Surveiller les services avec des vérifications de statut, des notifications, un historique et des pages de statut publiques.
- Un clic déployer
- 15 Go Espace disque nécessaire
- 1 Go de RAM Mémoire nécessaire
- À partir de 2 € Prix
Pas de frais d'installation
Liens officiels
Les liens officiels et le site web original de Uptime Kuma
- Plus
Site web de Uptime Kuma
Ce que vous obtenez
sur AvaHost
Le déploiement en un clic, un domaine personnalisé, HTTPS gratuit, des mises à jour automatiques des applications et des sauvegardes programmées sont inclus avec chaque application Cloud. Vous pouvez exécuter plusieurs applications sur un seul serveur, et l'accès au terminal est inclus.
Ce modèle n'inclut pas de conteneur de base de données.
Tech
- Image Docker
- louislam/uptime-kuma:2
- Port par défaut
- 3001
Comment fonctionne Uptime Kuma
Uptime Kuma planifie les moniteurs pour les protocoles supportés et enregistre chaque résultat au fil du temps. Les vérifications HTTP et par mot-clé peuvent tester un endpoint web, les moniteurs TCP vérifient qu'un port accepte les connexions, ping et DNS couvrent la disponibilité de base, les moniteurs push reçoivent un heartbeat externe, et d'autres types de moniteurs couvrent les services documentés. Les tableaux de bord affichent l'état actuel, l'historique, le temps de réponse, les certificats, les incidents et les périodes de maintenance.
Chaque résultat reflète la position réseau et les permissions du serveur de monitoring. Un service accessible depuis un autre pays ou un réseau privé peut sembler différent du nœud hébergé, et un seul emplacement ne peut pas prouver la disponibilité mondiale. Le catalogue ne monte pas de socket Docker, donc le monitoring du host Docker ne fait pas partie du package par défaut. Les cibles privées doivent être accessibles via un chemin réseau autorisé.
Fonctionnalités clés d'Uptime Kuma
Les intégrations de notification peuvent transférer les changements d'état vers de nombreux fournisseurs supportés, tandis que les pages de statut publient les moniteurs sélectionnés pour les utilisateurs ou les clients. Ces canaux nécessitent des comptes externes, des webhooks, des bots, des fournisseurs de téléphonie ou de messagerie, et une configuration des destinataires. L'email d'application est désactivé, donc les notifications Uptime Kuma basées sur SMTP ne peuvent pas envoyer de courrier depuis l'installation hébergée.
Les fenêtres de maintenance peuvent supprimer les alertes attendues, et les informations de certificat aident à identifier l'expiration imminente où le moniteur peut inspecter TLS. Uptime Kuma est un vérificateur de disponibilité plutôt qu'une plateforme d'observabilité complète : il ne collecte pas chaque trace d'application, ne corrèle pas les incidents distribués, ne fournit pas de personnel d'astreinte, et ne répare pas un service défaillant.
Uptime Kuma vs UptimeRobot
Uptime Kuma
Uptime Kuma et UptimeRobot surveillent tous deux les endpoints, envoient des alertes et publient des pages de statut. Uptime Kuma est une application auto-hébergée dont les vérifications proviennent du serveur déployé. UptimeRobot est un service géré par le fournisseur avec des emplacements de monitoring hébergés, des plans de compte, des canaux d'alerte et une infrastructure de page de statut public maintenue.
UptimeRobot
UptimeRobot peut convenir aux équipes qui souhaitent que le monitoring soit opéré en dehors de leur propre environnement d'hébergement et qui ne veulent pas maintenir le serveur de monitoring. Uptime Kuma est plus attrayant lorsque l'organisation souhaite un contrôle direct des vérifications et de l'historique, tout en acceptant les limites de la perspective réseau du nœud hébergé et les dépendances de notification externe.
Qui utilise Uptime Kuma
Les administrateurs surveillent les sites web, les API, les routeurs, les enregistrements DNS et les ports supportés. Les développeurs suivent les endpoints de test, tandis que les petites équipes de service publient une page de statut ciblée et utilisent les fenêtres de maintenance lors des travaux planifiés. Les moniteurs push permettent également aux tâches planifiées de signaler leur propre achèvement réussi.
Uptime Kuma est moins approprié comme seul contrôle pour les rapports de disponibilité réglementés, le monitoring de sécurité, la preuve multi-région, l'analyse des logs, le tracing distribué ou la réponse aux incidents gérée. Les services critiques doivent utiliser des chemins de monitoring indépendants et des procédures d'escalade testées.
Auto-hébergement d'Uptime Kuma : exigences et coût
L'utilisation des ressources d'Uptime Kuma augmente avec le nombre de moniteurs, l'intervalle de vérification, l'historique conservé, le traitement des réponses, le trafic de la page de statut, l'activité de notification et les utilisateurs du tableau de bord simultanés. Le catalogue ne provisionne aucun service PostgreSQL ou MariaDB et persiste /app/data. Le logiciel lui-même est gratuit à exécuter ; les vérifications très fréquentes et l'historique long sur de nombreux moniteurs nécessitent plus de ressources qu'une petite liste d'endpoints.
Sur AvaHost, Uptime Kuma utilise le Plan 1 à 2 €. Le package Uptime Kuma hébergé inclut le déploiement en un clic, un domaine personnalisé avec HTTPS automatisé, les mises à jour automatiques de l'application et les sauvegardes planifiées. L'email SMTP, les comptes de fournisseur d'alerte externe, les bots, les webhooks, la livraison téléphonique, les sondes multi-région, la connectivité réseau privé, l'accès au socket Docker, le personnel d'incident, les actions de réparation et les rapports de conformité ne sont pas inclus. Testez les notifications via chaque canal externe autorisé et maintenez un chemin indépendant pour les alertes critiques.
F.A.Q
Uptime Kuma commence à 2 € sur le Plan 1. Un ensemble modeste de moniteurs avec des intervalles raisonnables et un historique ordinaire peut débuter sur le plan d’entrée. Le nombre de moniteurs, la fréquence de vérification, les résultats conservés, le traitement des réponses, les visiteurs de la page de statut, le volume de notifications et les utilisateurs du tableau de bord simultanés déterminent quand une capacité supplémentaire est appropriée.
Les vérifications proviennent du serveur Uptime Kuma hébergé et reflètent sa route réseau, sa vue DNS et ses permissions. Un seul nœud ne peut pas démontrer la disponibilité depuis chaque région ou réseau privé. Pour les services critiques, comparez les résultats avec des sondes indépendantes et les rapports utilisateurs, et assurez-vous que les cibles privées ne sont accessibles que via un chemin autorisé.
L’email d’application est désactivé, les notifications SMTP d’Uptime Kuma ne peuvent donc pas être livrées via le package hébergé. D’autres méthodes de notification prises en charge peuvent fonctionner lorsque vous fournissez les identifiants de compte externe, webhook, bot ou fournisseur requis. Configurez chaque canal séparément, envoyez des alertes de test et maintenez un itinéraire d’escalade indépendant pour les incidents critiques.
Un domaine personnalisé peut pointer vers Uptime Kuma, et HTTPS automatisé protège le trafic du tableau de bord et de la page de statut. Publiez uniquement les moniteurs et les détails d’incident destinés aux lecteurs externes. Le catalogue ne fournit pas de sondes multi-régions, d’accès au socket Docker, de tunnels réseau privé, de comptes fournisseur ou de réponse aux incidents gérée, donc ces éléments nécessitent une conception séparée.