Surveillance de disponibilité pour hébergeurs qui vous alerte avant l’arrivée des tickets.
Uptimia vérifie les sites de vos clients depuis l’extérieur, tandis qu’un agent en une ligne remonte le CPU, le disque et la charge depuis l’intérieur de chaque serveur. Vous voyez /var à 92 % pendant que les quarante sites de ce nœud continuent de se charger normalement — et vous réglez le problème avant même qu’une panne survienne.
CPU Usage
alerts only if every 30 s reading stays over 90% for 5 minDisk Usage
per mount · worst firstServer Details
reported by the agentQuatre idées reçues qui remplissent la file d’attente
Les quatre tiennent la route jusqu’à ce qu’un disque plein fasse tomber quarante sites.
« Nous surveillons déjà tout depuis l’intérieur du datacenter. »
La surveillance depuis l’intérieur partage le sort de ce qu’elle observe — quand le rack perd le réseau, vos alertes le perdent aussi. Et elle mesure depuis vos propres murs ; elle ne pourra jamais voir ce que voit un client à trois réseaux de distance.
« Les sites répondent, donc les serveurs vont bien. »
« Répond » est un indicateur retardé. Un serveur à 96 % sur /var répond à chaque requête — jusqu’au moment où il n’en sert plus aucune. Le temps que les sites vous le disent, ce n’est pas une alerte isolée — c’est tout le nœud, d’un coup.
« Si nos IP de messagerie avaient un problème, on verrait des rejets. »
Les rejets se produisent discrètement, à l’autre bout. Le message quitte votre file sans problème ; une IP blacklistée se fait simplement refuser ailleurs. Vous l’apprenez quand un client vous transfère sa troisième facture jamais reçue.
« Personne ne lit vraiment les pages de statut. »
Personne ne les lit quand tout va bien. Pendant un incident, elles font la différence entre une seule note de statut et quarante tickets identiques — et un seul incident suffit à vos clients pour apprendre où regarder.
« Un serveur en panne, c’est un incident » est la plus grande de toutes. En hébergement mutualisé, la multiplication est brutale : un nœud × 40 clients = quarante pannes simultanées, quarante boîtes de support, quarante conversations de renouvellement — à cause d’un seul disque plein. La correction coûte un ingénieur et une rotation de logs ; le découvrir trop tard coûte la patience de quarante clients.
La question n’est donc pas de savoir si un serveur va se remplir ce trimestre. C’est de savoir si la première personne à l’apprendre travaille pour vous.
Voici à quoi ressemble un disque qui se remplit quand quelque chose le surveille depuis l’intérieur du serveur.↓ minute par minute
Ce qui se passe quand /var se remplit
Un disque sur l’un de vos serveurs se remplit discrètement pendant la nuit. Les quarante sites clients de ce serveur continuent de répondre à chaque requête, et tous les tableaux de bord restent au vert.
C’est un serveur sauvé. Mais une flotte d’hébergement tombe en panne à plus de niveaux que le disque — sites, certificats, domaines, réputation e-mail.↓ chaque niveau, un seul tableau de bord
Sites, serveurs et IP de messagerie
La surveillance de serveurs pour les hébergeurs, c’est trois veilles à la fois : les sites clients depuis l’extérieur, les serveurs depuis l’intérieur, et les IP par lesquelles part leur messagerie. Un seul tableau de bord, regroupé par rack ou par client.
Ce que vos clients remarquent en premier
À un log incontrôlé de la saturation
Aujourd’hui, il faudrait vous connecter à chaque serveur pour savoir lequel est concerné. Un agent en une ligne le remonte en continu — CPU, mémoire, disque, charge et réseau depuis chaque serveur Linux, toutes les 30 secondes — pour qu’un /var qui se remplit alerte votre astreinte pendant que les sites qui y résident sont encore servis.
- Installation en une ligne — une commande
curl, un timer systemd, aucune interruption des sites - Seuils de disque par point de montage —
/varalerte plus tôt que/, et chaque point de montage ouvre et résout son propre incident - Le silence compte aussi — un serveur qui manque trois rapports d’affilée est signalé hors ligne, 90 secondes après le dernier
IP de messagerie passées au crible sur 17 zones
Un listage chez Spamhaus ou Barracuda ne s’annonce nulle part : le message quitte votre file proprement et se fait refuser à l’autre bout. La surveillance de blacklist pour serveurs de messagerie passe chaque domaine d’envoi et ses IP au crible de 17 zones DNSBL toutes les 15, 30 ou 60 minutes, et ouvre un plan de délistage dès qu’une zone répond « listé ».
- Domaine + IP web + IP de messagerie — une sonde couvre tout un domaine d’envoi, plus jusqu’à cinq IP dédiées, sur les 17 zones
- Suit votre infra — l’IP web (enregistrement A) et l’IP de messagerie (MX) sont réévaluées à chaque passage, si bien que la surveillance suit quand vous déplacez le serveur
- Aucune fausse alerte — les codes de réputation comme Hostkarma NOBL et Mailspike « good » sont interprétés comme propres, jamais confondus avec un listage
Un collage, tout un rack de sondes
Intégrer un rack formulaire par formulaire, c’est ainsi que la surveillance finit discrètement par ne plus correspondre à la flotte. Collez la liste des sites hébergés, choisissez le type de vérification, et tout le rack est créé en une seule passe et classé dans le groupe de ce rack — une passe par type, donc disponibilité, SSL et domaine en prennent trois. Le rack est arrêté dimanche ? Mettez-les tous en sourdine en une seule action, tous types confondus.
- Coller pour créer — créez en masse des sondes de disponibilité, SSL, domaine, malware, vitesse ou utilisateurs réels, un type par passe, avec la liste analysée prévisualisée avant toute création
- Résultats ligne par ligne — les doublons et les lignes hors limite reviennent nommés, ligne par ligne ; les lignes valides sont créées quand même
- Maintenance en masse — suspendez, reprenez ou planifiez une fenêtre sur tout un rack depuis une seule sélection
bravo-clinic.co
gamma-realty.net
delta-cafe.io
… 96 lignes de plus
Une note au lieu de quarante tickets
Pendant un incident, vos clients regardent votre boîte de réception — à moins que vous ne leur ayez donné un meilleur endroit où regarder. Une page de statut sur le propre domaine du client — son logo, aucun badge Uptimia — est alimentée en direct par ses sondes, si bien qu’un incident devient une note que vous écrivez au lieu de quarante tickets auxquels vous répondez.
- Son domaine, vos notes — pointez un sous-domaine du client vers nous, et une page de statut à sa marque y répond, avec le badge « Powered by Uptimia » désactivé
- Publique ou privée — ouverte à ses clients, ou restreinte par mot de passe / IP pour que lui seul la voie
- Rapports à votre marque — synthèses de disponibilité planifiées en PDF, HTML ou CSV, avec vos couleurs et votre logo en tête
Alerté avant que la file de support ne se remplisse
Un serveur, une IP de messagerie ou un site client — quoi qui tombe, l’alerte atteint votre roulement d’astreinte sur les canaux que votre équipe utilise déjà pour gérer les incidents.
Microsoft TeamsUne seule liste de contacts — une seule liste d’astreinte pour toute la flotte.
Parcourir l’annuaire complet des intégrations →L’indisponibilité d’un client devrait vous alerter, vous.Pas un ticket de support.
L’essai de 30 jours débloque tous les types de sonde — sites, serveurs, SSL, domaine et blacklist.
Votre flotte surveillée en trois étapes
Sites, serveurs et IP de messagerie sous surveillance dès cet après-midi.
Ajoutez les sites et les serveurs
Collez votre liste de sites hébergés une fois par type de vérification — disponibilité, puis SSL, puis domaine — et déposez l’agent en une ligne sur chaque serveur Linux pour le CPU, le disque et la charge.
bravo-clinic.co
… 98 de plus
Définissez les seuils & acheminez les alertes
Définissez des seuils de disque et de charge par serveur, connectez Slack et les SMS, et décidez qui est alerté en premier — et qui suit si personne ne répond.
Activez la couche visible par vos clients
Pages de statut à votre marque sur les domaines de vos clients et rapports mensuels à vos couleurs — ils apprennent les incidents par vous.
Également inclus
Intégrez depuis l’API
Créez des sondes et des pages de statut depuis vos scripts de provisionnement — un nouveau serveur démarre, un appel suffit à le mettre sous surveillance.
Fenêtres de maintenance
Un rack hors ligne ce week-end ? Planifiez la fenêtre — les vérifications se mettent en pause, les alertes restent silencieuses, personne ne s’alerte lui-même.
Expiration SSL & domaine
Certificats et enregistrements surveillés avec une fenêtre d’alerte configurable avant l’expiration. Les sondes de domaine suivent l’échelle de la disponibilité jusqu’à 1 000 ; le SSL est compté avec les familles plus serrées, 100 tout en haut.
Chaînes d’escalade
Acheminez d’abord une alerte de serveur en panne vers l’astreinte, le chargé de compte seulement si elle est encore ouverte après 15 minutes.
Avis de rétablissement
Quand un serveur ou un site revient, les personnes alertées l’apprennent aussi — plus de panique qui traîne à 3 h du matin.
Un seul compte, toute la flotte
Les groupes évitent que 25 nœuds et 940 sites ne deviennent une seule liste plate — filtrez, mettez en pause ou générez un rapport pour n’importe quel rack isolément.
Surveillance de disponibilité pour hébergeurs
La surveillance de disponibilité pour hébergeurs consiste à observer chaque site hébergé, les serveurs qui les font tourner et les IP de messagerie par lesquelles envoient les clients — dans un seul tableau de bord externe — afin de repérer les problèmes avant l’arrivée des tickets de support. Les sites sont vérifiés depuis l’extérieur, un agent remonte les serveurs depuis l’intérieur, et les résultats alimentent des pages de statut et des rapports visibles par vos clients.
La file de support l’apprend en premier
Chaque problème qu’un client remarque en premier devient un ticket, un risque de rétrofacturation et une entaille dans votre réputation.
Vous le repérez en premier
L’incident devient une ligne dans le rapport du nœud — la preuve que la plateforme est surveillée.
Ce que détecte chaque niveau
Trois choses à surveiller — sites, serveurs, IP de messagerie — couvertes depuis un seul endroit ; ajoutez la vitesse de page et les transactions là où c’est important.
Découvrir la surveillance SSL →| Niveau | Ce qui est détecté | Comment ça marche |
|---|---|---|
| Disponibilité | Sites en panne, erreurs serveur | Toutes les 30 s à partir du forfait Professional, revérifié depuis jusqu’à 3 régions supplémentaires |
| Métriques serveur | Disque plein, pic de charge, serveur hors ligne | L’agent remonte CPU/mémoire/disque/charge toutes les 30 s, 8 seuils |
| Certificat SSL | Expiration, chaînes cassées | Fenêtre d’alerte configurable, critique à moins de 45 jours |
| Expiration du nom de domaine | Enregistrements expirés | WHOIS revérifié selon votre intervalle, critique à moins de 3 jours |
| Blacklist | IP de messagerie listée sur une DNSBL | 17 zones passées au crible toutes les 15 à 60 min, IP réévaluées à chaque passage |
FAQ sur la surveillance pour hébergeurs
01Qu’est-ce que la surveillance de disponibilité pour hébergeurs ?+
02Puis-je donner à un client un accès qui n’affiche que ses sites ?+
03Vous intégrez-vous à cPanel, WHM ou Plesk ?+
04Est-ce un programme de revente ou de marque blanche ?+
05L’agent serveur fonctionne-t-il sous Windows ?+
06À quelle vitesse la surveillance de blacklist détecte-t-elle un listage ?+
07Combien de serveurs et de sites puis-je surveiller ?+
08Puis-je limiter un membre de l’équipe à certains racks seulement ?+
09Que se passe-t-il quand un serveur franchit un seuil ?+
/var peut alerter plus tôt que /.10Dois-je installer quoi que ce soit sur les sites hébergés ?+
11Quels canaux d’alerte mon équipe peut-elle utiliser ?+
Détectez le disque plein avant qu’il n’emporte des sites
Chargez une tranche de votre flotte dans l’essai — sites, serveurs et IP de messagerie — et détectez le prochain problème avant qu’il ne devienne un ticket.