SEGP

Système d'Exploitation et Gestion de Parc

Le monitoring

En monitoring, on supervise, on doit savoir si notre système fonctionne ou pas. Et évidemment, plus le système surveillé est sensible, plus il faudra garder un oeil dessus. La surveillance de son système va permettre plusieurs choses :

  • De corriger un souci avant qu'il ne survienne
  • Réagir rapidement en cas d'incidents ! (le système de supervision nous alertera)
  • Pouvoir regarder l'état de tout le parc avec facilité (et ainsi, d'analyser rapidement)
  • Mesurer

La métrologie

La métrologie est la mesure temporelle provenant d'une ou plusieurs sondes d'un système ou d'une activité ! Par exemple, pouvoir regarder quel pourcentage d'espace utilisé correspond à tel disque dur à tel heure. Cela va nous permettre une analyse et une anticipation sur l'achat d'espaces supplémentaires !

Comment je stocke cette métrologie ?

Vous avez plusieurs moyens de stocker votre métrologie. Vous pouvez la stocker sur un fichier plat (ce qui n'est pas conseillé... difficile à exploiter, attention à la rotation des logs), dans une base de données times series (ça, c'est plutôt une bonne pratique, performant, possibilité de TAG et scalable :) ou encore dans une base de données relationnelle (pas faite pour ça, donc pas conseillé : peu performant, non scalable)

Journalisation

Dans le même style, on a également besoin de stocker la journalisation (les logs). Cela pourra nous aider en cas de soucis ou encore en cas d'intervention de la police chez un hébergeur :) Vous vous devez d'avoir à disposition des logs qui prouveront chaque faits et gestes de votre serveur. Certains évenements peuvent nécessiter une alerte (une notification), les logs sont importants aussi pour des raisons de sécurité (pouvoir tracer les évennements, comprendre un comportement...)

Il est très utile de centraliser tous les journaux du système sur un serveur dédié. La preservation des journaux est très utile en cas de perte du système, pour la sécurité du système et pour l'analyse et le traitement d'un ensemble de systèmes simultanément.

Combien de temps je dois garder ces logs ?

Ne stockez que les données utiles ! La journalisation peut devenir rapidement très volumineuse :) Supprimez les données trop anciennes, il n'est pas utile de garder ces données pendant plus de 13 mois.


Le serveur qui se heal tout seul...

Il est effectivement possible de dire à un serveur virtuel "Si jamais ton disque se remplit trop, ajoute de l'espace tout seul ! Sinon, je te laisse mourir de toutes façons." Bien évidemment, le serveur va prendre peur et se soigner tout seul. Pourquoi on devrait bosser à la place de ces foutues machines ? Par contre c'est difficile à mettre en oeuvre et le Retour sur Investissement (ROI) n'est pas toujours intéressant.


Mais on l'autorise à appeler à l'aide quand il douille un peu trop, on n'est pas des bêtes

Configurez des alertes ! (Notifications) Vous pouvez envoyer un message à plusieurs personnes en cas de souci détecté par le serveur. Cela peut prévenir d'un danger (un incident) ou annoncer un changement majeur.

Et bien entendu, prévenir un humain... c'est prendre le risque de ne pas être entendu... En cas de non réponse de la première personne prévenue, il est possible d'en prévenir d'autres. Vous pouvez configurer ce système de "Notifications en escalade" en fonction du temps passé, de la criticité de la notification... etc. Il est possible de prévenir via SMS, Mail, Push ou par téléphone. En fonction des besoins et de l'organisation de l'entreprise. Toutes ces solutions ont des failles, mieux vaut prévenir que guérir ! Soyez alerté une fois de trop plutôt que l'inverse :)


On monitore aussi l'environnement, mais... pas que...

La partie logicielle n'est pas la seule partie devant être surveillée. Il faut également surveiller tout ce qui est environnemental : la température, l'humidité, les sinistres naturels (inondations, incendits...) mais aussi la consommation électrique etc...

Et la partie Hardware, alors ?

Il faut la surveiller aussi ! Bien sûr ! L'ensemble des composants, les onduleurs les disques durs, les barettes de mémoire... Un composant physique du système est aussi mortel que vous, pauvres humains. Il est fréquent qu'on les remplace... comme on vous remplace. :3

