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.

Pandora FMS dispose d'un système de gestion des arrêts de service planifiés ou programmés dans menu Management → Alerts → Scheduled downtime. Ce système permet de désactiver les alertes dans les intervalles d'arrêt de service.

Les alertes sont composées de :

• Commandes : Ils précisentce 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écisentla manière dont cela doit être fait; ce sont les personnalisations des arguments de commande.
• Modèles : Ils précisentle 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écialetoken. _html_editor_ .

• eMail: Envoie un e-mail depuis le Serveur Pandora FMS. Les messages électroniques sont envoyés au format HTML. Il faut garder à l'esprit que le destinataire doit pouvoir accéder aux ressources utilisées dans le modèle, comme par exemple les images.
• Internal audit: Génère une entrée dans le système d'audit interne de Pandora FMS. Cela est stocké dans la base de données de Pandora FMS et peut être consulté avec le visualiseur d'événements depuis la console.
• Monitoring Event: Crée un événement personnalisé dans la console des événements de Pandora FMS.
• Alertlog: Une alerte prédéfinie qui écrit les alertes en format ASCII brut dans le fichier /var/log/pandora/pandora_alert.log.
• SNMP Trap: Envoie un trap SNMP avec les paramètres utilisés.
• Syslog: Envoie une alerte au journal système à l'aide de la commande système logger.
• Sound Alert: Joue un son sur la console sonore des événements lorsque l'alerte se déclenche.
• Jabber Alert: Envoie une alerte Jabber vers une salle de discussion sur un serveur prédéfini (le fichier .sendxmpprc doit être configuré au préalable). Placez l'alias de l'utilisateur dans field1, le nom de la salle de discussion dans field2 et le message texte dans field3.
• SMS Text: Envoie un SMS à un téléphone mobile spécifique. Il est nécessaire de définir une alerte et de configurer une passerelle SMS accessible depuis le Serveur Pandora FMS.
• Validate Event: Valide tous les événements liés à un module. Il faut passer le nom de l'agent et le nom du module.
• Remote agent control: Envoie des commandes aux agents avec le serveur UDP activé. Le serveur UDP est utilisé pour ordonner aux agents (MS Windows® et UNIX®) de rafraîchir l'exécution de l'agent : c'est-à-dire pour forcer l'agent à exécuter et envoyer des données.
• Generate Notification: Permet d'envoyer une notification interne à tout utilisateur. Les destinataires doivent être ajoutés manuellement et chaque utilisateur supprimera sa notification lorsqu'il pourra et/ou jugera approprié.
• Send report by e-mail et Send report by e-mail (from template): Les deux options permettent d'envoyer un rapport dans différents formats (PDF, JSON, CSV) par e-mail. La deuxième option permet d'utiliser un modèle pour le rapport attaché.

• Console notification: Permet d'envoyer une notification via la Console Web à tout utilisateur. Les destinataires disponibles seront ajoutés de manière interactive. Les notifications apparaîtront et disparaîtront en fonction de l'alerte correspondante déclenchée ou récupérée. De plus, les messages seront définitivement supprimés en fonction du token Max. days before delete old messages. Des macros préconfigurées afficheront des informations sur l'agent, le module, etc. Assurez-vous que le destinataire dispose de droits de lecture suffisants sur les éléments alertés.
• API request: Effectue une requête API via une action d'alerte basée sur cette commande. Les paramètres suivants sont nécessaires dans cet ordre :

1. URL: Adresse IP ou lien web vers le serveur API où la requête sera effectuée.
2. Method: Méthode à utiliser, parmi une liste d'options (GET, POST, PUT, PATCH, DELETE), similaires à celles utilisées par la API PFMS (sauf PATCH).
3. Headers: Pour inclure le format de la demande (généralement en format JSON), le token d'autorisation, etc.
4. Data: La requête elle-même et ses paramètres respectifs.
5. SSL: Indique si une connexion sécurisée sera utilisée pour la connexion.

Une requête typique inclut un code similaire à celui-ci :

• HEADER:

Authorization: Bearer abc123token; Content-Type: application/json; X-Request-ID: 123456

• DATA:

{'title': 'foo', 'body': 'bar'}

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éfinircomment 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 queAll, seul le groupe associé à la commande ou le groupeAll 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.

