Page History

Scroll Ignore

scroll-pdf	true
scroll-office	true
scroll-chm	true
scroll-docbook	true
scroll-eclipsehelp	true
scroll-epub	true
scroll-html	true

Panel

title	Sommaire

Table of Contents

style	none

Description

...

Activation du module

Le module broker-module-livedata est un module qui peut être activé seulement sur le démon Broker.

L'activation du module s'effectue en ajoutant le nom de ce module dans le fichier de configuration du démon Broker.
Pour se faire, ouvrez le fichier de configuration du Broker à l'emplacement /etc/shinken/modules/, et ajouter le nom de votre module "broker-module-livedata".

Code Block

language	js

define broker {
    [...]
    modules                   Module 1, Module 2, Module 3, broker-module-livedata
    [...]
}

Pour prendre en compte le changement de configuration, il faut ensuite redémarrer l'Arbiter:

Code Block
service shinken-arbiter restart

Configuration

Paramétrage

La configuration du module se trouve par défaut dans le fichier suivant : /etc/shinken/modules/broker-module-livedata.cfg

Exemple de fichier de configuration

Code Block

language	js

#===============================================================================
# broker module livedata
#===============================================================================
# Daemons that can load this module:
# - broker
# This module is an api getting information from the broker
#===============================================================================

define module {

    #======== Module identity =========
    # Module name. Must be unique
    module_name               broker-module-livedata

    # Module type (to load module code). Do not edit.
    module_type               broker_module_livedata

    #======== Listening address =========
    # host: IP address to listen to.
    #       note: 0.0.0.0 = all interfaces.
    host                      0.0.0.0
    # port to listen
    port                      50100

    # HTTPs part, enable if you want to set the visualisation interface listen in HTTPs mode
    # disabled by default. Set your own certificates.
    use_ssl                   0
    ssl_cert                  /etc/shinken/certs/server.cert
    ssl_key                   /etc/shinken/certs/server.key
    token                     change_me

    lang                      en

    #======== Broks getter in broker-module-livedata =========
    # These parameters allow some internal tuning in broks management in broker-module-livedata

    # Enable or disable late broks sets catchup
    # broker_module_livedata__broks_getter__activate_late_set_catchup                                1

    # Take extra broks sets to manage if more than this parameter sets are waiting
    # broker_module_livedata__broks_getter__nb_late_set_allowed_before_catchup                       10

    # Stop taking extra broks sets in catchup when we reach this number of broks
    # broker_module_livedata__broks_getter__catchup_broks_managed_by_module_in_a_catchup_loop        200000

    # Continue catchup if too much late broks sets remains after
    # broker_module_livedata__broks_getter__catchup_run_endless_until_nb_late_set_allowed_reached    0

    # Take the lock as soon as getter thread has some broks to manage
    # in order to attempt to reduce concurrent usage of CPU
    # broker_module_livedata__broks_getter__include_deserialisation_and_catchup_in_lock              0
}

Configuration de l'interface et du port d'écoute

Détails des sections composant le fichier de configuration

Identification du module

Il est possible de définir plusieurs instances de module de typePar défaut, le port de l'API rendue disponible par le module " broker-module-livedata" est 50100. Ce port peut être changé via le paramètre "port" dans le fichier de configuration du module: /etc/shinken/modules/. Chaque instance devra avoir un nom unique.

Nom

Type

Unité

Defaut

Commentaire

Code Block
module_name

Texte

---

broker-module-livedata

Nous vous conseillons de choisir un nom en fonction de l'utilisation du module pour que votre configuration soit simple à maintenir.

Code Block
module_type

Texte

---

broker-module-livedata

Ne peut être modifié.

Configuration de l'interface et du port d'écoute

Code Block

language	js

#======== Listening address ========= 
# host: IP address to listen to. 
# note: 0.0.0.0 = all interfaces. 
host 			0.0.0.0 
# port to listen 
port 			50100

Il est cfg.En plus du port, il est également possible de configurer l'interface réseau sur laquelle est mise à disposition l'API. Si par exemple l'API ne doit être accessible seulement via un réseau local, il est possible de n'écouter les requêtes que sur cette interface réseau.

Cette modification de configuration se fait via le paramètre "host" du fichier de configuration du module: /etc/shinken/modules/broker-module-livedata.cfg. Dans l'exemple suivant, l'API ne sera disponible que sur l'interface avec l'adresse 192.168.1.27:

Les paramètres suivants permettent de configurer l'accès à l'API :

Code Block

language	bash
title	/etc/shinken/modules/broker-module-livedata.cfg

define module {
    [...]
    host                      192.168.1.27
    [...]
}

L'API du module est par défaut mise à disposition sur toutes les interfaces: le paramètre "host" est à

Nom

Type

Unité

Défaut

Commentaire

Code Block
host

Texte

Adresse IPv4

0.0.0.0

Pour prendre en compte le changement de configuration, il faut ensuite redémarrer l'Arbiter:

Code Block
service shinken-arbiter restart

Activation du SSL

L'interface réseau sur laquelle le module "broker-module-livedata" va écouter.

Code Block
port

Texte

Port réseau

50100

Port réseau sur lequel le module "

L'API du module est accessible via HTTP. Si pour des raisons de sécurité, cette API doit être accessible via HTTPS, il faut passer le paramètre "use_ssl" à 1 dans le fichier de configuration du module :

