25
I Use This!
Activity Not Available

News

Analyzed 3 months ago. based on code collected almost 3 years ago.
Posted almost 12 years ago by Centreon Com
Centreon CLAPI (stands for Command Line API) allows you to control your Centreon server from the command line terminal. It gives you the possibility to add, modify but also delete all objects' configuration in Centreon (hosts, services, contacts ... [More] , groups) directly from a terminal. CLAPI has been created for Centreon admin to save time, it can be tedious to use the Centreon web portal when you need to interact with several servers at a time. When your modifications are finalized, you can even generate the Nagios©/ Centreon Engine configuration, test it and finally restart the engine directly through Centreon CLAPI. Distributed architectures are perfectly supported, since Centreon CLAPI can also manage multiple Nagios© authorities. Centreon CLAPI 1.3 released We are very pleased to announce the release of Centreon CLAPI 1.3 which brings quite a lot of bugfixes and of course and a major improvement for better object management! With Centreon CLAPI 1.3, you can now interact and modify any Centreon object or conf directly via the CLAPI command line interface. If you are currently using Centreon CLAPI on a production environment, please note that some commands have been modified so we strongly recommend you check out the Centreon Wiki first before you even consider upgrading the module.As usual, we invite you to report any bug that you may encounter at our forge to follow each ticket.Enjoy ! ----------------------------------------------------------------------------------------------------- Centreon CLAPI ( pour Command Line API) vous permet de contrôler votre serveur Centreon en ligne de commande. Depuis un terminal, vous pouvez directement ajouter, modifier ou même supprimer tous les objets de configuration de Centreon (hôtes, services, contacts, groupes). CLAPI a été créé pour faire gagner du temps aux administrateurs de Centreon. En effet, il peut être fastidieux d'utiliser le portail web de Centreon quand on n'a besoin d'intéragir avec différents serveurs en même temps. Une fois votre modification réalisée, vous pouvez aussi générer la configuration de Nagios/Centreon Engine, la tester et enfin redémarrer le moteur directement à partir de Centreon CLAPI. Les architectures distribuées sont parfaitement supportés et Centreon CLAPI peut aussi gérer plusieurs instances de Nagios. Nouvelle version Centreon CLAPI 1.3 Nous sommes très heureux de vous annoncer la sortie de la nouvelle version de Centreon CLAPI 1.3, version qui apporte quelques corrections et bien sur, une réelle améloriation des performances! Avec Centreon CLAPI 1.3, vous pouvez dès à présent intéragir et modifier n'importe quel objet de Centreon directement via l'interface de commande CLAPI. Si vous utilisez actuellement Centeron CLAPI dans un environnement de production, veuillez noter que plusieurs commandes ont été modifiées et nous vous encourageons vivement à vérifier le Wiki Centreon avant de faire la mise à jour du module.Comme d'habitude, nous vous invitons à nous remonter les bugs éventuels que vous avez pu rencontrer sur notre forge afin d'avoir un suivi de chaque ticket. Enjoy ! [Less]
Posted almost 12 years ago by lpinsivy
The Centreon team desactivated temporarily the registration of new users accounts on the Centreon Forum because we received a large amount of spam in the last 24hours. The Centreon team is looking for a solution to protect us from future ... [More] inconvenience and avoid that robots can create accounts automatically. We apologize for any inconvenience. Nous avons désactivé temporairement l'inscription de nouveaux comptes utilisateurs sur le forum Centreon car nous avons subi un grand nombre de spam ces dernières 24heures. L'équipe Centreon recherche actuellement une solution pour nous prémunir de ces futurs désagréments et éviter que des robots ne créent des comptes automatiquement. Nous nous excusons de la gêne occasionnée. [Less]
Posted almost 12 years ago by Centreon Com
This release fixes the compatibility issues with PHP 5.3. Centreon BI works now with the versions 5.2.x and superior or equal to 5.3.3 of PHP. 2 more majors bugs were detected and fixed on : The reports containing graphs exported from Centreon ... [More] (RRD graphs). Concerned reports : - Host-Detail - Host-Graphs - Hostgroup-Graphs - Servicegroup-Graphs  The upgrade of downloadable reports in Centreon BI interface. Manual steps are needed to upgrade Centreon BI from versions prior to 1.4.0. Refer to the installation documentation for more informations. The changelog of the product also contains more details on the bug fixes of this version. ----------------------------------------------------------------------------------------------------------------------------------- Cette version corrige les problèmes de compatibilité avec PHP 5.3. Centreon BI fonctionne maintenant avec les versions PHP 5.2.x ainsi que les version supérieures ou égale à 5.3.3. Des bugs majeurs de migration de Centreon BI vers les versions 1.4.x ont été résolus. Ils concernent essentiellement : -Les rapports contenant des exports de graphiques Centreon: - Host-Detail - Host-Graphs - Hostgroup-Graphs - Servicegroup-Graphs  La migration des rapports téléchargeables depuis l'interface Centreon BI Des étapes manuelles de migration sont à réaliser si vous souhaitez mettre à jour une version inférieure à Centreon BI 1.4.0. Référez-vous aux chapitres concernant la migration dans la documentation d'installation de Centreon BI. Le "change log" du produit contient également le détail des corrections réalisées sur cette nouvelle version. [Less]
Posted almost 12 years ago by Centreon Com
Guillaume DEGROISSE - Head of Marketing & Communications and Head of Partnership Management, was in Czech Republic this week. While visiting the Centreon Silver Parner CDC Data, Guillaume had the opportunity to talk about Centreon in front of 25 ... [More] customers of CDC Data. Presentation of Centreon in Czech language... Lubos Strapina (CEO of CDC Data) wearing a Centreon TShirt and Guillaume Degroisse wearing a CDC Data vest [Less]
Posted almost 12 years ago by Centreon Com
Il y a quelques semaines nous vous annoncions la sortie de Centreon BI 1.4.0. Découvrez dans cet article, les nouvelles fonctionnalités de cette version détaillées et illustrées :- La matrice de compatibilité- Les nouveaux protocoles de publication ... [More] des rapports - La modification dynamique des images dans les rapports- Les améliorations de performance- les logs et suivi des tâches d'exécution des rapports- L'internationalisation des rapports- Et bien sur, les nouveaux rapportsBonne lecture !------------------------------------------------------------------------------------------------------- Few weeks ago, we announced the release of Centreon BI 1.4.0. In this article, learn more about the new functionnalities of this version : - The software compatibility- The new report publication protocols - The dynamic image replacement in reports - the logs and report generation tasks tracking- The performance improvements - The reports internationalization - And of course, the new reports Enjoy ! Software compatibility Softwares Versions Centreon BI 1.3.9 1.4.0 Centreon >= 2.0 >= 2.3 Eclipse BIRT 2.6.1 2.6.2 Sun Java runtime environment >= 1.5 >= 1.5 PHP >=5.1 >=5.1 Report publication protocols The reporting engine (CBIS) allows to publish the reports on different platforms at the same time. 4 protocols are available in addition to the local copy on the reporting server : CIFS: Windows shared folders ; FTP ; SFTP : Secure copy of files on Linux/Unix servers ; SMTP : send reports by e-mail. Form used to define publication rule List of defined publication rules Dynamic replacement of images in reports Centreon is frequently used as a shared platform to monitor the IT infrastructure of different companies or different branches of the same company. Centreon BI must be able to provide reports customized to each branch, client or business. This also concerns the customization of images and logo. In the Centreon BI interface, you can declare images that will be used to replace existing images in the reports during their generation. Page that lists logos added in Centreon BI These logos can be used in the « Report Parameters » part when creating or modifying a job : Job report parameter form Improved performances Now on , multiple jobs can be scheduled and used simultaneously. The number of parallel jobs is automatically calculated by the engine regarding to the weight of the report template to execute and the job weight multiplicative. Parallelized jobs execution Logs and scheduled job execution monitoring The report is published with its log file. In case of failure during the execution, this file contains all generation information to identify the problem. It is now possible to configure an email notification that sends the log file when the job is finished. This notification has to be defined in the General Option, in the «Notification Options» tab. It is separated from the report publication rules and mainly designed for administrator. Administrator notification configuration form Report Internationalisation Report can be translated in different languages using « .properties » files. These files are stored in the « report/translation » folder, in the centreon BI installation directory, on the reporting server. The « .properties » files have to be named as follow : « filename_locale.properties » filename : name identifying the file (ex : report name) locale: locale used for the translation (Ex: fr_FR, de_DE, en_US, en_EN, …) properties: file extension A file named « filename.properties » has to be defined and will be used as the default english translation file. You do not have to create a filename_en_US.properties file , the filename.properties will be used for the english version. Each line of a«.properties» file is defined with a key associated to a value. : - key : ID used in BIRT report to defined the text zone to translate - value : texte to insert in the text zone The «.properties » files have to be uploaded on the reporting server. The new locales are detected in the job configuration interface. You have to click on the double arrow icon to refresh the list (see image below). Update locale available for a report template in the job configuration interface The new reports The content of new report template : - Evolution of performance indicators - Maintenability and Reliability of equipments, acknowledgement delay of incidents - Capacity management Below, you will find short description of some of the 9 new reports added in Centreon BI 1.4.0. Capacity management report : The goal of capacity management is to anticipate saturation of system resouces ( mainly storage capacity) by measuring usage level and determining delay before saturation. The graph below is used to see the evolution of a performance indicator and to visualize its evolution in the future (forecast) days / weeks / month using linear regression. This graphs is generated by capacity performance metrics of a host group given in parameter. Capacity planning report Maintenability and reliability report : This report give information on 3 important indicators in incidents management: MTBF (Mean Time Between Failure) : corresponds to the average time between two incidents. A low average means that the equipment is not reliable. MTTR ( Mean Time To Repair) : corresponds to the time to repair incidents on a host or host group. A high MTTR average means that in case of incident , the maintenance of the equipments is expensive. Acknowledgement delay : Acknowledgement means that the problem is beeing resolved and notification mecanism has been stopped for this alarm. For the reporting, this delay is important to measure teams reactivity. Resolution delay and acknowledgement delay Top 10 of less reliable resources Performance report With Centreon BI , data are aggregated on defined time period. The graph below allows you to compare on different period the evolution on the 24 hours of a day of a chosen indicator. With this view, you can easily determine the critical hours of a typical day. In parameter of this report, you can choose the host group , services categories and metrics. Evolution of performance metrics --------------------------------------------------------------------------------------------------------- Compatibilité des logiciels Logiciels Versions Centreon BI 1.3.9 1.4.0 Centreon >= 2.0 >= 2.3 Eclipse BIRT 2.6.1 2.6.2 Sun Java runtime environment >= 1.5 >= 1.5 PHP >=5.1 >=5.1 Les protocoles de publication des rapports ll est possible de publier les rapports générés par le moteur CBIS (Centreon BI Server) sur plusieurs plateformes à la fois, en utilisant 4 protocoles en plus de la copie simple sur des répertoires personnalisés du serveur de reporting. Il est donc possible de publier les rapports sur : des répertoires windows partagés; des serveurs FTP; des serveurs Linux/Unix via SSH ; par E-mail. Formulaire de définition des règles de publication Page listant les règles de publication des rapports Les modifications dynamiques d'images dans les rapports Centreon est souvent exploité comme une plateforme de supervision mutualisée des infrastructures de différentes sociétés ou différentes cellules d'activités d'une même société… Centreon BI doit donc fournir un reporting adapté à chaque cellule, client ou métier et cela va jusqu'à la personnalisation des images d'illustration et logos dans les rapports. Il est possible de déclarer dans l'interface des images qui seront insérées dynamiquement dans les rapports. Page listant les images déclarées dans Centreon BI Ces images peuvent ensuite être ré-utilisées dans le paramétrage spécifique des tâches de génération de rapports : Formulaire de paramétrage spécifique des tâches de génération de rapports Amélioration des performances Les tâches de génération des rapports peuvent désormais être lancées en simultané. Le nombre de tâches parallélisées est calculé automatiquement par le moteur de reporting en fonction de l'indice de charge du serveur et des poids affectés à chaque modèle de rapport (en fonction de son contenu, des requêtes d'extraction de données, etc...). Exécution parallélisées des tâches de génération des rapports. Logs et suivi des tâches d'exécution des rapports Le rapport est toujours publié avec son fichier de log. Ce fichier contient toutes les informations nécessaires à l'identification du problème lorsque la génération du rapport se termine dans un état « Echec ».. Il est maintenant possible de configurer une notification qui envoie par email le fichier de log associé à la tâche une fois celle-ci terminée.Cette notification se définit dans la configuration globale de Centreon BI, elle est décorellée de la publication des rapports par e-mail. Cette fonctionnalité de notification a pour but de fournir un suivi des tâches aux administrateurs de la plateforme. Formulaire de configuration de la notification des administrateurs Internationalisation des rapports Les rapports peuvent être traduits dans différentes langues grâce à l'utilisation des fichiers « .properties ». Ces fichiers sont stockés dans le répertoire « reports/translation » du répertoire d'installation de Centreon BI sur le serveur de reporting. Les fichiers « .properties » doivent avoir un nommage spécifique « filename_locale.properties » : filename : nom identifiant le fichier .properties locale : locale utilisée pour la traduction des rapports (Exemple : fr_FR, de_DE, en_US, en_EN, …) properties : extension du fichier Il doit obligatoirement y avoir un fichier « filename.properties » qui sera utilisé pour la traduction par défaut en anglais des textes. Si un fichier de traduction « filename_locale.properties » est introuvable ou si la traduction d'un texte a été omis dans ce fichier, le contenu du fichier « filename.properties » sera pris en compte automatiquement. Il n'est donc pas nécessaire de créer des fichiers « filename_en_US.properties » pour la traduction des rapports en anglais. Chaque ligne d'un fichier « .properties » est formaté avec une correspondance « clé=valeur » : - clé : identifiant utilisé dans les rapports BIRT pour définir une zone de texte à traduire ; - valeur : texte à insérer dans la zone identifiée par la clé. Les fichiers doivent être déposés sur le serveur de reporting. Les nouvelles locales sont ensuite détectées dans l'interface de configuration des tâches planifiées lorsque l'on clique sur l'icône de mise à jour des langues. Mise à jour des locales dans l'interface de configuration des tâches planifiées Les nouveaux rapports Les nouveaux modèles de rapports sont orientés sur: - le suivi des indicateurs de performance (métrologie) - la maintenabilité et la fiabilité des équipements ainsi que les délais d'acquittement des incidents - la gestion de la capacité La suite de ce document introduit quelques uns de ces rapports. 9 rapports ont été ajoutés à la version 1.4.0 de Centreon BI. Rapport de gestion de capacité  : La gestion de la capacité a pour objectif d'anticiper la saturation des ressources systèmes (notamment les espaces de stockage) en mesurant leur niveau d'utilisation et surtout en déterminant leurs délais critiques de saturation. La vue ci-dessous permet d'évaluer le comportement d'un indicateur de performance et de visualiser sa progression sur les prochains jours/semaines/mois en appliquant un algorithme de calcul prévisionnel. Cette vue est déclinée par métrique de capacité pour un groupe de ressources (hôtes) passé en paramètre au modèle de rapport. Exemple de rapport de capacity planning Rapport de maintenabilité et de fiabilité des équipement  : Le rapport suivant met en avant 3 indicateurs importants dans la gestion des incidents  MTTR (Mean Time To Repair) : il s'agit du temps moyen de résolution des pannes pour un équipement ou un groupe d'équipements. Une moyenne élevée indique qu'en cas de panne la maintenance de l'équipement ciblé est lourde et couteuse. MTBF (Mean Time Between Failure) : il s'agit du temps moyen entre deux pannes. Une moyenne faible indique que les incidents sont récurrents sur les équipements ciblé. La fiabilité de cet équipement est donc remise en question. Le délai d'acquittement des incidents : l'acquittement (ou « acknowledgement ») des incidents dans la console de supervision Centreon permet de prendre en compte les alertes et de couper les notifications récurrentes en cas de persistence de la panne. Pour le reporting, c'est également un indicateur de réactivité des équipes pour le rétablissement d'un service lorsqu'une panne est identifiée. Délai de résolution et d'acquittement des pannes Top 10 des équipements les moins fiables et les plus lourds à maintenir Rapport de mesure de performance Centreon BI permet également d'agréger les données sur des intervalles de temps précis (créneaux horaires par exemples). Le graphique ci-dessous permet de comparer sur différentes périodes de l'année le niveau de fonctionnement moyen, par heure de la journée, d'un indicateur système. Il est ainsi aisé de déterminer sur quels créneaux horaires l'utilisation des ressources est la plus importante. Le rapport présentant cette vue prend en paramètre un groupe de ressources (hôtes) et décline ces graphiques pour chaque métrique. Il est possible de filtrer les métriques affichés à l'aide de catégories de services et noms de métriques. Evolution des métriques de performance [Less]
Posted almost 12 years ago by Centreon Com
Hôte, Service, Groupe d'hôtes, services attachés à un Groupe d'hôtes... Les utilisateurs de Nagios © et de Centreon connaissent ces termes par coeur. Beaucoup d'utilisateurs de Centreon sont des habitués de Nagios et souhaitent disposer de toutes ... [More] les fonctionnalités prévues dans Nagios... même celles qui, de notre point de vue, ne devraient pas l'être ! L'une de ses fonctionnalités est l'attachement d'un service à un groupe d'hôtes. Cet article basé sur notre expertise et notre expérience, a pour but d’expliquer pourquoi vous ne devriez jamais attacher un service à un groupe d'hôtes... ------------------------------------------------------------------------------------------------------------------------------- Host, Service, Host Group, Hosted services… The Nagios© and Centeron users know these terms by heart. Some Centreon users use regularly Nagios and want to have all Nagios features available… even the ones which shouldn’t be available for us. One of these features is assigning a service to multiple hosts. This article is based on our expertise and experience and its aim is to explain why you shouldn’t attach a service to multiple hosts. Definitions Before getting to the heart of the matter, here are a few reminders: Host: monitored equipment (for example, a server Windows/Linux/AIX/HP-UX/Solaris/AS400... or switch/router/firewall/SSL gateway/IP compression/power supply...) Service: a specific monitoring indicator on an host (for example cpu/memory/partition/process/interface/network/bandwidth/temperature/connexion/...) Host Group: a logical grouping of hosts. This grouping should be logical for a human being : grouping by Operating System (“all Windows servers”, “all Linux servers”, …), by location (continent/country/region/city/building/room), by type (“database”, “application server”,…), by application (“ERP”) or by what you want that makes sense to you. Services group: a logical grouping of services. The principle is similar to the host grouping but most of the time, we use services groups for applications (“ERP”). Dependencies between a service and a Host Group To create a service and to attach it to an host group, it is very simple: you do the same thing that you do to create a service linked with an host, but this time, you just attach it to an Host Group. First, you create a service, you give it a name and you use a service template: Then, you go to the tab «Relations», you don't click on an host and you choose the Host Group that you want: In the screenshot above, I have chosen the Host Group “Linux-servers”. I click on confirm…but I can’t see the service I created… You have to go in services by host group screen to see it! Indeed, this new service is a service related to an Host Group and not a regular service: the software put it in a specific screen to avoid the confusion. Assigning a service to multiple hosts: why it is not such a good idea When a service is linked with an Host Group, the service is the same for all hosts of this Host Group. It means that if there are 200 hosts in the Host Group, the service is exactly the same for these 200 hosts. It means : Same name same configuration same threshold … The benefit of this is “configuration made easy”: indeed, I configure my service once and it is the same everywhere. This is what we are used to hear from our customers and users... and actually, it IS quick but it's a real trap! Any time you make a chance to the service, this change will affect all group members. But, a group is (most of the time) composed of unique elements: each server is unique! Indeed, two servers run different applications with different loads, have load peak at different periods, etc. Imagine, imagine a very standardized environment: same provider, same server type, same CPU, same memory, same physical disks, same network cards, same Operating system, same partitioning, same system configuration, etc. Even in such an environment, to make a service assignment to multiple hosts worth it, all the machines must do the exact same thing! Servers don’t always run the same applications and they don’t have the same teamplate. The CPU occupancy rate for a database is probably higher than DHCP server. Why should we have the same configuration then? Because they all are Linux servers, please!?! In this case, if i want to adapt my monitoring policy, the solution is: 1. I don’t do it : if I do it, all my hosts will be impacted and for example, I want to change only one threshold for a specific server; 2. I can set a very high threshold: by doing this, I’m sure not to have false positive. Problem: I can’t see the true positives that indicate a CPU occupancy rate going crazy. It’s strange… It shouldn’t do anything but it is loaded... Something is happening… but I can’t see it because the value is too high and I won’t be alerted; 3. I do it putting out the host from Host Group, and then creating a specific service on this host… While I first create a group “Linux servers”,why do I have only one Linux machine alone? 4. 4. I create several Host Groups, one for the high-loaded CPU, another one for loaded CPU and another for little-loaded CPU. Of course, I cut in three parts for memory, then in three parts for swap, and three parts again for partition, etc. What a complexity! It was done to make my life easier and now I don’t understand anything at my own set up. Conclusion: We don’t assign a service with Host Group! At first sight, it seems to be very practical for the first configuration but an IT system lives: new servers can be installed, others go away, applications can be used very often for a period of time and then be less used, servers can be consolidated and then separated for a better security purpose and then consolidated again for monitoring, and separated again… So the threshold values have to follow these modifications. So, the monitoring is not efficient because it doesn’t reflect the reality of the IT architecture. The only case where you can really assign a service with Host Group is when you are sure that this service will be exactly identical for the next three years in both configuration and threshold values. I think of one case: ping check, and I'm not so sure because a ping on LAN and a ping on WAN are two different things… How to obtain the same result? Don’t worry; we can obtain the same result with Centreon, using the service models! The service models will be the subject for the next articles. Their configuration is quite difficult to manage at first but very efficient to use. So, we are giving you some ideas to begin using them: 1. To create a Linux host model; 2. To create CPU service model (Linux), to definite macros for this service and to link this model and host model previously established; 3. When you create a new Linux host, just use this host model; So, all new hosts based on this host model will be perfectly identical ==> industrialized configuration If you want to modify a threshold value of CPU service on a particular host: you can do it by modifying a corresponding macro. Thus, you keep the configuration flexibility! Great… Stay tuned with the next articles! ------------------------------------------------------------------------------------------------------------------------------- Hôte, Service, Groupe d'hôtes, services attachés à un Groupe d'hôtes... Les utilisateurs de Nagios © et de Centreon connaissent ces termes par coeur. Beaucoup d'utilisateurs de Centreon sont des habitués de Nagios et souhaitent disposer de toutes les fonctionnalités prévues dans Nagios... même celles qui, de notre point de vue, ne devraient pas l'être ! L'une de ses fonctionnalités est l'attachement d'un service à un groupe d'hôtes. Cet article basé sur notre expertise et notre expérience, a pour but d’expliquer pourquoi vous ne devriez jamais attacher un service à un groupe d'hôtes... Définitions Avant attaquer le cœur du sujet, quelques petits rappels ne font jamais de mal :  hôte: équipement supervisé (par exemple un serveur Windows/Linux/AIX/HP-UX/Solaris/AS400... ou un switch/routeur/firewall/passerelle SSL/compresseur IP/onduleur/...) service;: point de supervision sur un hôte (par exemple cpu/mémoire/partitions/processus/interface réseau/bande passante/température/connexion/...) groupe d'hôtes : regroupement logique d'hôtes. Le regroupement est « logique » pour un être humain sensé : regroupement par Système d'exploitation (« tous les serveurs Windows », « tous les serveurs Linux », …), par site géographique (continent/pays/région/ville/bâtiment/salle), par type (« base de données », « serveur d'application », …), par application (« ERP ») ou par... ce que vous voulez groupe de services : regroupement logique de services. Le principe est le même que pour les hôtes mais les groupes de service sont généralement dédiés aux applications dans le sens large (« ERP ») Association d'un service à un groupe d'hôtes Pour créer un service et l'attacher à un groupe d'hôtes, c'est très simple : l'opération est la même que la création d'un service attaché à un hôte à la différence que l'attachement se fait... sur un groupe d'hôtes. Tout d'abord, je crée un service, je lui donne un nom et j'associe un modèle de service :  Ensuite, on se rend dans l'onglet « Relation », on ne choisit aucun hôte et on sélectionne le groupe d'hôtes souhaité :  Dans la capture d'écran ci‑dessus, j'ai choisi le groupe d'hôte « Linux-servers ». Je valide.... pourtant mon service créé n'apparaît pas... Il faut se rendre dans la vue des services par groupe d'hôtes pour le voir ! En effet, le service est un service par groupe d'hôtes et non un simple service : l'interface le dissocie pour éviter toute confusion. Impact (NEGATIF !) de la création d'un service attaché à un groupe d'hôtes Lorsqu'un service est attaché à un groupe d'hôtes, le service est identique pour tous les hôtes de ce groupe d'hôtes. C'est à dire que s'il y a 200 hôtes dans ce groupe d'hôtes, le service est exactement le même pour ces 200 hôtes. Ce qui signifie : même nom même configuration mêmes valeurs seuils ... L'avantage de ce type d'association est la rapidité de configuration : je configure une fois mon service et il est identique partout. Je peux le modifier une fois et tous les services seront modifiés en même temps. Voilà ce que nous avons l'habitude d’entendre chez nos clients et utilisateurs … et pourtant, cette facilité annoncée est en réalité un vrai piège ! Si nous créons un service identique, chaque modification est répercutée sur tous les membres du groupe. Or, un groupe est composé d'éléments uniques : chaque serveur est unique ! En effet, deux serveurs font tourner des applications différentes, avec des charges différentes, des pics de charges à des périodes différentes, etc... On pourrait imaginer un environnement extrêmement standardisé : même constructeur, même modèle de serveur, même CPU, même mémoire vive, même disques physiques, mêmes cartes réseaux, même version de système d'exploitation, même partitionnement, même configuration système, etc… Mais... en plus d'avoir un environnement standard, il faudrait que toutes ces machines aient la même fonction ! Les serveurs ne font toujours pas tourner les mêmes applications et n'ont pas le même rôle. Le taux d'occupation du CPU pour une base de données sera probablement un peu plus élevé que le serveur DHCP. Pourquoi devrait-on avoir la même configuration !?! Dans ce cas, lorsque je veux adapter ma politique de supervision … , la solution est donc : 1. je ne le fais pas : si je le fais, tous mes services seront impactés, or je ne veux changer qu'un seul seuil par exemple 2. je le fais en configurant la valeur seuil la plus haute possible : de cette façon, je suis sûr de ne pas avoir de faux positif. Problème : je ne vois pas les vrais positifs qui m'indiquent que le taux d'occupation du CPU d'un serveur qui est sensé ne faire presque rien est anormalement élevé... C'est étonnant... il ne devrait (presque) rien faire mais il est chargé... il doit se passer quelque chose... mais je ne le verrai pas car la valeur seuil est trop haute, je ne serai pas averti 3. je le fais en « sortant » l'hôte du groupe d'hôtes puis en créant mon service spécifique sur cet hôte... Alors que j'avais initialement crée un Groupe « serveurs Linux » je vais désormais avoir une machine Linux toute seule ? 4. je crée plusieurs groupes d'hôtes, un pour les CPU très chargés, un autre pour les CPU chargés et un dernier pour les CPU peu chargés. Bien sûr : et je découpe en trois aussi pour la mémoire, puis en trois pour le swap puis encore en trois pour la partition / et encore en trois pour la partition /var et encore.... Quelle complexité ! J'étais parti pour me simplifier la vie et je ne comprends plus rien à ma configuration.Conclusion : on n'associe pas un service à un groupe d'hôtes ! C'est certes très pratique pour la première configuration mais un système d'information vit : de nouveaux serveurs arrivent, d'autres partent, des applications sont fortement utilisées pendant une période puis après beaucoup moins, des serveurs sont consolidés puis séparés pour une meilleure sécurité puis reconsolider pour la virtualisation puis re-séparés … Les valeurs seuils doivent suivre. Sinon, la supervision est inutile car elle ne permet pas de refléter la réalité. Le seul cas conseillé d'association d'un service à un groupe d'hôtes est lorsque l'on est sûr et certain que ce service sera toujours, dans les trois prochaines années au moins, exactement identique, tant dans sa configuration que dans ses valeurs seuils. Je n'en vois qu'un : le ping... et encore, on distingue le ping sur un LAN du ping sur un WAN... Comment obtenir le même résultat ? Rassurez vous, il est possible d'obtenir le même résultat (ou à peu près) avec Centreon, en utilisant les modèles de service ! Les modèles de service vous seront présentés dans les prochains articles. Leur configuration est un peu difficile à appréhender au départ, mais une fois maîtrisés, ils sont extrêmement efficaces. Cependant, nous allons quand même vous donner une piste pour commencer à les utiliser:  1. créer un modèle d'hôte Linux 2. créer un modèle de service CPU (spécifique Linux), définir des macros pour ce service et associer ce modèle de service au modèle d'hôte créé précédemment 3. lorsque vous créez un nouvel hôte Linux, utiliser ce modèle d'hôte Dès lors, tout nouvel hôte basé sur ce modèle d'hôte sera parfaitement identique ==> industrialisation de la configuration. Vous souhaitez modifier une valeur seuil du service CPU sur un hôte bien particulier : vous pouvez toujours le faire en modifiant la macro correspondante : on conserve la flexibilité de la configuration ! Magique... à voir dans les prochains articles ! [Less]
Posted almost 12 years ago by Tilap
We are glad to release 2 bugfix versions today Before reading the changelog, please notice that if you want to upgrade to Centreon Broker 2.1 and further versions, you need to upgrade to Centreon 2.3.5 before because of a database change (see below ... [More] for more details) Centreon version 2.3.5 This version fix the following minor bugs : fix the problem that occured when editing a service linked to an Host group from the service details page; fix a problem with Nagios stats graphs; fix nagiosPerfTrace running problems; fix service categories special characters; fix meta service parsing error; fix problem with host downtime; fix the pagination error in host and service downtime; avoid to block SSH/SCP connexion in centcore; fix the problem with the backup file in centstorage; fix the generation of servicegroup dependancies which failed; retrieve the status_file parameters in nagios.cfg; delete the old Broker files when removing it. Moreover, a few changes have been added : it's now possible to start Nagios from Administration » status screen; Centreon Broker is now the default engine. Centreon Broker 2.1 & 2.1.1 Centreon Broker 2.1 comes with a big database change: The acknowledgements and downtimes delete time are thrown in databases; Add the deletion_time column in the database table of the acknowledgements and downtimes. The Centreon Broker 2.1.1 version just includes a small fix (issue on metrics names special chars). ------------------------------------------ Nous sommes heureux aujourd'hui de publier 2 versions bugfix de Centreon et Centreon Broker réglant quelques problèmes. Veuillez noter que si vous souhaitez migrer vers Centreon Broker 2.1 et supérieur, vous devez d'abord effectuer la mise à jour vers Centreon 2.3.5, du fait de modifications en base de données. Centreon version 2.3.5 Les bugs corrigés : correction du problème survenant lors de l'édition d'un service lié à un hostgroup sur la page de détail d'un service; correction d'un problème lié aux graphs de stats de Nagios ; correction sur un bug lors de l'exécution de nagiosPerfTrace ; correction sur des caractères spéciaux dans les noms des catégories de services ; correction sur des erreurs de parsing de meta service ; correction liée à un bug sur les downtime des hosts ; correction d'erreurs de pagination sur les hosts et les downtime des services ; empêche le blocage des connexions SSH et SCP dans centcore; correction d'un bug sur les fichiers de backups de centstorage; correction sur la génération des dépendances des groupes de services qui échouaient parfois; récupère le status_file parameters dans nagios.cfg; suppression propre des anciens fichiers de Broker lorsqu'on le supprime. Par ailleurs, quelques changements ont été apportés : il est maintenant possible de démarrer Nagios depuis l'écran Administration » Status ; Centreon Broker est désormais le moteur par défaut. Centreon Broker 2.1 & 2.1.1 Centreon Broker version 2.1: Remontée des temps de suppression des acknowledgements et des downtimes en base de données; Rajout d'un champ deletion_time dans les tables acknowledgements et downtimes Cette version de Centreon Broker  2.1.1 apporte simplement un correctif (gestion de tous les caractères spéciaux dans les noms de métriques). [Less]
Posted about 12 years ago by Centreon Com
For many months now, members of the Centreon community have asked us to share good practices for monitoring with Centreon. So, we are pleased to begin a series of articles which should provide you all necessary information to use efficiently your ... [More] favourite monitoring platform. :) Centreon is a modular software that can adapt to a lot of contexts. You can use Centreon to monitor some network equipment or many servers or middleware in a datacenter. So, Centreon is flexible and has been conceived to meet different needs. This relative complexity can be disturbing. Thus, to successfully deploy your monitoring plat-form, you need to get a comprehensive view of the software. We are going to describe and share some good practices related to Centreon. These practices have been presented and described by our experts. They are the people who deal best with all the problems related to the development and the use of Centreon. Our teams integrate Centreon in various contexts, within simple or complex architectures with huge or light monitoring scales. Basically we will tackle several subjects such as: - make full use of Centreon - obtain optimum performance - save your time - make your life easier Make full use of Centreon Centreon has many features. We will provide some advices helping you to better use all the features. Each of them will be presented and analysed with some case-studies. We will explain some of the features that you don’t use just because you don’t know them! You will find some advices to avoid misuse of features as well. The macros of hosts and services are examples of features that you have to know and to use. Obtain optimum performance To obtain the best performance, we will bring you our own experiences related to huge and complex architectures and will explain some good practices. A monitoring plat-form needs several tools: Centreon, MySQL database, plugins, a schedule such as Nagios or Centreon Engine, a broker such as NDO or Centreon Broker and some monitoring agents. You can use these advises for each component or more generally to distributed architectures. Save your time Follow our good practices and save time! You have different ways: -Not to waste time because you had to look for a feature you don’t know -not to lose it because you had to change a part of the configuration after a wrong strategy -maybe to spend a little time at the beginning to avoid to spend lot of time afterwards -to modify a large numbers of elements in one time Some advises about configuration strategy, configuration of monitoring or macro model will be brought to you. Make your life easier The objective of a monitoring plat-form is to make your life easier. Thanks to these advises, you won’t have to enter many times the information, to reconfigure your monitoring every months, to look for how you can optimize your plat-form or to check what behaviour for what parameters… The next themes The upcoming themes will be: - to get out of services with hosts group - service models - hosts models - macro based on host or service model - how you can use properly hosts and services group ---------------------------------------------------------------------------------------------------------------------------- Depuis plusieurs mois déjà, de nombreux membres de la communauté Centreon nous demandent de leur apporter notre aide et notre expérience en partageant nos bonnes pratiques de supervision et d’usage de Centreon. Nous avons donc le plaisir de démarrer une série de petits articles qui vous fourniront les éclairages nécessaires au bon usage de votre plateforme de supervision. Nous vous invitons donc à parcourir ces articles afin de mieux utiliser votre logiciel de supervision préféré :) L'un des nombreux points forts de Centreon est de s'adapter à tous les contextes. Centreon peut ainsi être utilisé pour superviser quelques équipements réseaux comme de très nombreux serveurs ou middleware dans un datacenter. Centreon est donc flexible et conçu comme tel afin de répondre à des attentes totalement différentes. Ce point fort peut aussi se transformer en point faible car certaines fonctionnalités sont complexes à appréhender… Et cette complexité relative peut être perturbante. C’est pourquoi la réussite de la mise en place d’une plateforme de supervision nécessite de bien en comprendre la finalité et de bien appréhender le logiciel utilisé. Nous allons donc nous attacher à vous décrire un certain nombre de bonnes pratiques dédiées à Centreon. Ces bonnes pratiques sont proposées et écrites par nos experts intégrateurs. Ce sont eux qui maitrisent le mieux les problématiques liées au déploiement et à l’usage de Centreon. Nos équipes intègrent Centreon dans de nombreux contextes différents, sur des architectures simples ou très complexes, avec des volumétries de supervision peu chargées ou au contraire très importantes. Ces Bonnes Pratiques vous sont proposées dans les buts suivants : - utiliser pleinement le logiciel - obtenir de meilleures performances - gagner du temps - vous simplifier la vie Utiliser pleinement le logiciel Centreon dispose de très nombreuses fonctionnalités. Les conseils que nous vous apporterons vous permettront d'utiliser pleinement chacune des fonctionnalités. Chacune d'entre elles vous sera présentée, décortiquée et des cas d'utilisation seront analysés. Vous apprendrez aussi toutes les fonctionnalités que vous n'utilisez pas car vous... ne les connaissez simplement pas ! Des conseils pour éviter la mauvaise utilisation de certaines fonctionnalités vous seront aussi présentés. Les macros d'hôtes et de services ou les modèles sont des exemples de fonctionnalité que vous devez connaître et utiliser. Obtenir de meilleures performances Notre expérience des architectures de supervision complexes et de taille très importante nous permettra de vous conseiller sur les bonnes pratiques à mettre en place pour obtenir les meilleures performances possibles. Une plate-forme de supervision repose sur plusieurs outils : Centreon, une base de données MySQL, des sondes de supervision (plugins), un ordonnanceur (Nagios ou Centreon Engine), un broker (NDO ou Centreon Broker) et des agents de supervision. Ces conseils pourront concerner chacun de ces composants de manière unitaire mais pourront aussi être plus globaux et aborder les architectures réparties Gagner du temps Les bonnes pratiques que nous allons vous présenter vous permettront de gagner du temps. Il existe plusieurs moyens pour gagner du temps : -ne pas en perdre inutilement en cherchant comment utiliser telle partie ou telle fonctionnalité du logiciel -ne pas en perdre en évitant de devoir changer tout un pan de la configuration après une mauvaise stratégie -en perdre (un peu) au début pour éviter d'en perdre (beaucoup) par la suite -modifier beaucoup d'éléments en une seule étape Des conseils sur la stratégie de configuration, la configuration de modèle de supervision ou de macro vous seront présentés. Vous simplifier la vie Le but d’une plateforme de supervision est aussi de se simplifier la vie. Les conseils que nous vous donnerons vous permettront d'éviter de devoir saisir 100 fois la même information, de reconfigurer votre supervision tous les mois, de chercher comment optimiser votre plate-forme, de devoir tester quel est le comportement de tel paramètre, … Les prochains thèmes que nous aborderons Les prochains thèmes que nous aborderons seront : - Pour en finir avec les services attachés à un groupe d'hôtes - Les modèles de service - Les modèles d'hôte - Les macro sur les modèles d'hôte et de service - Comment bien utiliser les groupes d'hôtes et les groupes de services [Less]
Posted about 12 years ago by Centreon Com
The Centreon Business Intelligence (BI) module offers in-depth examination of the data collected by your Centreon monitoring tool. Centreon BI is driven by a very powerful reporting engine and offers the possibility of generating custom reports on ... [More] the availability and performance of your IT infrastructure. Based on the logs and data collected by Centreon, reports generated by Centreon BI allow you to accurately analyze data to find the critical indicators that you can quickly act upon to fix your IT infrastructure's issues.The 1.4 version brings major improvements such as new reports where maintainability (MTTR) and reliability (MTBF) of equipments can now be measured. This new version also includes some planning forecast algorithms for performance metrics, thus allowing you to foresee the saturation of capacity indicators, for example. Centreon BI integrates some new features to make easy to customize, generate and  publish reports. The reporting engine automatically parallelizes generation tasks of reports depending on the estimated load per report template.From your dashboard, you can customize logo on the head page or headers of your reports. The documents which are generated by the reporting engine can be published on different platforms at the same time : Windows© share folders, FTP server, Linux server, e-mail. ----------------------------------------------------------------------------------------------------------- La solution Centreon Business Intelligence (BI) permet de générer des rapports personnalisés sur les disponibilités et les performances de votre Système d'Information (SI). Sur la base des journaux et des données collectées par Centreon, les rapports générés par Centreon BI vous pouvez analyser de façon détaillée les données qui vous intéressent, et  ainsi intervenir efficacement sur votre SI lorsque cela est nécessaire.La version 1.4 s'est enrichi de nouveaux rapports qui permettent de mesurer la maintenabilité (MTTR) et la fiabilité de vos équipements (MTBF). Cette nouvelle version intègre également des algorithmes prévisionnels sur les métriques de performance, vous permettant par exemple de prévoir la saturation des indicateurs de capacité. De nouvelles fonctionnalités ont été apportées pour faciliter la personnalisation, la génération et la publication des rapports. Le moteur de reporting parallélise automatiquement les tâches de génération des rapports en fonction des charges estimées par modèle de rapport ; les logos intégrés dans les pages de garde ou en-tête des rapports sont personnalisables depuis l’interface de planification des tâches. Les documents générés par le moteur de reporting peuvent maintenant être publiés sur plusieurs plateformes en simultané : partage Windows, serveur FTP, serveur Linux, E-mail. [Less]
Posted about 12 years ago by Centreon Com
With more than 45.000 users worldwide, Centreon keeps growing in every countries. With now more than 10% of Centreon users located in America, MERETHIS has decided to protect the product by registering the trademark "Centreon" first in the United ... [More] States to secure the name, the product, and the community. It has been a long road to get this trademark registered, with tedious and lenghty procedures. It's now done and Centreon is officialy registered as trademark in United-States from July 12, 2011 :) We would like to thanks you all, contributors, customers and end users to use our products all around the world. Hoping it will go on :) You can be involved in this international growth too by helping us to translate Centreon in other langages. ______________________________________________________ Grâce à vous, Centreon compte aujourd'hui plus de 45 000 utilisateurs dans le monde et ce chiffre ne cesse de grandir. Plus de 10% des utilisateurs de Centreon sont en Amérique et c'est pourquoi MERETHIS a décidé de protéger Centreon, son nom, le produit mais aussi la communauté en enregistrant la marque déjà aux Etats-Unis. Après de longues et difficiles démarches administratives, nous sommes heureux de vous annoncer que Centreon est officiellement une marque déposée aux États-Unis depuis le 12 juillet 2011 :) Nous souhaitons remercier tous les contributeurs, les utilisateurs et les clients qui utilisent nos produits à travers le monde entier. Espérons que cela va continuer :) Si vous le souhaitez, vous pouvez vous aussi contribuer à cette croissance internationale en nous aidant à traduire Centreon dans différentes langues. [Less]