• Console notification : Cette commande vous permet de générer une notification au superviseur lorsqu'une alerte est déclenchée. Elle utilise la commande d'alerte prédéfinieConsole notification. En modifiant cette action prédéfinie, vous pouvez sélectionner les utilisateurs qui seront notifiés.
• Create Pandora ITSM ticket : Une fois l'intégration avec Pandora ITSM activée, vous pourrez créer automatiquement des incidents dans cette application.
• Mail to Admin : Utilisez la commande prédéfinie eMail pour envoyer un message électronique tel que configuré dans le champ Destination address.
• Monitoring Event : Utilisez la commande du même nom et vous pourrez configurer les types et la gravité (déclenchement et récupération) des événements, entre autres détails.
• Pandora ilert, Pandora Slack, Pandora Telegram, Pandora Vonage : Pandora FMS peut envoyer des notifications, après configuration, dans plusieurs applications de messagerie instantanée.
• Restart agent : Permet d'envoyer des instructions (redémarrer par défaut) selon la commande Remote agent control aux EndPoints PFMS.
• Send Report by e-mail et Send Report by e-mail (from template) : Pour l'envoi de rapports par courrier électronique. Vous pouvez ici configurer les destinataires, le rapport en tant que tel (ou modèle) et son format (PDF, JSON ou CSV).

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 exécuter l'action). Ils sont associés à des modules, de sorte que lorsque 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 peuvent être utilisés dans la plupart des cas possibles dans Pandora FMS.

Menu Management → Alerts → Templates → Create.

Suivez ensuite les trois étapes guidées.

• 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.

• 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 consécutif, autrement le compteur sera redémarre.

• Si le jeton de redémarrage 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:

• 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 champsfield 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.

Les modèles créés par défaut sont:

