Salutations,
J'aimerais demander l'avis et la vue des collectifs sur les systèmes de surveillance distribués, qu'utilisez-vous et que savez-vous qui pourraient cocher mes cases?
Les exigences sont assez complexes;
Aucun point de défaillance unique. Vraiment. Je suis tres sérieux! Doit être capable de tolérer une défaillance de nœud unique / multiple, à la fois «maître» et «travailleur» et vous pouvez supposer qu'aucun emplacement de surveillance («site») ne contient plusieurs nœuds ou n'est sur le même réseau. Par conséquent, cela exclut probablement les techniques HA traditionnelles telles que DRBD ou Keepalive.
Logique distribuée, j'aimerais déployer plus de 5 nœuds sur plusieurs réseaux, dans plusieurs centres de données et sur plusieurs continents. Je veux que la vue "Birds Eye" de mon réseau et de mes applications du point de vue de mes clients, des points bonus pour la logique de surveillance ne s'embourbent pas lorsque vous avez plus de 50 nœuds, voire 500+ nœuds.
Doit être capable de gérer un nombre assez raisonnable de vérifications d'hôte / service, à la Nagios, car les chiffres approximatifs supposent de 1500 à 2500 hôtes et 30 services par hôte. Ce serait vraiment bien si l'ajout de nœuds de surveillance vous permettait d'évoluer de manière relativement linéaire, peut-être que dans 5 ans, je chercherais à surveiller 5000 hôtes et 40 services par hôte! En plus de ma note ci-dessus sur la `` logique distribuée '', ce serait bien de dire:
- Dans des circonstances normales, ces vérifications doivent s'exécuter sur $ n ou n% des nœuds de surveillance.
- Si une défaillance est détectée, exécutez des vérifications sur un autre $ n ou n% de nœuds, corrélez les résultats, puis utilisez-les pour décider si les critères ont été remplis pour émettre une alerte.
Graphiques et fonctionnalités conviviales de gestion. Nous devons suivre nos SLA et savoir si nos applications «hautement disponibles» sont disponibles 24h / 24 et 7j / 7 est quelque peu utile. Idéalement, la solution que vous proposez devrait faire un rapport "prêt à l'emploi" avec un minimum de faff.
Doit avoir une solide API ou un système de plugin pour développer des contrôles sur mesure.
Doit être sensible aux alertes. Je ne sais veux pas nécessairement (par SMS, à 3h du matin!) Que l' un noeud de surveillance estime mon routeur de base est en panne. Je ne veux savoir si un pourcentage défini d'entre eux conviennent que quelque chose géniale qui se passe;) Essentiellement ce que je parle ici est la logique « quorum », ou l'application de la santé mentale à la folie distribuée!
Je suis prêt à envisager des options commerciales et open source, bien que je préfère éviter les logiciels coûtant des millions de livres :-) Je suis également prêt à accepter qu'il n'y ait peut-être rien qui cocherait toutes ces cases, mais voulait demander cela au collectif.
Lorsque vous pensez à la surveillance des nœuds et à leur emplacement, gardez à l'esprit que la plupart d'entre eux seront des serveurs dédiés sur des réseaux FAI aléatoires et donc largement hors de ma sphère de contrôle. Les solutions qui s'appuient sur des flux BGP et d'autres singeries de réseau complexes ne conviendront probablement pas.
Je dois également souligner que j'ai déjà évalué, déployé ou largement utilisé / personnalisé la plupart des versions open source dans le passé, y compris Nagios, Zabbix et amis - ce ne sont vraiment pas de mauvais outils mais ils tombent à plat dans l'ensemble " aspect "distribué", notamment en ce qui concerne la logique évoquée dans ma question et les alertes "intelligentes".
Heureux de clarifier tous les points requis. Bravo les gars et les filles :-)
la source
Réponses:
pas vraiment une réponse, mais quelques conseils:
jetez un coup d'œil à la présentation de nagios @ goldman sachs . ils ont fait face à des problèmes que vous mentionnez - redondance, évolutivité: des milliers d'hôtes, également génération de configuration automatisée.
j'avais une configuration nagios redondante mais à une échelle beaucoup plus petite - 80 serveurs, ~ 1k services au total. un serveur maître dédié, un serveur esclave tirant la configuration du maître à intervalles réguliers quelques fois par jour. les deux serveurs couvraient la surveillance des mêmes machines, ils avaient une vérification croisée de la santé entre eux. j'ai utilisé nagios principalement comme cadre pour invoquer des vérifications spécifiques à un produit personnalisé [groupe de tâches cron exécutant des scripts faisant des «contrôles de flux artificiels», les résultats sont consignés dans sql, les plugins nrpe vérifient les exécutions réussies / échouées de celles-ci au cours des dernières x minutes]. tout fonctionnait très bien.
votre logique de quorum semble bonne - un peu similaire à mes «flux artificiels» - continuez, ipmplement vous-même; -]. et demandez à nrpe de vérifier simplement une sorte d'indicateur [ou sql db avec timestamp-status] comment les choses se passent.
vous voudrez probablement construire une hiérarchie à l'échelle - vous aurez des nœuds qui rassemblent une vue d'ensemble des autres nœuds, regardez la présentation du premier point. par défaut, nagios bifurque pour chaque vérification est exagéré avec un nombre plus élevé de services surveillés.
pour répondre à quelques questions:
la source
Ce que vous demandez ressemble beaucoup à ce que Shinken a fait pour Nagios.
Shinken est une réécriture de Nagios.
Cela devrait être matière à réflexion.
À votre santé
la source