Tout administrateur travaillant sur une plateforme Nagios / Centreon sait à quel point NDOUtils ralentit l’interface à cause de ses requêtes complexes pour récupérer l’information (le schéma de base étant très old school). Merethis a donc fait le choix de travailler sur un broker et un moteur dédié à leur solution afin d’obtenir de bien meilleures performances.

Merethis annonce la publication de nouvelles versions tous les 3 mois. Elle annonce aussi que Centreon 2.3 est la dernière étape avant la prise à chaud d’événements et de modifications de la configuration. Elle annonce la sortie de l’interface permettant de visualiser la corrélation des éléments.

L’équipe de Merethis annonce une sortie de Centreon 2.4 en fin d’année.

Beaucoup de nouvelles de la part de Merethis qui montre depuis le Salon Solution Linux 2011 qu’ils ont passé la seconde … Nous devrions prévoir une interview de l’équipe de Centreon d’ici peu pour y voir plus clair

• Une mise à jour sur la dernière centOS 5.7
• La présence de Shinken en version 0.6.5
• Du GLPI, Fusion Inventory / OCSInventory pour l’inventaire du S.I dans le but de construire une CMDB
• L’apparition d’un projet qui a déjà retenu notre attention : Thruk en version 1.1.1.
• Et encore bien d’autres améliorations …

Extrait du changelog 3.0 :

• NEW : Un seul support d’installation DVD (~1GO)
• NEW : Version 64 Bits
• NEW : EyesOfNetwork Production
• NEW : Glpi 0.8.4
• NEW : Glpi Fusion Inventory 2.4.0
• NEW : Glpi Mass Import 1.5.2
• NEW : Fusion Inventory Agent 2.1.9
• NEW : Ocsinventory 2.1
• NEW : Shinken 0.6.5 (Béta)
• NEW : Thruk 1.1.1
• NEW : Association/Désassociation multiples d’objets Nagios
• NEW : Affichage de l’id des nouveaux jobs lilac
• NEW : Export/Import d’objets Nagios
• NEW : Changement du mot de passe par les utilisateurs
• NEW : Planification des downtimes via eonweb ou traps snmp
• NEW : Synchronisation cacti via le hostname ou l’adresse ip Nagios
• NEW : Sélection des utilisateurs LDAP via autocompletion
• NEW : Vues Thruk supplémentaires dans eonweb
• UPDATE : Centos 5.7
• UPDATE : Eonweb 3.0
• UPDATE : Ged 1.2-12
• UPDATE : Lilac 1.3
• UPDATE : Mk-livestatus 1.1.10p3
• UPDATE : Nagvis 1.5.10
• UPDATE : Php 5.3
• UPDATE : Snmptt 1.3-4
• FIX : Confirmation lors de la suppression des jobs lilac
• FIX : Optimisation des recherches dans annuaires LDAP
• FIX : Context snmpv3 lors de la synchronisation des utilisateurs Cacti
• FIX : Erreurs lors des sélections des data queries cacti
• FIX : Erreurs lors du redémarrage d’apache suite à l’utilisation de la vue processus
• FIX : Arrêts inattendus de ged
• FIX : Impossibilité de redémarrer le démon gedd lors d’erreurs MySQL

• Core : D’un correctif sur la mémoire allouée aux macros servant aux notifications.
• Web UI : De quelques corrections sur l’interface « classic ui ».
• IDOUtils : D’une correction sur l’allocation mémoire concernant le broker_data IDO_MAX_BUFLEN.
• IDOUtils : D’une amélioration de la verbosité en cas d’erreurs du processus ido2db.

Pour de plus amples précisions, je vous invite à scruter le changelog de cette version à l’url suivante :

https://www.icinga.org/2011/09/09/icinga-1-5-1-released/

Un module de découverte!

Le grand rajout de cette version est incontestablement le module de découverte. Ce dernier est totalement modulaire et extensible. De base, il permet de détecter les machines et les services réseaux classiques (HTTP, DNS, MySQL, Mssql, Oracle, …) et de les rajouter automatiquement à la configuration. Un module de découverte des machines virtuelles sous VmWare vSphere est également disponible.

