Shinken on Zwindler's Reflection

Superviser des appliances HPE StoreVirtual VSA (LeftHand) avec Nagios/Centron/Shinken

Tue, 08 Jan 2019 12:45:34 +0000

Superviser des Lefthand ?

Dans une vie antérieure (article dans mes tiroirs depuis fin 2015 a priori XD), j’ai eu à gérer, on premise, du stockage hautement disponible HPE VSA pour mes clusters VMware.

Si vous êtes ici, c’est sûrement parce que vous aussi, vous avez acheté des LeftHand (StoreVirtual P4000) et/ou des HPE VSA, et que vous voulez les superviser.

La plupart des tâches d’administration se font depuis la CMC (Centralized Management Console), mais clairement ce n’est pas hyper pratique. La section 7 du manuel StoreVirtual traite de la supervision en général : h20628.www2.hp.com/km-ext/kmcsdirect/emr_na-c04581885-1.pdf (lien mort, pas sauvegardé par Internet Archive).

Heureusement, la documentation explicite clairement qu’il est possible d’activer SNMP pour externaliser tout ça.

A noter, je n’ai pas pu m’empêcher de glousser en lisant cette petit phrase dans un manuel d’administration un peu plus ancien, qui dit que vous ne pouvez pas changer, ni même supprimer (#Sécurité), les communautés par défaut :

Section 7 du manuel d’administration http://www.hp.com/ctg/Manual/c01865545.pdf

Nagios / Centreon / Shinken

Pour superviser mes machines dans mes DC « on-premise », j’utilisais Centreon. Tout naturellement je me suis tourné vers Nagios Exchange pour voir s’il n’y avait pas déjà des gens qui avaient fait le travail.

2 plugins ont attirés mon attention :

Prérequis

Le plus récent et le plus téléchargé, check_lhc, nécessite le téléchargement de MIB. Je les avaient trouvé sur circitor (ex. www.circitor.fr/Mibs/Html/L/LEFTHAND-NETWORKS-NUS-COMMON-CLUSTERING-MIB.php), puis de les déposer dans votre serveur Nagios/Centreon/Shinken

/usr/share/snmp/mibs/

J’avais également trouvé des ressources sur le site d’HPE, mais comme ils passent leur temps à le refaire les 3 liens que j’avais sauvegardés sont maintenant HS. Voilà voilà.

En gros, ce que ça disait, c’est que les MIB sont contenues dans l’installeur, celui qui est utilisé pour instancier les VSA la première fois.

Fallait le savoir…

Configurer SNMP

Comme les deux plugins utilisent SNMP, on va… l’activer. #ThanksCaptainObvious.

Depuis la CMC, on peut donc configurer nos StoreVirtual pour qu’elles acceptent des connexions SNMP et configurer une communauté (voir le manuel d’admin, page 93). Clairement, ce n’est pas sorcier.

Dans le Management Group, on a un menu Event, dans lequel on peut configurer un serveur SMTP (pratique pour recevoir les mails qui m’informe que mon cluster est à plat et que mes données sont définitivement corrompues et que je peux aller pointer à Paul Emploi).

Et, SNMP.

Checker

Maintenant que vous avez activé SNMP (avec une communauté bien complexe, readonly et des restrictions IP à vos seuls serveurs de supervision, on est d’accord), on peut voir si ça marche.

Personnellement j’ai préféré check_lefthand, car la doc est plus fournie et les options plus nombreuses .

./check_lefthand.pl -H 10.10.10.16 -C hyperdifficultcommunity
Cowardly exiting, not instructed to check anything!
check_lefthand.pl -H -C [-t timeout] [-p port]
Additional Options:
--module-space
report the available space on each 'module' within a management group
--module-status
report on the various status elements for each 'module' within a management group
--volume-space
report the available space on each volume within a management group
--volume-status
report on the various status elements for each volume within a management group
--cluster-space
report the available space for each cluster within a management group
--cluster-status
report the status of each cluster within a management group

Les deux alertes que j’ai mises en place sont l’état du clusters, et le status de mes volumes (synchronisés ou pas entre les 2 salles).

centreon$ ./check_lefthand.pl -H 10.10.10.16 -C hyperdifficultcommunity --cluster-status
OK - mgmt group: MyAwesomeHPVSA 5/5 Cluster Managers Active.
centreon$ ./check_lefthand.pl -H 10.10.10.16 -C public --volume-status
OK - mgmt group: MyAwesomeHPVSA 4 Volumes with valid replication and Data Protection.

A noter, tout n’est pas parfait. Dans certains cas, j’ai remarqué que l’alerte ne se déclenchait pas quand des nœuds étaient DOWN, car le compteur « total » de nœuds décrémentait en même temps que les nœuds tombaient (ce qui est très bête…).

Mais c’est quand même un début :)

