Compte-rendu du meeting Zabbix France du 5 Avril 2016

Posted by on 13 Avr 2016 in Conférences & Salons, Planet, Professionnels, Zabbix | 0 comments

Le Mardi 5 Avril 2016 a eu lieu le meeting annuel organisé par la société Zabbix SIA éditrice du logiciel libre de supervision Zabbix.
Voici le compte rendu de cet événement.

Mot de bienvenue d’Alexei Vladishev (Zabbix SIA CEO)

Alexei a présenté les nouveautés de la version 3.0 initialement prévue en Mai 2015, mais sortie le 16 février 2016, soit avec 9 mois de retard.

Les nouvelles fonctionnalités de Zabbix 3.0

  • L’interface graphique (UI) qui n’avait pas évolué depuis longtemps fait peau neuve.

La version 3.0 pose les fondations d’évolutions importantes à venir sur l’UI.
  • L’amélioration de la sécurité avec le support du chiffrement sur l’ensemble des composants Zabbix.

Chiffrement et authentification

  • Il est possible de partager cartes, écrans et diaporamas avec d’autres utilisateurs ou groupes d’utilisateurs.

Sharing options

  • L’apparition de nouvelles fonctions Timeleft (combien de temps avant d’être sous le trigger ?) et Forecast (quelle sera la valeur d’un item au bout d’un certain laps de temps ?).
Timeleft
Forecasting
  • L’utilisation CPU par processus (individuel ou groupe).

Per-process CPU utilisation

  • Les applications peuvent être créées via une règle de découverte bas niveau (Low Level Discovery).
  • L’amélioration des performances (history cache, multiple escalators, amélioration du cache)
  • La possibilité pour les items d’être déclenchés à des périodes précises façon crontab.
Business checkScheduling IntervalFlexible Interval
  • Le nettoyage de la base de données (Housekeeper) peut être exécuté à la demande.
  • Il est possible d’exécuter Zabbix en avant-plan.
  • L’authentification SMTP pour l’envoi de courriels.
SMTP Authentication
Toutes les nouveautés se trouvent dans ce précédent billet.

Recommandation

Il est recommandé de migrer vers la version 3.0.1 ou 3.0.2 qui devrait arriver prochainement (la version 3.0.2rc1 est sortie le 11 Avril 2016).
L’upgrade de Zabbix est très rapide et ne nécessite pas la mise à jour des agents (ceux-ci sont rétrocompatibles avec les agents version 1.0).
L’upgrade concerne uniquement le serveur et les proxys.

Le support des versions de Zabbix

Concernant le support, la version 2.2 LTS (Long Term Support) expire fin 2018.
La version 2.4 de Zabbix n’est officiellement plus supportée depuis la fin du 1er trimestre 2016.
La version 3.0 sera supportée jusqu’à fin 2020.

Études de cas d’utilisation de Zabbix par Sergey SOROKIN (Business Development)

  • Retour sur la supervision du système des noms de domaine de l’internet (ICANN).
  • Un autre exemple d’un client, dont le nom n’a pas été cité, dans le domaine de la logistique qui nous parle d’amélioration de sa chaîne métier avec un outil de supervision.

Le futur de Zabbix, notamment la version 3.2 (Alexei VLADISHEV)

Avec la prochaine version 3.2 de Zabbix, il faut s’attendre à voir venir :
  • La gestion avancée de supervision de fichier de log et remontée de trap
  • De l’event correlation (dé-duplication, agrégation, tempête de messages, filtrage et masquage)
  • De la modularité au niveau des composants Zabbix

Les avantages à utiliser les services professionnels de Zabbix (Sergey SOROKIN)

Cela tourne autour du Service avec :

  • Installation, mise à jour
  • Support
  • Formation
  • Création de modèle de supervision
  • Assistance client (sur site ou à distance)

Présentation du réseau de professionnels Zabbix en France

Sergey SOROKIN a présenté les partenaires France de Zabbix.

 

