Surveillance / collecte de métriques pour les systèmes collectifs qui changent beaucoup dans le temps (par exemple, le nuage).

Pour les systèmes à courte durée de vie ou dont l'infrastructure change souvent, j'utilise deux outils différents pour gérer la surveillance. J'ai ajouté un commentaire demandant quelles étaient les mesures les plus importantes pour vous, et il semble que vous recherchiez des mesures de base " que s'est-il passé quand ? "Suivi des statistiques avec quelques alertes...

Les systèmes et le matériel étant de plus en plus abstraits grâce aux services en nuage et à la virtualisation, certains des outils de surveillance traditionnels sont moins utiles, car vous ne vous souciez peut-être pas des ressources matérielles physiques et de leur santé. Ce qui compte, ce sont les applications et les ressources virtuelles (du point de vue de la VM, de l'instance ou du conteneur).

Les deux exemples que je donne ci-dessous sont entièrement autonomes et constituent un défaut dans mes environnements. Renforcé par Puppet, je peux m'assurer que tous les systèmes capturent et rapportent leurs performances.

Choix n° 1 - New Relic

La surveillance de New Relic est basée sur un agent et il est assez facile de l'intégrer dans un système d'approvisionnement ou de gestion de la configuration. Dans mon cas, chaque serveur que je déploie reçoit un agent New Relic. Configuration de New Relic marionnettisée L'installation de l'application est terminée, elle s'enregistre dans mon compte New Relic et est disponible dans le tableau de bord de surveillance environ 30 à 60 secondes après l'installation. L'hôte a poussé les données sur des ports standard, donc cela fonctionne bien dans tous les environnements. Le système peut se désenregistrer lors du démontage.

Les principaux points positifs sont une granularité de 60 secondes, une vue en direct du tableau de bord/kiosque, c'est gratuit pour la surveillance des serveurs et est propre et présentable d'une manière acceptable pour les utilisateurs finaux et les clients.

Choix n°2 - Monit y M/Monit

Monit est incroyablement pratique pour la surveillance des applications et du système de base. Monit est un agent qui s'installe facilement sur les systèmes cibles via la gestion native des paquets du système d'exploitation. Il peut être adapté pour surveiller des applications personnalisées et leurs paramètres pertinents, ainsi que pour prendre des mesures en fonction de ces paramètres. M/Monit ajoute un degré de centralisation aux contrôles Monit, et vous permet d'agréger les données à des fins d'analyse et de création de graphiques légers.

Étant donné qu'il est basé sur un agent, il est également facile de pousser les configurations vers les hôtes de manière automatisée. J'utilise également Puppet pour cela, avec quelques tentatives créatives pour construire les fichiers de confutations. Lors de l'initialisation, les nouveaux serveurs s'enregistrent auprès du démon central M/Monit sur les ports http/https, de sorte que les pare-feu et la surveillance de plusieurs sites ne posent pas de problème.

Si vous parlez d'un logiciel standard pour le cloud, alias Openstack, les composants sont bien connus.

Collecter des données historiques à l'échelle du nuage : https://wiki.openstack.org/wiki/Ceilometer

Surveiller - sensu

EDIT :

Ceilometer est spécifique à openstack, mais sensu est un cadre de surveillance générique. De plus, collectd est un système assez standard pour collecter des métriques, que vous pouvez à votre tour alimenter dans cacti ou graphite, pour générer des graphiques de tendance. Pour quelque chose d'encore plus poussé, vous pouvez intégrer un serveur de rapports, comme Jasper Reports, mais vous devrez faire votre propre CTL. En bref, il existe de nombreuses options, et cette question est en effet trop vaste pour qu'on puisse y répondre de manière concise.

Je ne suis pas sûr qu'il soit possible de répondre à cette question, car les systèmes de cloud computing sont très diversifiés (j'ai d'ailleurs signalé qu'elle était trop vaste), mais voici mes réflexions.

En ce qui concerne les mesures du système, vous aurez besoin d'un agent sur vos serveurs qui transmet les mesures à un point de collecte central pour s'assurer que les nouveaux serveurs sont automatiquement ajoutés et que les anciens serveurs sont élagués ou cessent simplement de transmettre des mesures lorsqu'ils sont arrêtés.

Vous pouvez soit mettre en place votre propre infrastructure (mais cela s'accompagne également d'un problème potentiel de surveillance de l'infrastructure en nuage avec l'infrastructure en nuage - que se passe-t-il lorsque Amazon décide de retirer votre serveur collectd ? StackDriver , NewRelic , Frontière , HostedGraphite pour n'en citer que quelques-uns - les solutions SaaS vont généralement de pair avec les plateformes IaaS).

Vous pouvez bien sûr gérer votre propre serveur Nagios dans votre infrastructure en nuage, et quelque chose comme Puppet utilisant des ressources exportées peuvent rendre cette tâche extrêmement facile - vous devriez au moins déjà utiliser une sorte d'outil d'automatisation si vous utilisez des technologies en nuage.

Si vous avez besoin d'une plateforme de surveillance/alerte d'infrastructure descendante, NewRelic et StackDriver disposent tous deux de cette fonctionnalité, du moins pour le nuage Amazon, et peuvent se brancher sur des mécanismes de notification comme PagerDuty - pour l'instant, je n'ai pas connaissance d'une solution globale "unique".