Bonus : Rage

Ouais, je sais…HPE VSA (maintenant HPe StoreVirtual VSA), quoi. L’alternative « géniale » de HPE à VSAN.

Ne me blâmez pas… A l’époque, on m’avait donné le choix entre 2 appliances physiques NetApps plus chères et même pas hautement disponibles (actif/passif) et donc les fameuses HPE VSA Storevirtual. Et puis sur le papier, ça paraissait robuste. C’est basé sur un produit éprouvé, les Lefthands (appliances physiques) et un OS Linux.

What could go wrong?

Maintenant que je ne m’en occupe plus, je peux dire que c’est grâce à ce superbe outil que j’aurai fais un week end non-stop quasiment sans dormir au téléphone avec des techs HPE et VMware de tout autour du monde (mais je me suis fait payer plus de 25 heures d’astreinte #youpi) parce que les nœuds tombaient les uns après les autres sans raison apparente.

Pour les curieux, c’était un problème de hotspare qui se mettait en veille et bloquaient les nodes, les uns après les autres, dès qu’une commande « refresh storage usage » était lancée par l’ESXi (automatique ou manuel).

C’est aussi mon record personnel du ticket support le plus longtemps, tout constructeur/éditeur confondu. Les chiffres sont impressionnants :

un mois pour trouver un workaround (désactiver les hotspares, #genious)
plus de 200 emails
5 mises à jours (dont 4 inutiles)
3 interventions le soir sur la prod
Et last but not least : 2 ans pour trouver le fix (alors que le problème était détecté puisqu’on savait qu’il suffisait de désactiver les hotspares).

DEUX… ANS…

Au final, je ne suis même pas vraiment sûr que le problème soit fixé.

Je ne suis plus sûr de rien, à part du niveau de compétence de HPE sur le sujet des serveurs et du stockage.

Mais qui peut les blâmer, ce n’est pas leur cœur de métier après tout. #ohwait

Monitorez le fait que les URLs bloquées sont bien bloquées par le proxy

Sat, 18 Nov 2017 12:45:25 +0000

Comment je vérifie que les sites bloqués par mon proxy sont bien bloqués ?

Il y a plein de raisons qui peuvent expliquer qu’un site non légitime soit bloqué sur un lieu de travail (par exemple). Et autant de raisons qui font que, parfois, les proxies ne bloquent pas bien des sites que vous aviez pourtant bloqués !

Pour tout ce qui est supervision des pages web, Nagios fourni le plugin check_http, dans les nagios-plugins (collection officielle de plugins), et qui permet de vérifier qu’une page web donnée est accessible (ou non).

Limitations

Cependant, il existe plusieurs cas où ce plugin ne « fonctionne pas » comme je le souhaite :

D’abord, dans le cas où l’URL checkée renvoie un 30x (redirection), le check_http considère que c’est bon et ne va pas chercher plus loin. Hors, il arrive que le site soit down au-delà de la redirection. Dans ce cas là, check_http ne nous notifie pas de l’échec.
Ensuite, dans le cas où vous voulez traverser un proxy pour vérifier si une page est accessible ou non comme dans mon introduction, vous ne pouvez pas spécifier si un code retour 40x est une bonne chose ou non. Dans tous les cas, avec check_http, un 40x sera considéré comme un WARNING, jamais comme un CRITICAL ou un OK.

Pour résoudre ces problèmes, j’ai donc réécris un petit script bash simple, permettant de résoudre tous les cas ci-dessus. Avec check_proxy_http_url, vous pouvez vérifier des URLs en spécifiant un proxy, suivre correctement les redirections (301 ou 302 par ex.) et spécifier si le fait qu’une page soit accessible (ou pas accessible) est une bonne chose ou non.

Installation

Le script est simplissime. Pour des raisons de facilité je me suis simplement appuyé sur un script bash et de wget, présents sur la plupart des serveurs par défaut. Il n’y a pas d’autres prérequis.

Dans un futur (plus ou moins) proche j’ajouterai également une compatibilité avec cURL, qui a tendance à le remplacer.

Usage

Là encore, j’ai fait au plus simple. Le script dispose d’un nombre limité d’arguments, permettant de réaliser les usecases indiqués précédemment.

/var/lib/nrpe/plugins/check_proxy_http_url.sh -u TARGET_URL [-p PROXY_ADDRESS:PROXY_PORT] [-r] [-v]

TARGET_URL : obligatoire - l’URL que vous souhaitez superviser. Par défaut, un code retour de type 200 induira un OK, un 4XX/5XX un CRITICAL
PROXY_ADDRESS & PROXY_PORT : optionnels - le hostname ou l’adresse de votre proxy, si nécessaire
-r : optionnel - permet d’inverser les codes retours de Nagios. Un code retour 200 induira un CRITICAL (URL qui est accessible alors qu’elle ne le devrait pas) et un 4XX/5XX induira un OK

Exemples

Vérifier que http://@IPsome_forbidden_website.com n’est pas accessible et renvoyer un CRITICAL sinon.

[root@lanhost ~]# /var/lib/nrpe/plugins/check_proxy_http_url.sh -u some_forbidden_website.com -r
OK: URL some_forbidden_website.com isn't available and it shouldn't - 403

Vérifier que http://@IPsome_allowed_website_that_isnt_accessible.com n’est pas accessible et renvoyer un CRITICAL sinon.

[root@lanhost ~]# /var/lib/nrpe/plugins/check_proxy_http_url.sh -p internal_proxy:8181 -u some_allowed_website_that_isnt_accessible.com
CRITICAL: URL some_allowed_website_that_isnt_accessible.com isn't available and it should - 403

Code source

Comme d’habitude avec mes plugins « Nagios compatibles », les sources sont disponibles sur Github à l’adresse suivante :

github.com/zwindler/check_proxy_http_url

Le lien pour Nagios Exchange est également disponible ici !

Mes autres plugins sont également disponibles sur le Github :

check_emc_rlp : supervision des LUNs dans le RLP sur baies VNX EMC²

Tue, 25 Apr 2017 12:00:51 +0000

Dans la série …

… plugins pour les outils de supervision Nagios(r) like et « Nagios(r) compatibles » (Icinga, Naemon, Shinken, …), je met à disposition un script que j’ai écris il y a quelques années et qui permet de vérifier et de grapher que vous disposez toujours des LUNs dans le RLP (Reserved LUN Pool). Je l’ai appelé sobrement check_emc_rlp et j’en parle aussi dans cet article à propos de NaviSecCli.

Mon problème initial était que j’avais plusieurs fois eu mes snapshots bloqués lors de l’utilisation un peu trop intensive du LUN source. Il n’y avait plus de place sur les LUNs dans le RLP, ce qui a pour effet de bloquer le snapshot et donc la base de préproduction que j’avais dessus. Un petit script qui vérifie qu’il y a toujours au moins 1 LUN non utilisé par LUN snapshoté permet de garder un peu de marge avant plantage.

Voilà ce que donne ce check_emc_rlp une fois mis en place dans Centreon :

Le script nous informe qu’il reste suffisamment de LUN dans le RLP lorsqu’il y a des snapshots actifs

La courbe de performance (PERFDATA Nagios) indique ici qu’il reste 3 LUN par LUN snapshoté (12 en fait en tout), et qu’on remonte à 6 par LUN à minuit (moment où on rafraichit notre préproduction et que les snapshots se vident)

La vue agrégée avec à la fois le nombre de LUN disponibles dans le RLP ainsi que le remplissage des LUN utilisés pour stocker le différentiel, par LUN snapshoté. Ce qui est intéressant ici c’est qu’on voit bien l’évolution du remplissage et le moment où la baie décide qu’elle a besoin d’un nouveau LUN en provenance du RLP

Comme d’habitude pour le téléchargement et la documentation, c’est sur Nagios Exchange et Github que ça se passe.

Pour rappel, vous trouverez aussi mes autres plugins Nagios dans le même repository Github.

Superviser des onduleurs/UPS avec Nagios/Centreon et SNMP

Tue, 17 Jan 2017 13:00:52 +0000

Être alerté par l’onduleur en SNMP

Il n’est pas rare que les onduleurs (ou Uninterrupted Power Supply chez nos amis anglosaxons), même sans être très haut de gamme, disposent de sortie Ethernet permettant de superviser l’état de l’onduleur, sa charge, …

Généralement, ce genre d’onduleur est également livré avec des clients propriétaires qui vous permettent de configurer la partie réseau de l’onduleur, puis ensuite de définir des alertes, voire des actions à réaliser lorsque l’onduleur commence à se décharger. Cependant, dans un environnement un tant soit peu industrialisé, ce genre d’outil est rarement pratique :

Il y a généralement déjà un outil de supervision en place, et en ajouter un va à l’encontre de l’efficacité pour les équipes support. Des consoles de supervision doivent être installés sur les postes des administrateur.
Les agents pour éteindre les serveurs alimentés doivent être installés (ce qui induit une tâche d’exploitation/maintenance supplémentaire), parfois en s’appuyant sur des versions hors d’age de Java comme dépendance, et avec bien peu de support une fois que le produit est chez vous.

Heureusement, la plupart des onduleurs exposent également une MIB SNMP standard, que vous pouvez donc très simplement ajouter pour réaliser vous même votre propre supervision. Et même pourquoi pas votre propre agent d’extinction, en se basant sur un script ainsi qu’un agent déjà présent sur les machines pour la supervision (NSClient/NRPE pour moi).

Pour trouver cette MIB (.1.3.6.1.4.1.21111.1.1, originalement nommée UPS), j’ai tout simplement utiliser un snmpwalk sous Unix en me connectant à l’adresse IP de l’onduleur après configuration. Sous Windows, on peut aussi utiliser un utilitaire graphique pour faire la même chose, notamment avec iReasoning MIB Browser qui nous donne également quelques informations sur les indicateurs disponibles.

MIB Browser donne des informations sur la MIB de manière graphique, ce qui peut être plus lisible qu’un simple snmpwalk

Quoi surveiller ?

Les indicateurs de la MIB UPS qui m’ont parus les plus opportuns à surveiller sont les suivants :

upsBatStatus (.1.3.6.1.4.1.21111.1.1.3.1.0) : L’état de la batterie qui peut être chargé ou en cours de déchargement. Tout ce qui n’est pas 2 est inquiétant.
upsBatEstChargeRemaining (.1.3.6.1.4.1.21111.1.1.3.4.0) : L’estimation de la charge restant de la batterie en %age. Si on descend sous 90% c’est que l’onduleur se décharge et que ce n’est pas une microcoupure !
upsBatEstMinutesRemaining (.1.3.6.1.4.1.21111.1.1.3.3.0) : L’estimation du temps restant avant que la batterie soit épuisée. Je trouve cet indicateur pratique pour 2 raisons
- On peut lancer des actions d’urgence (ssh + shutdown sur tous les linux) à partir d’un certain temps avant l’épuisement plutôt qu’un pourcentage, car on peut estimer que 5 minutes avant l’échéance, on aura plus le temps de rétablir avant coupure. Ce qui est plus difficile à fixer en pourcentage.
- On peut éventuellement détecter un problème sur les batteries ou sur la charge de l’onduleur si en fonctionnement normal (sur secteur) on se retrouve avec un temps de charge trop bas.
upsBatSecondsOnBattery (.1.3.6.1.4.1.21111.1.1.3.2.0) : Le nombre de secondes depuis que l’onduleur est sur batterie et n’est donc plus sur secteur. Si on dépasse 0, c’est mauvais signe mais pour éviter les alertes intempestives j’ai mis 2.

Et comme je suis sympa, je vous passe la configuration Nagios/Centreon (ou tout autre produit compatible) associée qui vous permettra d’obtenir les indicateurs en question sans effort. Enjoy !

define command {
command_name check_snmp
command_line $USER1$/check_snmp -H $HOSTADDRESS$ -o $ARG1$ -w $ARG2$ -c $ARG3$
}
define service {
service_description Template_par_défaut_pour_tous_les_serivces
name generic-service
contacts generic-contact
check_period 24x7
notification_period 24x7
max_check_attempts 5
check_interval 5
retry_interval 5
notification_interval 15
notification_options w,u,c
first_notification_delay 0
register 0
notifications_enabled 1
}
define service {
service_description 2_tentatives_et_interval_de_5_minutes_en_24_7
name 2retry_5min_24x7
check_period 24x7
max_check_attempts 2
check_interval 5
retry_interval 5
notification_interval 5
register 0
use generic-service
}
define service {
service_description Check_SNMP_upsBatStatus
name snmp_upsBatStatus
check_command check_snmp!.1.3.6.1.4.1.21111.1.1.3.1.0!2!2
register 0
use 2retry-5min-24x7
}
define service {
service_description Check_SNMP_upsBatEstChargeRemaining
name snmp_upsBatEstChargeRemaining
check_command check_snmp!.1.3.6.1.4.1.21111.1.1.3.4.0!90:!80:
register 0
use 2retry-5min-24x7
}
define service {
service_description Check_SNMP_upsBatEstMinutesRemaining
name snmp_upsBatEstMinutesRemaining
check_command check_snmp!.1.3.6.1.4.1.21111.1.1.3.3.0!30:!20:
register 0
use 2retry-5min-24x7
}
define service {
service_description Check_SNMP_upsBatSecondsOnBattery
name snmp_upsBatSecondsOnBattery
check_command check_snmp!.1.3.6.1.4.1.21111.1.1.3.2.0!2!2
register 0
use 2retry-5min-24x7
}

Plugin de supervision check_wlst_sessions (WebLogic 9+)

Wed, 09 Nov 2016 13:00:18 +0000

Dans la série : plugin pour les outils de supervision Nagios(r) like et « Nagios(r) compatibles » (Icinga, Naemon, Shinken, …), je met à disposition un script que j’ai écris il y a quelques années et qui permet de vérifier et de grapher que vous n’avez pas atteint un certain nombre de sessions concurrentes dans le serveur d’application Java WebLogic d’Oracle.

Mon problème initial était que je n’arrivais pas à avoir de manière simple le nombre de sessions sur une JVM WbLogic. Je pouvais compter le nombre de processus/threads, mais ça ne correspond pas forcément à un nombre d’utilisateurs actifs.

Or, l’éditeur du progiciel nous avait fourni un sizing en fonction d’un nombre d’utilisateurs. Il était donc important d’avoir ce chiffre de manière fiable.

Il existait un plugin similaire pour la version 8 du serveur d’application (développé par Sergei Haramundanis), mais qui utilisait un module Weblogic.Admin, déprécié dans la version 10 que j’utilise.

Je me suis donc basé sur le WebLogic Scripting Tool (WLST) qui permet d’administrer et de récupérer des informations des serveurs WebLogic via des commandes Python interprété par Java (-_-« ). En fait, on peut réaliser l’ensemble des opérations disponibles dans la console WebLogic (l’AdminServer) en script.

La documentation du WLST est disponible à l’URL suivante.

Voilà ce que ça donne, une fois mis en place :

Comme d’habitude pour le téléchargement et la documentation, c’est sur Nagios Exchange et Github que ça se passe.

Pour rappel, vous trouverez aussi mes autres plugins Nagios dans le même repository Github.

Comment installer Shinken 2.4 hors ligne (sans accès à Internet)

Wed, 02 Nov 2016 15:11:10 +0000

Pourquoi installer un logiciel (et notamment Shinken) hors ligne ?

[Aparté] Pour ceux qui ne connaissent pas encore bien Shinken, je vous propose de lire mes précédents articles sur le sujet et notamment celui où j’introduis le logiciel ainsi que ces fonctionnalités principales. [/Aparté]

De plus en plus -même si ça fait bien longtemps que la tendance s’est installée- les packages (dépôts Debian like/RHEL/whatever) mais aussi les langages & les frameworks (perl, pear (php), npmjs), voire même les logiciels vous simplifie la vie. On vous met à disposition un gestionnaire/binaire/ligne de commande pour télécharger de nouveaux modules/composants depuis un dépôt sur Internet, avec une gestion des dépendances et l’installation (voire compilation) automatisée.

Et c’est vrai que c’est quand même super pratique.

Qui n’a jamais pesté de ne pas avoir le CPAN de Perl à disposition ? Devoir télécharger manuellement sur le site CPAN.org puis compiler des modules selon un arbre de dépendances long comme le bras ? Et avec deux méthodes de compilation différentes (Make & Build) selon le module si possible !

Pour ceux qui n’ont pas connus ce « fun ultime » je vous propose de jeter un œil à cet article où je récapitule comment installer sur EON et CentOS une sonde Nagios (oui, une seule) en 161 lignes de commande.

Pour autant, il n’est pas rare que les administrateurs réseaux du DataCenter, par souci de sécurité et respect des bonnes pratiques, refuse par défaut l’accès direct à Internet pour les serveurs. Dans le meilleur des cas, il existe des dépôts locaux qui sont le miroir de ce qu’on trouve sur Internet à un instant T, mais :

Ils ne contiennent jamais l’exhaustivité des RPM/DEB/…
Les versions des packages évoluent tout le temps et garder un ensemble cohérent de tous les modules et leur dépendances et quasi impossible (notamment les rpm pour des modules PHP… $*%$$*)
On ne peut pas avoir l’ensemble des gestionnaires qui existent (rien que la courte liste que je cite plus haut, c’est compliqué)
Dernier cas : il n’existe pas nécessairement de méthode pour stocker dans le DC une copie des modules

Il faut donc s’y résigner : il arrive des fois où l’installation hors ligne de dépendances est malheureusement incontournable.

Le cas de Shinken

Il m’est arrivé à plusieurs reprises à devoir installer Shinken hors ligne dans des DC coupés d’Internet et a priori je ne suis pas le seul (quelques anciens collègues, un commentaire sur le blog, …). Pour autant, de ce que j’ai pu voir, il n’existe pas dans la documentation (ou alors plus) qui mentionne la méthode pour le faire.

Mais vous avez de la chance, la méthode existe !

Je ne vais pas rentrer autant dans les détails de l’installation et de la configuration de Shinken. Cette partie est traitée de manière exhaustive dans les tutoriels précédemment publiés (ici puis ici). Pour autant, voici la marche à suivre lorsque Shinken fait appel à Internet et que vous souhaitez réaliser l’opération hors ligne.

Pour les dépendances RPM via yum

Note : cette partie de l’article est applicable au delà de Shinken, je l’utilise tous les jours pour constituer mes bases de RPM pour l’ensemble des distributions et des logiciels que j’administre.

Pour les dépendances RPM, 2 solutions :

Soit vous montez votre propre dépôt local, par exemple avec createrepo et un serveur Apache. C’est très simple à mettre en place et c’est un bonne idée lorsque vous avez beaucoup de packages a installer, ou plusieurs version de distrib’ a administrer.
Soit vous vous créez un dossier dans lequel vous récupérer tous les RPM et leurs dépendances. Vous copierez ce dossier sur le serveur où vous souhaitez installer Shinken.

Quoiqu’il arrive, vous devrez donc passer par la case « téléchargement manuel » de tous les RPM nécessaires.

yumdownloader

Dans le meilleur des cas, vous disposez d’un Linux de la même version et qui a un accès à Internet. Et là vous allez vous simplifier la vie avec le binaire yumdownloader.

Ce binaire fonctionne de la même manière que yum, à ceci près qu’il télécharge les packages au lieu de les installer. Vous n’aurez donc qu’a ajouter dans votre /etc/yum.repo.d/ l’ensemble des dépôts qui seront nécessaires à l’installation de Shinken (probablement CentOS-Base et EPEL Release pour un CentOS), puis télécharger tous les RPMs dont vous avez besoin avec la commande :

yum install yum-utils
mkdir shinken_deps && cd shinken_deps
yumdownloader --resolve mon_package

A noter cependant, d’expérience le –resolve censé télécharger les dépendances du package en même temps est peu fiable. Vous aurez surement des dépendances manquantes à télécharger de manière complémentaire.

A la mimine

Si vous n’êtes pas dans le cas cité plus haut, alors cette opération peut être fastidieuse. Elle va alors consister à taper dans votre moteur de recherche favori des mots clés du type « mon_package rpm el6 » (dans le cas d’un RHEL6 ou CentOS6), puis de télécharger la version qui y est disponible sur des sites comme rpm.pbone.net et www.rpmfind.net.

Et bien sûr, comme vous ne pouvez pas deviner aisément si les dépendances qui y sont affichées sont actuellement disponibles ou pas sur votre serveur, il y a un risque que ce soit une opération itérative, jusqu’à ce que vous ayez enfin toutes les dépendances pour tous les cas de figure.

…

Et qu’il n’y ait pas de conflits entre versions de packages interdépendants…

Installation

Votre base de RPM est enfin complète. Pour installer les RPMs nécessaires à Shinken !

Si vous avez choisi le dépôt local

Un simple ajout du dépôt sur le serveur vous permettra donc d’installer toutes les dépendances comme s’y vous étiez sur Internet

yum install package1 package2 ...

Transparent !

Si vous avez plutôt une clé USB/DVD/disque 5″1/4 avec toutes les dépendances dessus

Pendant longtemps, quand j’avais des RPMs à installer, je m’embêtais à les installer dans l’ordre de dépendance avec la commande rpm -hiv mon_package. Et des fois je pestais parce que je ne l’avais pas fais dans le bon ordre…
Mais vous avez quand même de la chance, yum est bien pensé. Il permet également d’installer des RPMs locaux et gère les dépendances de lui même, qu’elles soient sur déposés sur le serveur ou sur vos dépôts. Vous n’avez donc à vous soucier que des packages qui ne sont pas sur vos dépôts, yum fera le tri parmi toutes les sources disponibles. Et ça simplifie grandement la vie.

cd shinken_deps/
yum install *.rpm

Installation des modules Python via pip (dont Shinken lui même)

Shinken étant codé majoritairement en python, vous ne serez donc pas surpris d’apprendre qu’il faut utiliser pip (ou pipy) pour installer des dépendances à Shinken, et même d’ailleurs Shinken lui même.

Rappel des tutos précédents, pour installer Shinken sur un CentOS qui a accès au net, il faut « juste » faire

rpm -iUvh http://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-5.noarch.rpm
yum update
yum install python-pip
adduser shinken
pip install shinken

Si vous avez quand même partiellement accès à Internet via un proxy, vous pourrez vous en sortir en indiquant dans la variable https_proxy l’URL du proxy HTTPS pour pip (notez le S).

export https_proxy=http://@IP_proxy_https:8080/

Mais dans le cas où vous êtes réellement coupé d’Internet et que vous devez récupérer des packages pipy a priori, vous pourrez quand même le faire de la façon suivante :

Récupérer le tar.gz du module pipy sur le site Internet. Par exemple, pour Shinken, il existe une page dédiée sur pipy
Déposer le fichier shinken-2.4.x.tar.gz sur le serveur où on souhaite installer Shinken
Installer le module pipy simplement à l’aide de la commande pip install shinken-2.4.x.tar.gz

Cette méthode est valable pour toutes les dépendances Python de Shinken, mais aussi pour Shinken lui même, comme on vient de le voir.

Pour l’installation des modules de Shinken (comme webui2 par exemple)

Mais au delà de l’installation de Shinken, de ses dépendances RPMs et Python, il reste encore un dernier problème : les modules de Shinken !

Les développeurs de Shinken ont mis à disposition sur shinken.io une liste de modules (plus de 100 je crois) optionnels et qui ne sont pas inclus dans le logiciel de base. Pour autant, certains sont quand même très utiles voir carrément importants. C’est notamment le cas de la webui (interface graphique officielle de Shinken).

Et pour vous simplifier la vie, l’installation de ces fameux « modules de shinken » se fait via une ligne de commande très simple, qui se charge de télécharger et d’installer pour vous les dépendances :

shinken install webui

C’est une super idée, mais, là encore, sans Internet, impossible de télécharger ce module de cette manière.

N’ayez crainte ! En réalité, bien qu’il ne soit pas (ou plus, ou je n’ai pas trouvé) documenté, il existe un mécanisme d’installation locale de la même manière qu’avec yum ou pip. Ouf !

Dépendances

La première étape consiste à récupérer les dépendances pipy listées dans le mod-webui/requirements.txt qu’on peut trouver dans le code source du module.

Dans le cas de la webui, il s’agit (à date) de bottle==0.12.8, pymongo>=3.0.3, requests, arrow et passlib. On les récupèrent donc tous sur pipy, et on les installe comme je viens de le décrire avec un pip install monmodule.tar.gz

Récupérer les sources du modules

Ensuite, on récupère les sources en un zip, qu’on dézippe sur le serveur. Pour le module webui, les sources sont sur github github.com/shinken-monitoring/mod-webui

On peut enfin installer le module de Shinken à la main, à l’aide du flag –local

shinken install --local webui

Facile, non ?

;-)

[Tutoriel] Shinken 2.4 sur CentOS/RHEL 7 – partie 1

Tue, 22 Sep 2015 16:30:24 +0000

Cet article fait parti d’une série d’articles (au moins 3) que je vais publier sur le sujet et que j’ai séparé pour les rendre un peu plus digestes. Je vous conseille quand même de ne pas en sauter pour bien comprendre de quoi on parle ;-) :