Read More

Eyes Of Network : sorties de la version 4.2

Posted by on 28 Oct 2015 in Planet, Supervision | 0 comments

Eyes Of Network (“EON”) est une solution de monitoring Open Source réunissant de manière pragmatique les processus ITIL. Elle est basée sur plusieurs produits libres tel que Nagios, Nagvis, GLPI….

EON est accessible via une interface web qui comprends une interface graphique de définition des processus métiers et des modules de génération de rapports de statistiques sur les incidents et de génération de graphiques de performances permettant à chaque acteur d’un Système d’Information de disposer des information pertinentes pour son métier.

La version 4.2 renforce encore ce positionnement en offrant un nouveau module de simulation utilisateur. Ce module permet de définir, sur une workstation,  des scénarios applicatifs et de les jouer à place de l’utilisateur afin d’obtenir une disponibilité encore plus précise des applications métiers et de donner au DSI une vision encore plus fine de son Système d’Information.

Release Notes : https://www.eyesofnetwork.com/?p=1554&lang=fr

Téléchargement: https://www.eyesofnetwork.com/?page_id=48&lang=fr

Read More

Shinken Web UI version 2

Posted by on 15 Sep 2015 in Shinken | 0 comments

Après plusieurs mois sans activité, la nouvelle version de l’interface Web de Shinken a été publiée il y a quelques jours et mise à disposition de la communauté sur le site shinken.io. Cette nouvelle version est une refonte quasi complète de l’application Web UI (User Interface) qui améliore et enrichit les fonctionnalités des versions précédentes :

  • interface utilisateur moderne et responsive compatible avec la majorité des Web browsers
  • consultation en temps réel des données du framework Shinken (hosts, services, contacts, groups, timeperiods, …)
  • application opérationnelle dès l’installation
  • gestion des utilisateurs et de leur rôle
  • filtrage performant des ressources de supervision (hosts/services)
  • tactical views: worldmap, minemap, disponibilité, logs, …

Dans la suite de cet article, nous reviendrons sur les principales fonctionnalités de l’interface Shinken Web UI.

Read More

Sorties mineures : Centreon 2.6.1 et CES 3.2

Posted by on 17 Juin 2015 in Centreon, Interviews, Supervision | 0 comments

Le 27 mai 2015, l’équipe de développement de Centreon a annoncé la sortie de deux versions :

Monitoring-fr a interviewé Julien Mathis, Directeur technique de Centreon pour l’interroger sur ces deux sorties. Vous pouvez retrouver l’enregistrement audio en fin d’article.

Points principaux de la version 2.6.1 de Centreon

Cette version 2.6.1 de Centreon est une version de maintenance. Comme souvent chez Centreon, la version 2.x.1 sort quelques jours ou quelques semaines après la version 2.x afin d’intégrer les principaux retours de bug formulés par les utilisateurs. C’était notamment le cas pour :

  • la 2.1.1 sortie le 25/09/2009, 4 jours après la 2.1 sortie le 21/09/2009
  • la 2.3.1 sortie le 17/10/2011, 4 jours après la 2.3 sortie le 13/10/2011
  • la 2.4.1 sortie le 26/02/2013, 8 semaines après la 2.4 sortie le 07/01/2013

Peu de nouveautés dans cette version mais si vous avez mis à jour votre plate-forme vers la version 2.6, il est conseillé de passer à la version 2.6.1 pour corriger les bugs introduits dans la version 2.6.0.

