Pandora: Documentation fr: Alertes

From Pandora FMS Wiki
Jump to: navigation, search

Revenir à l’Index de Documentation Pandora FMS

Contents

1 Configuration des alertes sur Pandora FMS

1.1 Introduction

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 et les alertes pièges SNMP. Dans ce chapitre, nous allons traiter le système d'alerte dans son ensemble et parler en détail des premiers.

== Introduction au système d'alerte ==

Dans Pandora FMS, les alertes fonctionnent par la définition de certaines conditions déclenchées, de certaines actions choisies pour cette alerte, et enfin l'exécution de certaines commandes dans le serveur Pandora FMS, qui seront chargées d'exécuter les actions configurées.

Le système d'alerte générale associe une seule alerte pour chaque module, cette alerte peut effectuer une ou plusieurs actions.

1.1.1 Structure d'une alerte


Esquema-alert-structure.png


Les alertes sont composées de :

  • Commandes' : Spécifiez ce qui sera fait ; ce sera l'exécution que le serveur Pandora FMS fera lors du déclenchement de l'alerte. Il peut s'agir d'écrire dans un log, d'envoyer un mail ou un SMS, d'exécuter un script, etc.
  • Les actions : Spécifiez comment cela se fera, sont les personnalisations des arguments de la commande, permettent de personnaliser l'exécution en tant que telle, en passant à la commande des paramètres particuliers comme le nom du module, de l'agent, etc.
  • Modèles : Spécifiez quand, définissez les conditions pour déclencher l'action ou les actions. Par exemple : lorsque le module passe à l'état critique.

1.1.2 Flux d'informations dans le système d'alerte

Lors de la configuration des modèles et des actions, les deux ont une série de "'champs génériques'" appelés Champ1, Champ2, Champ3, etc. qui sont utilisés pour personnaliser le déclenchement de l'alerte.

Ces champs sont appliqués selon un ordre de priorité, "transfert" de l'information depuis le modèle -> action -> commande, pour finalement être utilisés comme paramètres dans l'exécution de cette commande.


L'ordre de préséance est :

Modèle < Action < Commande


Où la valeur du champ remplace le contenu spécifié dans le calque ci-dessus :

Alert precedence.png



