Système d'alerte

Une alerte est la réaction de Pandora FMS à une valeur incorrecte d'un module. Cette réaction est configurable et peut consister en tout ce qui peut être déclenché par un script configuré dans le Système d'Exploitation où tourne le serveur Pandora FMS qui traite le module.

Il existe plusieurs types d'alertes :

• Les alertes simples.
• Les alertes événements.
• Les alertes trap SNMP.

Dans ce chapitre, nous allons traiter le système d'alerte dans son ensemble et parler en détail des premiers.

Les alertes sont composées de :

• Commandes : Ils précisent ce qui sera fait ; il s'agit de l'exécution que le serveur Pandora FMS effectuera lorsque l'alerte sera déclenchée.
• Les actions : Ils précisent la manière dont cela doit être fait ; ce sont les personnalisations des arguments de commande.
• Modèles : Ils précisent le moment où cela sera fait ; ils définissent les conditions de déclenchement de la (des) action(s).

Lors de la configuration des modèles et des actions, les deux ont une série de champs génériques appelés Field1, Field2, Field3, … Fieldn qui sont utilisés pour transférer les informations depuis le modèle à l'action et depuis l'action jusqu'à la commande pour finalement être utilisés comme des paramètres dans l'exécution de ladite commande.

Ces informations sont tranferts pendant que l'echélon suivante n'aie pas des informations définies dans ses châms Fieldn. C'est à dire, en cas de chevauchement de châmps ou paramètres, il superpose l'action au modèle (par exemple, si le modèle a Field1 défini et l'action aussi, le Field1 de l'action prévaut).

Menu Management → Alerts → Commands.

Les actions que Pandora FMS effectuera en cas de situations d'alerte seront traduites à la fin en exécutions dans le serveur, sous forme de commandes.

Menu Management → Alerts → Commands → Create.

• Command : Commande à exécuter lorsque l'alerte est déclenchée. Il est possible d'utiliser macros pour remplacer les paramètres configurés dans la déclaration d'alerte.
• Group : Cela détermine le groupe d'alerte auquel vous pouvez associer la commande. Vous ne pouvez attribuer qu'un groupe auquel appartient l'utilisateur qui crée la commande d'alerte, à moins que cet utilisateur n'appartienne explicitement au groupe TOUS (ALL).
• Field description et Field values :
  • Valeurs disponibles pour le champ : L'ensemble des valeurs possibles pour ce champ. Si ce champ est configuré (non vide), il s'agira d'une liste déroulante au lieu d'une zone de texte. Pour chaque valeur possible, la liste déroulante doit comporter une étiquette (l'option visible) et une valeur (l'option envoyée). La syntaxe est la suivante : valeur1,étiquette1;valeur2,étiquette2;valeur3,étiquette3;valeurN,étiquetteN.
  • Hide : Si le champ contient un mot de passe, cette option masque le contenu par des astérisques.
• Il est possible d'afficher un éditeur de code HTML dans un champ de commande lors de la création ou de la modification d'une action d'une alerte si ce champ de commande possède la valeur spéciale token. _html_editor_ .

Il existe une série de commandes prédéfinies prêtes à être utilisées dans le système d'alerte Pandora FMS.

