Versions Compared

Old Version 8

changes.mady.by.user Soubrié Grégoire

Saved on

compared with

New Version Current

changes.mady.by.user Quentin Soubeyrol

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Scroll Ignore
scroll-pdftrue
scroll-officetrue
scroll-chmtrue
scroll-docbooktrue
scroll-eclipsehelptrue
scroll-epubtrue
scroll-htmltrue
Panel
titleSommaire

Table of Contents
stylenone

Contexte

Le modèle shinken-poller vous permet de superviser un hôte hébergeant le démon Le Poller.

  

 

Panel
titleSommaire

Table of Contents
maxLevel3

Description du modèle

Modèle d'hôte correspondant: shinken-poller    (notez

  • à noter que ce modèle hérite du modèle   shinken et shinken-deamon
)
  • .

Afin de superviser le démon Poller, le modèle  shinken-poller  appliqué à votre hôte, attachera plusieurs checks qui vérifieront la santé et la performance de ce démon.

Checks

Nom du checkDescriptionExemple de résultat

  • Poller - $KEY$ - Running Well

    Vérifie que le Poller est joignable sur le réseau avec son numéro de version, affiche ses tags et le statut de connexion avec les
schedulers
  • Schedulers.
Panel

Image Modified

  • Poller - $KEY$ - Performance

    Affiche les statistiques des performances de l'exécution des checks dans le Poller
    Si jamais le démon Arbiter est en exécution sur une machine virtuelle supervisé par
Vmware
  • VMware, alors le pourcentage de temps de vol de CPU ( CPU Ready ) sera affiché.
Panel

Image Modified

Paramétrage des checks

Les checks du Poller peuvent être configurés via des données fournies par le modèle.

Les données suivantes sont disponibles pour le Poller:

Nom de la donnéeDescriptionValeur par défautHérité du modèle d'hôte ou locale
SHINKEN_PROTOCOLProtocole utilisé pour établir la connexion avec le Pollerhttpshinken
CHECK_SHINKEN_TIMEOUTTimeout utilisé pour établir la connexion avec le Poller3shinken
POLLER_PORTPort utilisé pour établir la connexion avec le poller7771Locale
POLLER_LISTListe de Poller (Multi-démon)poller-master$($_HOSTPOLLER_PORT$)$Locale - Duplicate For EachDupliquer les checks ( voir la page Dupliquer des checks en fonction d'une liste de valeurs présentes dans la Donnée d'un hôte (duplicate_foreach) )
NB_CHECK_NB_CHECK_IN_TIMEOUT_TOLERATE

Nombre de checks en timeout provoquant une sortie en erreur du check

0Locale
POLLER_NB_CHECK_IN_TIMEOUT_TOLERATE

Nombre de checks en timeout provoquant une sortie en erreur du check

$_HOSTNB_CHECK_IN_TIMEOUT_TOLERATE$Locale
ACTIVE_POLLER_LATENCY

Latence de connexion (en secondes)  au-delà de laquelle le check sort en erreur

0.5Locale
THRESHOLD_CPU_STOLEN_WARNINGSeuil de cpu CPU volé (en pourcentage) sur une machine virtuelle supervisée par vmware avant VMware avant de déclencher un warning5shinken-deamon
THRESHOLD_CPU_STOLEN_CRITICALSeuil de cpu de CPU volé (en pourcentage) sur une machine virtuelle supervisée par vmware avant VMware avant de déclencher un critique10shinken-deamon

Données de performances

Les checks du modèle shinken-poller enregistrent des données de performance, qui peuvent ensuite être affichées dans l'interface de Visualisation sur l'Onglet GraphesGraphiques ou bien le Widget Graphique.

Nom du checkNom de la métriqueExplication

Poller - $KEY$ - Running Well

nb_check_in_timeout

Nombre de checks qui sont entrés en timeout sur le Poller pendant les 20 dernières minutes. Cette durée est configurable dans le fichier de configuration du Poller, avec l'option keep_timeout_time (par défaut 1200s)

Poller - $KEY$ - Performance

nb_action_done_per_sec

Nombre moyen de checks exécutés par le Poller (moyenne glissante calculée sur 1mn)

Poller - $KEY$ - Performance

poller_load_state

Booléen (0 ou 100) qui indique si le Poller a atteint sa charge maximale:

  • 0: Le Poller n'a pas atteint sa charge maximale, il peut encore exécuter des checks supplémentaires
  • 100: Le Poller a atteint sa charge maximale, il ne peut pas exécuter plus de checks.