Ce module est très facilement extensible, que ce soit pour la découverte à proprement parler (ceci se base sur de simples scripts qui retournent les informations comme le font les sondes Nagios), ou bien son système de règles qui permet suivant les informations récoltées de créer les hôtes et les services dans la configuration.

L’architecture globale est finie

Cette version voit arriver la fin des travaux initiés depuis les toutes premières versions sur l’architecture qui fait de Shinken un projet si particulier. On a donc à disposition désormais un nouveau daemon optionnel pour les données passives que l’on peux disposer sur les sites distants qui sont régulièrement coupés. Il n’y a ainsi plus de pertes d’informations possibles.

La partie distribution de charge n’est pas oubliée non plus, et le dernier point possible de contention est levé avec la possibilité de multiplier à merci les « broker », ces daemons qui gèrent les données pour les sauvegarder/présenter.

Enfin, un soin tout particulier a été donné aux daemons qui lancent les sondes afin qu’ils puissent être placés en zone DMZ et que leur connexions soient uniquement du sens LAN->DMZ afin de respecter les exigences de sécurités actuelles. Le rajout de ces daemons est également désormais possible à chaud sans redémarrer tous les daemons!

Des modules immortels, et pour de nouveaux daemons

Les modules sont l’autre clé de voute de Shinken. Désormais, en cas de soucis, comme la perte de la connexion à une base de donnée, ces modules sont redémarré de temps en temps au lieu de disparaitre et demander un redémarrage complet du daemon.

Ces modules font également leur arrivées sur de nouveaux daemons, comme par exemple les poller qui ont comme charge de lancer les sondes. Un des modules disponible est par exemple un module NRPE qui permet de lancer les interrogations sur les serveurs distants sans avoir à lancer de processus. Ceci apporte un gain de performance important pour ceux qui utilisent cette sonde.

Un lien fort avec VMware

Tout comme pour le module de découverte, Shinken est de plus en plus adapté à la supervision des environnements virtuels, VMware en tête. Il permet ainsi de détecter et mettre à jour si besoin les liens de dépendances entre les machines virtuelles et leurs hôtes. Ainsi, après une migration d’un hôte vers un autre (VMotion), le lien de dépendance entre les hôte dans Shinken va être automatiquement mis à jour sans que l’administrateur n’ait besoin de lui dire!

Un nouveau wiki plus simple

Un gros travail de fond a été fait sur le wiki du projet pour le rendre plus accessible aux débutants. Ce travail est toujours en cours, mais il est déjà bien plus simple de débuter sur Shinken avec des tutoriels simple, comme celui qui propose de démarrer en 10minutes avec découverte automatique et interface graphique! (Thruk)

Et maintenant ?

Avec la finalisation de l’architecture, c’est toute une phase de ce projet qui se termine. Une phase de stabilisation se profile, avec la rédaction d’aides de plus en plus nombreuses pour aider à installer et tirer parti de tout le potentiel de l’outil. Vous pouvez toujours voter pour vos prochaines fonctionnalités favorites sur le site dédié, car gageons que les auteurs nous ravirons encore dans le futur proche, avec de nouvelles fonctionnalités qui facilitent la vie des utilisateurs

La version 1.3 sortie hier nous apporte un joli lot de fonctionnalités et pas seulement que sur le Core. Il est annoncé une liste assez conséquente de mise à jour, une compatibilité avec l’IPv6 et un élargissement de l’éventail de compatibilité du Broker avec des bases de données comme MySQL, PostgreSQL et même Oracle pour les plus sceptique de l’open source. Icinga annonce aussi que sa nouvelle interface est plus optimisé en temps de réponse.

Voici la liste des changements apportés par la version 1.3 :

Changelog Icinga v1.3

Pour télécharger la version 1.3 d’icinga c’est ici :

Shinken sort déjà une nouvelle version, un peu plus d’un mois et demi après la dernière! Cette version 0.5 (nom de code ver de terre éruptif) continue sur la même lignée que son prédécesseur, et sur un rythme toujours effréné. Comme à son accoutumée, elle est disponible sous forme classique et sous forme d’une machine virtuelle de démonstration.

Outre les quelques corrections de bugs, nous avons le droit à cinq fonctionnalités principales :