• eMail : Envoyez un courriel à partir du serveur Pandora FMS. Les emails sont envoyés au format HTML, ce qui vous permet de créer des modèles visuellement très attractifs. N'oubliez pas que le destinataire doit pouvoir accéder aux ressources utilisées dans le modèle, comme les images.
• Internal audit : Génèrez une entrée dans le système d'audit interne de Pandora FMS. Ceci est stocké dans la base de données Pandora FMS et peut être consulté à l'aide du visualiseur d'événements de la console.
• Monitoring Event : Créez un événement personnalisé dans la console d'événements Pandora FMS.
• Pandora FMS Alertlog : C'est une alerte prédéfinie qui écrit les alertes en ASCII simple dans le fichier journal /var/log/pandora/pandora_alert.log.
• SNMP Trap : Il envoie un trap SNMP paramétré avec les arguments utilisés.
• Syslog : Envoyez une alerte au journal système, utilisez la commande système logger.
• Sound Alert : Il réproduit un son de la console sonore d'événements lorsqu'une alerte se produit.
• Jabber Alert : Il envoie une alerte jabber à un salle de discussion sur un serveur prédéfini (configurez d'abord le fichier .sendxmpprc). Mettez dans le field1 l'alias de l'utilisateur, dans le field2 le nom de la salle de chat et dans le field3 le message textuel.
• SMS Text : Il envoie un SMS vers un certain téléphone mobile, bien sûr, vous devez définir une alerte avant de rendre cela possible et une passerelle pour envoyer des SMS configurée et accessible depuis le serveur Pandora FMS. Vous pouvez également en installer un en utilisant Gnokii pour envoyer des SMS, directement en utilisant un téléphone Nokia avec un câble USB. Le processus est décrit ci-dessous.
• Validate Event : Il valide tous les événements liés à un module. Le nom de l'agent et le nom du module lui seront transmis.
• Remote agent control : Il envoie des commandes aux agents dont le serveur UDP est activé. Le serveur UDP est utilisé pour commander aux agents (Windows et UNIX) de rafraîchir l'exécution de l'agent : c'est-à-dire de forcer l'agent à s'exécuter et à envoyer des données.
• Generate notification : Il permet d'envoyer une notification interne à n'importe quel utilisateur ou groupe.
• Send report by e-mail et Send report by e-mail (from template) : Les deux options vous permettent d'envoyer un rapport dans différents formats (XML, PDF, JSON, CSV) par courrier électronique. La seconde option vous permet d'utiliser un modèle pour un tel rapport en pièce jointe.

Menu Management → Alerts → Commands → cliquez sur le nom de la commande à éditer. Une fois l'alerte choisie modifiée, cliquez sur Update.

Les actions sont les composants des alertes dans lesquelles une commande est liée aux variables génériques Field 1, Field 2, …, Field 10.

Les actions nous permettent de définir comment nous allons lancer la commande.

Menu Management → Alerts → Actions → Create.

• Group : Le groupe de l'action. Vous ne pouvez assigner qu'un groupe auquel appartient l'utilisateur qui crée la commande d'alerte, à moins que cet utilisateur n'appartienne explicitement au groupe TOUS (ALL). Si la commande associée a un groupe autre que All, seul le groupe associé à la commande ou le groupe All peut être défini comme groupe de l'action. Si, pour une raison ou une autre, ce groupe est différent, un message d'avertissement s'affiche afin qu'un utilisateur disposant des droits nécessaires corrige rapidement la situation.
• Command : Commande à utiliser en cas d'exécution de l'alerte. Vous pouvez choisir parmi les différentes commandes prédéfinies dans Pandora FMS.
• Threshold : Une action d'alerte n'est exécutée qu'une seule fois au cours de cet intervalle de temps, quel que soit le nombre de déclenchements de l'alerte.
• Command Preview : Dans ce champ, non modifiable, la commande à exécuter sur le système apparaîtra automatiquement.
• Field 1 ~ Field 10 : Si nécessaire, ces champs définissent la valeur des macros, de _field1_ à _field10_, à utiliser dans la commande. Ces champs peuvent être des champs de texte ou des listes déroulantes si elles sont configurées.

Menu Management → Alerts → Actions → cliquez sur le nom de l'action à modifier.

Menu Management → Alerts → Actions → cliquer sur l'icône de l'emplacement correspondant (colonne Delete).

Les modèles définissent les conditions de déclenchement de l'alerte (quand pour exécuter l'action). Les modèles d'alerte sont associés aux modules, de sorte que dès que les conditions du modèle sont remplies, la ou les actions associées sont exécutées.

Sa conception permet de générer un groupe réduit de modèles génériques qui sont utiles pour la plupart des cas possibles dans Pandora FMS.

Menu Management → Alerts → Templates → Create.

Suivez ensuite les trois étapes guidées.

Étape 1 : Généralités