Note : Pour les plus pressés ou qui connaissent déjà bien Shinken, la partie technique pure commence à partir du 2ème article.

Pourquoi Shinken ?

Ça fait un moment déjà que je parle de Shinken sans pour autant l’avoir vraiment présenté. Le sujet avait déjà été traité par pas mal de gens relativement calés comme Nicolargo pour ne citer que lui (et quelques articles de Monitoring-FR) et j’estimais du coup ne pas avoir forcément beaucoup à ajouter.

Cependant, avec la sortie avant l’été de la version 2.4, ainsi que les récentes amélioration sur l’interface, j’ai voulu revenir sur le sujet car ça a pas mal bougé depuis, surtout la 2.0 qui a changé pas mal de choses !

Ok, alors. Shinken c’est quoi?

Je suis tombé par hasard sur Shinken pratiquement à son début. Par pur hasard, je m’intéressais justement à des alternatives hautement disponibles à Nagios à l’époque et je suis tombé sur la v0.1 (lien mort, j’utilise Internet Archive).

Selon les propres mots de Jean Gabès son créateur en 2011, alors interviewé par Nicolargo.

Shinken est un outil de supervision, une implémentation de Nagios en Python ‘from scratch’ qui a pour objectifs principaux de simplifier la vie des administrateurs de grands parcs et de coller au mieux à l’évolution de l’IT des dix dernières années, et si possible préparer les dix prochaines…