Poller - $KEY$ - Performance

cpu_usage_percent

Pourcentage de temps processeur utilisé par le Poller

Poller - $KEY$ - Performance

used_ram_percent

Pourcentage de mémoire utilisée sur le serveur

Détail des commandes

Nom du check

Commande du check

Ligne de commande

Poller - $KEY$ - Performancecheck_shinken_poller!stats!$VALUE1$ $PLUGINSDIR$/check_shinken -H "$HOSTADDRESS$" -p "$ARG2$" --shinkenversion "$SHINKENVERSION$" -t poller -m $ARG1$ --active_poller_latency "$_HOSTACTIVE_POLLER_LATENCY$" --check_tolerate "$_HOSTNB_CHECK_IN_TIMEOUT_TOLERATE$" --timeout $_HOSTCHECK_SHINKEN_TIMEOUT$ -w $_HOSTTHRESHOLD_CPU_STOLEN_WARNING$ -c $_HOSTTHRESHOLD_CPU_STOLEN_CRITICAL$
Poller - $KEY$ - Running Wellcheck_shinken_poller!alive!$VALUE1$ $PLUGINSDIR$/check_shinken -H "$HOSTADDRESS$" -p "$ARG2$" --shinkenversion "$SHINKENVERSION$" -t poller -m $ARG1$ --active_poller_latency "$_HOSTACTIVE_POLLER_LATENCY$" --check_tolerate "$_HOSTNB_CHECK_IN_TIMEOUT_TOLERATE$" --timeout $_HOSTCHECK_SHINKEN_TIMEOUT$ -w $_HOSTTHRESHOLD_CPU_STOLEN_WARNING$ -c $_HOSTTHRESHOLD_CPU_STOLEN_CRITICAL$

Les modes dépréciés ("-m") :

  • api_connection
  • cpu_load
  • overload_protection

Interprétation des données de l'état de santé du Poller ( Poller - $KEY$ - Running Well )

Statistiques de l'état de santé du Poller

Le check "Poller - Running Well" vérifié l'état de santé du Poller supervisé.

Il remonte plusieurs informations sur le statut du Poller:

  • Une mention qui indique si le Poller est actif ou passif. Dans l'exemple, on a affaire à un Poller actif.
  • La liste des tags du Poller. Dans l'exemple, aucun tag n'est défini sur le Poller.
  • La latence de connexion avec le ou les schedulers Schedulers du royaume et des sous-royaumes.
Panel

Image RemovedImage Added

Description des erreurs


Problème de surcharge des disques constaté lors de l'écriture de logs

ErreurDescription de l'erreurAffichage

  • Disque des logs trop lent
En
  • : en cas de disques trop lent sur le volume des logs, le check sera mis en WARNING avec l'erreur suivante.


Panel

Image Modified

Exemple

Erreur d'un

état de santé dégradé du Poller

Lorsque le Poller rencontre des problèmes qui peuvent signifier un fonctionnement dégradé, ces problèmes sont également remontés dans le résultat du check "Poller - Running Well".

Lorsque certains checks ont un temps d'exécution supérieur aux différents seuils définis, ils sont répertoriés dans le résultat du check "Poller - Running Well" pour permettre d'avertir des potentielles erreurs sur ces checks ou du Poller.

Dans l'exemple, le check nous signale que 10 checks ont pris plus que 10 secondes pour s'exécuter pendant les 20 dernières minutes, et ont leur exécution a donc été arrêtée de force.

Panel

Image Removed

La durée de temps (en secondes) pendant laquelle les checks sont conservés dans l'ensemble des checks en timeout est configurable dans le fichier de configuration du Poller concerné.

Il est également possible de définir une seuil de tolérance afin d'afficher un avertissement seulement lorsqu'il y a plus qu'un certain nombre de checks en timeout. Pour cela, il faut modifier la donnée NB_CHECK_IN_TIMEOUT_TOLERATE dans l'hôte concerné dans la configuration.

Code Block
title/etc/shinken/pollers/mon_poller.cfg
define poller {
	...
    keep_timeout_time    1200
    ...
}

démon bloqué, qui doit être redémarré

  • Si un démon est dans un état bloqué, il doit être redémarré. Si c'est le cas:
    • les checks seront en ERROR avec le message suivant,
    • il faut ouvrir un ticket à votre support pour analyser le blocage
Panel

Image Added

Problème de conflits d'Arbiters