• Group : Le groupe auquel le modèle sera appliqué. Vous ne pouvez assigner qu'un groupe auquel appartient l'utilisateur qui crée le modèle, à moins que cet utilisateur n'appartienne explicitement au groupe TOUS (ALL).
• Priority : Champ d'information sur l'alerte. L'événement généré lors du déclenchement de l'alerte héritera de cette priorité, ce qui est utile pour le filtrage dans les recherches d'alertes.

Étape 2 : Conditions

• Use special days list : Il définit le calendrier des jours spéciaux à utiliser dans le modèle.
• Time Threshold : Le temps qui doit s'écouler avant la remise à zéro du compteur d'alertes. Il définit l'intervalle de temps pendant lequel il est garanti qu'une alerte ne sera pas déclenchée plus d'une fois que le nombre de fois défini dans la section Max. number of alerts. Après l'intervalle défini, le compteur est remis à zéro. La réinitialisation du compteur de déclenchement n'est pas relancée si le signalement est récupéré après réception d'une valeur positive, sauf si l'option Reset counter for non-sustained alerts est activée, auquel cas le compteur est réinitialisé immédiatement après réception d'une valeur positive.
• Min number of alerts : Nombre minimum de fois que la situation définie dans le modèle doit se produire (toujours en comptant à partir du nombre défini dans le paramètre Flip Flop du module) pour commencer à déclencher une alerte. La valeur par défaut est 0, ce qui signifie que l'alerte sera déclenchée lorsque la première valeur répondant à la condition arrivera. Il fonctionne comme un filtre, utile pour ignorer les faux positifs.
• Max number of alerts : Nombre maximal d'alertes pouvant être envoyées consécutivement dans le même intervalle de temps (Time Threshold). Il s'agit de la valeur maximale du compteur d'alertes. Il n'y aura pas plus d'alertes par intervalle de temps que ce qui est indiqué dans ce champ.
• Default Action : Dans cette liste, vous définissez l'action par défaut du modèle. Il s'agit de l'action qui sera créée automatiquement lorsque vous attribuerez le modèle au module. Entrez une action ou aucune, mais vous ne pouvez pas entrer plusieurs actions par défaut.
• Schedule : Définir les jours où l'alerte peut être déclenchée. Il est possible de visualiser et de configurer quand l'alerte sera active chaque jour de la semaine grâce à l'éditeur intégré qui s'affiche par défaut en mode simple. De plus, en accédant au mode détaillé, vous pouvez configurer les horaires de manière plus précise.
• Reset counter for non-sustained alerts : Son activation dépend du numéro indiqué dans Min. number of alerts étant supérieur à 0. L'activation de ce jeton remet à zéro le compteur d'alertes lorsque aucune condition n'est répétée consécutivement. Par exemple, si le champ Min. number of alerts a une valeur de 2, cela signifie que le module doit passer 3 fois par l'état assigné dans Condition type pour déclencher l'alerte. Il y a deux scénarios possibles avec ce dernier jeton :
• Si le jeton de redémarrage est marqué, il sera nécessaire que le nombre d'états critiques soit consecutif, autrement le compteur sera rédémarré.

• Si le jeton de rédermarrage n'est pas marqué, l'alerte sera déclenchée après une séquence alternative ou continue des états critiques :

• Disable event : En cochant ce token, l'événement généré dans la vue d'événement du déclencheur d'alerte ne sera pas créé.
• Condition type : Il permet de spécifier l'élément qui déclenchera l'alerte, par exemple un état critique. (Critical estatus) ou est simplement différent de l'état normal (Not normal status). Des alertes complexes peuvent également être mises en place (Complex alerts), par exemple, la somme est exactement égale à deux au cours des trente derniers jours :

Étape 3: Champs avancés

• Alert recovery : Combo dans lequel vous pouvez définir si la récupération des alertes doit être activée ou non. Dans le cas où la récupération des alertes est activée, lorsque le module cesse de remplir les conditions indiquées par le modèle, l'action associée aux arguments spécifiés par les champs field définis dans cette colonne sera exécutée.
• Dans toutes les instances des champs field1 … field10 (dans le modèle d'alerte, dans la commande et dans l'action), vous pouvez utiliser ceux définis dans la liste des macros.

