Il s'agit d'une question canonique sur le logiciel de surveillance.
Également lié: Quel outil utilisez-vous pour surveiller vos serveurs?
J'ai besoin de surveiller mes serveurs; que dois-je considérer lors du choix d'une solution de surveillance?
Réponses:
Il existe de nombreuses solutions de surveillance. Chacun a sa préférence et chaque entreprise a ses propres besoins, il n'y a donc pas de bonne réponse. Cependant, je peux vous aider à comprendre ce que vous voudrez peut-être rechercher dans le choix d'une solution de surveillance.
En général, les systèmes de surveillance ont deux objectifs principaux. La première consiste à collecter et à stocker des données au fil du temps. Par exemple, vous souhaiterez peut-être collecter l'utilisation du processeur et la représenter graphiquement au fil du temps. Le deuxième objectif est d'alerter lorsque les choses ne répondent pas ou ne sont pas dans certains seuils. Par exemple, vous pouvez souhaiter des alertes si un certain serveur ne peut pas être atteint par des pings ou si l'utilisation du processeur est supérieure à un certain pourcentage. Il existe également des systèmes de surveillance des journaux tels que Splunk, mais je les traite séparément pour cela.
Ces deux rôles principaux viennent parfois dans un seul produit, d'autres fois et plus commun est d'avoir un produit dédié à chaque objectif.
Pollers :
Tous les systèmes de surveillance ont besoin d'une sorte de poller pour collecter les données. Toutes les données ne sont pas collectées de la même manière. Vous devriez regarder votre environnement et décider de quelles données vous avez besoin et comment elles pourraient être collectées. Assurez-vous ensuite que le système de surveillance que vous choisissez prend en charge ce dont vous avez besoin. Certaines méthodes courantes incluent:
Si vous avez principalement un système d'exploitation dans votre environnement ou un système d'exploitation principal, certains systèmes peuvent avoir plus d'options que d'autres.
Configuration :
Dans les systèmes de surveillance, il y a généralement beaucoup de réutilisation d'objets. Par exemple, vous souhaitez surveiller une certaine application telle qu'Apache ou IIS sur un groupe de serveurs. Ou vous souhaitez que certains seuils s'appliquent aux groupes de serveurs. Vous pouvez également avoir certains groupes de personnes "sur appel". Par conséquent, un bon système de modèles est vital pour un système de surveillance.
La configuration se fait généralement via une interface utilisateur ou des fichiers texte. L'option d'interface utilisateur sera généralement plus facile, mais les fichiers texte ont tendance à être meilleurs pour la réutilisation et les variables. En fonction de votre personnel informatique, vous préférerez peut-être la simplicité à la puissance.
Interface utilisateur :
L'interface la plus courante pour les systèmes de surveillance de nos jours est une interface Web. Certaines choses à évaluer en ce qui concerne l'interface Web sont:
Moteur d'alerte :
Le moteur d'alerte doit être flexible et fiable. Il existe de nombreuses façons d'être notifié, notamment:
Les autres fonctionnalités à rechercher sont:
Il est important de croire qu'en cas de problème, vous recevrez l'alerte. Cela revient à deux choses:
Stockage de données :
si le système collecte et stocke des données (c'est-à-dire des systèmes qui incluent des graphiques), le système stocke des données. RRD par exemple est une implémentation très courante pour le stockage et la représentation graphique.
Certaines fonctionnalités à rechercher dans le magasin de données sont les suivantes:
Bibliothèque de
graphiques : les graphiques peuvent être utiles pour identifier rapidement les tendances et donner un contexte à l'état actuel de quelque chose en fonction de son historique. Certains incluent les tendances qui peuvent être utiles pour prévoir les choses avant qu'elles ne se produisent (c'est-à-dire manquer d'espace disque). Assurez-vous que les graphiques vous fourniront clairement les informations dont vous pensez avoir besoin.
Contrôles d'accès :
si vous avez une grande organisation, vous aurez peut-être besoin de contrôles d'accès, car certains administrateurs ne devraient pouvoir ajuster que certaines choses. Vous pouvez également souhaiter des tableaux de bord accessibles au public. Si cela est important, vous devez vous assurer que le système de surveillance dispose des contrôles dont vous avez besoin.
Rapports :
un système qui fournit de bons rapports peut vous aider à identifier ce qui doit être amélioré sur de longues périodes. Par exemple, il peut donner une bonne réponse à des choses comme "quels systèmes tombent le plus en panne?". Cela peut être important lorsque vous essayez de convaincre la direction de dépenser de l'argent pour certaines choses - les affaires sont comme des preuves tangibles.
Caractéristiques
spéciales : Certains systèmes de surveillance sont destinés à des produits spécifiques ou bénéficient d'un support plus important que d'autres. Par exemple, si la principale chose que vous devez surveiller est SQL Server, ou si vous faites un usage intensif des produits VMWare, vous devriez voir dans quelle mesure ceux-ci sont pris en charge.
Modèles de surveillance prédéfinis :
un système fourni avec de nombreux modèles prédéfinis (ou dont la base d'utilisateurs a créé de nombreux modèles) peut être un énorme gain de temps.
Découverte :
si vous avez un environnement vaste ou changeant. Certains systèmes offrent la possibilité d'ajouter de nouveaux systèmes via une API ou d'exécuter des analyses pour trouver de nouveaux serveurs ou composants.
Surveillance distribuée:
si vous avez plusieurs emplacements à surveiller, il peut être utile d'avoir des scrutateurs de surveillance dans chaque emplacement au lieu de beaucoup de systèmes indépendants surveillent via le WAN.
Il existe de nombreux systèmes de surveillance. Nous avons une liste avec un résumé de cette vieille question . Pour une référence rapide, certains dont j'entends le plus parler sont:
La raison pour laquelle je ne peux pas vous dire quoi utiliser est parce que chaque organisation a ses propres besoins. Si vous voulez faire le bon choix, vous devez réfléchir à tous les composants ci-dessus et déterminer quelles fonctionnalités sont importantes pour votre organisation. Trouvez ensuite un ou plusieurs systèmes qui prétendent fournir ce dont vous avez besoin et essayez-les. Certains d'entre eux coûtent un peu, beaucoup ou sont gratuits. En tenant compte de tout cela, vous pouvez ensuite faire votre choix. D'après ce que j'ai utilisé, ils sont tous loin d'être parfaits, mais au moins vous pouvez essayer d'obtenir quelque chose qui vous convient.
Il est utile de faire la distinction entre la surveillance et les alertes. La surveillance signifie la collecte de données et la création de graphiques. Alerte signifie m'envoyer un SMS lorsqu'un serveur tombe en panne au milieu de la nuit.
Nagios sert à alerter. Les cactus et Munin sont destinés à la surveillance. D'autres produits combinent les deux fonctions. Zenoss et Zabbix en sont des exemples.
Je commencerais par répondre à quelques questions:
Avez-vous besoin de surveiller des serveurs, des périphériques réseau, des applications ou les trois?
Y a-t-il des limitations sur les méthodes que vous pouvez utiliser pour surveiller? Pouvez-vous installer des clients de surveillance comme NRPE sur les serveurs, ou allez-vous utiliser SNMP, ou peut-être les deux?
Qui utilisera les graphiques et qui utilisera les alertes? À quoi aimeriez-vous que le résultat final ressemble? L'aspect et la convivialité de l'interface sont-ils importants (les gens d'affaires l'utiliseront-ils ou uniquement le personnel technique?)
Quelles sont vos ressources, en termes de temps, de compétences et de matériel? Avez-vous au moins une capacité de script modeste? Avez-vous besoin d'une solution prête à l'emploi?
À mon avis, la première règle d'alerte et de surveillance devrait être Keep it Simple! Une organisation peut vivre ou mourir sur la façon dont elle alerte et recueille des données, et la plupart du temps, cela se compliquera de toute façon. Commencez par les bases et construisez à partir de là.
Pensez aux services fournis par votre logiciel , envoyez des alertes lorsque ces services échouent ou lorsque le risque de défaillance de ces services augmente.
La théorie derrière les stratégies de surveillance est de lier la surveillance et les alertes à une sorte d' accord de niveau de service . Après tout, vous voulez être alerté du fait que vous perdez de l'argent, pas nécessairement qu'il y ait un pic dans le nombre de connexions TCP vers nji0019.myserver.com. Il existe divers outils qui vous donneront des tonnes d'alertes, définiront des dépendances entre les alertes, mais bon nombre de ces vérifications ne sont pas directement pertinentes pour le service que vous fournissez à quelqu'un.
Identifiez les services importants que vous fournissez, tels que la possibilité de servir un site Web et la possibilité de modifier ce site Web (par exemple, un CMS quelconque). Celles-ci doivent être vérifiées (par exemple en surveillant que vous pouvez obtenir la page Web et que vous pouvez). L'échec de ces deux Services (utilisés ici avec un S majuscule) devrait déclencher une alerte pour vous avertir.
S'il est important que le site réponde dans un délai raisonnable, cela devrait également déclencher des alertes. Une sorte de "violation de SLA" si vous voulez.
Habituellement, il y a un risque inhérent à l'échec d'un service, et assez souvent ce risque est atténué par le fait que vous introduisez une redondance, par exemple un deuxième serveur, ou une base de données esclave, ou des cartes réseau supplémentaires ...
Lorsque cette redondance est perdue, le service fonctionne toujours bien, mais le risque d'échec du service vient d'augmenter.
C'est la deuxième raison majeure de déclencher des alertes; que la redondance a disparu (par exemple, que le deuxième serveur est mort), ou qu'il existe un danger imminent que le risque augmente (par exemple, il ne reste que 500 Mo de disque, ou la tendance du disque indique que le disque sera plein dans environ 5 heures).
Mais check_mk me donne 50-60 chèques par hôte, sont-ils tous sans valeur?
Non. Tout cela ne signifie pas que vous voulez abandonner la pléthore de vérifications automatiques que vous obtenez avec, par exemple, check_mk, mais cela signifie que vous devriez essayer de classer chacune des vérifications dans les services qui pourraient être affectés si quelque chose échouait.
Quel service serait affecté si la partition / var / se remplissait? Quel service serait affecté si l'interface eth0 était en panne? ... si les connexions TCP sortantes sont bloquées par un pare-feu? ... si le nombre de threads dépasse 800? ... si la base de données tombe en panne?
Vous avez 2 serveurs Web et un serveur de base de données desservant un site derrière un équilibreur de charge que vous ne possédez pas (par exemple le FAI). Le service que vous fournissez est le port 80 sur les deux serveurs, et ils ont d'énormes caches qui peuvent survivre, par exemple le temps d'arrêt de la base de données (base de données sur un troisième serveur).
Dans ce scénario, l'échec complet d'un serveur Web n'entraînerait pas l'arrêt du site. Ce qui s'est passé, c'est que la redondance a disparu, de sorte que le risque d'échec a augmenté. Cela devrait déclencher une alerte.
L'échec complet de la base de données pourrait ne pas affecter la capacité de servir le site du tout, en raison des caches bien réglés en place; Cela n'affecte alors pas le Service de servir le site Web, mais cela peut affecter un Service différent, à savoir la mise à jour du site Web, ou l'acceptation de commandes ...
Chaque service aurait son propre niveau de service qui indique à quel point il est important de rétablir le service ou d'éviter les pannes
Chaque fois que vous recevez une alerte, vous devez effectuer l'une des opérations suivantes: - changer le système surveillé pour résoudre le problème qui a provoqué l'alerte (par exemple remplacer le lecteur ou reconfigurer la rotation du journal ou autre) - changer le système de surveillance pour éviter que l'alerte soit envoyé la prochaine fois que la situation se présente. (par exemple, changez les niveaux pour "sans disque" afin que le disque puisse remplir jusqu'à 90% au lieu de seulement 80%)
Je connais principalement Nagios et sa configuration détaillée, et j'ai depuis été accroché au multisite de Check-mk. J'ai récemment appris que check_mk a ce concept de Business Intelligence (depuis 1.11) qui semble bien correspondre à cette pensée. Vous pouvez définir que les contrôles dans les nagios font partie d'un service plus vaste et ont des règles qui définissent l'état du "Service" comme étant fonction de l'état de nombreux contrôles, agrégés au pire ou au meilleur état.
L'un des points les plus critiques que les entreprises oublient lorsqu'elles choisissent une solution de surveillance est qu'il ne s'agit pas seulement de résoudre des problèmes opérationnels immédiats, mais des problèmes imprévus de demain! Je veux dire, bien sûr, la résolution de problèmes immédiats est importante, mais croyez-moi, dans de nombreux cas, cette stratégie à courte vue ne garantira pas la survie d'une entreprise.
Il existe des dizaines d'excellentes solutions de surveillance sur le marché. Présélectionner un petit ensemble de solutions qui répondent à vos besoins est une tâche difficile et longue, en outre, trouver celle qui correspond à votre budget est encore plus difficile. La partie intéressante consiste à en trouver un qui correspond à votre présent et à votre avenir . Et il n'y a pas de processus d'évaluation pour détecter cela, c'est une question d'expérience + d'intuition + un facteur très important: la confiance , ce qui n'est pas facile à pirater .
En règle générale, recherchez et recherchez des exemples de réussite de votre ensemble de solutions de surveillance présélectionné, surtout si cela affecte une entreprise de votre secteur. Demandez au vendeur leurs histoires de réussite, et même demandez-lui la permission de parler à l'un de ses clients. Les entreprises qui n'ont pas peur de ce spectacle ont de vraies relations avec leurs clients, et elles ne le cachent pas, et c'est une chose extrêmement rare à trouver de nos jours.
Zabbix, Icinga, Pandora FMS, op5, Datadog, New Relic ... ils ont tous leurs hauts et leurs bas, mais le vrai problème est de savoir lequel s'adapte le mieux à votre avenir.
Si vous envisagez de surveiller le système à distance, il peut être judicieux de rechercher les emplacements réels à partir desquels les tests sont effectués. Les problèmes de connectivité ne sont pas une chose du passé et si votre matériel dessert un groupe dans une région spécifique, vous voudrez peut-être vous assurer que vos ressources sont disponibles à cet emplacement particulier.