• rajout du chiffrement SSL entre les processus, basés sur des certificats
• des périodes d’absences pour les contacts
• les escalades de notifications basées sur le temps, afin de mieux coller aux notions de SLA
• l’arrivée de la notion de criticité des hôtes et services
• et la dernière mais pas la moindre : l’arrivée dans le cœur de l’application des règles métiers!

Regardons un peu les dernières fonctionnalités plus en profondeur.

Périodes d’absences pour les contacts

Les administrateurs sont comme tout le monde, ils partent de temps en temps en vacances. Lors de leur retour, chacun faisait à peu près la même chose : prendre toutes les alertes s’étant produites pendant ses congés et les supprimaient. Dorénavant, avant de partir il peut prévenir l’outil qu’il ne sera pas là sur une période de temps, et ce dernier ne va tout simplement pas lui lever de notifications pendant celle-ci.

Escalades de notifications basées sur le temps

Dans Nagios, les escalades de temps sont basées sur un nombre de notifications. Ceci rend cette configuration très complexe lorsqu’il est question de SLA basés sur le temps. Or la plupart le sont (comme par exemple escalader le problème au support niveau 2 au delà de 3h).

Shinken ajoute ceci dorénavant. Ce rajout n’est pas un simple « temps=nombre de notifications/temps entre les notifications » car il gère le cas où l’administrateur a décidé qu’entre deux notifications il faille 1 journée, mais qu’il faille escalader au bout de 3heures. L’outil va savoir qu’au bout de 3 heures il doit escalader le problème sans attendre une prochaine notification pour cela.

La notion de criticité

Les outils à licence libre ont un souci : les administrateurs n’ont aucun remord à mettre en supervision tout leur parc, car ils n’ont pas à payer de licence pour chaque objet supervisé. Ceci signifie qu’ils supervisent aussi bien de la production que des serveurs moins critiques comme ceux de qualifications.

Or dans les consoles de supervisions actuelles du monde Nagios/Shinken, il n’y avait que 3 états : ok, avertissement et critique. Mais un avertissement sur un serveur de production peux être plus important qu’un critique sur un serveur de qualification.

C’est pour gérer cela que Shinken permet désormais aux administrateurs de définir la criticité de ses objets. Ils seront triés comme il faut dans les consoles temps réels. Un point important sur le fonctionnement de ce mécanisme vient du fait que lorsqu’un « problème source » est détecté (comme sur un switch qui impacte des applications de production) sa criticité est calculée avec la valeur maximale de celle de ses impacts.

Ainsi, il est possible de lever une alerte la nuit pour un administrateur réseaux pour un switch défaillant que si celui-ci à réellement impacté un service important et non pas un de qualification.

Voici un exemple de vue dans Thruk qui présente les « problèmes sources » et uniquement eux, le tout trié par criticité :

Vue des problèmes sources par Thruk, avec tri sur la criticité

Une telle vue peux être résumée simplement pour les administrateurs « faites ceci, et dans cet ordre ».

Les règles métiers, ou business rules

Il existait déjà dans le monde Nagios un addon permettant d’avoir une « agrégation d’états » sur un indicateur unique avec Nagios Business process addon. Mais il était intéressant d’incorporer un tel fonctionnement dans le cœur de la supervision, afin d’avoir les autres rajouts comme les relations problème source/impacts ou la criticité liés à ces objets « business ».

C’est ce que propose Shinken. Désormais, une simple commande de supervision permet d’obtenir une telle règle « complexe ». L’exemple donné dans la documentation est la suivante, pour décrire une application complète :

• deux bases de données redondées
• trois services webs, dont au moins deux sont nécessaires pour cause de charge
• deux répartiteurs de charges redondés

Une telle règle va s’écrire simplement comme commande de supervision :

bp_rule!(base1|base2) & (2 of: http1 & http2 & http3) & (lvs1 | lvs2)

Un tel hôte ou service est ainsi affichable avec n’importe quelle interface, car après tout c’est un objet comme les autres d’un point de vue externe.

Certains outils comme Thruk sont cependant capables d’interpréter les données du module LiveStatus de Shinken et de représenter ces objets sous forme d’arbres.

Voici un exemple de ce que ceci peux donner :