Une fois la configuration terminée, finaliser en cliquant sur le bouton Finish.

Menu Management → Alerts → List of alerts → cliquez sur l'icône du crayon Builder alert.

• Agent : Autocomplete pour choisir l'agent.
• Module : Liste des modules de l'agent sélectionné précédemment.
• Actions : Action à exécuter lorsque l'alerte est déclenchée. Si le modèle possède déjà une action par défaut, celle-ci peut être laissée à la valeur Default.
• Template : Modèle contenant les conditions de déclenchement de l'alerte.
• Threshold : Une action d'alerte ne doit pas être exécutée plus d'une fois toutes les secondes du action_threshold, quel que soit le nombre de déclenchements de l'alerte.

Une fois le signalement créé, il ne sera possible de modifier que les actions qui ont été ajoutées à l'action dans le modèle.

Il est également possible de supprimer l'action sélectionnée lors de la création du signalement en cliquant sur l'icône de la corbeille grise à droite de l'action, ou d'ajouter de nouvelles actions en cliquant sur le bouton +.

Dans la section d'administration des agents, vous pouvez ajouter de nouvelles alertes en naviguant vers l'onglet correspondant :

Vous y trouverez les informations suivantes :

• Modifier ou supprimer chaque action pour chaque alerte attribuée à l'agent (colonne Actions).
• Dans la colonne des options (Op.) :

• Vous pouvez le désactiver ou l'activer.
• Vous pouvez régler l'alerte sur standby .
• Vous pourrez ajouter une action.
• Vous pouvez supprimer complètement l'alerte.
• Vous pourrez alors consulter l'alerte en détail.

• Définir les seuils critiques et d'alerte dans le module.
• Pour associer l'alerte au module, allez dans l'onglet Alertes de l'agent où se trouve le module.

Si nécessaire, vous pouvez créer une nouvelle action et/ou nouveau template, en cliquant sur ces boutons vous serez redirigé vers les sections correspondantes. Une fois que vous avez créé le(s) nouveau(x) composant(s), revenez à l'étape précédente.

• Le bouton Add alert enregistre le nouveau signalement.
• Alert escalation : Une escalade d'alerte est une action supplémentaire qui est exécutée si l'alerte est répétée un certain nombre de fois consécutivement.
  • Il vous suffit d'ajouter les actions supplémentaires et de déterminer entre quelles répétitions consécutives (Number of matching alerts) de l'alerte vous allez exécuter cette action.
  • Lorsqu'une alerte est récupérée, toutes les actions qui ont été exécutées jusqu'à ce moment-là sont réexécutées, et pas seulement celles qui correspondent à la configuration Number of alerts match from en cours.
  • En outre, un Threshold peut être défini comme deuxième paramètre, de sorte qu'une alerte ne peut être déclenchée plus d'une fois pendant cet intervalle.
• Enfin, il est possible de configurer l'envoi de messages d'alerte via une messagerie instantanée telle que Telegram, par exemple.

Les alertes peuvent être activées, désactivées ou en veille. La différence entre les alertes désactivées et les alertes de veille est que les alertes désactivées ne fonctionneront tout simplement pas et ne seront donc pas affichées dans la vue d'alerte. Les alertes de veille, par contre, seront affichées dans la vue Alertes et ne fonctionneront qu'au niveau de la vue. En d'autres termes, il sera montré s'ils sont déclenchés ou non, mais ils n'exécuteront pas les actions qu'ils ont programmées ni généreront d'événements.

Les alertes de veille sont utiles pour pouvoir les visualiser sans les perturber sur d'autres aspects.

La protection en cascade est une fonction de Pandora FMS qui permet d'éviter un bombardement massif d'alertes lorsqu'un groupe d'agents n'est pas accessible en raison d'une défaillance de la connexion principale.