Si un modèle a du contenu dans le champ Champ1, si l'action " non " a du contenu dans son champ Champ1, il héritera du contenu du champ1 du modèle. Cependant, si l'action a déjà son propre contenu (précédemment configuré lors de la création de l'action) dans son champ Champ1, elle prévaudra sur celle qui transfère le modèle. Ainsi suivant la succession d'actions modèle -> Action -> Commande ->, les informations seront transférées du premier au deuxième et du deuxième au troisième à condition que l'étape suivante n'apporte pas déjà des informations définies dans ses champs Champ1, Champ2, Champ3.....

Dans le diagramme suivant, vous pouvez voir ce transfert de paramètres du modèle à la commande :


Esquema-parameters-carrying.png


Il s'agirait d'un exemple de la façon dont les valeurs de schéma type sont écrasées à l'aide des valeurs déclenchant l'action.

Alertas esquema6.png


Par exemple, nous créons un modèle qui déclenche l'alerte et envoie un e-mail avec les champs suivants :

  • Modèle :
    • Field1: [email protected]
    • Field2: [Alert] The alert was fired
    • Field3: The alert was fired!!! SOS!!!

Les valeurs qui atteindraient la commande seraient :

  • Commande :
    • Field1: [email protected]
    • Field2: [Alert] The alert was fired
    • Field3: The alert was fired!!! SOS!!!

Pour les champs Field2 et Field3, les valeurs définies dans le modèle sont conservées, mais pour le champ Champ 1, il utilise la valeur définie dans l'action.

1.2 Commande d'alerte

1.2.1 Introduction

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


Susi2.png

1.2.2 Création d'une commande pour une alerte

Le formulaire nous demandera quelques informations descriptives sur la commande :


Susi3 5.png

Les champs sont détaillés ci-dessous :


Name Le nom du Commandement. Il doit être bref et descriptif.


Command Commande qui sera exécutée lorsque l'alerte sera déclenchée. Il est possible d'utiliser des macros pour remplacer les paramètres configurés dans la déclaration d'alerte. Les macros qui peuvent être utilisées sont détaillées ci-dessous dans une section spécifique.

Lors de la création des commandes pour les alertes, il est nécessaire de prendre en compte que ces commandes sont exécutées par le serveur Pandora FMS. Les alertes sont également exécutées avec les privilèges de l'utilisateur qui exécute le serveur Pandora FMS.

Lors de la définition d'une commande, il convient de prouver, à partir de la ligne de commande, que l'exécution de la commande est réussie et qu'elle produit le résultat souhaité (envoyer un e-mail, générer une entrée dans un fichier journal, etc.)

Group

Groupe de commandement. Ceci déterminera à quelles alertes la commande peut être associée.

Description

Longue description de la commande d'alerte à titre d'information.


Description des champs et des valeurs possibles.

Pour chaque champ, il est possible de configurer :

  • Description : Ce sera l'étiquette à côté de la zone de texte dans le formulaire de configuration de l'action qui utilise cette commande.
  • Valeurs possibles : Un ensemble de valeurs possibles pour ce champ.

Si ce champ est configuré (non vide), le champ sera une liste déroulante de sélection au lieu d'une zone de texte. Le combo a besoin pour chaque valeur possible d'une étiquette (l'option visible) et d'une valeur (l'option envoyée).

La syntaxe est la suivante :

valeur1,étiquette1;valeur2,étiquette2;valeur3,étiquette3,étiquette3


Par exemple :

Un champ simple où il sera possible de choisir entre les quatre premiers chiffres :

1,Numéro un;2,Numéro deux;3,Numéro trois;4,Numéro quatre



Possible values 1.png





Possible values 2.png



Info.png

A partir de la version 6.0, il sera possible d'afficher un éditeur HTML dans un champ de commande lors de la création ou de la modification d'une action d'alerte si ce champ de commande a pour valeur le conteneur spécial _html_editor_

 


  • Cacher : Cette case doit être cochée lorsque vous voulez masquer ou masquer la valeur du champ. Cette option sera utilisée dans le cas où le champ stocke un mot de passe.


Une fois créé, cliquez sur Create.

1.2.2.1 Commandes macros

Les macros qui peuvent être utilisées dans la configuration d'une commande sont :


  • _adress_ : Adresse de l'agent qui a déclenché l'alerte.
  • _address_n_ : L'adresse de l'agent qui correspond à la position indiquée en "n". Exemple : adresse_1_, adresse_2_, adresse_2_.
  • _agent_ :Alias de l'agent qui a lancé l'alerte. Si aucun alias n'est attribué, le nom de l'agent est utilisé.
  • _agentalias_ : Alias de l'agent qui a tiré l'alerte.
  • _agentcustomfield_n_: Champ personnalisé n numéro de l'agent (ex. _agentcustomfield_9_).
  • _agentcustomfield_n_ : 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 lancé 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 CRITIQUE.
  • _alert_description_: Description du signalement.
  • _alert_name_ : Nom de l'alerte.
  • _alert_priority_:Priorité numérique de l'alerte.
  • Alerte_text_severity_: Priorité dans le texte de l'alerte (Maintenance, Informatif, Mineur normal, Avertissement, Majeur, Critique).
  • _alert_threshold_: Seuil d'alerte : Seuil d'alerte.
  • _alert_times_fired_ :Nombre de fois que l'alerte a été déclenchée.
  • _alert_unknown_instructions_: Instructions contenues dans le module pour un état INCONNU.
  • _alert_unknown_instructions_ : Instructions contenues dans le module pour un état AVERTISSEMENT.
  • _all_address_  : Toutes les adresses de l'agent qui a déclenché l'alerte.
  • _data_ : Données qui ont déclenché l'alerte.
  • _email_tag_: Emails associés aux balises du module.
  • _event_cfX_: (Alertes d'événement uniquement) 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énement seulement) Description textuelle de l'événement Pandora FMS.
  • _event_extra_id_  : (Alertes d'événements uniquement) Id extra.
  • _event_id_ : (Uniquement les alertes d'événements) Id de l'événement qui a déclenché l'alerte.
  • _event_text_severity_ : Priorité dans le texte de l'événement qui déclenche l'alerte (Maintenance, Informative, Mineure normale, Mineure normale, Avertissement, Majeure, Critique).
  • _eventTimestamp_: Horodatage dans lequel l'événement a été créé.
  • _fieldX_ : Champ C défini par l'utilisateur.
  • _groupcontact_: 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_: Ceci est un lien vers l'URL publique qui doit être configuré dans les options générales de configuration.
  • _id_agent_: ID de l'agent, utile pour construire l'URL d'accès à la console Pandora FMS.
  • _id_alert_ : ID de l'alerte, utile pour corréler l'alerte dans des outils tiers.
  • _id_group_ : ID de groupe d'agents.
  • _id_module_: ID module.
  • _interval_ : Intervalle d'exécution du module.
  • _module_ : Nom du module.
  • _modulecustomid_ : ID module personnalisé.
  • _moduledata_X_: En utilisant cette macro ("X" est le nom du module en question) nous collectons les dernières données de ce module et s'il est numérique il retourne les données formatées avec les décimales spécifiées dans la configuration de la console et avec son unité (s'il en dispose). 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) Retourne une image codée 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) Même opération que la macro précédente mais seulement avec les seuils critiques et d'alerte du module, s'ils sont définis.
  • _modulegroup_: Nom du groupe de modules.
  • _modulestatus_: Statut 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 balises de module.
  • _plugin_parameters_ : Paramètres du module plugin.
  • _policy_: Nom de la politique à laquelle le module appartient (le cas échéant).
  • _prevdata_ : Données antérieures avant le déclenchement de l'alerte.
  • _rca_ : Chaîne d'analyse de cause racine (uniquement pour les services).
  • _secondarygroups_: Affiche les groupes secondaires de l'agent.
  • _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.
  • _timezone_: Heure et date du déclenchement de l'alerte.
  • Fuseau horaire représenté dans _timestamp_.

1.2.3 Edition d'une commande pour une alerte

A partir de Command dans le menuAlerts, il est possible d'éditer les commandes d'alerte qui ont été créées.

Susi2.png

Pour modifier la commande d'une alerte, il suffit de cliquer sur le nom de la commande.


Susi6 5.png


Une fois que l'alerte sélectionnée a été modifiée, cliquez sur le bouton Mettre à jour.

Template warning.png

Les commandes eMail,Audit Interne etEvénement Pandora FMS' ne peuvent pas être modifiées.

 


1.2.4 Opération d'une commande d'alerte

Susi7.png

Supprimé : Pour supprimer une alerte, cliquez sur la corbeille grise à droite de l'alerte.

"'Copié"' : Les alertes peuvent être copiées. Il est particulièrement utile de générer des commandes similaires à d'autres commandes existantes en modifiant certains détails tels qu'un champ ou un groupe.


Les alertes "eMail", "Internal Audit" et "Monitoring Event" ne peuvent pas être supprimées ou copiées.

1.2.5 Commandes prédéfinies

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. Utilisez Perl sendmail. Pandora FMS fonctionne avec les propres outils du système pour exécuter presque toutes les alertes, il sera nécessaire de valider que le paquet libmail-sendmail-perl xprobe2 est installé dans votre système.

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ère 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.

Pandora FMS 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

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

Lecture d'un son lorsqu'une alerte se produit.

Jabber Alert

Envoie une alerte jabber à un salon de discussion sur un serveur prédéfini (configurez d'abord le fichier.sendxmpprc). Dans le champ3 se trouve le message texte, dans le champ1 l'alias de l'utilisateur, et dans le champ2 le nom de la salle de chat.

SMS Text

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

Valide tous les événements liés à un module. Le nom de l'agent et le nom du module lui seront transmis.

1.2.6 Exemples de commandes

1.2.6.1 Envoie d'alertes avec Jabber

Il est très utile de configurer Pandora FMS pour envoyer des alertes à un serveur Jabber qui peut être un système d'alerte en temps réel qui reste aussi historique et qui permet de les recevoir à un groupe de personnes simultanément.

1.2.6.1.1 Installation des services Jabber

Du côté du client :

  1. Installez un client Jabber, par exemple Gaim (maintenant Pidgin).
  2. Enregistrer un compte (en Pidgin : créez un compte en cliquant sur le bouton d'enregistrement du compte).
  3. Connectez-vous avec le compte.

Dans la partie serveur de Pandora FMS :

  1. Installer sendxmpp. Avec cet outil, vous pouvez envoyer des messages Jabber.
  2. Créez un fichier dans le répertoire /home avec le nom .sendxmpprc.
  3. Modifiez le fichier et entrez ce qui suit :
    [email protected] password
  1. Donnez les permissions au fichier :
 chmod 0600 .sendxmpprc

Les messages privés peuvent maintenant être envoyés via la ligne de commande, par exemple :

$ echo "Hello" | sendxmpp -s pandora [email protected] 

Pour enregistrer l'alerte dans la console Pandora FMS, une nouvelle commande est ajoutée, et les variables de la commande sont configurées de la manière la plus pratique. C'est une bonne idée de procéder comme suit :

  • Field_1 : adresse jabber.
  • Field_2 : Envoyer du texte.

L'alerte serait donc définie comme suit :

  echo _field2_ | sendxmpp -s pandora _field1__
1.2.6.1.2 D'autres exemples d'utilisation avec Jabber

Envoyer à un tchat :

  $ echo "Dinner Time" | sendxmpp -r TheCook --chatroom [email protected]

Envoyez les lignes d'enregistrement telles qu'elles apparaissent à une destination Jabber :

$ tail -f /var/log/syslog | sendxmpp -i [email protected]

REMARQUE : Veillez à ne pas surcharger les serveurs Jabber publics, sinon ils vous couperont l'accès.

1.2.6.2 Envoi d'email avec expect

Parfois, vous avez besoin d'utiliser un SMTP authentifié pour envoyer des e-mails. Il est probablement plus facile et plus polyvalent d'utiliser un simple script EXPECT au lieu de configurer sendmail pour utiliser un SMTP authentifié. Il s'agit d'un exemple utilisant EXPECT pour envoyer des courriels à l'aide d'un serveur Exchange.

Un fichier appelé /etc/snmp est créé avec le contenu suivant :

#!/usr/bin/expect -f
set arg1 [lindex $argv 0] 
set arg2 [lindex $argv 1]
set arg3 [lindex $argv 2]
set timeout 1 
spawn telnet myserver.com 25 
expect "220"
send "ehlo mymachine.mydomain.com\r"
expect "250"
send "AUTH login\r"
expect "334"
send "2342348werhkwjernsdf78sdf3w4rwe32wer=\r"
expect "334"
send "YRejewrhneruT==\r"
expect "235"
send "MAIL FROM: [email protected]\r"
expect "Sender OK"
send "RCPT TO: $arg1\r"
expect "250"
send "data\r"
expect "354"
send "Subject: $arg2\r"
send "$arg3 \r\r"
send ".\r"
expect "delivery"
send "quit"
quit

Les permissions des fichiers sont modifiées pour permettre leur exécution.

chmod 700 /root/smtp 

Avant d'essayer de l'utiliser, assurez-vous que /usr/bin/expect fonctionne correctement.

Pour l'utiliser avec Pandora FMS, vous devrez créer une nouvelle commande (ou modifier celle existante pour envoyer des alertes par e-mail) et spécifier les champs suivants dans la définition de la commande Alerte Pandora FMS, dans le champ "Command" sera écrit :

/root/smtp _field1_ _field2_ _field3_

Bien sûr, le script peut se trouver n'importe où dans le système. Il suffit de prendre en compte que le script d'alerte est lancé par le serveur qui traite les données : s'il s'agit d'une donnée réseau, ce sera le serveur réseau, s'il s'agit d'une donnée provenant d'un agent, via un fichier XML, alors ce sera le serveur de données qui le lance.

Si vous avez des serveurs physiques différents, vous devrez peut-être copier le même script au même endroit, avec les mêmes permissions et le même propriétaire d'utilisateur dans tous les systèmes où vous avez un serveur Pandora FMS qui veut exécuter cette alerte. Gardez également à l'esprit que les serveurs réseau Pandora FMS doivent être exécutés en tant que root (pour pouvoir faire des tests de latence ICMP) et que les serveurs de données peuvent être exécutés avec un utilisateur sans privilèges.

L'alerte sera exécutée par l'utilisateur qui exécute le processus du serveur Pandora FMS.

1.2.6.3 Envoi de SMS avec Gnokii

Pour utiliser Gnokii, il est nécessaire d'utiliser un téléphone portable compatible Nokia ou Gnokii (vérifiez le matériel compatible sur la page du projet Gnokii). Vous aurez également besoin d'un câble de données USB auquel vous devrez connecter le téléphone portable et le serveur Pandora FMS sur lequel vous souhaitez envoyer des alertes SMS.

Gnokii supporte une grande variété de téléphones Nokia (et certains d'autres fabricants).

Avec Gnokii, vous pouvez envoyer des SMS depuis la ligne de commande. De cette façon, il est très facile et rapide d'envoyer des SMS directement à partir d'un serveur Pandora FMS, évitant l'utilisation de passerelles pour envoyer des SMS sur Internet (peu utiles en cas de panne du réseau) ou de solutions matérielles GSM très coûteuses pour envoyer des messages.

Une autre alternative à l'utilisation de Gnokii est le projet Gammu.

Exemple d'envoi d'un SMS avec Gnokii depuis une ligne de commande :

echo "PANDORA: Server XXXX is down at XXXXX" | gnokii --sendsms 555123123

Gnokii ne peut pas envoyer de MMS avec des images jointes, mais il peut envoyer une URL HTTP/WAP à afficher lors de la réception d'un message, par exemple :

echo "Image capture sample" | gnokii --sendsms 555123123 -w http://artica.homelinux.com/capture.jpg

Vous pouvez envoyer une URL à partir d'une image, ou une URL qui mène à une version allégée de la console pour accéder à la console à partir de l'appareil mobile et analyser les données.

L'équipe de développement a testé l'envoi de SMS à partir d'un téléphone Nokia 6030, envoyant des alertes SMS lorsque la connexion Internet était inaccessible. Le Nokia 6030 utilise la définition du module 6510 dans le fichier gnokiirc, et prend environ quatre secondes pour envoyer un SMS.

Une passerelle d'envoi plus puissante peut être implémentée en utilisant Gammu.

1.2.6.4 Exécution d'une commande distante dans un autre système (UNIX)

Parfois il est intéressant d'exécuter une commande dans un autre système, pour cela la commande ssh est utilisée. Le système sur lequel la commande sera exécutée doit être UNIX et avoir le démon ssh installé, monté et accessible.

Afin d'éviter d'avoir le mot de passe d'accès à la machine qui a exécuté la commande dans Pandora Console, la première chose à faire est de copier la clé publique du serveur où vous voulez exécuter la commande à distance dans Pandora FMS serveur.

Une fois que cela a été fait, nous devons le définir comme une commande :

ssh [email protected] [_field1_]

En mettant _field1_ comme variable, vous pouvez utiliser la commande que vous voulez.

1.3 Action

1.3.1 Introduction

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.


1.3.2 Création d'une action

De nouvelles actions sont créées en cliquant sur le bouton "Create" sous Action dans le menu Alerts.


Accion1.jpg

Une fois que vous avez cliqué sur Créer, le formulaire suivant apparaîtra :


Accion2.jpg

Les champs à remplir sont détaillés ci-dessous :

Une fois les champs remplis, cliquez sur Create.


Boton1.jpg

A partir de Actions dans le menu Alerts, il est possible de modifier les actions qui ont été créées.

1.3.2.1 Macros d'actions

Les macros qui peuvent être utilisées dans la configuration d'une action sont :


  • _address_: Adresse de l'agent qui a déclenché l'alerte.
  • _address_n_ : L'adresse de l'agent qui correspond à la position indiquée en "n". Exemple : adresse_1_, adresse_2_, adresse_2_.
  • _agent_ : Alias de l'agent qui a lancé l'alerte. Si aucun alias n'est attribué, le nom de l'agent est utilisé.
  • _agentalias_ : Alias de l'agent qui a tiré l'alerte.
  • _agentcustomfield_n_: Champ personnalisé n numéro 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 lancé 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 CRITIQUE.
  • _alert_description_: Description du signalement.
  • _alert_name_ : Nom de l'alerte.
  • _alert_priority_ : Priorité numérique de l'alerte.
  • Alerte_text_severity_: Priorité dans le texte de l'alerte (Maintenance, Informatif, Mineur normal, Avertissement, Majeur, Critique).
  • _alert_threshold_ : Seuil d'alerte.
  • _alert_times_fired_ : Nombre de fois que l'alerte a été déclenchée.
  • _alert_unknown_instructions_: Instructions contenues dans le module pour un état INCONNU.
  • _alert_warning_instructions_: Instructions contenues dans le module pour un état AVERTISSEMENT.
  • _all_address_  : Toutes les adresses de l'agent qui a déclenché l'alerte.
  • _data_ : Données qui ont déclenché l'alerte.
  • _email_tag_: Emails associés aux balises du module.
  • _event_cfX_: (Alertes d'événement uniquement) 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énement seulement) Description textuelle de l'événement Pandora FMS.
  • _event_extra_id_ : (Alertes d'événements uniquement) Id extra.
  • _event_id_: (Uniquement les alertes d'événements) Id de l'événement qui a déclenché l'alerte.
  • _event_text_severity_: (alertes d'événements uniquement)Priorité dans le texte de l'événement qui déclenche l'alerte (Maintenance, Informative, Mineure normale, Mineure normale, Avertissement, Majeure, Critique).
  • _eventTimestamp_: Horodatage dans lequel l'événement a été créé.
  • _fieldX_: Champ C défini par l'utilisateur.
  • _groupcontact_: Coordonnées du groupe. Il est configuré lors de la création du groupe.
  • _groupother_: ID de groupe personnalisé.
  • Autres informations sur le groupe. Il est configuré lors de la création du groupe.
  • _homeurl_: Ceci est un lien vers l'URL publique qui doit être configuré dans les options générales de configuration.
  • _id_agent_: Agent ID, utile pour construire l'URL d'accès à la console Pandora FMS.
  • _id_alert_ : ID de l'alerte, utile pour corréler l'alerte dans des outils tiers.
  • _id_group_ : ID de groupe d'agents.
  • _id_module_: ID module.
  • _interval_: Intervalle d'exécution du module.
  • _module_: Nom du module.
  • _modulecustomid_: ID module personnalisé.
  • _moduledata_X_: En utilisant cette macro ("X" est le nom du module en question) nous collectons les dernières données de ce module et s'il est numérique il retourne les données formatées avec les décimales spécifiées dans la configuration de la console et avec son unité (s'il en dispose). 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_: Retourne une image codée 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) Même opération que la macro précédente mais seulement avec les seuils critiques et d'alerte du module, s'ils sont définis.
  • _modulegroup_: Nom du groupe de modules.
  • _modulestatus_: Statut 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 balises de module.
  • _plugin_parameters_: Paramètres du module plugin.
  • _policy_: Nom de la politique à laquelle le module appartient (le cas échéant).
  • _prevdata_ : Données antérieures avant le déclenchement de l'alerte.
  • _rca_ : Chaîne d'analyse de cause racine (uniquement pour les services).
  • _secondarygroups_ : Affiche les groupes secondaires de l'agent.
  • _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.
  • _timezone_: Heure et date du déclenchement de l'alerte.
  • Fuseau horaire représenté dans _timestamp_.

1.3.2.2 Modifier une action=


Alert action.png

Pour modifier l'action, cliquez simplement sur le nom de l'action.


Alert action edit.png

Lorsque vous avez terminé, vous pouvez enregistrer vos modifications en cliquant sur le bouton "Mettre à jour".


1.3.3 Effacer une action

Vous pouvez supprimer une action en cliquant sur l'icône de la corbeille, qui se trouve dans la partie droite.

Sipo.jpg

1.4 Modèle d'alerte

1.4.1 Introduction

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.


1.4.2 Création d'un modèle

Accédez au menu Alertes > Modèles. Vous pouvez créer un nouveau modèle en cliquant sur le bouton "Créer", où nous allons créer chaque modèle en trois étapes.


Planti.jpg

1.4.2.1 Étape 1 : Général


Templform.JPG

Dans cet assistant de modèle, vous pouvez spécifier :

  • Name : Le nom du modèle, obligatoire.
  • Description : Décrit la fonction du modèle, et est utile pour identifier le modèle parmi d'autres dans l'aperçu des alertes.
  • 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é. Il est également très utile pour filtrer lors de la recherche d'alertes.

Vous pouvez choisir parmi les priorités suivantes :

  • Maintenance
  • Informational
  • Normal
  • Warning
  • Critical

1.4.2.2 Etape 2: Conditions


Templform2.JPG


Dans cette section, on nous offre la possibilité de configurer le modèle lui-même, quand devrait être lancé :

  • Condicion Type : Champ dans lequel est défini le type de condition qui sera appliqué au signalement. Les combos nécessaires seront ajoutés en fonction du type choisi, il existe les types suivants :
  • Regular Expresion : Une expression rationnelle est utilisée. L'alerte est déclenchée lorsque la valeur du module remplit une condition établie.


Regular.jpg


Si vous choisissez la condition régulière, vous pouvez cocher la case Déclencheur quand elle correspond à la valeur. En cas de cochage, l'alerte sera lancée lorsque la valeur correspond et, en cas de non cochage, l'alerte sera lancée lorsque la valeur ne correspond pas.

  • Max et Min : Intervalle numérique dimensionné.


Notmaxmin.png


Si vous cochez'Déclencher lorsque la valeur correspond à la valeur', l'alerte sera déclenchée lorsque la valeur se situe dans la plage indiquée entre le maximum et le minimum et, si vous ne la cochez pas, l'alerte sera déclenchée lorsque la valeur est hors de la plage indiquée.

  • Max : Une valeur maximale est utilisée. L'alerte saute lorsque la valeur du module est supérieure à la valeur maximale marquée.

Max.png


  • Min : Une valeur minimale est utilisée. L'alerte est déclenchée lorsque la valeur du module est inférieure à la valeur minimale marquée.

Min.png


  • Equal to : Utilisé pour déclencher l'alerte lorsqu'une valeur est fournie, elle doit être égale aux données reçues. Cette condition, comme max/min n'est utilisée que pour les valeurs numériques, par exemple : 234 ou 124.35.

<centre> <centre Equal.png] </centre> </centre

  • N'est pas égal à : Identique à ce qui précède, mais annule la condition (opérateur logique NON).

Notequal.png


  • Warning/Critical/Unknown status : L'état du module est utilisé. L'alerte est déclenchée lorsque l'état du moniteur est indiqué :

Status template.png

Ce sont les explications pour les champs que vous allez y voir :

Days of Week

Définit les jours pendant lesquels l'alerte peut être déclenchée.

Use special days list

Activer/désactiver l'utilisation de la liste des jours spéciaux (jours fériés et jours ouvrables spéciaux).

Time From

Temps à partir duquel l'action du signalement est exécutée.

Time To

Temps jusqu'à ce que l'action de l'alerte soit exécutée.

Time Threshold

Temps qui doit s'écouler pour redémarrer le compteur d'alertes.

Définit l'intervalle de temps dans lequel il est garanti qu'une alerte ne sera pas déclenchée plus de fois que le nombre défini dans Nombre maximum d'alertes.

Une fois l'intervalle défini écoulé, le compteur redémarre. La réinitialisation du compteur de déclenchement ne sera pas redémarrée si l'alerte est récupérée lorsqu'une valeur correcte est atteinte, sauf si la valeur " Alerte récupération " est activée, auquel cas le compteur sera redémarré immédiatement après avoir reçu une valeur correcte.

Min number of alerts

Nombre minimum de fois que la situation définie dans le modèle doit se produire (en comptant toujours à partir du nombre défini dans le paramètre FlipFlop du module) pour lancer une alerte. La valeur par défaut est 0, ce qui signifie que l'alerte sera déclenchée lorsque la première valeur qui remplit la condition arrive. Il fonctionne comme un filtre, utile pour ignorer les faux positifs.

Max number of alerts

Nombre maximum d'alertes qui peuvent être envoyées consécutivement dans le même intervalle de temps (Time Threshold). C'est la valeur maximale du compteur d'alertes. Il n'y aura pas plus d'alertes par intervalle de temps que celles indiquées dans ce champ.

Default Action Dans cette liste déroulante, vous définissez l'action par défaut du modèle. Il s'agit de l'action qui sera créée automatiquement lorsque vous affecterez le modèle au module. Vous pouvez n'en mettre aucune ou une, mais vous ne pouvez pas mettre plusieurs actions par défaut.

1.4.2.3 Étape 3 : Champs avancés



Combo.jpg

Dans cette vue, vous pouvez régler les options suivantes :

'"Alerte à la récupération

Combo où vous pouvez définir si vous voulez activer ou non la récupération des alertes.

Si la récupération des alertes est activée, lorsque le module ne remplit plus 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.

Field 1

Définit la valeur de la variable "_field1_". Vous pouvez utiliser ici une série de macros décrites ci-dessous.

Field n

Définit la valeur de la variable "_fieldn_", où n est un entier compris entre 1 et 10.

Une fois la configuration terminée, terminez l'édition en cliquant sur le bouton "Terminer".

1.4.3 Macros remplaçables dans les champs Field1, Field2, Field3... Field10

Dans tous les cas des champs field1, field2... field10' (dans le modèle d'alerte, ainsi que dans la commande et dans l'action) on peut utiliser les macros suivantes, qui sont des "mots" qui sont remplacés au moment de l'exécution par une valeur qui varie selon le moment, la valeur, l'agent qui déclenche l'alerte, etc.

  • _adress_ : Adresse de l'agent qui a déclenché l'alerte.
  • _address_n_ : L'adresse de l'agent qui correspond à la position indiquée dans "n". Exemple : adresse_1_, adresse_2_, adresse_2_.
  • _agent_ : Alias de l'agent qui a lancé l'alerte. Si aucun alias n'est attribué, le nom de l'agent est utilisé.
  • _agentalias_ : Alias de l'agent qui a tiré l'alerte.
  • _agentcustomfield_n_ : Numéro du 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 CRITIQUE.
  • _alert_description_ : Description de l'alerte.
  • _alerte_name_ : Nom de l'alerte.
  • _alert_priority_ : Priorité numérique de l'alerte.
  • _alert_text_severity_ : Priorité dans le texte d'alerte (Maintenance, Informatif, Mineur normal, Avertissement, Majeur, Critique).
  • _alert_threshold_ : Seuil d'alerte.
  • _alert_times_times_fired_ : Nombre de fois où l'alerte a été activée.
  • _alert_unknown_instructions_ : Instructions contenues dans le module pour un état INCONNU.
  • _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.
  • _data_ : Données qui ont déclenché l'alerte.
  • _email_tag_ : Emails associés aux tags du module.
  • _event_cfX_ : (Alertes d'événement uniquement) 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_.
  • _email_tag_ : Emails associés aux tags du module.
  • _event_description_ : (Alertes d'événement seulement) Description textuelle de l'événement FMS Pandora.
  • _event_extra_id_ : (Alertes d'événements seulement) Id extra.
  • _event_id_ : (Seulement les alertes d'événements) ID de l'événement qui a déclenché l'alerte.
  • _event_text_severity_ : Priorité dans le texte de l'événement qui déclenche l'alerte (Maintenance, Informative, Mineure normale, Mineure normale, Avertissement, Majeure, Critique).
  • _eventTimestamp_ : Horodatage dans lequel l'événement a été créé. v733
  • _field1_ : Champ 1 défini par l'utilisateur.
  • _field2_ : Champ 2 défini par l'utilisateur.
  • _field3_ : Champ 3 défini par l'utilisateur.
  • _field4_ : Champ 4 défini par l'utilisateur.
  • _field5_ : Champ 5 défini par l'utilisateur.
  • _field6_ : Champ 6 défini par l'utilisateur.
  • _field7_ : Champ 7 défini par l'utilisateur.
  • _field8_ : Champ 8 défini par l'utilisateur.
  • _field9_ : Champ 9 défini par l'utilisateur.
  • _field10_ : Champ 10 défini par l'utilisateur.
  • _field11_ : Champ 10 défini par l'utilisateur.
  • _field12_ : Champ 10 défini par l'utilisateur.
  • _field13_ : Champ 10 défini par l'utilisateur.
  • _field14_ : Champ 10 défini par l'utilisateur.
  • _field15_ : Champ 10 défini par l'utilisateur.
  • _groupcontact_ : Coordonnées du groupe. Il est configuré lors de la création du groupe.
  • _groupcustomid_ : ID personnalisé du groupe.
  • _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_ : Id de l'agent, utile pour construire une URL directe qui redirige vers une page web de la console Pandora FMS.
  • _id_alert_ : identifiant numérique de l'alerte (unique), utilisé pour corréler l'alerte avec le logiciel tiers.
  • _id_group_ : L'ID du groupe d'agents.
  • _id_module_ : L'ID du 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 qui a activé l'alerte.
  • _modulegraph_nh_' : (Uniquement pour les alertes qui utilisent la commande eMail) Retourne une image codée en base64 du graphique d'un module avec une période de n heures (par exemple, _modulegraph_24h_). Une configuration correcte de la connexion entre le serveur et l'API de la console est requise. Cette configuration se fait dans le fichier de configuration du serveur.
  • _modulegraphth_nh_ : (>=7.0) (Uniquement pour les alertes qui utilisent la commande eMail) Même opération que la macro précédente seulement celle avec les seuils critiques et d'alerte du module lorsque ceux-ci sont définis.
  • _modulegroup_ : Nom du groupe de modules
  • _modulestatus_ : Statut 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 balises de module.
  • _plugin_parameters_ : Paramètres du module plugin.
  • _policy_ : Nom de la politique à laquelle le module appartient (le cas échéant).
  • _prevdata_ : Données antérieures avant le déclenchement de l'alerte.
  • _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 auxquelles l'alerte a été déclenchée.
  • _timezone_ : Fuseau horaire qui est représenté dans _timetamp_.


Exemple : L'agent _agent_ a le module _module_ en état _modulestatus_ avec données _data_



1.4.3.1 Exemple d'alerte avec remplacement de macros

En supposant que vous voulez créer une entrée dans un LOG où le format suivant apparaît sur chaque ligne :


2009-12-24 00:12:00 pandora [CRITICAL] Agent <agent_name> Data <module_data> Module <module_name> in CRITICAL status

Command Configuration

echo _timestamp_ pandora _field2_ >> _field1_

Action Configuration

Field1 = /var/log/pandora/pandora_alert.log
Field2 = <En blanc>
Field3 = <En blanc>

Template Configuration

Field1 = <En blanc>
Field2 = [CRITICAL] Agent _agent_ Data _data_ Module _module_ in CRITICAL status
Field3 = <En blanc>

Dans la section récupération :

Field2 = [RECOVERED] [CRITICAL] Agent _agent_ Data _data_ Module _module_ in CRITICAL status
Field3 = <En blanc>

Ainsi, lors de l'exécution d'une alerte, la ligne suivante sera placée dans le LOG :

2009-10-13 13:37:00 pandora [CRITICAL] Agent raz0r Data 0.00 Module Host Alive in CRITICAL status

Et la ligne suivante pour récupérer l'alerte :


2009-10-13 13:41:55 pandora [RECOVERED] [CRITICAL] Agent raz0r Data 1.00 Module Host Alive in CRITICAL status

1.4.4 Modifier un modèle

Il est possible d'éditer les modèles qui ont été créés à partir de Modèles dans le menuGestion des alertes.


Plantilla.jpg


Pour éditer le modèle, il vous suffit de cliquer sur le nom du modèle.

1.4.5 Supprimer un modèle

Pour supprimer un modèle, cliquez sur l'icône de la corbeille grise à droite de l'alerte.


Cruz.jpg


1.5 Assigner des modèles d'alerte aux modules

Connaissant les informations de base sur le système d'alerte, nous allons vous montrer les possibilités d'affecter les alertes aux modules.

1.5.1 Gestion des alertes à partir du sous-menu Alertes

1.5.1.1 Affectation d'alerte dans le sous-menu Alertes

A partir de la section List of Alerts, nous pourrons créer de nouvelles alertes à partir du constructeur :


Pinar.jpg


Ce sont les champs qui doivent être remplis :

  • Agent : auto-complétion intelligente pour choisir l'agent.
  • Module : liste des modules de l'agent précédemment sélectionné.
  • Actions : action qui sera exécutée lorsque l'alerte sera déclenchée. Si le modèle a déjà une action par défaut, il peut être laissé en Default.
  • Template : gabarit qui contiendra les conditions d'alerte de tir.
  • Threshold : une action d'alerte ne sera pas exécutée plus d'une fois toutes les secondes, malgré le nombre de fois que l'alerte est déclenchée.

1.5.1.2 Modifier les alertes dans le sous-menu Alertes =

Une fois qu'une alerte a été créée, il n'est possible de modifier que les actions qui ont été ajoutées à l'action du modèle.

Il est également possible de supprimer l'action sélectionnée lors de la création de l'alerte 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 "Ajouter".


Modifica.jpg


1.5.1.3 Désactiver les alertes à partir du sous-menu Alertes

Une fois l'alerte créée, il est possible de la désactiver en cliquant sur l'icône de l'ampoule à droite du nom de l'alerte.


Desha.jpg


1.5.1.3.1 Supprimer les alertes du sous-menu Alertes===

Il est possible de supprimer toute alerte en cliquant sur la corbeille à droite de l'alerte.


Filter.jpg


1.5.2 Gérer les alertes depuis l'agent

1.5.2.1 Affectation des alertes de l'agent

Depuis la section d'administration de l'agent, nous pouvons ajouter de nouvelles alertes en naviguant vers l'onglet correspondant :


Wiz agent alerts.png


Nous allons maintenant détailler les champs disponibles dans le formulaire :

  • Module : liste des modules agents.
  • Actions : action qui sera exécutée lorsque l'alerte sera déclenchée. Si le modèle a déjà une action par défaut, il peut être laissé dans Default.
  • Template : modèle qui contiendra les conditions de déclenchement de l'alerte.
  • Threshold : une action d'alerte ne sera pas exécutée plus d'une fois toutes les secondes, malgré le nombre de fois que l'alerte est déclenchée.

1.5.2.2 Modifier les alertes de l'agent

Une fois l'alerte créée, il n'est possible de modifier que les actions qui ont été ajoutées à l'action du modèle.

Il est possible de supprimer l'action qui a été sélectionnée pour créer l'alerte en cliquant sur l'icône de la corbeille à droite de l'action, ou en ajoutant de nouvelles actions en cliquant sur le bouton "Ajouter".

Agent edit alerts.png

1.5.2.3 Désactive les alertes de l'agent

Une fois qu'une alerte a été créée, il est possible de la désactiver en cliquant sur l'icône de l'ampoule située à droite du nom de l'alerte.

Wiz agent disable alert.png

Dans l'image d'exemple, la deuxième alerte est désactivée (notez que la couleur de la police et l'icône d'alerte désactivée sont gris clair).


1.5.2.4 Supprimer des alertes depuis l'Agent

Vous pouvez supprimer une alerte en cliquant sur l'icône de la corbeille à droite de l'alerte.

Wiz agent delete alert.png


1.5.2.5 Détail des alertes

En cliquant sur l'icône loupe dans le bouton des options d'alerte, on accède à une page récapitulative de la configuration effective de l'alerte.

C'est l'écran où nous pourrons confirmer chacune des configurations que nous avons sélectionnées pour notre alerte :

Agent alert summary.png

Sélectionnez une action spécifique dans la liste déroulante des actions pour voir un exemple de la commande finale :

Agent alert summary action.png


1.6 Définir un seuil

Dans la capture d'écran suivante, nous voyons un module appelé " CPU Load " pour lequel nous allons définir un seuil critique et un avertissement.


Cpu1.JPG


Le formulaire d'édition du module sera utilisé pour établir les seuils comme indiqué dans la capture d'écran suivante.

Il est important de se rappeler que la modification des modules de type local n'est disponible qu'à partir de la console dans la version Enterprise, sinon il sera nécessaire de le faire directement dans le fichier de configuration de l'agent :


Cpu2.JPG



Nous acceptons et sauvegardons la modification. Maintenant quand la valeur du module CPU Load est entre 70 et 90, son état devient AVERTISSEMENT, et entre 91 et 100 devient CRITIQUE, montrant son état en rouge comme nous le voyons ici :


Cpu3.JPG


1.7 Configurer l'action

Nous devons maintenant créer une action qui est "Envoyer un email à l'opérateur". Allez dans le menu:Alertes >Actions et cliquez sur le bouton pour créer une nouvelle action :

Qgcpu5.png

Cette action utilisera la commande "Envoyer e-mail", et ses champs Field1, Field2 et Field3 correspondront à l'adresse de destination, l'objet de l'e-mail et le corps du message.




1.8 Configurer le modèle

Un modèle d'alerte générique sera créé pour tout module en état critique, son action par défaut sera de notifier le groupe d'opérateurs par email. Nous allons définir le modèle à partir de la section Templates :

Qgcpu6.png

La priorité définie ici "Informational" sera utilisée pour afficher l'événement dans une certaine couleur lorsque l'alerte est déclenchée.

Dans l'étape 2, vous spécifiez les paramètres qui déterminent les conditions de déclenchement spécifiques, telles que l'état que le module doit avoir ou les intervalles de temps dans lesquels le modèle doit fonctionner.

Qgcpu7.png


Les paramètres les plus importants de cette étape sont :

  • Condition type : détermine si l'alerte sera déclenchée par un changement d'état, une variation d'une valeur, etc. C'est le paramètre le plus important pour que l'alerte fonctionne comme souhaité. Nous utiliserions la conditionEtat critique pour que l'alerte soit déclenchée lorsqu'un module est dans un état critique.
  • Default action : Action par défaut à exécuter lorsque l'alerte est déclenchée. Elle est facultative.
  • Time threshold : temps pendant lequel l'alerte ne sera pas répétée si l'état incorrect est maintenu en permanence. Si nous le laissons dans un jour (24 heures), il ne nous enverra l'alerte qu'une fois toutes les 24h même si le module reste plus longtemps dans le mauvais état.
  • Nombre minimum d'alertes : Le nombre minimum de fois que la condition devra être donnée (dans ce cas, que le module est à l'état CRITIQUE) avant que Pandora FMS exécute les actions associées au modèle d'alerte. Avec la valeur 0, la première fois que le module est incorrect, il déclenchera l'alerte.
  • Max. Nombre d'alertes : 1 signifie qu'il n'exécutera l'action qu'une seule fois. Si nous en avons 10 ici, il exécutera l'action 10 fois. C'est un moyen de limiter le nombre de fois qu'une alerte peut être exécutée.

Dans la section 3 nous avons les champs Field1, Field2, Field3, etc. qui, comme nous l'avons expliqué, nous serviront à transférer les paramètres du modèle vers l'action, et de l'action vers la commande. Aussi dans cette troisième section nous pouvons activer ou désactiver la récupération d'alerte, qui est d'exécuter une autre action lorsque la situation problématique revient à la normale.

Qgcpu8.png




1.9 Associer l'alerte au module

Nous avons déjà tout ce dont nous avions besoin, il ne nous reste plus qu'à associer le modèle d'alerte au module. Pour ce faire, nous allons dans l'onglet alerte à l'intérieur de l'agent où se trouve le module :

Qgcpu9.png

Nous avons créé une association entre le module "cpu_user" et le modèle d'alerte "Critical condition". Par défaut, il affichera l'action que nous avons définie dans ce modèle "Envoyer un email à XXX".




1.10 Escalade d'alerte

Une fois qu'une alerte complète a été associée à un module, il est possible d'ajouter des actions supplémentaires qui seront exécutées si l'alerte est répétée un certain nombre de fois de suite. C'est ce que nous appelons l'escalade des alertes. Únicamente necesitaremos añadir las acciones adicionales y determinar entre qué repeticiones consecutivas de la alerta se va a ejecutar esta acción, tal y como vemos en la siguiente captura:

Alert1.JPG


Lorsqu'une alerte est récupérée, toutes les actions exécutées jusqu'à présent seront réexécutées, et pas seulement celles correspondant à la configuration de "Number of alerts match from" actuelle.

De plus, nous pouvons mettre un seuil en seconde à partir duquel une alerte ne peut pas être lancée plus d'une fois pendant cet intervalle.



1.11 Alertes en Standby

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 ne généreront d'événements.

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



1.12 Protection en cascade

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 connexion principale qui échoue. Ce genre de choses se produit lorsqu'un élément de réseau intermédiaire comme un routeur ou un commutateur tombe en panne, et qu'il est laissé inaccessible à une grande partie du réseau géré avec Pandora FMS. Parce que les contrôles réseau échoueraient dans ce scénario, les alertes pour les appareils hors service commenceraient à se déclencher sans être vraies.


Recursive cascade protection ilustration.png


La protection en cascade est activée à partir de la configuration de l'agent. Cliquez sur l'option "protection en cascade". Pour que l'agent avec protection en cascade activée fonctionne, il doit avoir correctement configuré l'agent parent, dont il dépend. Si l'agent parent a à ce moment une alerte de module dans un état critique déclenchée, l'agent inférieur avec protection en cascade n'exécutera pas ses alertes.

Ceci ne s'applique pas aux alertes de module en état WARNING ou UNKNOWN.


Down1.jpg


1.12.1 Exemples

Vous avez les agents suivants :

  • Router : module de contrôle ICMP et module de contrôle SNMP, utilisant un OID standard pour vérifier l'état d'un port ATM. Nous pouvons également vérifier la latence jusqu'au routeur de notre fournisseur.
  • Web server : possède plusieurs modules exécutés par l'agent : Vérification du CPU, de la mémoire, du processus Apache. Il dispose également d'un contrôle de latence WEB en quatre étapes.
  • Database server : possède plusieurs modules exécutés par l'agent : Vérification du CPU, de la mémoire, du processus MySQL. En outre, il dispose de quelques contrôles supplémentaires de l'intégrité de la BD. Il dispose également d'une vérification de la connectivité à distance à une autre base de données, à l'aide d'un plugin spécifique qui se connecte, interroge et quitte, en mesurant le temps total.

Dans WEB SERVER et DATABASE SERVER, nous définissons ROUTER comme parent. Activez la case à cocher Protection en cascade dans WEBSERVER et DATABASE SERVER.

Nous définissons maintenant plusieurs alertes simples :

  • ROUTER

SNMP Check / CRITICAL -> Action, send MAIL. Latency > 200ms / WARNING -> Action, send MAIL.

  • WEB SERVER

CPU / WARNING MEM / WARNING PROCESS / CRITICAL -> Action, send MAIL. HTTP LATENCY / CRITICAL -> Action, send MAIL.

  • DATABASE SERVER

CPU / WARNING MEM / WARNING PROCESS / CRITICAL -> Action, send MAIL. SQL LATENCY / CRITICAL > Action, send MAIL.

Si la connexion ROUTER tombe en panne, c'est-à-dire là où Pandora FMS se connecte à WEB SERVER et DATABASE ; sans activer la protection en cascade, il recevrait six alertes, essayez d'imaginer l'effet que cela aurait si au lieu de deux serveurs, il avait deux cents. Cet effet est connu sous le nom de "tempête d'événements", dans le pire des cas, peut faire tomber votre serveur de messagerie, serveur de surveillance et votre propre mobile, l'inonder de SMS.

Si vous disposez d'une protection en cascade, vous ne recevrez qu'une alerte indiquant que l'interface ATM du routeur est hors service. Cependant, je verrais les éléments WEBSERVER et DATABASE SERVER en rouge, mais je n'aurais pas les alertes.


1.12.2 Protection en cascade basée sur les services

Depuis la version 7.0 OUM727, nous pouvons utiliser les services pour éviter que des alertes de sources multiples ne signalent le même incident.


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


C'est-à-dire, dans l'image suivante :

Proteccion cascada1.png



Si l'élément 192.168.10.149 entre dans un état critique sans affecter le reste du service, l'opérateur reçoit une alerte indiquant que 192.168.10.149 est en panne, mais que le service Service fonctionne normalement.

Si 192.168.10.149 affecte le fonctionnement du service, l'opérateur recevra une alerte indiquant que Service est affecté par la chute de 192.168.10.149.



Pour recevoir ces informations, nous devons éditer ou créer un nouveau modèle d'alerte, en utilisant la macro _rca_ root cause analysis (root cause analysis).

_rca_

A partir de Pandora FMS 7.0 OUM727, cette macro fournira à l'opérateur des informations sur le'chemin' affecté dans le service.


Proteccion cascada2.png



Par exemple, la valeur de la macro _rca_ correspondant à l'état de service dans l'image serait :

 [Service -> web_service -> 192.168.10.149]

Bien que l'état du service soit correct.

Observation  : La chaîne d'événements représentée dans l'analyse de la cause fondamentale représente les éléments critiques d'un service, nous permettant de voir quels éléments affectent mon service.



1.12.3 Protection en cascade basée sur des modules

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 passe en état critique.

Alerta-modulo.png

1.13 Mode de fonctionnement sûr (Version >= 7.0)

Safe operation mode.png

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 critique, les autres modules de l'agent sont désactivés jusqu'à ce qu'il revienne à la normale ou qu'un avertissement se déclenche. Cela permet, par exemple, de désactiver les modules distants en cas de perte de connectivité.

1.14 Liste des jours spéciaux

Pandora FMS permet de définir une liste de jours spéciaux pour les jours fériés et les vacances qui peuvent être utilisés dans la configuration du modèle afin que pendant ces jours les alertes ne soient pas déclenchées.

1.14.1 Créer un jour spécial

De nouveaux jours spéciaux sont créés dans la section "Alerts" -> "List of special days", en cliquant sur le bouton "Plus" ou sur "Create", sous le calendrier.



Creating special day61-1.png



Une fois que vous avez cliqué sur l'un d'eux, un écran comme celui-ci apparaît :



Creating special day2.png



Les champs à remplir sont les suivants :

  • Date : La date du jour spécial. Le format est AAAA-MM-JJ. Pour régler le même jour chaque année, "*" peut être utilisé dans AAAA.
  • Group : Sélectionnez ici le groupe auquel s'applique le jour spécial.
  • Same day of the week : Sélectionnez un jour. La date dans la section "Date" sera traitée de la même façon que ce jour de la semaine.
  • Description : Description de la journée spéciale.

Par exemple, supposons que le 2 mai 2017 soit un jour spécial. Si nous définissons "2017-05-02" comme "dimanche", ce jour sera traité comme si c'était un dimanche. En gardant à l'esprit que les modèles ont des options de configuration et agiront d'une manière ou d'une autre selon le jour de la semaine, cela nous aidera à ce qu'ils se comportent comme nous le voulons.

'"Exemple pratique"'

Nous avons un modèle qui nous avertit du lundi au vendredi de 8h à 18h, les samedis et dimanches, ce modèle ne déclenchera aucune alerte. Le 15 août est mercredi et c'est un jour férié, donc nous créons un jour spécial et sur le terrain, nous choisissons le samedi ou le dimanche pour ne pas être alertés d'un problème le 15 août car il sera traité comme un jour (samedi ou dimanche) où le modèle n'est pas configuré pour déclencher des alertes.

Une fois les champs sélectionnés, cliquez sur le bouton "Create".

1.14.2 Créer massivement des journées spéciales à l'aide d'un fichier.ics

Des jours spéciaux peuvent également être créés à l'aide d'un fichier iCalendar (.ics). Ceux-ci peuvent être importés en haut de la fenêtre. Une fois importées, les données correspondantes seront enregistrées dans le mois en cours.



Creating special day ics.png



1.14.3 Modifier un jour spécial

Il est possible de créer des jours spéciaux créés dans l'option "List of special days" de la section "Alerts".



Editing special day61-1.png



Pour modifier un jour spécial, cliquez sur l'icône de la clé à molette à côté du jour spécial correspondant.



Editing special day2.png



Une fois les modifications effectuées, cliquez sur le bouton "Update" pour les confirmer.

1.14.4 Supprimer un jour spécial

Pour supprimer un jour spécial, cliquez sur l'icône de la poubelle à côté de l'icône de la clé journalière spéciale.



Deleting special day61.png



1.15 Exemples d'alertes

1.15.1 Envoi d'alertes par SMS

Dans cet exemple, nous allons voir quelque chose de très fréquent : comment envoyer un SMS quand quelque chose arrive ou est sur le point d'arriver.

Vous devez avoir installé un outil qui permet l'envoi de SMS sous forme de smstools.

Supposons que vous ayez configuré votre compte SMS. Exécutez la commande :


> sendsms 
Vous devez spécifier deux paramètres : <destination> 'Full message'.
N'oubliez pas d'envoyer le message entre guillemets simples (), et entrez le numéro de destination
avec le code international  (346276226223 pour les téléphones espagnols, par exemple).


Nous allons maintenant pouvoir utiliser la 'commande d'alerte dans l'interface d'administration de Pandora FMS.



Smsalert sample1.png




Dans cette commande, nous envoyons "346666666666" comme source du message, nous pouvons utiliser un mot (alphanumérique), mais certains opérateurs mobiles ne gèrent pas bien les ID alphanumériques. Field1 et Field2 seront utilisés pour définir la commande de comportement. Sur la photo du téléphone portable qui reçoit le SMS, j'utilise une chaîne d'identification : "Aeryn". Le field1 sera le téléphone de destination, et le champ2 le texte, défini dans l'Action des alertes.

Définissez maintenant l'action de l'alerte. Dans ce cas spécifique, l'alerte modèle ne met pas de données dans le SMS ; toutes les informations sont définies dans l'Action Alerte.



Smsalert sample3.png



Field1 serait notre numéro de téléphone. Dans le champ 2 se trouve le message texte. Nous utilisons ici quelques macros, qui seront remplacées au fil du temps, lorsque l'alerte se produit.

Dernière étape : créons un modèle d'alerte (passez cette étape si vous en avez déjà un valide). Nous voulons créer un modèle d'alerte très simple, juste pour "tirer la sonnette d'alarme" quand un module est CRITIQUE. Cette alerte sera déclenchée une fois par jour au maximum, mais si elle se répète, elle sera déclenchée à chaque fois qu'elle sera répétée et déclenchée à nouveau.




Smsalert sample5.png





Smsalert sample6.png



Maintenant, tout ce que vous avez à faire est d'assigner un module avec un modèle d'alerte et une action d'alerte :




Smsalert sample4.png



Pour avoir ce champ d'alerte, le module doit être en CRITICAL. Dans la capture d'écran suivante, je vais vérifier la configuration du module pour voir si son seuil CRITIQUE est défini. Si ce n'est pas le cas, l'alerte ne sera jamais déclenchée car elle attend d'avoir un statut CRITICAL. Dans mon cas, je l'ai fixé à 20. Lorsqu'une valeur inférieure est reçue, le module passe en CRITIQUE et l'alerte est déclenchée.




Smsalert sample7.png



Tout est prêt. Nous pouvons maintenant "forcer" l'alerte à l'exécuter et à la tester. Pour forcer l'alerte, allez à la vue d'alerte de l'agent et cliquez sur l'icône circulaire verte.



Smsalert sample8.png



Un SMS peut apparaître sur mon téléphone portable, comme le montre la photo ci-dessous. J'ai obtenu des données "N/A" parce que, lorsque vous forcez l'alerte, aucune donnée réelle n'est reçue du module.




Smsalert sample9.png



1.15.2 Utilisation de commandes d'alerte autres que l'email

L'email, car la commande est interne à Pandora FMS et ne peut pas être configuré, c'est-à-dire que le champ1, le champ2 et le champ3 sont des champs définis qui sont utilisés comme destinataire, objet et texte du message. Mais, que se passe-t-il si je veux exécuter une action différente, définie par moi ?

Nous allons définir une nouvelle commande, quelque chose de totalement défini par nous. Imaginons que nous voulions générer un fichier journal avec chaque alerte que nous trouvons. Le format de ce fichier journal doit être quelque chose comme :

DATE_HEURE - NOM_AGENT - NOM_MODULE - VALEUR - DESCRIPTION DU PROBLÈME

Où VALEUR est la valeur du module à ce moment. Il y aura plusieurs fichiers journaux, selon l'action qui appelle la commande. L'action définira la description et le fichier vers lequel se dirigeront les événements.

Pour ce faire, nous allons d'abord créer une commande comme suit :


Qgcpu11.png

Et nous allons définir une action :


Qgcpu12.png

Si nous voyons le fichier journal que nous avons créé :

2010-05-25 18:17:10 - farscape - cpu_user - 23.00 - Custom log alert #1

L'alerte a été déclenchée à 18:17:10 dans l'agent "farscape", dans le module "cpu_sys" avec une donnée de "23.00" et avec la description que nous avons mise lors de la définition de l'action.

Depuis l'exécution de la commande, l'ordre des champs et d'autres choses peuvent nous faire ne pas bien comprendre comment la commande est exécutée à la fin, le plus simple est d'activer les traces de débogage du serveur pandora (verbose 10) dans le fichier de configuration de Pandora Server dans /etc/pandora/pandora_server.conf, redémarrons le serveur (/etc/init.d/pandora_server restart) et regardons le fichier /var/log/pandora/pandora_server.log cherchant la ligne exacte avec l'exécution de la commande d'alerte que nous avons définie, pour voir comment le serveur Pandora FMS lance cette commande.


1.15.2.1 = Exemple d'alerte avec macros de substitution

Supposons que vous vouliez générer une entrée dans un LOG où le format suivant apparaît sur chaque ligne :

2009-12-24 00:12:00 pandora [CRITICAL] Agent <agent_name> Data <module_data> Module <module_name> in CRITICAL status

"'Configuration de la commande

echo _timestamp_ pandora _field2_ >> _field1_

"'Configuration de l'action

Field1 = /var/log/pandora/pandora_alert.log
Field2 = <En blanc>
Field3 = <En blanc>

"'Configuration du modèle

Field1 = <En blanco>
Field2 = [CRITICAL] Agent _agent_ Data _data_ Module _module_ in CRITICAL status
Field3 = <En blanc>

Dans la section récupération :

Field2 = [RECOVERED] [CRITICAL] Agent _agent_ Data _data_ Module _module_ in CRITICAL status
Field3 = <En blanc>

Ainsi, lors de l'exécution d'un signalement, la ligne suivante serait insérée dans le LOG :

2009-10-13 13:37:00 pandora [CRITICAL] Agent raz0r Data 0.00 Module Host Alive in CRITICAL status

Et la ligne suivante quand l'alerte est récupérée :

2009-10-13 13:41:55 pandora [RECOVERED] [CRITICAL] Agent raz0r Data 1.00 Module Host Alive in CRITICAL status

1.16 Macros personnalisées d'alertes module

N'importe quel nombre de macros peut être ajouté à un module d'agent.



Add module macros.png


Ces macros ont les caractéristiques suivantes :

  • Définis dans le module.
  • Stocker les données dans la DDBBB
  • .
  • Peut avoir n'importe quel nom, par ex : pepito
  • Ils ne sont pas reflétés dans la configuration locale (.conf)
  • .
  • Utilisé exclusivement pour les alertes.
  • Ne peut pas être défini au niveau composant.
  • Peut être défini dans policies.
  • .

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



Module macros.png


Les valeurs définies peuvent être utilisées comme partie des champs dans la définition des alertes. Par exemple : Pour inclure une macro à l'action d'envoi d'e-mail, il est nécessaire de configurer le champ corps du message comme suit :



Campos alertas.png


Si un module est ajouté à cette alerte sans avoir configuré la macro, la section où la valeur de la macro doit apparaître dans l'action sera vide.

1.17 Alertes d'événements et corrélation

Il y a un Chapitre_spécifique pour traiter ce sujet.

[Pandora:Documentation|Retour à l'index de documentation de Pandora FMS]]]


1.18 Guide rapide de configuration des emails pour les alertes dans Pandora FMS

1.18.1 Paramètres pour le courrier avec compte Gmail

Pour que le serveur Pandora FMS puisse envoyer les alertes via le compte mail Gmail, nous devons avoir configuré Pandora FMS et Postfix de la manière suivante :

1.18.1.1 Configuration Pandora FMS

Pour configurer correctement le mail avec un compte Gmail dans le fichier de configuration du serveur Pandora FMS (/etc/pandora/pandora/pandora_server.conf) tous les champs doivent être commentés sauf l'adresse mta que nous allons configurer avec localhost ou l'ip du serveur où le serveur postfix est installé.

Si nous avons installé Postfix sur le même serveur que Pandora FMS, la configuration dans pandora_server.conf serait la suivante :

mta_address localhost 
#mta_port 25
#mta_user [email protected]
#mta_pass mypassword
#mta_auth LOGIN
#mta_from Pandora FMS <[email protected]>

Nous verrons ensuite un petit résumé de la configuration d'une alerte dans la console Pandora FMS.

1.18.1.1.1 Action Configuration

Pour configurer le destinataire du mail, nous utilisons l'action Mail to XXX pour ajouter un destinataire auquel tous les emails des alertes seront envoyés.


GMAIL1.png

1.18.1.1.2 Configuration de l'Alerte

Dans ce cas a été généré dans la configuration de module > Alertes, une nouvelle alerte avec le module que vous pouvez voir dans la capture d'écran.


GMAIL2.png

Une fois l'alerte déclenchée, nous observons comment elle atteindra le mail choisi dans l'action :


GMAIL3.png


GMAIL4.png

1.18.1.2 Installation Postfix

Vous devez avoir les paquets suivants installés sur le serveur Pandora FMS pour le bon fonctionnement du serveur postfix avec un compte Gmail.

 yum install postfix mailx cyrus-sasl-plain cyrus-sasl cyrus-sasl-lib cyrus-sasl-md5 cyrus-sasl-scram cyrus-sasl-gssapi

1.18.1.3 Configuration Postfix

En supposant que Postfix est déjà installé sur votre serveur et que tout fonctionne correctement, à l'exception de l'envoi de courrier via Gmail, vous devriez suivre ces étapes :

1-- Vérifiez que l'option "less secure pass" soit activée dans le compte Gmail. Pour ce faire, vous pouvez activer ce lien https://myaccount.google.com/lesssecureapps)

2-- Editez le fichier /etc/postfix/main.cf et ajoutez les lignes suivantes à la fin du fichier :

myhostname = <hostname> #Ajouter le nom d'hôte du serveur ici
relayhost = [smtp.gmail.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
smtp_sasl_security_options = noanonymous
smtp_use_tls = yes
smtp_tls_CAfile = /etc/pki/tls/cert.pem
smtp_tls_security_level = encrypt

3-- Créez le fichier /etc/postfix/sasl_passwd avec votre adresse Gmail et votre mot de passe.

nano /etc/postfix/sasl_passwd

Ajoutez la ligne suivante dans le fichier avec votre adresse Gmail et votre mot de passe :

[smtp.gmail.com]:587 [email protected]:PASSWORD

Protégez-le correctement :

chmod 600 /etc/postfix/sasl_passwd
chown root:root/etc/postfix/sasl_passwd

4-- Créez le fichier etc/postfix/tls_policy avec les informations suivantes :

nano /etc/postfix/tls_policy
[smtp.gmail.com]:587 encrypt

Protégez-le correctement :

 chmod 600 /etc/postfix/tls_policy
chown root:root/etc/postfix/tls_policy

5-- Transformez /etc/postfix/sasl_passwd et /etc/postfix/tls_policy en un fichier indexé avec la commande :

postmap /etc/postfix/sasl_passwd && postmap /etc/postfix/tls_policy

Ce qui va créer le fichier /etc/postfix/sasl_passwd.db et /etc/postfix/tls_policy.db


6-- Enfin, redémarrez postfix pour appliquer les changements, comme ceci :

 /etc/init.d/postfix restart

7-- Le fonctionnement peut être vérifié en ouvrant deux consoles. On exécutera la commande suivante pour surveiller le comportement du courrier :

tail -f /var/log/maillog

Et dans l'autre, un e-mail sera envoyé :

echo "Test mail" | mail [email protected]

Si les étapes précédentes ont réussi, vous devriez voir quelque chose comme ceci dans l'autre console :

Dec 18 18:33:40 OKComputer postfix/pickup[10945]: 75D4A243BD: uid=0 from=
Dec 18 18:33:40 OKComputer postfix/cleanup[10951]: 75D4A243BD: message-id=
Dec 18 18:33:40 OKComputer postfix/qmgr[10946]: 75D4A243BD: from=, size=403, nrcpt=1 (queue active)
Dec 18 18:33:44 OKComputer postfix/smtp[10953]: 75D4A243BD: [email protected], relay=smtp.gmail.com[74.125.93.109]:587, delay=3.7,  delays=0.15/0.14/1.8/1.6, dsn=2.0.0, status=sent (250 2.0.0 OK 1324249500 eb5sm36008464qab.10)
Dec 18 18:33:44 OKComputer postfix/qmgr[10946]: 75D4A243BD: removed

Si le résultat est le précédent, Pandora FMS pointera vers le serveur Postfix pour envoyer les mails et ils seront envoyés sans problème.

1.19 Corrélation des alertes : alertes dans les événements et les journaux


A partir de Pandora FMS version 741, 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 logs. 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 (et, ou, xor, nand, ni, ni, nxor), pour rechercher 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.

Depuis la version NG741 il est possible 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.

Info.png

En raison du nombre élevé d'événements que la base de données Pandora FMS peut héberger, le serveur travaille sur une fenêtre d'événements maximum, qui est définie dans le fichier de configuration pandora_server.conf via le paramètre'event_window'. Les événements générés en dehors de cette fenêtre temporelle ne seront pas traités par le serveur, il n'est donc pas utile de spécifier dans une règle une fenêtre temporelle supérieure à celle configurée dans le serveur.

 



De la même manière, il existe un autre paramètre serveur, appelé log_window, qui fonctionne de la même manière que celui décrit ci-dessus.

Template warning.png

Pour que les alertes de corrélation d'événements fonctionnent, il est nécessaire d'activer le serveur de corrélation d'événements avec le paramètre eventserver 1 dans le fichier de configuration Pandora FMS

 

.

1.19.1 Création d'alertes de corrélation

1.19.1.1 Alertes de corrélation / modèles =

Pour configurer une alerte corrélée, accédez à la section'‘Alert correlation’ du menu.

Alertaslog2.png


Nous créons une règle, et définissons son comportement (similaire aux Alert Templates) :

Alertaslog12.PNG


Alertaslog13.PNG


Les paramètres de configuration des modèles pour les alertes 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 :

  • Mode d'évaluation des règles (Rule evaluation mode) : Peut être Pass ou Drop. Pass signifie que si un événement coïncide avec une alerte, le reste des alertes continuera à être évalué. Drop signifie que si un événement coïncide avec une alerte, le reste des alertes ne sera pas évalué.
  • Groupe (Group by) : Permet de regrouper les règles par agent, module, alerte ou groupe. Par exemple, si une règle est configurée pour sauter 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. Il peut être désactivé.

Dans le cas d'alertes contenant des règles de journalisation, cela n'affectera que le regroupement par agent. Si vous choisissez un groupe différent, les alertes basées sur les entrées du journal ne seront jamais remplies . Chaque règle est configurée pour sauter à un certain type d'événement ou de correspondance de journal ; lorsque l'équation logique définie par les règles et leurs opérateurs est satisfaite, l'alerte se déclenche.

1.19.2 Règles dans une alerte de corrélation

Alertaslog14.PNG


Pour définir les règles de l'alerte, vous devrez faire glisser les éléments du côté gauche vers la zone de dépôt du côté droit pour construire votre règle.

Éléments de configuration disponibles  :

Alertaslog3.png


Ces éléments seront activés pour guider l'utilisateur dans le respect de la grammaire de la règle. Vous trouverez ci-dessous une explication simplifiée de la grammaire à utiliser :

S -> R | R + NEXO +R
R -> CAMPO + OPERADOR + C | CAMPO + OPERADOR + C + MODIFICADOR
C -> VARIABLE

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

Il sera nécessaire de faire glisser l'élément sur la zone de définition des règles :

Alertaslog4.png


Pour nettoyer et annuler tous les changements, deux boutons sont disponibles:'Cleanup' et'Reset'.

Aucun changement ne sera sauvegardé jusqu'à ce que le bouton'Suivant.}} soit pressé.

REMARQUE : Les blocs ont une simultanéité au moment où la condition est remplie.

(A and B) 

Elle force l'élément analysé (événement ou journal) à se conformer simultanément à A et B.

A and B

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

1.19.3 Alertes multiples corrélées

Lorsque nous avons plusieurs alertes, elles ont un ordre d'évaluation spécifique. Ils seront toujours évalués dans l'ordre en commençant par le premier de la liste.

Si nous configurons le mode d'évaluation des règles'PASS', si une alerte corrélée est exécutée, les éléments suivants seront également évalués. C'est le mode'normal'.

Si l'on configure le mode d'évaluation des règles'DROP', si une alerte corrélée configurée avec ce mode est exécutée, l'évaluation des règles ci-dessous sera arrêtée. Cette fonction nous donne la possibilité d'une protection d'alerte en cascade.

Par exemple :

  • Alerte générique.
  • Alerte spécifique.

Si l'alerte générique échoue, il n'est pas nécessaire d'évaluer l'alerte spécifique. Configurez les deux avec DROP.

Cliquez sur l'icône de tri et faites-la glisser pour modifier l'ordre dans lequel les règles sont évaluées.

Alertaslog9.png


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 Pandora FMS et ne nécessitent aucune explication supplémentaire.

1.19.4 Macros d'alertes d'événements

Les macros qui peuvent être utilisées dans la configuration d'une alerte de corrélation sont :

  • _address_ : Adresse de l'agent qui a déclenché l'alerte.
  • _address_n_ : L'adresse de l'agent qui correspond à la position indiquée dans "n".

Exemple : adress_1_, adress_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 CRITIQUE.
  • _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, Major, 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.
  • _data_: Données qui ont déclenché l'alerte.
  • _email_tag_ : Emails associés aux tags du module.
  • _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_ : Horodatage dans lequel l'événement a été créé.
  • _fieldX_ : Champ C défini par l'utilisateur.
  • _groupcontact_ : 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). 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). 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_ : Statut 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.
  • _rca_ : Chaîne d'analyse des causes profondes (uniquement pour les services).
  • _server_ip_ip_ : IP du serveur auquel l'agent est affecté.
  • _nom_du_serveur_ : Nom du serveur auquel l'agent est affecté.
  • _target_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.
  • _timezone_ : Fuseau horaire représenté dans _timestamp_.