Thruk et vue business trié par criticité

Et après?

La prochaine version de Shinken devrait introduire des fonctions avancées sur les connexions réseaux afin de pouvoir les « inverser » à loisir et ainsi être plus facile à intégrer dans des environnements hautement sécurisés.

Pour rappel, vous pouvez rajouter votre idée ou voter pour votre future fonctionnalité favorite sur le site http://shinken.ideascale.com.

Comme nous vous l’avions annoncé dans l’article précédent sur Zabbix, la sortie de Zabbix 1.8.4 était imminente en ce début d’année 2011. C’est donc sans surprise que nous vous présentant aujourd’hui cette version stable de la solution de supervision open source au fameux « Z ».

Alors qu’est-ce qu’apporte de plus la 1.8.4 ?

Tout d’abord, Zabbix 1.8.4 voit son API (interface de programmation) améliorée, avec une meilleure cohérence dans les noms des méthodes et dans la manipulation des paramètres. De plus, l’utilisation des macros a été étendue pour permettre un usage à la fois dans les triggers et dans les items.

Enfin, on peut citer comme améliorations majeures le support du système d’authentification NTLM pour le web monitoring, ainsi que le support des bases de données DB2. Ce qui porte donc maintenant à 5 le nombre de SGBDR supportés : Oracle, MySQL, PostgreSQL, SQLite et DB2 !

Bien sûr, Zabbix 1.8.4 apporte aussi son lot de fonctionnalités supplémentaires telles que par exemple l’ajout d’un système de filtrage pour les hôtes (par nom, DNS, IP ou encore par port) dans la page de configuration de ces derniers, ou bien encore la compatibilité de Zabbix avec Zapcat (passerelle JMX pour Zabbix).

Pour une liste complète et détaillée des nouvelles fonctionnalités de Zabbix 1.8.4, rendez-vous sur le site de la documentation officielle :

http://www.zabbix.com/documentation/1.8/manual/about/what_s_new_1.8.4

Pour télécharger l’application :

http://www.zabbix.com/download.php

En conclusion, Zabbix 1.8.4 devrait donc satisfaire un grand nombre de ses utilisateurs, et pourquoi pas, en convaincre d’autres de franchir le pas ?

Au niveau de l’interface, hormis l’ajout d’un nouveau thème et de quelques modifications de l’affichage (notamment pour la gestion des cartes), une section de visualisation des notifications comportant des alertes sonores fait son apparition. La gestion des notifications globales de Zabbix propose plus d’options de personnalisation.

Pour plus d’informations sur les nouveautés de Zabbix 1.8.3 :

http://www.zabbix.com/documentation/1.8/manual/about/what_s_new_1.8.3

Pour télécharger la nouvelle version Zabbix 1.8.3 :

http://www.zabbix.com/download.php

Source : http://blog.centreon.com/

Cette version est essentiellement une version intégrant des correctifs qui peuvent être classés comme mineurs : aucune alerte de sécurité et aucun bug bloquant n’a été signalé.

• Correction d’un problème de vue des commentaires dans les CGIs lorsque les permissions étaient fixées en lecture seule (bug #000002 9)
• Correction d’un problème de reporting (disponibilité, tendances, etc.) lorsque les périodes se chevauchent sur heure d’été, heure d’hiver (bug #0000046)
• Détection du support truecolor de la librairie GD corrigée (Lars Hecking)
• Retour à l’utilisation de –datadir dans le script de configuration plutôt que le nouvellement introduit — datarootdir
• Les fichiers de statut et de rétention sont désormais synchronisés sur disque pour prévenir l’affichage d’informations incomplètes dans les CGIs.
• Correction du calcul de l’heure de prochain contrôle lorsque Nagios est redémarré avec des périodes de temps différentes
• Mise à jour du guide de démarrage rapide Fedora pour indiquer les pré-requis PHP
• Problème connu : Les contrôles de services qui sont définis avec des périodes de temps contenant des directives d’ »exclusion » sont incorrectement ré-ordonnancés. Ne les utilisez pas pour le moment – ce sera corrigé pour la version 3.4

Comme d’habitude, vous pouvez télécharger Nagios Core sur nagios.org.