Ce genre de chose se produit, par exemple, lorsqu'un élément de réseau intermédiaire tel qu'un routeur ou un switch tombe en panne et laisse une grande partie du réseau géré par Pandora FMS inaccessible. Comme les vérifications du réseau échouent dans ce scénario, les alertes concernant les appareils hors service commencent à se déclencher non vrai.

Pour que l'agent fonctionne avec la protection en cascade activée, l'agent parent doit être correctement configuré (Advanced options, token Parent), dont il dépend.

La protection en cascade est activée à partir de la configuration de l'agent, section Advanced options, cliquez sur l'option Cascade protection modules et/ou Cascade protection services.

Il est possible d'utiliser les Services pour éviter que des alertes provenant de plusieurs sources ne signalent le même problème.

Si la protection en cascade basée sur le Service est activée, les éléments du service (agents, modules ou autres services) ne signaleront pas les problèmes, mais le service lui-même alertera au nom de l'élément affecté.

Pour recevoir ces informations, vous devez modifier ou créer un nouveau modèle d'alerte, en utilisant la macro _rca_ pour un analyse des causes profondes (root cause analysis).

L'état d'un module d'un agent parent peut être utilisé pour éviter les alertes d'agent au cas où le module de l'agent parent devienne critique.

Le mode de fonctionnement sécurisé peut être activé dans les options de configuration avancées d'un agent.

Si l'état du module sélectionné devient critical, les autres modules de l'agent sont désactivés jusqu'à ce qu'il revienne à normal ou warning. Cela permet, par exemple, de désactiver les modules distants en cas de perte de connectivité.

Ces macros spécifiques peuvent être ajoutées en développant la section macro de n'importe quel module.

• Ils sont définis dans le module.
• Ils stockent les données dans la base de données.
• Ils peuvent porter n'importe quel nom, par exemple _myMacro.
• Non reflété dans la configuration locale (.conf).
• Utilisé exclusivement pour les alertes.
• Ils ne peuvent pas être définis au niveau des composants.
• Ils peuvent être définis dans les politiques de supervision.
• Les valeurs définies peuvent être utilisées dans les champs de la définition de l'alerte.

Pandora FMS lui même a la capabilité d'envoyer des emails comme expliqué dans la configuration générale de la Console.

Cependant sa flexibilité permet l'envoi des emails avec des différens plate-formes d'email.

Pour que le serveur Pandora FMS puisse envoyer des alertes via la messagerie du compte Google Mail® (Gmail®), passez à la section configuration générale de la console ou à la configuration du serveur Pandora FMS et entrez vos données d'identification (domaine web, noms d'utilisateur, mot de passe, etc.).

Paramètres d'action

• Une action est ajoutée, par exemple avec le nom Mail to Admin.
• Pour configurer le destinataire du courrier, la commande eMail est utilisée en ajoutant les destinataires dans le Destination address Field 1 séparés par des virgules.

Paramètres d'alerte

Dans la configuration du module, onglet Alertes, une nouvelle alerte est créée avec l'action créée.

Pandora FMS peut utiliser Office365® par le biais de la configuration suivante :