Si la définition a probablement un peu évolué aujourd’hui, les grandes lignes sont là et présente bien la philosophie du projet telle quelle l’était au départ. Et c’est probablement cette philosophie qui a permis à Shinken de gagner autant de point parmi la communauté supervision open source, surtout face à un Nagios en perte d’identité.

Pour les plus curieux, on découvre aussi pas mal de l’âme du projet sur le blog de naparuba (Jean Gabès donc).

En quoi Shinken est mieux que Nagios ?

J’ai déployé mon premier Shinken sur un serveur complètement saturé qui surveillait un parc de développement de quelques milliers de serveurs.
A l’époque, ce qui a convaincu la direction c’est surtout que Shinken étant beaucoup plus économe en ressources que Nagios : nous avons pu continuer à surveiller le parc avec le même serveur qui a retrouvé une seconde vie et avec pratiquement aucune interruption puisque tout était compatible (agents, plugins, configuration des serveurs supervisés)

C’était très réducteur par rapport aux nombreux avantages de Shinken par rapport à Nagios, mais ça a permis de commencer à mettre le doigt dans l’engrenage. Voici quelques qualités que j’aime mettre en avant :

Compatible avec la configuration, les agents et les plugins d’un Nagios existant
Des performances brutes bien meilleures que Nagios 3, la référence open source à l’époque
Les root problems : meilleure gestion de la détection automatique des vrais problèmes
Multiplateforme - Shinken fonctionne sous Linux, Windows mais aussi sur Android. Vous pouvez l’installer sur un serveur ou un EeePC
Des mécanismes d’aide au démarrage via des « packs » préconfigurés pour un type d’équipement donné (AIX, Linux, baie EMC, …)
Une architecture distribuée : découpage des fonctions principale du programme en modules, ce qui permet entre autre
- De la répartition de charge gérée nativement
- De la haute disponibilité native
- Une gestion des DMZ et des sites distants native

