Systèmes de surveillance des applications / hôtes géographiquement distribués, tolérants aux pannes et «intelligents»


12

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 :-)


2
C'est vraiment étrange, j'allais poser une question similaire. Cette semaine, nous avons reçu des plaintes de clients concernant des pannes de site, mais uniquement de certains endroits. Nos systèmes d'alerte n'ont pas détecté ces problèmes. Nous avons contacté notre fournisseur et ils ont confirmé que certains avaient des problèmes de colonne vertébrale. Je suis donc également intéressé par une solution. Merci!
splattne le

Et quelle a été la solution finale?
ewwhite

Réponses:


4

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:

  • dans mon cas, l'environnement surveillé était une configuration maître-esclave typique [serveur SQL principal ou serveur d'applications + redondance d'UC], pas de maître-maître.
  • ma configuration impliquait «facteur de filtrage humain» - groupe de résolveurs qui était une «sauvegarde» pour la notification par SMS. il y avait déjà un groupe de techniciens rémunérés qui, pour d'autres raisons, avaient 24/5 quarts de travail, ils ont obtenu la «vérification des mails nagios» comme tâche supplémentaire sans leur imposer trop de charge. et ils sont chargés de s'assurer que les db-admins / it-ops / app-admins se lèvent réellement et résolvent les problèmes; -]
  • J'ai entendu beaucoup de bonnes choses sur zabbix - pour alerter et tracer des tendances, mais je ne l'ai jamais utilisé. pour moi, munin fait l'affaire, j'ai piraté un simple plugin nagios pour vérifier s'il y a une couleur «rouge» [critique] sur la liste des serveurs munin - juste une vérification supplémentaire. vous pouvez également lire les valeurs des fichiers rrd de munin pour réduire le nombre de requêtes que vous envoyez à la machine surveillée.

1
@astinus - bien pour les alertes sensibles j'ai utilisé un script de notification personnalisé. au lieu de compter sur nagios notifier par mail / pager j'ai stocké un message à fifo que et avait un consommateur qui a envoyé un message basé sur une logique personnalisée [basé sur un calendrier d'appel assez flexible, etc.], en plus il y avait une certaine limite de msgs envoyés par heure donc un n'obtient pas 50 smses en peu de temps. je vois des approches similaires à plus grande échelle - nagios est juste un squelette et des scripts de personnes autour et utilisent en fait de moins en moins de ses fonctionnalités.
pQd

1
En ce qui concerne la hiérarchie, ce que j'ai pour le moment est une configuration Nagios entièrement "modulaire" où votre répertoire etc / contient une configuration 'core' qui est partagée (et identique) sur tous les hôtes puis etc / modules / $ NAME (ie : Mail, Web, Réseau, DNS) qui est 100% portable entre les serveurs. Inclure avec cfg_dir =) Vous mettez dans toutes les commandes spécifiques au module, plugins et tout dans ce répertoire. Faire> 1 serveur exécuter ces vérifications est assez facile car vous copiez simplement le module dans autant de boîtes Nagios que nécessaire, mais encore une fois, la logique d'alerte pose des problèmes :-)
nixgeek

1
@ astinus # 2. dans mon cas, la configuration de réplication maître-> esclave se produit toutes les 6 heures. si le maître vient de mourir [panne de courant, etc.] - l'esclave alertera tout le monde sur le fait que le maître est mort [vérification croisée entre les serveurs]. on peut imaginer un autre scénario - lorsque le maître décède à cause d'une mauvaise configuration. si cela se produit jusqu'à 5 min avant de configurer la synchronisation avec l'esclave - il y aura une notification. si c'est juste avant de configurer la synchronisation - malheureusement, nous finissons par ne pas avoir de système de surveillance. «qui veillera sur le gardien»? enfin peut-être un autre nagios très simple.
pQd

1
@pQd - intéressant, je suis d'accord que l'implémentation de la logique dans les scripts de notification personnalisés est probablement la voie à suivre. Cependant, il est assez difficile d'éviter les notifications en double de 2+ hôtes, quand vous avez dit 50 hôtes de surveillance, et je n'ai encore vu personne (en public) mettre leur logique partagée dans un système de passage de `` message '' approprié comme Rabbit ou Amazon SQS.
nixgeek

1
@ astinus # 3 dans mon cas, c'était la solution 'Niveau 8' [du modèle iso osi]: les nagios primaires envoyaient des sms aux personnes sur appel + des mails au 24/5 'groupe de résolveurs', tandis que les nagios du 2e ne faisaient que poster ' groupe de résolveurs ». il appartenait à ce groupe de filtrer les doublons avant d'escalader;
pQd

1

Ce que vous demandez ressemble beaucoup à ce que Shinken a fait pour Nagios.

Shinken est une réécriture de Nagios.

  • Langage moderne (Python)
  • Cadre de programmation distribué moderne (Pyro)
  • Royaumes de surveillance (multi-tenancy), HA, pièces de rechange
  • API Livestatus
  • Compatible avec le plugin Nagios
  • Exécution native NRPE
  • Criticité métier des objets
  • Les règles métier peuvent être appliquées à l'état des objets (gestion de la disponibilité du cluster ou du pool)
  • La représentation graphique peut utiliser du PNP4nagios basé sur Graphite ou RRDtool
  • Stable et déployé dans de grands environnements
  • Les grands déploiements peuvent envisager de le coupler avec Splunk pour les rapports ou examiner Graphite où RRDtool ne convient pas.

Cela devrait être matière à réflexion.

À votre santé

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.