1. Critical condition : Configuré avec une gravité critique, un type de condition de état critique, avec l'action par défaut d'envoyer un courriel à l'administrateur et avec la récupération des alertes activée.
2. Manual alert : Il s'agit d'un modèle utilisé pour déclencher des alertes manuelles, la condition définie ici ne sera jamais exécutée. Ce modèle est utilisé pour mapper les actions et les commandes utilisées pour la gestion à distance (redémarrage de l'EndPoint, exécution de commandes sur le serveur, etc.)
3. Warning condition : Configuré avec une gravité d'avertissement, un type de condition de état d'avertissement, avec une action par défaut d'envoi d'un courriel à l'administrateur et avec une récupération d'alerte activée.
4. Unknown condition : Configuré avec une gravité d'avertissement, un type de condition dans un état inconnu, avec une action par défaut envoyant un message électronique à l'administrateur et avec une récupération d'alerte activée.
5. Default critical condition : Les quatre modèles précédents peuvent être personnalisés. Ce modèle est en lecture seule (modèle système) et est une copie du modèle Critical condition. Il est inclus en raison de l'importance de l'état critique.

Menu Management → Alerts → Module 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. Ce seuil a priorité sur la configuration du seuil d'action.

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 +.

A partir de la version 781, l'action par défaut n'est affichée que s'il s'agit de la seule action existante.

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 surstandby.
• 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 situation se produit, par exemple, lorsqu'un élément 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 sans être un valoration correcte.

Pour que l'agent fonctionne avec la protection en cascade activée, l'agent parent doit être correctement configuré (Advanced options, jeton 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.

La protection en cascade basée sur le service empêche les éléments d'un service de déclencher leurs alertes si l'alerte du service auquel ils appartiennent est déclenchée.

Pour activer cette fonctionnalité, le token Cascade protection services doit être activé dans la configuration avancée des agents pour lesquels ce comportement est requis, et activer token Cascade protection enabled dans la configuration du service auquel ces agents appartiennent.

Lorsque l'alerte de service est déclenchée, des informations sur les éléments du service qui sont critiques peuvent être envoyées dans l'alerte avec la macro _rca_ indiquant la cause première de l'état du service.

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érend plate-formes d'email. Une fois ces deux mécanismes mis en place, vous pourrez configurer l'action d'envoi et créer votre alerte.

Menu Management → Alerts → Event Alerts.

Des alertes peuvent être créées sur la base des événements reçus. Ces alertes peuvent être simples ou complexes, basées sur un ensemble de règles avec des relations logiques.

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

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

Menu Management → Alerts → Event Alerts.

Le bouton Create permet d'ajouter une nouvelle alerte événementielle et le processus est similaire à la création d'un modèle d'alerte. La création complète d'une alerte événementielle comporte cinq étapes, dont certaines sont importantes:

• Paso 1, Configure : Il contient les données de base telles que le nom, le groupe d'agents auquel appartient l'alerte et sa gravité.
• Paso 2, Conditions : Étape où un modèle d'alerte, une liste de jours spéciaux, l'option modèle d'alerte, l'option Disable event (l'événement généré dans la vue d'événement du déclencheur d'alerte ne sera pas créé si ce token) et un mode d'évaluation de la règle sont cochés:

Lorsqu'il existe deux alertes d'événement ou plus, elles sont évaluées une par une en suivant l'ordre chronologique de leur création et, si nécessaire, en établissant une hiérarchie.

Chaque alerte événementielle dispose à cet effet de deux paramètres de configuration spécifiques:

• Rule evaluation mode : Il peut être Pass ou Drop. La première signifie que, si un événement est conforme aux règles d'une alerte, les autres alertes sont encore évaluées par la suite. Il s'agit du comportement par défaut. Drop, sinon, cela signifie que lorsqu'un événement répond à une alerte, toutes les autres alertes cessent d'être évaluées.
• Grouped by : Permet de regrouper les règles par Agent, Groupe, Module ou Module Alert. Ainsi, si une règle est configurée pour être déclenchée 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.

• Paso 3, Rules : Règles au sein d'une alerte d'événement.
• Paso 4, Fields : Champs d'une alerte d'événement
• Paso 5, Triggering : Déclenché dans le cadre d'une alerte événementielle.

Lorsque vous terminez la création et que vous revenez à la vue globale, vous obtenez la liste des alertes d'événements enregistrées et des informations les concernant, ainsi que des options les concernant (fonctionnement avec l'action désactivée, en mode standby, ajout d'autres actions, modification ou suppression de l'alerte d'événement correspondante). Il sera également possible de modifier l'ordre des différentes alertes d'événements les unes par rapport aux autres.

Les alertes d'événements sont basées sur des règles de filtrage utilisant les opérateurs logiques suivants :

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

Ces opérateurs logiques sont utilisés pour rechercher des événements et/ou des expressions qui correspondent aux règles de filtrage configurées et, si des correspondances sont trouvées, 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 de journal.

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

Obliga a que el elemento analizado (log) cumpla simultáneamente A y B.

Force 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 satisfaisant les deux règles dans les dernières secondes (définies par le paramètre log_window).

Il faut configurer Field2, Field3, (…) , Fieldn, qui sont utilisés pour transférer l'information de template à action et de l'action à command, pour être finalement utilisés comme paramètres dans l'exécution de cette commande.

Ces informations sont transférées à condition que l'étape suivante ne contienne pas déjà des informations définies dans ses champs Fieldn. En d'autres termes, en cas de chevauchement des champs ou des paramètres, l'action est remplacée par le modèle (par exemple, si le modèle a un Field1 et une action définis, le Field1 de l'action écrase l'action du modèle).

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 : Action qui doit être exécutée.
• Threshold : Intervalle de temps qui doit s'écouler avant que l'action ne soit exécutée à nouveau après le déclenchement de l'alarme.

Une fois que les paramètres ci-dessus ont été sélectionnés, appuyez sur le bouton Add et vous pouvez alors choisir et visualiser la liste des actions configurées (section Select the desired action and mode to view the Triggering fields for this action).

Les macros qui peuvent être utilisées dans la configuration d'une alerte d'événement sont énumérées dans la liste des macros.

Menu Management → Alerts → Log Alerts.

Des alertes peuvent être créées sur la base des journaux reçus. Ces alertes peuvent être simples ou complexes, basées sur un ensemble de règles avec des relations logiques.

Ce type d'alertes permet de travailler dans une perspective beaucoup plus souple, car les alertes ne sont pas générées sur la base de l'état d'un module spécifique, mais sur la base d'un journal qui peut avoir été généré par plusieurs modules différents et même par différents agents.

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

Menu Management → Alerts → Log Alerts.

Le bouton Create permet d'ajouter une nouvelle alerte et le processus est similaire à la création d'un modèle d'alerte. La création complète d'une alerte de journal se fait en cinq étapes, dont voici quelques aspects importants:

• Étape 1, Configure : Il contient les données de base telles que le groupe d'agents auquel l'alerte appartient, le nom de l'alerte et sa gravité.
• Étape 2, Conditions : Étape où un modèle d'alerte, une liste de jours spéciaux sera attribuée, l'option Disable event (l'événement généré dans la vue de l'événement du déclencheur d'alerte ne sera pas créé si ce jeton est coché) et un mode d'évaluation des règles :

Lorsqu'il existe deux alertes ou plus, elles sont évaluées une par une en suivant l'ordre chronologique de leur création et, si nécessaire, en établissant une hiérarchie.

Chaque alerte dispose de deux paramètres de configuration spécifiques à cet effet:

• Rule evaluation mode : Le choix de Pass signifie que, dans le cas où un journal répond aux règles d'une alerte, toutes les autres alertes de journaux sont encore évaluées par la suite. Il s'agit du comportement par défaut. Si vous choisissez Drop, lorsqu'un journal répond à une alerte, toutes les autres alertes du journal ne sont pas évaluées.
• Grouped by : Permet de regrouper les règles par Agent, Groupe, Module ou Module Alert. Ainsi, si une règle est configurée pour être déclenchée 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.

• Étape 3, Rules : Règles au sein d'une alerte de journal.
• Étape 4, Fields : Champs d'une alerte de journal
• Étape 5, Triggering : Déclenché dans un journal d'alerte.

Lorsque vous terminez la création et que vous revenez à la vue globale, vous obtenez la liste des alertes enregistrées et des informations les concernant, ainsi que des options les concernant (fonctionnement avec l'action désactivée, en mode standby, ajout d'autres actions, modification ou suppression de l'alerte correspondante). Il sera également possible de modifier l'ordre des différentes alertes.

Les alertes d'événements sont basées sur des règles de filtrage utilisant les opérateurs logiques suivants:

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

Ces opérateurs logiques sont utilisés pour rechercher les enregistrements et/ou les expressions qui correspondent aux règles de filtrage configurées et, si des correspondances sont trouvées, 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 de journal.

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

Elle oblige l'élément analysé (log) à remplir simultanément les conditions A et B.

Force 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 satisfaisant les deux règles dans les dernières secondes (définies par le paramètre log_window).

Il faut configurer Field2, Field3, (…) , Fieldn, qui sont utilisés pour transférer l'information de template à action et de l'action à command, pour être finalement utilisés comme paramètres dans l'exécution de cette commande.

Ces informations sont transférées à condition que l'étape suivante ne contienne pas déjà des informations définies dans ses champs Fieldn. En d'autres termes, en cas de chevauchement des champs ou des paramètres, l'action est remplacée par le modèle (Par exemple, si le modèle a un Field1 et une action définis, le Field1 de l'action écrase l'action du modèle).

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 : Action qui doit être exécutée.
• Threshold : Intervalle de temps qui doit s'écouler pour que l'action soit à nouveau exécutée après le déclenchement de l'alarme.

Une fois que vous avez sélectionné les paramètres ci-dessus, appuyez sur le bouton Add et vous pouvez alors choisir et afficher la liste des actions configurées (section Select the desired action and mode to view the Triggering fields for this action).

Les macros qui peuvent être utilisées dans la configuration d'une alerte d'événement sont énumérées dans la liste des macros.

Ces alertes sont évaluées par le serveur d'événements SIEM au moment de leur génération, donc pour leur bon fonctionnement, la supervision SIEM doit être activé et configuré.

Menu Management → Alerts → SIEM Alerts.

Dans cette section, il est possible de créer, modifier et supprimer des alertes SIEM. L'autorisation LW est requise pour accéder à cette section.

Ces alertes sont basées sur le système de filtrage des vues d'événements SIEM, de sorte que tout événement affiché avec les conditions de filtrage configurées déclenche l'alerte.

Par exemple, si une alerte SIEM est configurée avec un filtre d'événement critique, l'alerte sera déclenchée juste avant que le serveur d'événements SIEM n'en génère un avec cette condition.

Les alertes SIEM, comme toutes les autres alertes, disposent d'options de configuration globale pour leur déclenchement.

Menu Operation → SIEM → Alerts.

Dans cette section, il est possible de visualiser, d'activer/désactiver et de modifier le modestandby des alertes SIEM disponibles dans l'environnement. L'autorisation LM est requise pour accéder à cette section.

Les macros de commande, les macros d'action et les macros d'alerte d'événement sont similaires, à quelques exceptions près, précisées dans chaque description:

Note :

Pour la macro _prevdata_, il est nécessaire de décommenter la section suivante dans le fichier de configuration de Pandora FMS Server:

# 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.

Retour à l'index de la documentation de Pandora FMS