Monitoring
Soyez prévenu avant vos utilisateurs
Chaque serveur remonte son CPU, sa charge, sa mémoire, son disque et son réseau une fois par minute, et chaque site est contrôlé depuis l’extérieur toutes les 15 minutes. Définissez des seuils, ajoutez des heartbeats pour vos tâches et recevez un seul message quand quelque chose change, pas un par minute.
Métriques serveur
Chaque serveur, mesuré chaque minute
Le provisionnement installe un petit agent bash que cron lance une fois par minute. Il mesure le serveur et envoie les chiffres en HTTPS avec un jeton propre à ce serveur. Aucun port n’est ouvert et aucun démon ne tourne.
La page Monitoring affiche les derniers chiffres et des graphiques sur 1 heure, 6 heures, 24 heures, 7 jours ou 30 jours. CPU, mémoire et disque passent à l’orange dès 75 % et au rouge dès 90 %. Les mesures sont conservées 31 jours.
Ce que mesure l’agent
CPU et charge
La part du temps CPU occupée sur une seconde, et la charge moyenne sur une minute à côté du nombre de cœurs.
Mémoire
La mémoire utilisée, total moins disponible, en pourcentage.
Disque
L’espace utilisé sur le disque racine, pour voir venir un disque plein.
Réseau
Les octets entrants et sortants sur l’interface réseau principale, affichés en Mbit/s.
Connexions SSH
Chaque connexion SSH réussie, avec l’utilisateur, l’adresse IP et la clé, sur la page Sécurité du serveur.
Redémarrage nécessaire
Quand Ubuntu demande un redémarrage après des mises à jour, et pour quels paquets.
Moniteurs
Des alertes qui attendent un vrai problème
Un moniteur compare l’utilisation du CPU, la charge CPU, l’utilisation de la mémoire ou du disque à un seuil sur 1 à 60 minutes. Il ne déclenche une alerte que si la valeur a atteint ou dépassé le seuil à chaque minute de cette fenêtre ; une minute sans données ne compte jamais, donc un trou ne peut pas la déclencher.
Vous recevez un e-mail quand l’alerte commence, par exemple *Warning: CPU usage on web-1 is 96%*, et un autre quand tout revient à la normale. Bons points de départ : CPU à 90 % pendant 5 minutes, mémoire à 90 % pendant 5 minutes, disque à 85 % pendant 1 minute.
Heartbeats
Sachez quand une tâche planifiée se tait
Cron ne vous dit pas quand une tâche s’arrête. Un heartbeat, si : ajoutez-en un avec l’intervalle et un délai de grâce, et faites appeler son URL par la tâche quand elle réussit. Si l’appel n’arrive pas à temps, le heartbeat passe à Manqué et vous recevez un e-mail ; quand la tâche rappelle, vous en êtes informé aussi.
Les heartbeats sont vérifiés chaque minute. L’URL accepte GET et POST et répond OK.
php /home/vimonto/example.com/current/artisan backup:run \
&& curl -fsS -m 10 https://deploy.example.com/heartbeat/your-tokenSurveillance de disponibilité
Chaque site contrôlé depuis l’extérieur, toutes les 15 minutes
Les contrôles de disponibilité sont actifs pour chaque site dès le départ, sans rien à installer. La vue d’ensemble du site affiche le statut actuel, la disponibilité sur 24 heures, 7, 30 et 90 jours, et le temps de réponse moyen.
Contrôlé comme un visiteur
Un
GETsur le domaine principal, en HTTPS si le site a un certificat, en suivant jusqu’à cinq redirections, avec un délai d’attente de 10 secondes.Pas de fausses alertes
Un site est considéré hors ligne après deux contrôles échoués d’affilée, et de nouveau en ligne après un seul succès. Un site protégé par mot de passe compte comme en ligne sur un
401.Grille sur 90 jours
Un carré par jour, coloré selon la disponibilité, avec les contrôles et les minutes d’indisponibilité au survol, plus une bande des 96 derniers contrôles.
Votre route de santé
Contrôlez un chemin comme
/upde Laravel au lieu de la page d’accueil, ou désactivez les contrôles pendant une maintenance prévue.
Pages de statut
Pages de statut publiques
Donnez à vos clients une page qui montre si tout fonctionne. Une page de statut à sa propre adresse affiche vos sites, heartbeats et serveurs, chacun avec une barre des 90 derniers jours, ainsi que les incidents et maintenances que vous publiez.
- Des composants issus des contrôles de disponibilité des sites, des heartbeats et des serveurs, regroupés en sections
- Un seul titre pour tout : opérationnel, performances dégradées, panne partielle ou majeure
- Des incidents avec mises à jour, et des maintenances planifiées
- Publique : les visiteurs n’ont pas besoin de compte
Notifications
Prévenu une fois, par le canal que chacun choisit
Les alertes des moniteurs, les heartbeats manqués, les sites hors ligne, les sauvegardes, déploiements et certificats en échec parviennent à chaque membre qui peut voir le serveur, dans la cloche de l’app et par e-mail. Chacun choisit, par type de notification, le canal qu’il veut, et peut mettre en sourdine les serveurs qu’il ne suit pas.
Par défaut, les échecs arrivent par e-mail et dans l’app, et les bonnes nouvelles seulement dans l’app. Un moniteur ou un heartbeat peut aussi envoyer un e-mail à une adresse partagée, comme la boîte de votre équipe, sans que cette personne soit membre.
Questions sur le monitoring
Le monitoring coûte-t-il plus cher ou ralentit-il mon serveur ?
Non. Le monitoring est inclus dans chaque forfait. L’agent tourne environ une seconde par minute et envoie quelques chiffres.
Puis-je contrôler mes sites plus souvent que toutes les 15 minutes ?
Non. Chaque site est contrôlé toutes les 15 minutes, et les contrôles sont conservés 90 jours.
Puis-je envoyer les alertes vers Slack ?
Il n’y a pas d’intégration Slack. Les alertes partent par e-mail et vers la cloche de l’app ; indiquez une boîte partagée comme adresse à prévenir. Pour les déploiements, le hook de déploiement d’un site peut envoyer vers votre propre endpoint.
Puis-je surveiller un serveur de base de données ou de cache ?
Oui. L’agent tourne sur tous les types de serveurs, y compris les serveurs de base de données, de cache, Meilisearch et load balancer.
Le contrôle de disponibilité apparaîtra-t-il dans mes statistiques ?
Seulement dans les statistiques qui lisent le log d’accès. Le contrôle utilise le user agent VimontoDeploy-Uptime/1.0, vous pouvez donc le filtrer. Les outils d’analyse côté navigateur ne le voient pas.
Pages associées
- ServeursProvisionnement pour chaque rôle : serveurs d’application, web, worker, base de données, cache, recherche et load balancer.
- Bases de données et sauvegardesMySQL, MariaDB ou PostgreSQL, utilisateurs de bases de données et sauvegardes planifiées vers votre propre bucket.
- AutomatisationUne API REST, un CLI pour la CI, des URL de déploiement, des recettes pour vos scripts récurrents et des hooks de déploiement.
Votre prochain déploiement pourrait être en ligne avant que votre café ne refroidisse.
Créez une organisation, connectez un serveur et poussez. C'est tout.