2 Arbiters ou plus veulent contacter le Poller.

  • Conflit d'Arbiters :

    Si le démon est contacté par des Arbiters qui ne sont pas sur la même architecture ( par exemple un Arbiter de Production, et un autre de l'environnement de Testing ), le check sera mis en CRITICAL .
Panel

Image Added

  • Conflit d'Arbiters qui ont le même nom d'Architecture :

 Comme dans le cas précédent, le démon est contacté par des Arbiters d'architectures différentes, mais qui ont le même nom. On sort également en CRITICAL mais en avertissant que les noms sont identiques, et en indiquant où changer le nom de vos architectures.

Panel

Image Added

Les serveurs ne sont pas à la même heure

  • Si le serveur n'est pas à la même heure que le serveur Arbiter ( qui fait office de référence ), une erreur CRITICAL sera levée, car des temps différents sur les serveurs va avoir des effets désastreux sur la cohérences des données de supervision.
Panel

Image Added

La dernière connexion de l'Arbiter remonte à trop longtemps

  • Si la dernière connexion de l'Arbiter remonte à trop de temps, le démon va lever un WARNING . Ceci peux être dû:
    • les Arbiters MASTER et SPARE sont réellement éteints.
    • les Arbiter MASTER et SPARE sont en train d'envoyer des configurations à d'autres démons, et ne peuvent donc pas contacter ce démon pour l'instant.


Panel

Image Added

Info

Le temps pris en compte comme limite de dernière connexion est de check_interval * max_check_attempts du démon ( définis dans sa configuration ).

Les valeurs par défauts sont de 60s * 3, soit 3 minutes.

Le démon a bloqué une tentative de chargement d'objet malveillant

Il est possible qu'un démon puisse détecter et bloquer une tentative d'injection d'objet malveillant par le biais de l'une de ses routes.

Un message est remonté :

  • le nombre total de ces tentatives que le démon a bloqué ce jour ( le compte commence à minuit ) ;
  • pour chacune des tentatives ( maximum 3 ) :
    • descriptif de l'objet que l'attaquant essaye de charger,
    • sa provenance de l'attaque, par exemple le nom de la route utilisée, et l'IP à la source de l'attaque,
    • sa date.
Panel

Image Added

Le démon est en cours d'arrêt

Lorsque le démon est en cours d'arrêt, le check le signale, et les informations relatives aux modules ne sont plus disponibles

Panel

Image Added

Exemple d'un état de santé dégradé du Poller

istiques de l'état de santé du Poller

Lorsque le Poller rencontre des problèmes qui peuvent signifier un fonctionnement dégradé, ces problèmes sont également remontés dans le résultat du check "Poller - Running Well".

Lorsque certains checks ont un temps d'exécution supérieur aux différents seuils définis, ils sont répertoriés dans le résultat du check "Poller - Running Well" pour permettre d'avertir des potentielles erreurs sur ces checks ou du Poller.


Dans l'exemple, le check nous signale que 10 checks ont pris plus que 10 secondes pour s'exécuter pendant les 20 dernières minutes, et ont leur exécution a donc été arrêtée de force.

Panel

Image Added

La durée de temps (en secondes) pendant laquelle les checks sont conservés dans l'ensemble des checks en timeout est configurable dans le fichier de configuration du Poller concerné.


Il est également possible de définir une seuil de tolérance afin d'afficher un avertissement seulement lorsqu'il y a plus qu'un certain nombre de checks en timeout. Pour cela, il faut modifier la donnée NB_CHECK_IN_TIMEOUT_TOLERATE dans l'hôte concerné dans la configuration.

Code Block
title/etc/shinken/pollers/mon_poller.cfg
define poller {
	...
    keep_timeout_time    1200
    ...
}

Interprétation des statistiques de performance du Poller ( Poller - $KEY$ - Performance )

La supervision d'un démon Poller présente un grand nombre de statistiques de performances qui permettent de visualiser le travail effectué par le Poller. Le Poller a pour rôle d’exécuter les checks.

Il est ainsi souvent un des premiers démons que l'on regarde lorsqu'on veut visualiser combien de checks sont exécutés. Aussi, pour dimensionner correctement une installation Shinken Entreprise, il est important de pouvoir visualiser combien de checks un Poller est capable d'exécuter pour pouvoir décider d'ajouter ou retirer des Pollers de la configuration.

Les checks du Poller fournis dans le pack Shinken fournissent donc un grand nombre de données sur les performances du Poller.

Statistiques générales sur l’exécution des checks

La première statistique remontée par le check est le nombre de checks effectués par seconde par le Poller supervisé.

Dans cet exemple, le Poller effectue 1.9 checks par seconde en moyenne, tous checks confondus.

Panel

Image Added

Dans le Résultat long du check "Poller - Performance", deux tableaux présentent des statistiques sur les temps d'exécution des checks dans le Poller.

  • Le premier tableau affiche les 5 checks consommant le plus de temps CPU parmi l'ensemble des checks exécutés sur le Poller. Dans ce tableau, pour chaque check est affiché le nom du check, l'hôte sur lequel il est accroché, et le temps d'exécution du check.
Panel

Image Added

  • Un deuxième tableau présente la répartition du temps d'exécution des checks. Dans le tableau en exemple, on voit que les checks exécutés sur ce Poller s'exécutent majoritairement en moins de 50ms.


Panel

Image Added

  • Si le temps moyen d’exécution des checks est très long, ou très court, il est possible de modifier les réglages des périodes de temps du tableau dans le fichier de configuration du Poller concerné. Dans le fichier de configuration du Poller en question, l'option "exec_stat_range" doit être modifiée

Interprétation des statistiques de performance du Poller ( Poller - $KEY$ - Performance )

La supervision d'un démon Poller présente un grand nombre de statistiques de performances qui permettent de visualiser le travail effectué par le Poller. Le Poller a pour rôle d'executer les checks.

Il est ainsi souvent un des premiers démons que l'on regarde lorsqu'on veut visualiser combien de checks sont exécutés. Aussi, pour dimensionner correctement une installation Shinken Entreprise, il est important de pouvoir visualiser combien de checks un Poller est capable d'exécuter pour pouvoir décider d'ajouter ou retirer des Pollers de la configuration.

Les checks du Poller fournis dans le pack Shinken fournissent donc un grand nombre de données sur les performances du Poller.

Statistiques générales sur l’exécution des checks

La première statistique remontée par le check est le nombre de checks effectués par seconde par le Poller supervisé.

Dans cet exemple, le Poller effectue 1.9 checks par seconde en moyenne, tous checks confondus.

Panel

Image Removed

Dans le Résultat long du check "Poller - Performance", deux tableaux présentent des statistiques sur les temps d'exécution des checks dans le Poller.

  • Le premier tableau affiche les 5 checks consommant le plus de temps CPU parmi l'ensemble des checks exécutés sur le Poller. Dans ce tableau, pour chaque check est affiché le nom du check, l'hôte sur lequel il est accroché, et le temps d'exécution du check.
Panel

Image Removed

Un deuxième tableau présente la répartition du temps d'exécution des checks. Dans le tableau en exemple, on voit que les checks exécutés sur ce Poller s'exécutent majoritairement en moins de 50ms.
Panel

Image Removed

  • Si le temps moyen d’exécution des checks est très long, ou très court, il est possible de modifier les réglages des périodes de temps du tableau dans le fichier de configuration du Poller concerné.Dans le fichier de configuration du Poller en question, l'option "exec_stat_range" doit être modifiée.
Code Block
title/etc/shinken/pollers/mon_poller.cfg
define poller {
...
# Ranges for the check : poller statistics
#exec_stat_range    50, 100, 200, 300, 400, 1000, 5000, 15000
...
}

Charge du Poller

Le check du Poller fournit aussi la charge du Poller. Il s'agit d'un indicateur général indiquant si le Poller peut encore supporter des checks supplémentaires, ou si il est chargé au maximum. Cet indicateur n'est pas lié aux autres indicateurs de performances de la machine (File d'attente CPU, mémoire).