• Vous devez avoir une compte sur Office365.
• Allez vers la configuration générale de la Console ou vers la configuration du serveur Pandora FMS et entrez vos identifiants (domaine web Office365, noms d'utilisateur, mot de passe, etc).

Avec Pandora FMS vous pouvez créer des alertes basées sur les événements reçus ou sur les logs collectés avec le système de collecte de journaux. Vous pouvez créer des alertes simples ou plus complexes, basées sur un ensemble de règles avec des relations logiques. Cette fonctionnalité remplace la précédente des alertes d'événements.

Ce type d'alertes permet de travailler dans une perspective beaucoup plus flexible, car les alertes ne sont pas générées en fonction de l'état d'un module spécifique, mais d'un événement qui peut avoir été généré par plusieurs modules différents, depuis différents agents.

Les alertes d'événements/journaux sont basées sur des règles de filtrage qui utilisent des opérateurs logiques :

• and
• or
• xor
• nand
• nor
• nxor

Ils recherchent les événements/expressions dans les journaux qui correspondent aux règles de filtrage configurées, et si des correspondances sont trouvées, l'alerte sera déclenchée.

Ils utilisent également des modèles pour définir certains paramètres, tels que les jours pendant lesquels l'alerte fonctionnera ; cependant, dans ce cas, les modèles ne déterminent pas quand l'alerte d'événement est déclenchée, mais c'est à travers les règles de filtrage qu'ils rechercheront et déclencheront les alertes des événements correspondants.

Il est recommandé d'utiliser un nouvel éditeur de règles, ce qui permet de construire les règles de manière visuelle. Pendant un certain temps, vous pourrez continuer à utiliser l'ancien éditeur d'alertes d'événements.

Menu Management → Alerts → Alert correlation.

Dans cette vue globale, vous trouverez la liste des alertes de corrélation enregistrées et des informations les concernant, ainsi que des options telles que le fonctionnement avec l'action désactivée, en mode standby, l'ajout d'autres actions, la modification ou la suppression de l'alerte corrélée.

Le bouton Create permet d'ajouter une nouvelle alerte de corrélation. Le processus est similaire à la création d'une alerte de type Alert Templates. Les paramètres de configuration des modèles d'alerte de corrélation sont similaires à ceux d'une alerte de module, il n'y a que deux paramètres spécifiques aux alertes d'événements :

• Rule evaluation mode : Il peut s'agir de Pass ou Drop. La première signifie que, si un événement coïncide avec une alerte, les autres alertes sont toujours évaluées. L'option Drop signifie que si un événement correspond à une alerte, toutes les autres alertes ne sont pas évaluées.
• Group by : Il permet de regrouper les règles par agent, module, alerte ou groupe. Par exemple, si une règle est configurée pour se déclencher lorsque deux événements critiques sont reçus et qu'elle est groupée par agent, deux événements critiques doivent arriver du même agent. Elle peut être désactivée.

Chaque règle est configurée pour se déclencher sur un certain type d'événement ou match de log ; lorsque l'équation logique définie par les règles et leurs opérateurs est satisfaite, l'alerte est déclenchée.

Pour définir les règles de l'alerte, vous devrez faire glisser les éléments de gauche vers la drop area de droite afin de construire votre règle.

Éléments de configuration disponibles :

Ces éléments permettront de guider l'utilisateur dans le respect de la grammaire de la règle. Voici une explication simplifiée de la grammaire à utiliser :

Où S est l'ensemble des règles définies pour l'alerte corrélée.

Il faudra faire glisser l'élément sur la zone de définition de la règle, de manière à ce que l'image ressemble à ceci par exemple :

Deux boutons permettent d'effacer et d'annuler toutes les modifications : Cleanup et Reset.

Il oblige l'élément analysé (événement ou journal) à remplir simultanément les conditions A et B.

Il oblige les deux règles (A) et (B) à être satisfaites dans la fenêtre d'évaluation. Cela signifie qu'il doit y avoir des entrées dans les dernières secondes (définies par les paramètres log_window et event_window) qui satisfont les deux règles.

Dans la séction précédente Système d'alertes on explique avec plus de détail le fonctionnement des champs des alertes.

Dans cette section, vous devez configurer les actions à entreprendre lorsque l'alerte est déclenchée et indiquer à quels intervalles et à quelle fréquence l'action sera exécutée.

• Actions : Mesures à prendre.
• Number of alerts match : Nombre d'intervalles qui doivent s'écouler depuis le déclenchement de l'alerte pour que l'action soit exécutée. Si vous souhaitez que l'action soit toujours exécutée, laissez ces champs vides.
• Threshold : Intervalle qui doit s'écouler avant que l'action ne soit exécutée à nouveau après le déclenchement de l'alarme.

Affichez ensuite la liste des actions configurées. Dans cette liste, le champ Triggering indique à quels intervalles de l'alerte l'action sera exécutée, comme configuré dans Number of alerts match. En outre, dans la colonne Options, vous pouvez supprimer ou modifier les actions configurées.

Lorsque vous avez plusieurs alertes, elles ont un ordre d'évaluation spécifique. Elles seront toujours évaluées dans l'ordre, en commençant par la première de la liste.

Si le mode d'évaluation des règles PASS est configuré, si une alerte corrélée est exécutée, les alertes suivantes seront également évaluées. Il s'agit du mode normal.

Si le mode d'évaluation des règles DROP est configuré, si une alerte corrélée configurée avec ce mode est exécutée, l'évaluation des règles qui lui sont inférieures sera interrompue. Cette fonctionnalité permet de protéger les alertes en cascade.

Les autres règles de corrélation (champs d'action et application des actions) fonctionnent de la même manière que les autres alertes de Pandora FMS.

Les macros qui peuvent être utilisées dans la configuration d'une alerte d'événement se trouvent dans la section liste de macros.

Les Macros de commandes, Macros d'actions et Macros d'alerte d’événement sont communes entre eux mais avec les exceptions suivantes : _modulelaststatuschange_, _rca_ et _secondarygroups_

_address_

Adresse de l'agent qui a déclenché l'alerte.

_addressn_n_

L'adresse de l'agent qui correspond à la position indiquée dans « n ». Exemple : addressn_1_, addressn_2_.

_agent_

Alias de l'agent qui a déclenché l'alerte. Si aucun alias n'est attribué, le nom de l'agent est utilisé.

_agentalias_

Alias de l'agent qui a lancé l'alerte.

_agentcustomfield_n_

Numéro de champ personnalisé n de l'agent (ex. _agentcustomfield_9_).

_agentcustomid_

ID d'agent personnalisé.

_agentdescription_

Description de l'agent qui a déclenché l'alerte.

_agentgroup_

Nom du groupe d'agents.

_agentname_

Nom de l'agent qui a déclenché l'alerte.

_agentos_

Système d'exploitation de l'agent.

_agentstatus_ État actuel de l'agent.

_alert_critical_instructions_

Instructions contenues dans le module pour un état critical.

_alert_description_

Description de l'alerte.

_alert_name_

Nom de l'alerte.

_alert_priority_

Priorité numérique de l'alerte.

_alert_text_severity_

Priorité dans le texte d'alerte (Maintenance, Informatif, Normal Minor, Avertissement, Majeure, Critique).

_alert_threshold_

Seuil d'alerte.

_alert_times_fired_

Nombre de fois où l'alerte a été déclenchée.

_alert_unknown_instructions_

Instructions contenues dans le module pour un état unknown.

_alert_warning_instructions_

Instructions contenues dans le module pour un état warning.

_all_address_

Toutes les adresses de l'agent qui a déclenché l'alerte.

_critical_threshold_min_

Seuil critique minimal.

_critical_threshold_max_

Seuil critique maximal.

_data_

Données qui ont déclenché l'alerte.

_dataunit_

Il affiche le type d'unité spécifié dans le champ Unit (situé dans la section Advanced options du module d'un agent).

_email_tag_

Emails associés aux tags du module.

_event_cf_text_

(Alertes événementielles uniquement). Éditer toutes les données personnalisées en mode texte (avec des sauts de ligne).

_event_cf_json_

(Alertes événementielles uniquement). Il extrait les informations des données personnalisées au format JSON.

_event_cfX_

(Uniquement les alertes d'événements). Clé du champ personnalisé de l'événement qui a déclenché l'alerte. Par exemple, s'il existe un champ personnalisé dont la clé est IPAM, sa valeur peut être obtenue en utilisant la macro _event_cfIPAM_.

_event_description_

(Alertes d'événements uniquement). Description textuelle de l'événement Pandora FMS.

_event_extra_id_

(Uniquement les alertes d'événements). Extra Id.

_event_id_

(Uniquement les alertes d'événements). Id de l'événement qui a déclenché l'alerte.

_event_text_severity_

(Alertes événements uniquement). Priorité dans le texte de l'événement qui déclenche l'alerte (Maintenance, Informational, Normal Minor, Warning, Major, Critical).

_eventTimestamp_

Timestamp dans lequel l'événement a été créé.

_fieldX_

Champ C défini par l'utilisateur.

_group_contact_

Coordonnées du groupe. Il est configuré lors de la création du groupe.

_groupcustomid_

ID de groupe personnalisé.

_groupother_

Autres informations sur le groupe. Il est configuré lors de la création du groupe.

_homeurl_

C'est un lien de l'URL publique qui doit être configuré dans les options générales de la configuration.

_id_agent_

Agent ID, utile pour construire l'URL d'accès à la console Pandora FMS.

_id_alert_

Alert ID, utile pour exécuter l'alerte dans des outils tiers.

_id_group_

ID du groupe d'agents.

_id_module_

ID module.

_interval_

Intervalle d'exécution du module.

_module_

Nom du module.

_modulecustomid_

ID personnalisé du module.

_moduledata_X_

En utilisant cette macro (« X » est le nom du module en question) on collecte les dernières données de ce module et s'il est numérique, on le retourne formaté avec les décimales spécifiées dans la configuration de la console et avec son unité (si elle le possède). Il serait utile, par exemple, lors de l'envoi d'un e-mail lors du saut d'une alerte de module, envoyer également des informations supplémentaires (et peut-être très pertinentes) à partir d'autres modules du même agent.

_moduledescription_

Description du module.

_modulegraph_nh_

(Uniquement pour les alertes qui utilisent la commande eMail). Il retourne une image codée en base64 d'un graphique de module avec une période de n heures (ex._modulegraph_24h_). Il nécessite une configuration correcte de la connexion du serveur à la console via API, ce qui se fait dans le fichier de configuration du serveur.

_modulegraphth_nh_

(Uniquement pour les alertes qui utilisent la commande _email_tag_). La même opération que la macro précédente mais seulement avec les seuils critiques et d'alerte du module, au cas où ils seraient définis.

_modulegroup_

Nom du groupe de modules.

_modulestatus_ État du module.

_modulelaststatuschange_

(Macros de commande uniquement) timestamp à laquelle s'est produit le dernier changement d'état du module.

_moduletags_

URLs associées aux balises de module.

_name_tag_

Nom des balises associées au module.

_phone_tag_

Téléphones associés aux tags de module.

_plugin_parameters_

Paramètres du module plugin.

_policy_

Nom de la politique à laquelle le module appartient (si applicable).

_prevdata_

Données antérieures avant le déclenchement de l'alerte. Il est nécessaire de décommenter la section suivante dans le fichier de configuration du serveur Pandora FMS :

# Default texts for some events. The macros _module_ and _data_ are supported.
text_going_down_normal Module '_module_' is going to NORMAL (_data_) with previous data (_prevdata_)
#text_going_up_critical Module '_module_' is going to CRITICAL (_data_)
#text_going_up_warning Module '_module_' is going to WARNING (_data_)
#text_going_down_warning Module '_module_' is going to WARNING (_data_)
#text_going_unknown Module '_module_' is going to UNKNOWN

Le processus du serveur doit être redémarré pour que les nouvelles modifications soient appliquées.

_rca_

Chaîne d'analyse des causes profondes (uniquement pour les services).

_secondarygroups_

Il affiche les sous-groupes de l'agent (uniquement pour les macros de commande et d'action).

_server_ip_

IP du serveur auquel l'agent est affecté.

_server_name_

Nom du serveur auquel l'agent est affecté.

_target_ip_

Adresse IP de la cible du module.

_target_port_

Port cible du module.

_timestamp_

Heure et date du déclenchement de l'alerte.

_time_down_human_

Heure au format long, par exemple « 1day 10h 35m 40s » (cette macro ne fonctionne que pour les alertes de récupération).

_time_down_seconds_

Temps en secondes (cette macro ne fonctionne que pour les alertes de récupération).

_timezone_

Fuseau horaire représenté dans _timestamp_.

_warning_threshold_max_

Seuil d'alerte maximum.

_warning_threshold_min_

Seuil d'alerte minimum.

Retour à l'index de documentation du Pandora FMS