Code Blocklanguagebashtitle/etc/shinken/modules/

broker-module-livedata" va écouter.

Sécurisation de la communication avec le module

cfg

Code Block

language	js

define module {
    [...]
    # HTTPs part, enable if you want to set the visualisation interface listen in HTTPs mode
    # disabled by default. Set your own certificates. Set your own token, it is usefull to get access to the API
    use_ssl                   1
    ssl_cert                  			0
ssl_cert 			/etc/shinken/certs/server.cert
    ssl_key                   			/etc/shinken/certs/server.key


    [...]
}

Les paramètres "ssl_cert" et "ssl_key" permettent de spécifier la clé et le certificat SSL à utiliser pour la connexion.

Pour prendre en compte le changement de configuration, il faut ensuite redémarrer l'Arbiter:

Code Blockservice shinken-arbiter restart

token 				change_me

L'API du module est accessible via HTTP. Il est recommendé d'utiliser le protocole HTTPS pour chiffrer la communication avec le module, et donc chiffrer le token d'accès.

Si pour des raisons de sécurité, cette API doit être accessible via HTTPS, il est possible de configurer les certificats avec les paramètres suivants :

Nom Type Unité Défaut Commentaire

Code Block
use_ssl

Booléen

---

0

Permet d'activer ou non l'utilisation du protocole HTTPS.

0 : Désactivé ( utilise HTTP )
1 : Activé ( utilise HTTPS )

Code Block
ssl_cert

Texte

Chemin

/etc/shinken/certs/server.cert

Chemin vers le certificat SSL utilisé par le protocole HTTPS.

Code Block
ssl_key

Texte

Chemin

/etc/shinken/certs/server.key

Chemin vers la clé SSL utilisée par le protocole HTTPS.

Code Block
token

Texte

---

change_me

Token utilisé lors des requêtes avec le module pour s'authentifier.

Warning
Si `use_ssl` est à `0`, alors ce token est lisible en clair ( non chiffré ) dans les requêtes faites au module.

Absorption des broks ( éléments de supervision )

Le fonctionnement du thread de récupération des broks de ce module peut être configuré via certains paramètres, afin de modifier son "agressivité".

Pendant la mise à jour des données de supervision, le module ne peut pas répondre aux requêtes via son API.

Warning
Une mauvaise configuration de ces paramètres peut compromettre le bon fonctionnement du module, se rapprocher du support si vous avez le moindre doute.

Principe de l'algorithme d'absorption des broks :

Attente de broks à traiter
Récupération de broks en retard ( fonctionnalité de rattrapage )
Désérialisation des broks
Entrée en session critique ( les requêtes à l'API sont bloquées )
Traitement des broks
Libérer la session critique et attendre de nouveaux broks, ou continuer l'absorption de broks ( en cas de retard important, on repart à l'étape 1. en restant sur la session critique )

CléValeur par défautDescriptionEntierEntier

Nom

Type

Unité

Défaut

Commentaire

Code Block
broker_module_livedata__broks_getter__activate_late_set_catchup

Booléen

---

1

Utilisation de la fonctionnalité de rattrapage pour absorber des broks en retard :

1 : ActiverActivé
0 : DésactiverDésactivé

Code Block
broker_module_livedata__broks_getter__nb_late_set_allowed_before_catchup

Nombre

Nombre de broks set

10

Nombre de brok set en attente tolérés.
Au-dessus de ce nombre, les brok set sont sont immédiatement récupérés par l'algorithme de rattrapage pour être traités maintenantimmédiatement.

Code Block
broker_module_livedata__broks_getter__catchup_broks_managed_by_module_in_a_catchup_loop

Nombre

Nombre de broks

200000

Nombre maximal de broks que que l'algorithme de rattrapage récupère avant de lancer le traitement.

Ce paramètre permet de borner la consommation mémoire et le temps d'exécution d'un tour de boucle de traitement.

Code Block
broker_module_livedata__broks_getter__catchup_run_endless_until_nb_late_set_allowed_reached

Booléen

---

1

Après traitement des broks, si le nombre de brok set en retard est trop élevé,

1 : continuer le rattrapage et absorber des broks en retard ( en restant sur la session critique ( "avec le lock" )
0 : arrêter l'absorption de brok et libérer la session critique ( rendre le lock )

Code Block
broker_module_livedata__broks_getter__include_deserialization_and_catchup_in_lock

Booléen

---

0

Dans le cas ou vous voulez disposer d'un maximum de temps CPU pour traiter les broks en retard, vous pouvez inclure la phase 2 ( Récupération de broks en retard ) et Phase 3 ( Désérialisation des broks ) dans la phase Critique ( Phase 4 )

La récupération des broks en retard, et la désérialisation se font alors dans la session critique ( Locké ) pour

1 : ActiverActivé
0 : DésactiverDésactivé

Page tree

Versions Compared

Old Version 16

New Version 17

Key

Description

Activation du module

Configuration

Exemple de fichier de configuration

Configuration de l'interface et du port d'écoute

Détails des sections composant le fichier de configuration

Identification du module

Configuration de l'interface et du port d'écoute

Activation du SSL

Sécurisation de la communication avec le module

Absorption des broks ( éléments de supervision )