Panel

Image Removed

Une pastille orange précédant la mention "Poller load" signifie que le Poller ne peut plus prendre de checks supplémentaires. Cette pastille indique que le Poller fonctionne à la vitesse maximale qui lui est permise par le processeur.

C'est donc un signe indiquant qu'il faudrait ajouter un Poller supplémentaire dans l'architecture Shinken.

Panel

Image Removed

Utilisation du CPU

Le Poller se limite intelligemment selon différents critères pour éviter de surcharger inutilement la machine sur laquelle il est exécuté. Le premier critère de limitation est l'utilisation du CPU de la machine par le démon (et l'exécution des checks).

Si le Poller se rend compte que le CPU de la machine sur laquelle il est exécuté est surchargé, il se régule pour exécuter moins de checks et éviter de rendre la machine inutilisable.

Dans le check "Poller - Performance", la quantité de CPU utilisée par les checks est affichée dans le Résultat du check.

Panel

Image Removed

Si le CPU de la machine hébergeant le Poller est utilisé de manière intensive, le résultat du check "Poller - Performance" avertit de l'utilisation trop élevée du CPU. Dans ce cas, le Poller se limite et n’exécute plus de checks supplémentaires tant que l'utilisation du CPU est trop élevée.

La ligne indiquant la charge du Poller indique alors que le CPU est surchargé.