Dans les nouveautés, il y a un point qui pourra perturber les utilisations. Il s’agit de [#6228] : lorsqu’un utilisateur ne disposera que du droit « Re-schedule the next check for a service (Forced) » et pas du droit « Re-schedule the next check for a service », le « (Forced) » ne sera pas affiché dans son interface. Cela pourra être perturbant pour l’administrateur qui configure les droits. En effet, l’administrateur supervision active un point et désactive un autre mais c’est celui qui est désactivé qui apparaît. Non, ce n’est pas un bug mais une fonctionnalité! Attention donc!

Un autre point qui pourra faire polémique : [#6392 : Block choice of Nagios and NDO in installation processus]. Centreon ne demande plus si vous disposez de Nagios et NDOUtils lors de l’installation. Par défaut, il considère que vous avez installé Centreon Engine et Centreon Broker. On peut se poser la question : comment va faire un administrateur lors de l’installation de Centreon lorsqu’il aura installé Nagios et NDOUtils?

Points principaux de la version 3.2 de CES

La version 3.2 de CES, Centreon Enterprise Server, est sortie le même jour que la version 2.6.1 de Centreon. Deux changements sont intégrés dans cette version :

  1. une amélioration de la documentation
  2. CES ne demande plus si vous préférez installer Nagios+NDOUtils ou Centreon Engine + Centreon Broker.

Les deux sorties semblent donc coordonnées dans le but de ne plus supporter Nagios+NDOUtils lors de l’installation. La question posée précédemment trouve sa réponse : la pile Centreon ne supporte plus l’installation de Nagios et NDOUtils.

Début de l’arrêt du support de Nagios dans la pile Centreon

Le message est clair de la part des développeurs de Centreon : Nagios (et NDOUtils) ne seront plus supportés à plus ou moins long terme. Cela commence par l’arrêt du support lors de l’installation. Puis progressivement, les fonctionnalités permettant de gérer Nagios dans l’interface Centreon seront supprimées. Cela se fera au fur et à mesure, en fonction des retours des utilisateurs. Il faut remarquer que la personne qui a fait la demande de supprimer le support de Nagios durant l’installation n’est pas un développeur de Centreon, ni un employé de la société Centreon, mais bien un utilisateur, il y a près d’un an et demi.

Que faire si ma plate-forme de supervision utilise Nagios?

Il est à noter que seul le support de l’installation de Nagios est supprimé : les fonctionnalités de gestion de Nagios de l’interface Centreon sont toujours présentes. Vous pouvez donc toujours utiliser Nagios. Si vous disposez d’une plate-forme CES avec Nagios et NDOUtils, cette plate-forme fonctionnera correctement encore quelques temps. Si vous avez une plate-forme CES composée de plusieurs serveurs et que vous avez besoin d’installer un nouveau serveur pour suivre la montée en charge, c’est un peu plus compliqué. Il vous faudra installer CES avec centreon-engine et centreon-broker. Puis remplacer ces paquets par nagios et ndoutils.

Cependant, à terme, il va vous falloir planifier ce changement. Le support complet de Nagios sera très probablement supprimé dans les prochaines années. Sera-ce dans la version 3.0 de Centreon? C’est une des questions que nous avons posé à Julien Mathis, Directeur Technique de Centreon? Nous vous invitons à écouter cette interview :

mp3mp3

Il est à noter que cette interview a été faite le 04/06/2015, à l’occasion du Meetup Monitoring Paris. Avant cette interview, l’équipe de Centreon n’avait pas et n’avait pas prévu de communiquer ouvertement sur ce point. C’est dorénavant chose faite sur leur blog

Read More

Sortie de la version 2.4 de Shinken

Posted by on 5 Mai 2015 in Communauté, Interviews, Shinken, Supervision | 0 comments

Shinken, le framework libre de supervision, est disponible en version 2.4. Monitoring-FR a interviewé Jean « naparuba » Gabes, fondateur et développeur principal de Shinken sur cette nouvelle version de Shinken. En comparaison des versions 2.0 et 2.2, cette version est une version de maintenance : peu de nouveautés, beaucoup de corrections de bug. Le cycle court enclenché par l’équipe de développement commence à prendre forme. Prévue à l’origine pour fin mars, cette nouvelle release sort certes avec un peu plus d’un mois de retard sur le planning prévu initialement mais seulement quatre mois après la précédente version, disponible le 16/01.

Rappelons dans un premier temps que Shinken n’est pas un « fork de Nagios » . Souvent présenté de cette façon, cela devient au fur et à mesure des avancées du logiciel de plus en plus éloignée de la réalité. En effet, à l’origine Shinken ne partait pas du code de Nagios, le terme fork peut donc être considéré comme erroné. Cependant, le but originel était bien de faire de Shinken une ré-implémentation des fonctionnalités de Nagios dans un langage de plus haut niveau (Python) avec une architecture plus performante. Par la suite, Shinken s’est développé et intègre des fonctionnalités non disponibles dans Nagios. Cela fait donc quelques années déjà que Shinken est plus qu’une simple ré-implémentation de Nagios. Quels sont les principaux points de cette nouvelle version? Comme toujours, il est nécessaire de bien comprendre l’architecture du logiciel afin d’appréhender le mieux possible les évolutions proposées dans une nouvelle version de celui-ci.

Rappels sur l’architecture

Shinken dispose d’une architecture de rupture face aux autres outils Libres de supervision. Shinken est composé de plusieurs démons, chaque démon ayant son propre rôle :

  • arbiter : lit la configuration, la sépare et l’affecte au(x) scheduler(s). Il vérifie régulièrement que le(s) scheduler(s) fonctionnent correctement et affecte la configuration d’un scheduler en panne à un autre scheduler. Il reçoit les actions de supervision (commentaire, acquittement, …) et les dirige vers le scheduler correspondant.
  • scheduler : gère une partie de la configuration. Dispatche les tests à effectuer sur les pollers et les actions sur les reactionners. Le scheduler est aussi responsable du traitement du résultat, de la corrélation et de l’activation des actions (notifications, reprise sur incident).
  • poller : lance les tests et transfère le résultat au scheduler. Un scheduler peut être associé à un domaine de supervision spécialisé (Windows par exemple) ou à un environnement (poller dédié à un site géographique par exemple).
  • reactionner : responsable de la notification et des reprises sur incident (« event handler »).
  • broker : responsable des données et de leur stockage. Il existe plusieurs brokers, chacun répondant à un besoin particulier : un broker dédié aux données de performance (pour Graphite par exemple) ou un broker dédié au stockage des données de supervision temps réel pour une interface web particulière.
  • receiver : reçoit les données de supervision passives et les transfert au scheduler correspondant.

Shinken dispose de sa propre interface appelée Shinken-UI mais il est courant de lui adjoindre d’autres (Thruk, Graphite, PNP4Nagios). Depuis quelques versions déjà, l’interface Shinken-UI ne fait plus partie de « Shinken » : cette interface est considérée comme un module complémentaire à Shinken et les codes de Shinken et Shinken-UI sont séparés, comme le sont aussi ceux des brokers. Donc lorsque l’on parle de « la version 2.4 de Shinken », on parle des démons présentés précédemment et non de l’interface.

Numéros de version de Shinken

Shinken sort en version 2.4. La version précédente était la version 2.2 et celle juste avant était la version 2.0. Où sont passées les version 2.3 et 2.1? Ces versions n’existent pas : dans les faits, elles ne sont pas releasées. Les développeurs de Shinken préfèrent sortir des versions x.y où y est pair. Cela se justifie car les versions impaires sont généralement considérées comme des versions de développement (donc instables) par les utilisateurs. Il n’y a pas de versions intermédiaires (en x.y.z) sauf si cela est vraiment nécessaire. Ce qui ne devrait pas changer suite à la mise en place du cycle de développement court.

Les changements de version majeure se font lorsque la compatibilité n’est plus assurée avec les modules ou lors d’un changement très structurant. La raison du passage de la version 1.4 à la version 2.0 est lié à la gestion des modules : ceux-ci ne sont plus livrés directement avec Shinken mais à part. Charge aux utilisateurs d’aller chercher les modules Shinken souhaités. Ce changement était très important et nécessitait une montée de version majeure. À priori, le prochain changement de version majeure devrait intervenir lorsque Shinken imposera une montée de version vers Python 3.X. Celle-ci ne devrait intervenir que lorsque la RHEL 5 commencera vraiment à disparaître et la décision sera prise en fonction des retours utilisateurs.

Les développeurs de Shinken ont à cœur de maintenir la compatibilité ascendante concernant les fichiers de configuration : les fichiers de configuration de la première version doivent pouvoir être utilisés sans aucune modification sur la dernière version. Même des fichiers de configuration Nagios doivent pouvoir fonctionner parfaitement sur Shinken. C’est grâce à la présence de nombreux tests unitaires que ceci est permis. Cela permet aux utilisateurs de Shinken de migrer vers la dernière version sans nécessiter de mise à jour de leurs fichiers de configuration, étape qui peut être fastidieuse et très risquée.

Nouveautés de la version 2.4

La maintenance de la configuration d’une plate-forme de supervision peut être complexe. Avec cette version 2.4, Shinken facilite un peu plus la gestion de la configuration en permettant aux responsables de la plate-forme d’exclure certains services d’un modèle lors de l’héritage. Ce point peut être complexe à comprendre et nécessite une explication. Pour éviter de devoir saisir plusieurs fois les mêmes éléments de configuration, Shinken permet à ses utilisateurs de saisir des « modèles d’équipement » (« packs » dans la terminologie Shinken) : ces modèles d’équipement sont reliés à des « modèles d’indicateurs de supervision ». Par exemple, on peut définir un « modèle Linux » auquel seront associés des modèles « CPU », « mémoire vive », « partitions », « processus cron démarré », … Lorsqu’un équipement hérite d’un modèle, il hérite de tous les éléments associés à ce modèle. S’il hérite de plusieurs modèles (exemple : Linux + Dell + MySQL + Apache) , il hérite de tous les indicateurs de chacun des modèles. C’est un gain de temps considérable. Cependant, dans certains cas, il est nécessaire qu’un ou plusieurs indicateurs de supervision ne soient pas associés automatiquement. C’est la nouveauté de cette version 2.4 : il est dorénavant possible d’exclure des indicateurs de supervision lors de l’héritage. Un cas simple pour comprendre plus facilement : un serveur Windows ne dispose pas de l’antivirus déployé sur tous les autres serveurs Windows car l’application qu’il héberge n’est pas compatible avec cet antivirus. Pour ce serveur spécifiquement, une ligne va être ajoutée afin d’exclure l’indicateur concerné.

L’un des points forts de Shinken est de pouvoir gérer plusieurs dizaines de milliers d’indicateurs de supervision. Afin d’éviter de saturer la mémoire vive du serveur, un travail a été réalisé par les développeurs afin d’optimiser la mémoire. Deux améliorations ont été apportées, l’une à l’arbiter et l’autre au scheduler. Un problème de fuite mémoire se posait lors de bascule sur l’esclave ou lors de retour sur le maître, dans le mode HA. Ce problème est corrigé.

Dorénavant, sudo n’est plus utilisé. Pour cela, Shinken utilise systemd : grâce à l’utilisateur Unix shinken, il est possible de redémarrer le service sans passer par sudo. systemd n’étant pas encore disponible sur toutes les plates-formes, Shinken continuera d’utiliser sudo là où cela s’avérera nécessaire.

Un travail de refactoring (« nettoyage« ) du code est entrepris au fur et à mesure des sorties de version. Cette version n’y échappe pas, bien au contraire et a fait l’objet d’adaptations afin de respecter au maximum les bonnes pratiques recommandées par Pep8. Suivre les bonnes pratiques permet de disposer d’un code identique partout : un développeur donné n’est pas gêné par la façon d’écrire du code des autres développeurs car tout le monde respecte le référentiel des bonnes pratiques. Le code est alors plus simple à analyser. La vérification des bonnes pratiques est faite à chaque modification de code et à l’aide d’outils dédiés.

Read More