Ingénierie Pandora FMS

Les premières versions de Pandora FMS, de 0.83 à 1.1, étaient basées sur une idée très simple : une donnée, une insertion de base de données. Cela permettait au logiciel d'effectuer rapidement des recherches, des insertions et d'autres opérations.

Outre tous les avantages de ce développement, il y avait un inconvénient : la scalabilité (croissance rapide avec peu ou pas d'impact sur les opérations et les routines de travail). Ce système avait une limite définie dans le nombre maximum de modules qu'il pouvait supporter, et avec une certaine quantité de données (plus de 5 millions d'éléments), les performances étaient affectées.

Les solutions basées sur les cluster MySQL, en revanche, sont difficiles: bien qu'elles puissent gérer une charge plus élevée, elles ajoutent des problèmes et des difficultés supplémentaires, et n'offrent pas non plus de solution à long terme au problème de performance avec de grandes quantités de données.

Actuellement, le Pandora FMS implémente une compression de données en temps réel pour chaque insertion, en plus d'effectuer une compression de données basée sur une interpolation. D'autre part, la tâche de maintenance permet de supprimer automatiquement les données qui dépassent un certain âge.

Le système de traitement du Pandora FMS ne stocke que les “nouvelles” données: si une valeur dupliquée entre dans le système, elle ne sera pas stockée dans la base de données. Ceci est très utile pour réduire la taille de la base de données et fonctionne pour tous les types de modules du Pandora FMS (numérique, incrémentiel, booléen et chaîne de texte).

Ces modifications impliquent des changements importants lors de la lecture et de l'interprétation des données. Dans les dernières versions de Pandora FMS, le moteur graphique a été entièrement repensé afin de pouvoir représenter rapidement les données avec le nouveau modèle de stockage des données.

Les mécanismes de compactage ont également certaines implications lors de la lecture et de l'interprétation graphique des données: Il existe actuellement un menu de configuration graphique qui permet d'ajouter des percentiles, des données en temps réel, des événements et/ou des alertes, ainsi que d'autres options.

En outre, Pandora FMS permet la désintégration totale des composants, de sorte que la charge de traitement des fichiers de données et l'exécution des modules de réseau dans différents serveurs peuvent être équilibrées.

Tout au long des mises à jour du logiciel, des améliorations ont été apportées au modèle relationnel de la base de données de Pandora FMS. L'un des changements introduits a consisté à indexer les informations en fonction des différents types de modules. De cette manière, Pandora FMS peut accéder beaucoup plus rapidement aux informations, car elles sont réparties dans différentes tables.

Le partitionnement des tables (par horodatage) est possible pour améliorer encore les performances de l'accès aux données historiques.

En outre, des facteurs tels que la représentation numérique des horodatages (format UNIX _timestamp_) accélèrent les recherches de plages de dates, les comparaisons de dates, etc. Ces travaux ont permis d'améliorer considérablement les temps de recherche et les insertions.

Pour éviter de surcharger la base de données, le serveur effectue une simple compression du temps d'insertion. Une donnée n'est pas stockée dans la base de données à moins qu'elle ne soit différente de la précédente ou qu'il y ait une différence de plus de 24 heures entre les deux.

Par exemple, en supposant un intervalle d'environ une heure, la séquence 0,1,0,0,0,0,0,0,0,0,1,1,0,0,0 est stockée dans la base de données sous la forme 0,1,0,1,1,0. Un autre 0 consécutif ne sera stocké que si 24 heures se sont écoulées.

La compression affecte grandement les algorithmes de traitement des données, qu'il s'agisse de métriques ou de graphiques, et il est important de garder à l'esprit que les “lacunes” causées par la compression doivent être comblées.

Compte tenu de tout ce qui précède, pour effectuer des calculs avec les données d'un module donné un intervalle et une date initiale, il faut suivre les étapes suivantes :

• Recherche des données précédentes, en dehors de l'intervalle et de la date donnés. Si elles existent, ramenez-les au début de l'intervalle. Si elle n'existait pas auparavant, il n'y aurait pas de données.
• Recherche de la donnée suivante, à partir de l'intervalle et de la date donnés jusqu'à un maximum égal à l'intervalle du module. Si elle existe, elle doit être ramenée à la fin de l'intervalle. Si elle n'existe pas, la dernière valeur disponible doit être prolongée jusqu'à la fin de l'intervalle.
• Toutes les données sont parcourues, en tenant compte du fait qu'une donnée est valide jusqu'à ce qu'une autre donnée soit reçue.

Pandora FMS a inclus un système pour compacter l'information dans la base de données. Ce système est destiné aux scénarios de petite et moyenne taille (de 250 à 500 agents et moins de 100.000 modules) qui souhaitent disposer d'un historique d'informations étendu mais sans perdre de détails.

La maintenance de la base de données Pandora FMS qui est exécutée toutes les heures, et entre autres tâches de nettoyage, permet de faire un compactage des anciennes données. Ce compactage utilise une interpolation simple et linéaire, puisqu'il s'agit d'une interpolation, ce qui fait que cette information perd des détails, mais elle sera toujours suffisamment informative pour la génération de rapports et de graphiques mensuels, annuels, etc.

Dans les grandes bases de données, ce comportement peut être très coûteux en termes de performances et doit être désactivé; il est recommandé d'opter pour le modèle base de données historique.

La configuration par défaut du Pandora FMS ne transfère pas de données de type string à la base de données d'historique, mais si cette configuration a été modifiée et que la base de données d'historique reçoit ce type d'informations il est essentiel de configurer sa purge, sinon elle finira par occuper trop de place, ce qui causera de gros problèmes et aura un impact négatif sur les performances.

Pour configurer ce paramètre, une requête de base de données doit être exécutée directement pour déterminer les jours après lesquels ces informations seront purgées. La table en question est tconfig et le champ string_purge. Pour définir 30 jours pour la purge de ce type d'information, la requête suivante serait exécutée directement sur la base de données historique:

UPDATE tconfig SET VALUE = 30 WHERE token = "string_purge";

La base de données est maintenue par un script appelé pandora_db.pl, pour vérifier que la maintenance de la base de données se déroule correctement, vous devez exécuter le script de maintenance script manuellement:

/usr/share/pandora_server/util/pandora_db.pl /etc/pandora/pandora_server.conf

Il ne devrait pas signaler d'erreurs. Si une autre instance utilise la base de données, vous pouvez utiliser l'option -f qui force l'exécution ; avec le paramètre -p, elle n'effectue pas le compactage des données. Ceci est particulièrement utile dans les environnements Haute Disponibilité (HA) avec une base de données historique, car le script s'assure d'exécuter dans un ordre et un mode corrects les étapes nécessaires pour ces composants.

• D'une part, chaque module a dans sa configuration des seuils Avertissement (WARNING) et Critique (CRITICAL).
  • Ces seuils définissent les valeurs de vos données pour lesquelles ces états seront activés.
  • Si le module fournit des données en dehors de ces seuils, il est considéré comme étant en état Normal (NORMAL).

• Chaque module dispose également d'un intervalle de temps qui définit la fréquence de collecte des données.
  • Cet intervalle sera pris en compte par la console pour collecter les données.
  • Si le module n'a pas collecté de données pendant deux fois son intervalle, il est considéré comme étant dans l'état Inconnu (UNKNOWN).

• Enfin, si le module a configuré des alertes et que l'une d'entre elles a été déclenchée et n'a pas été validée, le module aura le statut correspondant de Alerte déclenchée.

Dans l'organisation du Pandora FMS, certains éléments dépendent d'autres, comme c'est le cas des modules d'un agent ou des agents d'un groupe. Cela peut également s'appliquer au cas des politiques du Pandora FMS, qui ont associé certains agents et certains modules qui sont considérés comme associés à chaque agent.

Une telle structure est particulièrement utile pour évaluer les états des modules en un coup d'œil. Pour ce faire, les états sont propagés vers le haut de cette organisation, ce qui permet de donner un statut aux agents, aux groupes et aux politiques.

Un agent sera représenté avec le état le plus critique des états de ses modules. À son tour, un groupe présentera l'état le plus critique des agents qui lui appartiennent, et il en va de même pour les politiques, qui présenteront l'état le plus critique des agents qui leur sont assignés.

Ainsi, quand on voit un groupe avec un état critique, par exemple, on sait qu'au moins un de ses agents a le même état. Pour le localiser, il faut descendre d'un autre niveau, celui des agents, afin de resserrer le cercle et trouver le ou les modules à l'origine de la propagation de cet état critique.

Au fur et à mesure que l'état le plus critique des états est propagé, il doit être clair que les états ont la priorité sur les autres:

1. Alertes déclenchées.
2. État critique.
3. Statut d'alerte.
4. Statut inconnu.
5. Statut normal.

Lorsqu'un module a déclenché des alertes, son statut est prioritaire sur tous les autres, et l'agent auquel il appartient aura ce statut, et le groupe auquel cet agent appartient, à son tour, aura également ce statut.

D'autre part, pour qu'un groupe, par exemple, ait un statut normal, tous ses agents doivent avoir un statut normal, ce qui signifie que tous les modules de ces groupes auront un statut normal.

État des alertes déclenchées.

Statut critique.

Statut d'alerte.

Statut inconnu.

Statut normal.

Les graphiques sont l'une des applications les plus complexes du Pandora FMS; ils extraient des données en temps réel de la base de données et aucun système externe (RRDtool ou similaire) n'est utilisé.

Il existe plusieurs comportements des graphiques en fonction du type de données source:

• Modules asynchrones. On suppose qu'il n'y a pas de compactage des données. Les données dans la base de données sont toutes des échantillons réels des données, il n'y a pas de compactage. Produit des graphiques beaucoup plus “précis”, sans possibilité d'erreur d'interprétation.
• Modules de type chaîne de texte. Afficher des graphiques du taux de données en fonction du temps.
• Modules de données numériques. La plupart des modules rapportent ce type de données.
• Modules de données booléennes. Correspondent aux données numériques des moniteurs, PROC : par exemple, vérifications Ping, état de l'interface, etc. La valeur 0 correspond à l'état critique et la valeur 1 à l'état “normal”.

Retour à l'index de la documentation du Pandora FMS