Panel

Image Removed

Utilisation de la mémoire (RAM)

Si le CPU n'est pas le facteur limitant pour le fonctionnement du Poller, l'état de la mémoire du serveur est alors vérifiée. Dans le résultat du check "Poller - Performance", l'utilisation de la mémoire sur le serveur est indiquée.

Panel

Image Removed

Si l'utilisation de la mémoire (RAM) sur le serveur dépasse le seuil définit dans la configuration du Poller, le résultat du check "Poller - Performance" affiche une avertissement indiquant l'utilisation excessive de la mémoire. Lorsque cet avertissement est affiché, le Poller n'exécute plus de checks supplémentaires tant que l'utilisation de la mémoire est supérieure au seuil défini.

Panel

Image Removed

Comme mentionné précedemment, le réglage du seuil est effectué dans le fichier de configuration du Poller concerné
  • .
Code Block
title/etc/shinken/pollers/mon_poller.cfg
define poller {
...
# PercentageRanges offor usedthe physicalcheck RAM: beyond which the poller will not launch any new check
max_ram_percentpoller statistics
#exec_stat_range    50, 100, 200, 300, 400, 1000, 5000, 9515000
...
}
Le nombre de processus dans la file d'attente du processeur

Charge du Poller


Le Poller possède une dernière mesure de performance qu'il observe et selon laquelle il limite son activité. Après la vérification de l'utilisation du CPU du Poller et de la mémoire du serveur, le Poller vérifie le nombre de processus dans la file d'attente du processeur.

En fonction de la limite de processus dans la file d'attente du processeur, le Poller décide si il faut exécuter des checks supplémentaires.

Le nombre de processus dans la file d'attente du processeur est affiché dans le résultat du check "Poller - Performance".

Panel

Image Removed

Le nombre de processus dans la file d'attente du processeur est aussi accompagné d'une pastille indiquant le statut de cette mesure. Lorsque le nombre de processus est supérieur à la limite définie dans la configuration, cette pastille indique ce dépassement.

Dans ce cas, le Poller n'exécutera plus de checks supplémentaires tant que le nombre de processus dans la file d'attente du processeur sera supérieur au seuil choisi.

Panel

Image Removed

Le seuil mentionné précedemment se définit dans le fichier de configuration du Poller concerné. On note que ce seuil se définit par coeur du processeur, et pas globalement pour le processeur.

Ainsi, avec une limite définie à 3, et un processeur possédant 4 cœurs, le Poller ne se limitera que lorsqu'il y a plus de 12 processus dans la file d'attente du processeur.

Code Block
title/etc/shinken/pollers/mon_poller.cfg
define poller { ... # Number of maximum runnings processes in the CPU Queue per CPU. Default value is 4. max_cpu_queue_per_cpu 4 ... }

check du Poller fournit aussi la charge du Poller. Il s'agit d'un indicateur général indiquant si le Poller peut encore supporter des checks supplémentaires, ou si il est chargé au maximum.

Cet indicateur n'est pas lié aux autres indicateurs de performances de la machine (File d'attente CPU, mémoire).

Panel

Image Added



Une pastille orange précédant la mention "Poller load" signifie que le Poller ne peut plus prendre de checks supplémentaires. Cette pastille indique que le Poller fonctionne à la vitesse maximale qui lui est permise par le processeur.

C'est donc un signe indiquant qu'il faudrait ajouter un Poller supplémentaire dans l'architecture Shinken.

Panel

Image Added

Utilisation du CPU

Le Poller se limite intelligemment selon différents critères pour éviter de surcharger inutilement la machine sur laquelle il est exécuté. Le premier critère de limitation est l'utilisation du CPU de la machine par le démon ( et l'exécution des checks ).

Si le Poller se rend compte que le CPU de la machine sur laquelle il est exécuté est surchargé, il se régule pour exécuter moins de checks et éviter de rendre la machine inutilisable.

Dans le check "Poller - Performance", la quantité de CPU utilisée par les checks est affichée dans le Résultat du check.

Panel

Image Added

