| Panel | ||||
|---|---|---|---|---|
| ||||
|
Démarrage du démon
Au démarrage le démon affiche plusieurs logs contenant ses informations dont :
- Ses limites système en nombre de fichiers ouvrables, et nombre de threads/processus
| Code Block | ||
|---|---|---|
| ||
[YYYY-MM-DD HH:MM:SS] INFO : [ scheduler-name ] [ SYSTEM ] System resource number of open files is set to (soft:1024 / hard:1024 ) (from parameter max_file_descriptor_limit) [YYYY-MM-DD HH:MM:SS] INFO : [ scheduler-name ] [ SYSTEM ] System resource number of processes/threads is set to (soft:unlimited / hard:unlimited ) (set at system max values) |
- Sur quelle(s) interface(s) le démon écoute
S'il écoute sur toutes les interfaces:
| Code Block | ||
|---|---|---|
| ||
[YYYY-MM-DD HH:MM:SS] INFO : [ scheduler-name ] [schedulerdeamon] The daemon listens on all network interfaces. |
S'il écoute sur une interface précise:
| Code Block | ||
|---|---|---|
| ||
[YYYY-MM-DD HH:MM:SS] INFO : [ scheduler-name ] [schedulerdeamon] The daemon listens on the IP_INTERFACE:PORT_INTERFACE network interface. |
Les fichiers de log du Scheduler sont situés dans le dossier /var/log/shinken/. Pour plus d'informations, consultez la page Fichiers Logs.
Surcharge serveur en activité disque, ralentissant l'écriture des logs
Si le serveur hébergeant le démon est surchargé en termes d'IO disques sur le volume qui héberge le fichier de log, alors ce dernier va mettre du temps à s'écrire et va ralentir tout le démon. Il faut alors si c'est faisable isoler le volume des disques sur un disque moins chargé pour ne pas ralentir le démon.
En cas de soucis vous aurez dans les lots l'entrée suivante:
| Code Block | ||
|---|---|---|
| ||
[YYYY-MM-DD HH:MM:SS] WARNING : [ LOGGER ] [YYYY-MM-DD HH:MM:SS] WARNING : [ LOGGER ] ---------------------------------------------------------------------------------------------------- [YYYY-MM-DD HH:MM:SS] WARNING : [ LOGGER ] [ WRITING ] The log writes time is very high (1.87s). Please look at your log disk performance. [YYYY-MM-DD HH:MM:SS] WARNING : [ LOGGER ] ---------------------------------------------------------------------------------------------------- [YYYY-MM-DD HH:MM:SS] WARNING : [ LOGGER ] |
Chargement des broks initiaux par un regenerator ( créateur d'objets des modules de broker ) et vérifier que c'est bien la même configuration charger entre les regenerators / scheduler / arbiter
Les logs suivants permettent de suivre le chargement de la configuration de supervision entre l'Arbiter les Schedulers jusqu'aux interfaces : webui / livestatus / livedata
Il existe 2 types d'identifiants de configuration ( représentation de la configuration )
- configuration_uuid: uuid de configuration totale généré par l'Arbiter
- configuration_part_id: id de la partie de configuration gérée par un Scheduler
Quand un Scheduler reçoit une nouvelle configuration de l'Arbiter, il log
| Code Block | ||
|---|---|---|
| ||
[YYYY-MM-DD HH:MM:SS] INFO : [ scheduler-name ] [schedulerdeamon] [ CONFIGURATION ] [ NEW ] Configuration received [ configuration_part_id=configuration_part_id, configuration_uuid=configuration_uuid, arbiter=arbiter_name, date=creation_date, ] |
- configuration_part_id: id de la partie de configuration spécifiquement gérée par ce Scheduler ( unique pour chaque Scheduler )
- configuration_uuid: uuid créé lors du démarrage de l'Arbiter qui correspond donc à l'id de la configuration géré par l'Arbiter
- creation_date: date du démarrage de l'Arbiter
- arbiter_name: nom de l'Arbiter qui a créé cette configuration
| Code Block | ||||
|---|---|---|---|---|
| ||||
[YYYY-MM-DD HH:MM:SS] INFO : [ scheduler-name ] [schedulerdeamon] [ CONFIGURATION ] [ NEW ] Configuration received [ configuration_part_id=1280, configuration_uuid=e551f7f93f2d45bfafae77fc302db7a2, arbiter=arbiter-master1, date=15-05-2020 15:13:38 ] |
Dans le cas où le scheduler n'est pas de la même version que l'arbiter et que l'option *mismatch_version_error* est activé sur l'arbiter:
| Code Block | ||
|---|---|---|
| ||
[YYYY-MM-DD HH:MM:SS] ERROR : [ scheduler-name ] Incompatible daemon version : Your Arbiter daemon is in version [XX.XX.XX-release.fr culmulative-patch-YY] while this daemon is in version [XX.XX.XX-release.fr culmulative-patch-YY]. Refusing this configuration. |
Dans le cas où le scheduler n'est pas de la même version que l'arbiter et que l'option *mismatch_version_error* est désactivé sur l'arbiter:
| Code Block | ||
|---|---|---|
| ||
[YYYY-MM-DD HH:MM:SS] WARNING : [ scheduler-name ] Incompatible daemon version : Your Arbiter daemon is in version [XX.XX.XX-release.fr culmulative-patch-YY] while this daemon is in version [XX.XX.XX-release.fr culmulative-patch-YY]. |
Quand un Scheduler est en train de charger sa nouvelle configuration, il log
Le log suivant apparaît si le Scheduler n'a pas fini de charger sa configuration est qu'il reçoit une demande de statut.
| Code Block | ||
|---|---|---|
| ||
[YYYY-MM-DD HH:MM:SS] INFO : [ scheduler-name ] [scheduler][0] Someone asks to get the raw stats (deamon Health) but the scheduler is not initialized |
Quand un Scheduler a fini de charger la nouvelle configuration reçu, il log :
| Code Block | ||
|---|---|---|
| ||
[YYYY-MM-DD HH:MM:SS] INFO : [ scheduler-name ] [schedulerdeamon] [ CONFIGURATION ] [ NEW ] Loaded in [loading_time]s => [ configuration_part_id=configuration_part_id, configuration_uuid=configuration_uuid, date=creation_date, author=arbiter_name ] |
- configuration_part_id: id de la partie de configuration géré par ce Scheduler (unique pour chaque Scheduler)
- configuration_uuid: uuid crée lors du démarrage de l'Arbiter qui correspond donc à l'id de la configuration géré par l'Arbiter
- creation_date: date du démarrage de l'Arbiter
- arbiter_name: nom de l'Arbiter qui a créé cette configuration
- loading_time: temps de chargement de la configuration
| Code Block | ||||
|---|---|---|---|---|
| ||||
[YYYY-MM-DD HH:MM:SS] INFO : [ scheduler-name ] [schedulerdeamon] [ CONFIGURATION ] [ NEW ] Loaded in [1.31168293953]s => [ configuration_part_id=1280 configuration_uuid=e551f7f93f2d45bfafae77fc302db7a2, author=arbiter-master1, date=15-05-2020 15:13:38] |
Erreur de cohérence des périodes de maintenance
Les périodes de maintenance ont une incohérence entre non identifiée qui consiste à ce qu'une période de maintenance va être démarrée deux fois, ce qui va poser soucis lors de son arrêt (l'hôte/check sera dans un état incohérent). Pour l'instant, nous n'avons pas trouvé la source de l'incohérence, mais nous avons mis des protections pour les éviter et corriger.
Au chargement de la rétention, on aura une entrée "ERROR":
| Code Block | ||
|---|---|---|
| ||
[YYYY-MM-DD HH:MM:SS] ERROR : [ scheduler-name ] [ DOWNTIME-INCOHERENCY ] The host Linux has bad downtime values (saved number of downtime=1, actual=0). We are fixing the values. Please report it to the support. |
Lors du second démarrage de la période de maintenance:
| Code Block | ||
|---|---|---|
| ||
[YYYY-MM-DD HH:MM:SS] ERROR : [ scheduler-name ] [ DOWNTIME-INCOHERENCY ] The downtime [Downtime id=1596532528600972 active=active type=fixed start=Tue Aug 4 11:16:06 2020 - end=Tue Aug 4 12:15:06 2020] on server got activated twice. This is a bug and MUST be reported to support for investigation. Thanks. |
Dans les deux cas, il faut récupérer les logs du Scheduler, et les donner en analyse au support Shinken.
Exécution de commandes externes reçues d'un Receiver
Lorsque le Receiver envoie des commandes externes au Scheduler, il est possible que ce dernier n'ait pas reçu de configuration de la part de l'Arbiter et qu'il ne soit pas en capacité d'exécuter ces commandes.
| Code Block | ||
|---|---|---|
| ||
[YYYY-MM-DD HH:MM:SS] INFO : [ scheduler-name ] [ BUS COMMANDS ] Get external commands (like recheck, set acknowledge, etc) from the Receiver receiver-master but i am not ready. Waiting for configuration from Arbiter. |
Dans le cas où, les commandes ont pu être exécutées :
| Code Block | ||
|---|---|---|
| ||
[YYYY-MM-DD HH:MM:SS] INFO : [ scheduler-name ] [ BUS COMMANDS ] Running 200 external commands (like recheck, set acknowledge, etc) received from the Receiver receiver-master |
Échanges par paquet de taille limité des Broks avec le Broker
Quand le broker demande les broks au Scheduler, ce dernier va avoir dans ses logs:
| Code Block | ||
|---|---|---|
| ||
[YYYY-MM-DD HH:MM:SS] INFO : [ scheduler-name ] [ GIVE BROKS ] [ broker-master ] Sending 5 broks (1.3kB) |
Si on se retrouve dans un cas où la limite du broks_packet_size est atteinte (sur les broks initiaux par exemple), on va avoir la ligne suivante:
| Code Block | ||
|---|---|---|
| ||
[YYYY-MM-DD HH:MM:SS] INFO : [ scheduler-name ] [ GIVE BROKS ] [ broker-master3 ] Sending 2588 broks (413.4kB) [chunk, still 1698 to send] |
En cas de problème de communication, il se peut qu'un paquet de broks soit perdu, dans ce cas, une réémission est faite pour éviter cette perte, on aura un WARNING suivant:
| Code Block | ||
|---|---|---|
| ||
[YYYY-MM-DD HH:MM:SS] WARNING: [ scheduler-name ] [ GIVE BROKS ] [ broker-master ] Packet number did mismatch "100d0ccf12de4665bf04f2150dcc97d5" != "0ca27bc3ea5440358c1194b5b7c3b4f4" : Re-sending broks (6.3kB) |
Log de performance de la boucle du scheduler
Dans la boucle du Scheduler, les logs ci-dessous permettent de connaître le temps d'exécution passé pour chaque action.
| Code Block | ||||
|---|---|---|---|---|
| ||||
[YYYY-MM-DD HH:MM:SS] INFO : [ scheduler-name ] [ SCHEDULER TIME ] [ === Loop start === ] [ Loop number=7885 ] ===-===-===-===-===-===-===-===-===-===-===-===-=== [YYYY-MM-DD HH:MM:SS] INFO : [ scheduler-name ] [ SCHEDULER TIME ] took [ 0.005 ]s to schedule checks, consume results and create broks [YYYY-MM-DD HH:MM:SS] INFO : [ scheduler-name ] [ SCHEDULER TIME ] took [ 0.005 ]s to update items context ( downtimes, acknowledge, flapping, root_problems, business values ) [YYYY-MM-DD HH:MM:SS] INFO : [ scheduler-name ] [ SCHEDULER TIME ] took [ 0.005 ]s to clean data ( cache, zombies, proxy, stats, notifications list ) [YYYY-MM-DD HH:MM:SS] INFO : [ scheduler-name ] [ SCHEDULER TIME ] took [ 0.005 ]s to check environment and update stats ( satellite_thread, time, retention, orphan, modules ) [YYYY-MM-DD HH:MM:SS] INFO : [ scheduler-name ] [ SCHEDULER TIME ] [ === Loop stop === ] [ Loop number=7884 ] [PERF] [ 0.082 ]s |
Afin d'avoir toutes les informations de DEBUG sur les performances du scheduler (boucle principale) il faut le lancer avec:
| Code Block | ||
|---|---|---|
| ||
SHINKEN_LOG_SCHEDULER_RECURRENT_TIMES_FLAG=1 /etc/init.d/shinken-scheduler -d start |
Logs d'erreur concernant des objets d’exécution de check qui restent en mémoire dans le Scheduler
Dans le cas où le Scheduler détecte que des objets d'exécution de checks ne sont pas bien nettoyés dans l'index de lancement ( par rapport au temps ).
Ceci peut résulter en deux logs d'ERROR :
- Signifie qu'un objet a été consommé, mais qu'il est peut-être encore présent dans l'index
| Code Block | ||
|---|---|---|
| ||
[YYYY-MM-DD HH:MM:SS] ERROR : [ scheduler-name ] [ SCHEDULING ] [ JOB-EXECUTION FAST INDEX ] The check XXXX is zombie without being cleaned (name=YYYY, was indexed at SSSSSS). Please report to your support. |
- Suite au premier dans la minute suivante, le Scheduler corrigera l'objet en trop.
| Code Block | ||
|---|---|---|
| ||
[YYYY-MM-DD HH:MM:SS] ERROR : [ scheduler-name ] [ JOB-EXECUTION FAST INDEX ] [ SCHEDULING ] [ JOB-EXECUTION FAST INDEX ] [PERF: lock aquired in 0.000s, done in 0.001s] Did remove 9 forgotten execution from 2 past seconds indexed (total number of seconds inside=63). |
Cette situation ne devrait pas être présente, donc nous vous conseiller d'activer des logs de debug plus détaillé concernant ce mécanisme via la variable d'environnement SHINKEN_LOG_SCHEDULER_JOB_EXECUTION_FAST_INDEX_FLAG
| Code Block | ||
|---|---|---|
| ||
SHINKEN_LOG_SCHEDULER_JOB_EXECUTION_FAST_INDEX_FLAG=1 /etc/init.d/shinken-scheduler -d restart |
Nous vous conseillons de fournir ces logs détaillés à votre support pour analyse.
Logs de WARNING concernant la suppression d'objets "notification" défectueux
Sur des installations datant d'avant la 02.03.03-U01, des objets "notifications" pouvaient rester indéfiniment en mémoire dans le Scheduler, mais sans être lancés.
- Ces objets de notification sont anciens et défectueux et ils sont vus comme "late" par le check du Scheduler.
- Une mise à jour via une version ou un patch, permet de supprimer ces objets.
- Ceci sera visible sur le premier démarrage du Scheduler avec le log suivant:
| Code Block | ||
|---|---|---|
| ||
[YYYY-MM-DD HH:MM:SS] WARNING: [ scheduler-name ] [RETENTION] [myhost] The notification [Notification 557481183 status:scheduled command:VOID ref:unknown t_to_go:Tue Feb 2 07:49:19 2021 (creation=Fri Apr 28 02:19:56 2017) (is_master=False) (on myhost)] was detected as invalid (bug from the old code), and was dropped. |
Logs de WARNING concernant les notifications qui ne sont pas envoyées à cause des périodes de notification
| Code Block | ||
|---|---|---|
| ||
[YYYY-MM-DD HH:MM:SS] WARNING: [ scheduler-name ] [ NOTIFICATION ] The notification for NOM DE L'HOTE OU DU CHECK was not send because notification_period NOM DE LA PERIODE DE TEMPS do not provide a date in the next 366 days ( either in the past or nothing is defined, or days are excluded ). |
Ce log sera affiché qu'une fois par jour au max par éléments afin d'évité de stature les logs.