Time to go live

Fort de ces arguments, Shinken a réussi à trouver une place dans le paysage de la supervision open source. Une version 1 est sortie, des prix d’innovations ont été gagnés, et Jean Gabès a décidé de se lancer totalement dans l’aventure en créant Shinken Solutions courant 2013.

Le cœur de Shinken reste libre et communautaire, mais une version entreprise est lancée avec notamment des fonctionnalités de découvertes avancées et d’alimentation de référentiel par le biais de connecteurs (ex. vers VMware, vers la CMDB, vers un Active Directory, etc). La société Shinken Solutions offre également un support aux entreprises qui le souhaitent.

L’architecture distribuée : l’argument massue

Mais assez parlé du projet !

Pour débuter sur Shinken, la première chose à faire est de comprendre son architecture. Si la configuration et les plugins sont compatibles Nagios, Shinken n’en est pas moins très différent de son monolithique ancêtre.

Même si vous êtes un expert de Nagios, il faut bien comprendre les concepts fondateurs avant de s’y lancer (voir la doc).

Pour résumer :

l’arbiter est le chef de l’équipe. Il a la vision globale des démons et des modules. Du coup, il est responsable de découper la configuration générale vers les différents démons et gère la répartition de charge et la haute disponibilité.
le scheduler c’est l’ordonnanceur. Il réparti les checks et les notifications à réaliser respectivement entre les pollers et les reactioners.
le poller récupère les checks actifs qu’il doit effectuer sur l’infrastructure depuis les ordres du scheduler et renvoie le résultat au broker
le receiver reçoit les checks passifs provenant des serveurs et renvoie les résultat au broker (au même titre que le poller)
le reactionner déclenche les envoie de notifications et gère les events handlers.
le broker centralise et consolide les informations renvoyées par les pollers et les receivers. On peut ensuite exploiter ces informations à l’aide des modules du broker qui présentent l’information (interfaces graphiques, exports de données, logs, …)

