La supervision ScalarX repose sur une approche décentralisée, pensée pour les infrastructures qui ne tournent pas toujours dans un seul datacenter, ni même sur un seul continent.
ScalarX ne centralise pas artificiellement ce qui doit rester distribué. Nos clients peuvent avoir des serveurs dans plusieurs pays, chez plusieurs providers ou dans leurs propres datacenters. Notre supervision est conçue pour cette réalité.
Chaque serveur StackX peut générer dynamiquement son propre état opérationnel local, exposé sous la forme d’un point de contrôle HTTPS dédié. Ce point peut ensuite être vérifié depuis l’extérieur par Pingdom, SolarWinds ou tout autre système capable de contrôler une page web.
L’objectif est de séparer ce qui relève de l’état local du serveur, de la disponibilité du service, du chemin réseau et du point géographique de mesure.
Cette logique devient particulièrement utile sur les architectures multi-providers, multi-pays, multi-continents ou hybrides, où une mesure prise depuis un seul endroit peut donner une lecture incomplète, voire trompeuse, de la réalité opérationnelle.
Supervision décentralisée
Principe de supervision ScalarX
| Principe |
Application concrète |
| État local serveur |
Chaque machine peut produire son propre état opérationnel via StackX Monitoring System |
| Point de vérité exploitable |
Un endpoint HTTPS dédié restitue les contrôles locaux dans un format lisible par un outil externe |
| Contrôle externe |
Pingdom, SolarWinds, un autre outil ou un contrôle manuel peuvent interroger ce point de supervision |
| Tiers de confiance |
Le contrôle peut être confié à un acteur externe indépendant de l’infrastructure supervisée |
| Mesure géographique |
Le point de mesure peut être choisi selon la zone, le client, le provider ou le scénario de production |
| Découplage infrastructure |
La supervision n’impose pas un datacenter ScalarX, une région cloud unique ou un agent propriétaire |
Ce que la supervision permet de séparer
| Question |
Lecture opérationnelle |
| Le serveur va-t-il bien localement ? |
Processus attendus, filesystems, services et contrôles locaux remontés par StackX |
| Le service répond-il ? |
Vérification externe du point exposé et des services associés |
| Le problème vient-il du serveur ? |
Corrélation entre état local, processus, services et erreurs remontées |
| Le problème vient-il du réseau ? |
Comparaison entre état local correct et indisponibilité observée depuis un point externe |
| Le problème dépend-il de la géographie ? |
Interprétation selon le pays, le transit, le peering, le CDN, le provider ou le chemin BGP |
Pourquoi un monitoring centralisé peut tromper
| Situation |
Risque d’interprétation |
| Serveur en Australie, monitoring en Europe |
La latence observée ne représente pas forcément l’expérience réelle d’un client aux États-Unis |
| Application sur plusieurs continents |
Un seul point de mesure ne résume pas l’état global du service |
| Transit ou peering dégradé |
L’alerte peut venir du chemin réseau, pas du serveur |
| Route asymétrique ou congestion temporaire |
Une erreur ponctuelle peut refléter Internet, pas l’infrastructure managée |
| CDN, provider ou région spécifique |
La panne peut être localisée sans que le service soit globalement indisponible |
Outillage StackX de supervision
| Composant |
Rôle |
| StackX Monitoring System (SMS) |
Génère un état local serveur exploitable par un contrôle externe |
| monitoring.php |
Endpoint HTTPS dédié, avec nom généré aléatoirement lors du déploiement |
| sms.sh |
Script de contrôle local: processus, filesystems, services et état opérationnel |
| process2monitor.txt |
Liste des processus attendus, générée selon le profil de la machine |
| Munin |
Métriques historiques protégées par authentification HTTPS |
| sxpostcheck |
Audit post-install et contrôle de cohérence des composants StackX |
| sxnetstat |
Lecture réseau opérationnelle, connexions, ports et IPs observées |
| sxfpmcheck |
Contrôle local des pools PHP-FPM, avec modes JSON, full et OpenMetrics |
Diagnostics complémentaires StackX
| Outil |
Usage opérationnel |
| memcalc |
Mesure de consommation RAM par service, utilisateur ou PID |
| sxsqlyze |
Analyse MariaDB/MySQL: tailles bases/tables, croissance, fragmentation, moteurs et index |
| sxpgdb |
Inventaire, affichage et doctor des ressources PostgreSQL liées aux environnements |
| sxmdbsync |
Synchronisation MariaDB/MySQL entre environnements, utile pour reprise, tests ou trajectoires PRD/DRS |
| sxbkpmdb / sxbkppgdb |
Sauvegarde MariaDB/MySQL et PostgreSQL avec logs, rétention et contrôles d’exécution |
| sxserialcheck |
Vérification de cohérence des serials DNS entre serveurs de noms |
Ce que la supervision n'impose pas
| Contrainte absente |
Pourquoi c’est important |
| Pas de plateforme centrale obligatoire |
La supervision peut être vérifiée depuis plusieurs outils ou points externes |
| Pas d’agent propriétaire imposé |
Un simple contrôle HTTPS peut suffire pour valider l’état généré localement |
| Pas de région cloud unique |
Les environnements multi-providers ou multi-continents restent supervisables |
| Pas de topologie réseau figée |
Le modèle s’adapte aux serveurs dédiés, cloud public, cloud privé, PRA ou hybride |
| Pas de dépendance à un datacenter ScalarX |
Le serveur conserve la capacité de produire son état opérationnel localement |
Contrôles locaux typiques
| Contrôle |
Exemple StackX |
| Processus critiques |
Apache, SSH, cron, fail2ban, PHP-FPM, Redis, OpenSearch ou services spécifiques selon profil |
| Filesystems |
Vérification des points de montage attendus et des volumes critiques |
| RAID / pools ZFS |
Contrôle de l’état des volumes, pools, dégradations ou erreurs selon architecture |
| Load average |
Détection de pression CPU, saturation ou comportement anormal côté système |
| Consommation RAM |
Lecture mémoire par service, utilisateur ou PID avec des outils comme memcalc |
| Services applicatifs |
PHP-FPM par version, bases de données, composants applicatifs ou services dédiés |
| Réseau |
Ports exposés, connexions actives, IPs observées et cohérence avec les règles de filtrage |
| Cohérence post-install |
Fichiers StackX, configuration, monitoring, logs, permissions et services attendus |
En pratique :
ScalarX peut superviser un serveur via son état local StackX, tout en faisant valider cet état par un tiers de confiance comme Pingdom ou SolarWinds. Le contrôle externe reste indépendant de l’infrastructure supervisée, ce qui permet de distinguer plus rapidement une panne serveur, une panne service, un problème de chemin réseau ou une anomalie liée au point de mesure.
Cas d'usage
| Contexte |
Intérêt |
| Serveur isolé mais critique |
Vérifier localement les composants essentiels sans imposer une plateforme lourde |
| Infrastructure multi-sites |
Comparer état local et disponibilité externe selon les zones |
| PRA / DRS |
Contrôler séparément les nœuds de production et de reprise |
| Multi-provider |
Éviter de confondre panne fournisseur, transit réseau et panne serveur |
| Client international |
Adapter les points de mesure à la réalité géographique des utilisateurs |
Besoin de cadrer votre supervision ?
Nous pouvons définir les contrôles locaux, les points de mesure externes, les seuils d’alerte et la méthode d’interprétation adaptée à votre architecture.
Cadrer votre supervision