Pour accéder au tableau des alertes, cliquez sur le menu “Alertes” à gauche. Un grand tableau s'affiche comme si dessous.
Par défaut, certaines colonnes ne sont pas affichées afin de limiter la taille de chaque ligne et de s'adapter à toutes les tailles d'écrans.
Au besoin vous pouvez afficher les colonnes qui sont cachées par défaut via le bouton “Afficher/masquer les colonnes” situé en haut à droite. Voir l'image ci-dessous dans l'encadré rouge:
Le menu apparaît juste en dessous, décochez la case “Auto” pour pouvoir sélectionner les colonnes que vous souhaitez afficher ou cacher.
Les colonnes suivantes sont cachées par défaut:
Vous pouvez faire une recherche basique comme par exemple filtrer sur les groupes contenant les lettres “serv”. Et vous aurez un affichage comme ceci.
Fonctionnalité existante sur les versions supérieures à 3.2.5.
Mais il existe des mots clés qui vous permettent soit de configurer votre widget de tableau de bord ou d'affiner votre recherche. Voici la liste des mots-clés:
Le screen avec “VOIP||té”:
Voici un exemple sur une widget du tableau de bord d' “Alertes en cours”. Il y a une section filtre à droite. Je vais donc filtrer les alertes en éliminant les erreurs de niveau inconnu. Je vais donc indiqué !inconnu dans le filtre des alertes. Comme ci-dessous.
Une fois sauvegardé, vous pouvez constater que le filtre est bien ajouté sur votre widget de tableau de bord.
Par défaut, le tableau affiche les erreurs selon la priorité de chaque service. Il y a 7 niveaux disponibles (comme pour le modèle OSI). Cela permet de trier automatiquement les erreurs. Le niveau 1 étant le plus critique.
Par défaut, pour le pattern de supervision Windows ou Linux les priorités des services sont hiérarchisées de la sorte.
Cette nomenclature de base s'explique de la façon suivante: Si le ping ne répond pas, c'est que le nœud est injoignable donc pas la peine d'afficher le reste. Si la charge CPU est à 100%, il est normal que les requêtes SNMP échouent et le problème a traité est la charge processeur. Si SNMP n'est pas configuré, on n'affiche que la ligne du CPU. Il n'est donc pas nécessaire d'afficher les autres erreurs qui feraient doublon.
Exemple: mon serveur Houston qui a un problème de PING (noté l'utilisation d'un filtre de recherche ).
Si je cliques dessus, je peux pourtant voir qu'il y a 4 services en erreurs. Le ping + les 3 services SNMP de base. Dans l'exemple ci dessous, le service “Processeur” a été acquitté.
Le Ping ayant la plus haute priorité (1 par défaut), le tableau d'alerte a éliminé l'ensemble des erreurs de niveau supérieur.
Si vous souhaitez modifier les priorités des services sur un nœud, vous pouvez vous baser sur le tuto suivant: Appliquer des services sur vos nœuds
Prenons un serveur Esia classique, nous avons une partie liée au matériel qui sera supervisée par le pattern Linux qui a les priorités de services de base comme ceci :
J’ajouterais le service testant les IO disques (CHECK_SNMP_LINUX_IO). Je lui mettrais la priorité de niveau 4 car si mes IO sont saturées ma base de données risque d’être KO ou mon serveur apache très lent. Nous considérons donc que la priorité en dessous de 4 est vient d’un problème « matériel ».
Pour la partie logiciel, voici la liste des processus fonctionnant sur notre serveur:
Je vais rajouter les services suivants en partant du plus critique vers le moins ou en partant refaisant la chaîne de dépendance.
Ainsi dès que j'ai une erreur sur mon serveur, j'ai déjà un diagnostic rien qu'en lisant la première ligne dans mon tableau de bord.
Au final, voici la liste de tous les services avec leurs priorités respectives.