Doc Monitoring Evolix
Nous utilisons 2 instances quasi-indépendantes du logiciel Icinga2 pour vérifier l’état d’un certain nombre d’indicateurs système (load, espace disque, RAM), l’état des services que nous gérons (Apache, Nginx, HAProxy, MariaDB, PostgreSQL, etc.) et également l’état de vos applications (par exemple l’état de votre application web).
Surveillance 24/7 ou Heures Ouvrées ?
La surveillance en « Heures Ouvrées » est du lundi au vendredi (hors jours fériés français) de 9h à 12h et de 14h à 18h.
La surveillance « 24/7 » est en permanence.
Dans tous les cas, du lundi au vendredi (hors jours fériés français) de 9h à 12h et de 14h à 18h, nous recevons les alertes sur ce qui est surveillé en moins de 3 minutes.
Dans le cas d’une surveillance Heures Ouvrées, nous ne recevons les alertes que sur ces créneaux, et si il y a un problème le vendredi à 19h nous ne le verrons que lundi à 9h.
Dans le cas d’une surveillance 24/7, nous recevons les alertes :
- au bout de 15 minutes entre 12h et 14h (hors week-end et jours fériés)
- au bout de 22 minutes entre 18h et 22h (hors week-end et jours fériés)
- au bout de 22 minutes entre 7h30 et 9h (hors week-end et jours fériés)
- au bout de 22 minutes entre 7h30 et 22h (week-end et jours fériés)
- au bout de 55 minutes entre 22h et 7h30
Nous rappelons que nos SLA standards sur les suivantes sur les alertes :
- GTI 4h / GTR 8h pour une panne bloquante (en permanence si vous êtes en surveillance 24/7)
Vous pouvez avoir un contrat qui propose de meilleures conditions.
Nos SLA sur la partie réseau / hébergement / infogérance sont disponibles sur https://evolix.com/conditions-generales.html
Surveillance web
Surveillance de 3 URLs par serveur
Afin de surveiller vos applications, nous vous demandons en général de nous fournir 3 URLs accessibles sans authentification et qui renvoient un code HTTP 200. Cela peut par exemple être :
http://example.com/
https://foo.example.com/login/
https://bar.example.com/login.phpMerci de nous informer en amont si il faut changer ces URLs surveillées.
Surveillance plus poussée
Afin d’avoir une surveillance plus poussée, nous apprécions si vous nous fournissez une URL du type https://example.com/_monitoring pour vos applications les plus critiques. L’idée est que cette URL fasse appel à toutes les ressources vitales pour votre application comme la lecture/écriture sur la (ou les) base(s) de données (MariaDB, PostgreSQL, Redis, Memcached, Elasticsearch…), la lecture/écriture sur les espaces de stockage utilisés, des requêtes vers les API critiques que vous utilisez, le chargement de votre framework etc. Vous pouvez même mettre des seuils de temps de réponse : si la base de données met plus d’1 seconde à répondre, c’est considéré comme un problème. Si tout va bien, votre page renvoie HTTP 200, sinon elle renvoie HTTP 500 ce qui déclenchera une alerte chez nous.
Idéalement, en plus du code HTTP, cette URL va retourner aussi du détails sur les ressources vérifiées du type :
Check MariaDB 127.0.0.1 : OK (12ms)
Check Redis 127.0.0.1 : OK (3ms)
Check lecture /data : OK (66ms)
Check écriture /data : OK (221ms)
Check API 1 : OK (76ms)Note : Cette URL doit être restreinte à des requêtes locales (
127.0.0.1ou::1), nous pouvons le faire au niveau du serveur HTTP, ouvrez nous un ticket pour que l’on ajoute cette restriction.
Évidemment nous vérifions également les différentes ressources (bases de données, etc.) de notre côté, mais c’est très intéressant d’avoir une vérification du point de vue de votre application.