Si le CPU de la machine hébergeant le Poller est utilisé de manière intensive, le résultat du check "Poller - Performance" avertit de l'utilisation trop élevée du CPU. Dans ce cas, le Poller se limite et n’exécute plus de checks supplémentaires tant que l'utilisation du CPU est trop élevée.

La ligne indiquant la charge du Poller indique alors que le CPU est surchargé.

Panel

Image Added

Vol du CPU


Seulement si votre machine virtuelle est hébergé sur un hyperviseur VMWare


  • Votre machine à du vol de CPU :

    Si le CPU se fait voler trop de temps de calcul, le check sera mis en WARNING  ou en CRITIQUE
    ( en fonction du taux de vol fixé par défaut ou  indiqué par l'utilisateur ).
Panel

Image Added



Panel

Image Added

Utilisation de la mémoire ( RAM )

Si le CPU n'est pas le facteur limitant pour le fonctionnement du Poller, l'état de la mémoire du serveur est alors vérifiée.

Dans le résultat du check "Poller - Performance", l'utilisation de la mémoire sur le serveur est indiquée.


Panel

Image Added

Si l'utilisation de la mémoire ( RAM ) sur le serveur dépasse le seuil définit dans la configuration du Poller, le résultat du check "Poller - Performance" affiche une avertissement indiquant l'utilisation excessive de la mémoire.

Lorsque cet avertissement est affiché, le Poller n'exécute plus de checks supplémentaires tant que l'utilisation de la mémoire est supérieure au seuil défini.

Panel

Image Added

Comme mentionné précédemment, le réglage du seuil est effectué dans le fichier de configuration du Poller concerné.

Code Block
title/etc/shinken/pollers/mon_poller.cfg
define poller {
...
# Percentage of used physical RAM beyond which the poller will not launch any new check
max_ram_percent           95
...
}

Le nombre de processus dans la file d'attente du processeur

Le Poller possède une dernière mesure de performance qu'il observe et selon laquelle il limite son activité. Après la vérification de l'utilisation du CPU du Poller et de la mémoire du serveur, le Poller vérifie le nombre de processus dans la file d'attente du processeur.

En fonction de la limite de processus dans la file d'attente du processeur, le Poller décide si il faut exécuter des checks supplémentaires.

Le nombre de processus dans la file d'attente du processeur est affiché dans le résultat du check "Poller - Performance".

Panel

Image Added

Le nombre de processus dans la file d'attente du processeur est aussi accompagné d'une pastille indiquant le statut de cette mesure. Lorsque le nombre de processus est supérieur à la limite définie dans la configuration, cette pastille indique ce dépassement.

Dans ce cas, le Poller n'exécutera plus de checks supplémentaires tant que le nombre de processus dans la file d'attente du processeur sera supérieur au seuil choisi.

Panel

Image Added

Le seuil mentionné précédemment se définit dans le fichier de configuration du Poller concerné. On note que ce seuil se définit par cœur du processeur, et pas globalement pour le processeur.

Ainsi, avec une limite définie à 3, et un processeur possédant 4 cœurs, le Poller ne se limitera que lorsqu'il y a plus de 12 processus dans la file d'attente du processeur.

Code Block
title/etc/shinken/pollers/mon_poller.cfg
define poller {
...
# Number of maximum runnings processes in the CPU Queue per CPU. Default value is 4.
max_cpu_queue_per_cpu    4
...
}

Erreur d'un démon bloqué, qui doit être redémarré

  • Si un démon est dans un état bloqué, il doit être redémarré. Si c'est le cas:
    • les checks seront en ERROR avec le message suivant,
    • il faut ouvrir un ticket à votre support pour analyser le blocage
Panel

Image Added

Le démon a bloqué une tentative de chargement d'objet malveillant

Il est possible qu'un démon puisse détecter et bloquer une tentative d'injection d'objet malveillant par le biais de l'une de ses routes.

Un message est remonté :

  • le nombre total de ces tentatives que le démon a bloqué ce jour ( le compte commence à minuit ) ;
  • pour chacune des tentatives ( maximum 3 ) :
    • descriptif de l'objet que l'attaquant essaye de charger,
    • sa provenance de l'attaque, par exemple le nom de la route utilisée, et l'IP à la source de l'attaque,
    • sa date.
Panel

Image Added

Le démon est en cours d'arrêt

Lorsque le démon est en cours d'arrêt, le check le signale, et les informations relatives aux modules ne sont plus disponibles

Panel

Image Added