La suite ?

Si vous avez digéré tout ça, vous êtes prêt pour la partie suivante.

Monitoring-FR a besoin de vous !

Sun, 13 Sep 2015 10:03:12 +0000

Aparté (retour sur l’histoire)

Pour ceux qui ne connaîtraient pas Monitoring-FR, il s’agit du site d’une des plus grosses communautés francophone de supervision open source.

Ce site s’appelait initialement Nagios-FR mais Ethan Galstad (créateur de Nagios®) a réclamé le nom de domaine (Nagios® est une marque déposée et on ne plaisante pas avec les avocats de Nagios® pour ceux qui ne l’auraient pas compris).

Monitoring-FR se compose d’un blog animé par une équipe de passionnés qui sont présents lors des grands événements de la supervision, d’un forum d’entraide et d’un wiki assez conséquent quoiqu’un peu désordonné et pas forcément très à jour.

C’était mieux avant ?

Les habitués de Monitoring-FR l’auront vu, cela fait quelques années que le rythme des publications diminue. La communauté semble moins vivace. Je ne sais pas si c’est les années Nagios-FR qui ont laissé des traces ou si c’est l’éclatement du logiciel Nagios lui même en sous projets concurrents (Icinga/Shinken/Centreon et sa volonté standalone) qui en est la cause.

Le monde de la supervision Open Source n’est pas le même qu’il y a 5 ans.

On a aussi senti en filigrane lors des échanges de lettres ouvertes avec Cédric Temple de Merethis (Centreon) que les animateurs de la communautés manquaient de main d’oeuvre.

Monitoring-FR a besoin de vous

Mais au delà de tout ça, Monitoring-FR, c’était quand même une sacrée base de connaissance pour tout ceux qui débutent. C’est une référence pour tout ceux qui s’intéressent à la supervision et à son actualité (finalement pratiquement pas traité ailleurs) et le travail de l’équipe a toujours été très bon, aussi bien en terme de couverture d’événements que de retours sur les nouvelles versions des logiciels.

Et c’est ce côté que je voir persister.

Depuis quelques mois, les publications reviennent un peu, avec des retours sur les rencontres Paris et Nantes Monitoring notamment.

Donc je voudrais relayer l’appel de Monitoring-FR et vous inviter, si le cœur vous en dis, à rejoindre le mouvement pour relancer la machine (lien mort) :)