Avec quoi peut-on surveiller tout ça ?!

Si vous achetez votre matériel chez des grandes marques (Dell, HP, Cisco...) ils vous offrent (ou pas, des fois faut payer) un système de supervision "interne". Ils mettent généralement des sondes pour visionner l'état général de la machine.

Surveillez l'hyperviseur aussi ! Il faut que vos machines virtuelles puissent tourner dans un environnement saint. Le CPU, la mémoire, les volumes, le réseau... Toutes ces données venant de l'hyperviseur (entre autres, parce qu'il faut faire la même chose sur les systèmes d'exploitations de vos serveurs quels qu'ils soient.) sont très importantes.

Tout ça fait beaucoup de choses à surveiller...

Et ce n'est pas terminé, il faut aussi surveiller les "MiddleWare".

C'est long !

Mais non, un peu de courage ! Et oui ! Apache, MySQL, Redis, ElasticSearch, etc... Tout ça sont des MiddleWare ! Il faut aussi les surveiller. Mais... quoi surveiller ? Ben déjà le service en lui même ! Est-il up ? Down ? Ensuite les ports d'écoute : Apache est-il bien sur le 80 ? (ou un autre hein) Les performances du service (le nombre de requêtes sur la BDD par exemple) La réplication ! (est-ce que le slave MySQL a du retard par rapport au Master ?) Les journaux aussi ! Et oui, faut rien oublier...

Software, MiddleWare, Hardware... on a tout fait ?!

Toujours pas, le Cloud public doit lui aussi être surveillé. La facturation (surveillez votre argent !), tout ce qui est en fonction des services (le CPU, la RAM etc...). Les clouds publics mettent à disposition des outils pour les monitorer. Exemple : CloudWatch sur AWS.

Me redemande pas si c'est bientôt fini on en a encore pas mal à voir, faut aussi surveiller les applicatifs : les journaux (l'augmentation anormale du nombre de logs), les erreurs (évidemment) et les éventuelles détections d'intrusion (genre un dindon qui pop dans les logs). Mais aussi le temps d'exécution d'une fonction, la latence d'accès aux middleware, la latence d'accès à une autre application ou service (API, HTTP)

On surveille aussi ce débile d'utilisateur (parce-qu'on va pas se mentir mais au point où on en est, on va pas se géner). Son activité est-elle fluide, son comportement normal ? Des erreurs sont-elles générées ? Si oui, sur quelle application, quel OS, quelle machine, par quel biais est-il arrivé sur l'application ?

Surveillez aussi tout ce qui est en rapport avec le métier... Par contre là, ben ça dépend du métier. PS : je ferai un tableau récapitulatif

C'est fini ...?

Oui.


Help me please ! (Alerting)

Trop d'alertes tue l'alerte ! Il ne faut notifier que les choses qui peuvent avoir un gros impact (et non pas les incidents isolés). Attention à ne pas polluer avec 1000 notifications.


Les outils

Vous pouvez avoir des outils On Premise (des outils DANS VOTRE entreprise), c'est vous qui les gérez et c'est vous qui les achetez (ou pas si open source). Sinon vous pouvez prendre du SAAS. Software As A Service ! En gros c'est une autre société qui gère !

Certains logiciels sont "tout en un" qui regroupent la pluspart des services de monitoring :

  • Centreon : Maison ou SAAS (Très généraliste)
  • LibreNMS : Maison (Orienté réseau)
  • Piwik : Maison ou SAAS (Orienté WEB, Applicatif, Utilisateur)
  • Google Analytics : SAAS (Orienté WEB, Business, Utilisateur)
  • Newrelic : SAAS (Orienté Profiling WEB)
  • Datadog : SAAS (Orienté Infrastructure)
  • Cloudhealth : SAAS (Orienté billing : Cloud public)
  • Stackdriver : SAAS (Orienté Cloud public)

On a un besoin spécifique qu inécessite d'utiliser des outils de monitoring très spécifiques :

  • Journalisation
  • Métrologie
  • Analyse
  • Tableau de bord