Monitoring as a Service

Supervision OpenStack

MONaaS

Alexandre Viau

alexandre.viau@savoirfairelinux.com

Thibault Cohen

thibault.cohen@savoirfairelinux.com

Monitoring as a Servce

MONaas

https://blueprints.launchpad.net/ceilometer/+spec/monitoring-as-a-service

Qu'est-ce que la supervision?

Exécute des vérifications
Applique des règles
Alerte les utilisateurs
Stocke un historique des données

L'État de la supervision dans le cloud

Amazon CloudWatch

“Amazon CloudWatch fournit une surveillance pour les ressources du cloud AWS et les applications que les clients exécutent sur AWS.”

Supervision passive seulement
API Put pour métriques personnalisées
Alarmes
Utilisez Auto Scaling pour ajouter ou supprimer dynamiquement des instances Amazon EC2 en fonction de vos mesures Amazon CloudWatch

Rackspace Cloud Monitoring

Supervision active et passive
Vérification de services
API Put pour métriques personnalisées
Alarmes
Agent in-instance

OpenStack Telemetry

Ceilometer

Ceilometer

Objectif initial

Être l’unique point de contact pour les systèmes de facturation et d’acquérir toutes les mesures dont ceux ci ont besoin pour effectuer la facturation à travers l’ensemble des composants d’OpenStack.

_images/ruban_mesurer.png

Depuis Grizzly:

Devenir l’infrastructure pour la collecte de mesures dans OpenStack afin d’éviter que deux agents soient développés pour acquérir les mêmes données. Le but principal de Ceilometer est le monitoring et le metering.

caméra

Les métriques disponibles dans Ceilometer

Utilisation CPU
Utilisation mémoire
Utilisation du disque
Trafic réseau

Ce qui manque...

Polling
Disponibilité de services
Données applicatives
Scénarios de vérification
Règles d'affaires
Scaling sur les données applicatives

Fil conducteur...

Monitoring as a Service

API RESTful
Hautement disponible
Tolérant aux erreurs
Autosupervisé

Le SLA doit être beaucoup plus haut que celui de l'application.
00:10:00

Ce que cela apporterait

Polling d'agents dans les instances

NRPE
SNMP
SSH
etc... Nouveau protocole??

Supervision des services

Disponibilité
Temps de réponse
Scénarios HTTP
Protocoles TCP/UDP (NTP, DNS, MYSQL, SMTP, IMAP, ...)

Supervision depuis plusieurs sites

Expérience utilisateurs depuis plusieurs sites
Assurer la disponibilité
Supervision plus complète
Comment est-ce que les utilisateurs de Montréal vivent la release localisée d'un nouveau module de notre application?

Supervision depuis plusieurs sites (schéma)

_images/verification-multi-site.png

Monitoring actuel Nagios
00:15:00

Nos démarches

Soumission du blueprint
Openstack-dev
Contact avec l'équipe de Ceilometer

Réaction de HP
Meetings IRC

Idées d'implémentation

hpcloud-mon

_images/hpmon.png

Shinken comme coeur de supervision ?

Compatibilité Nagios
Écrit en Python
Architecture modulaire
Support des règles d’affaires
Intégration possible dans Horizon

Exemple d'implémentation avec Shinken

_images/shinken_in_openstack.png

Exemple d'implémentation avec Shinken

_images/shinken_openstack_multisite.png

Supervision de l'infrastructure OpenStack

Disponibilité de chaque élément d’OpenStack à travers l’API
Performance de chaque éléments d’OpenStack à travers Ceilometer
Supervision des événements à travers RabbitMQ

Monitoring actuel Nagios

Supervision sur terre

Supervision standard de l’infrastructure
- Serveurs
- Switches
- Firewall
- SAN
- ...

Supervision sur trois niveaux

Des applicatifs (Support de StatD, ...)
De la plate-forme (Apache, Mysql, Reddis, ...)
De l’infrastructure (CPU, mémoire, IO, ...)

Le concept de royaume dans Shinken permettrait d’effectuer la superivision de ces trois niveaux, de façon indépendante

références

Blueprint MONaas: https://blueprints.launchpad.net/ceilometer/+spec/monitoring-as-a-service
Page wiki: https://wiki.openstack.org/wiki/MONaaS
Annoncement sur openstack-dev: http://lists.openstack.org/pipermail/openstack-dev/2014-May/034189.html

Questions / Discussion

⇑⇑ savoirfairelinux.github.io/MONaaS-presentation ⇑⇑