Page History

Configuration

Fonctionnement

Configuration

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

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

Par 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/broker-module-livedata.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:

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 à 0.0.0.0

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

service shinken-arbiter restart

Activation du SSL

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:

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                  /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 rédémarrer l'Arbiter:

service shinken-arbiter restart

Authentification

L'API du module broker-module-livedata est accessible à l'adresse suivante:

http://<ip-broker>:<port-module>/

Les appels effectués à l'API demandent l'utilisation d'un token d'identification. Ce token est spécifié dans le fichier de configuration du module (/etc/shinken/modules/broker-module-livedata.cfg).

Il est fortement recommandé de changer ce token.

Ce token doit être ajouté en paramètre à chaque requête sous peine de recevoir une erreur 401 de la part de l'API.

Par exemple:

http://192.168.1.59:50100/api/v1/host/408cd29ad37611e8810e0800277b7e16?token=ak5zv6t5s25r6g4

Chaque appel à l'API renvoie une réponse au format JSON.

Utilisation

Les routes suivantes sont mise à disposition par l'API. Chaque appel doit contenir dans ses paramètres le token d'identification décrit dans la section précédente.

GET /api/v1/all-monitored-elements

Cet appel permet de recevoir la liste des uuids de tous les hôtes et clusters ainsi que de leurs checks.

Réponse

Codes de retour

Retour du code 200

• hosts : 
  • host_uuid : text
  • checks :
    • check_uuid : text
• clusters :
  • cluster_uuid : text
  • checks :
    • check_uuid : text

Exemple

GET /api/v1/host

Cet appel permet de recevoir la liste des uuids de tous les hôtes ainsi que de leurs checks.

Réponse

Codes de retour

Retour du code 200

• hosts : 
  • host_uuid : text
  • checks :
    • check_uuid : text

Exemple

GET /api/v1/host/{uuid}

Cet appel permet de recevoir des informations sur un hôte.

Paramètres

Réponse

Codes de retour

Retour du code 200

• host_uuid : text
• host_name : text
• host_display_name : text
• status : text
  • OK
  • WARNING
  • CRITICAL
  • UNKNOWN
  • MISSING-DATA
  • SHINKEN-INACTIVE
• status_since : epoch (en secondes)
• context : text
  • NOTHING
  • ACKNOWLEDGED
  • PARTIAL-ACKNOWLEDGED
  • INHERITED-ACKNOWLEDGED
  • DOWNTIME
  • PARTIAL-DOWNTIME
  • INHERITED-DOWNTIME
  • FLAPPING
  • PARTIAL-FLAPPING
  • DISABLED

• business_impact : 0, 1, 2, 3, 4, 5

• output : text

• long_output : text

Exemple

GET /api/v1/check-on-host/{uuid}

Cet appel permet de recevoir des informations sur un check attaché à un hôte.

Paramètres

Réponse

Codes de retour

Retour du code 200

• check_uuid : text
• check_name : text
• check_display_name : text
• status : text
  • OK
  • WARNING
  • CRITICAL
  • UNKNOWN
  • MISSING-DATA
  • SHINKEN-INACTIVE
• status_since : epoch (en secondes)
• context : text
  • NOTHING
  • ACKNOWLEDGED
  • PARTIAL-ACKNOWLEDGED
  • INHERITED-ACKNOWLEDGED
  • DOWNTIME
  • PARTIAL-DOWNTIME
  • INHERITED-DOWNTIME
  • FLAPPING
  • PARTIAL-FLAPPING
  • DISABLED
• output : text
• business_impact : 0, 1, 2, 3, 4, 5
• long_output : text
• host_uuid : text
• host_name : text
• host_display_name : text
  

Exemple

GET /api/v1/cluster

Cet appel permet de recevoir la liste des uuids de tous les clusters ainsi que de leurs checks.

Réponse

Codes de retour

Retour du code 200

clusters : 

• cluster_uuid : text
• checks :
  • check_uuid : text

Exemple

GET /api/v1/cluster/{uuid}

Cet appel permet de recevoir des informations sur un cluster.

Paramètres

Réponse

Codes de retour

Retour du code 200

• cluster_uuid : text
• cluster_name : text
• cluster_display_name : text
• status : text
• • OK
  • WARNING
  • CRITICAL
  • UNKNOWN
  • MISSING-DATA
  • SHINKEN-INACTIVE
• status_since : epoch (en secondes)
• context : text
• • NOTHING
  • ACKNOWLEDGED
  • PARTIAL-ACKNOWLEDGED
  • INHERITED-ACKNOWLEDGED
  • DOWNTIME
  • PARTIAL-DOWNTIME
  • INHERITED-DOWNTIME
  • FLAPPING
  • PARTIAL-FLAPPING
  • DISABLED
• business_impact : 0, 1, 2, 3, 4, 5
• output : text
• long_output : text

Exemple

GET /api/v1/check-on-cluster/UUID

Cet appel permet de recevoir des informations sur un check attaché à un cluster.

Paramètres

Réponse

Codes de retour

Retour du code 200

• check_uuid : text
• check_name : text
• check_display_name : text
• status : text
  • OK
  • WARNING
  • CRITICAL
  • UNKNOWN
  • MISSING-DATA
  • SHINKEN-INACTIVE
• status_since : epoch (en secondes)
• context : text
  • NOTHING
  • ACKNOWLEDGED
  • PARTIAL-ACKNOWLEDGED
  • INHERITED-ACKNOWLEDGED
  • DOWNTIME
  • PARTIAL-DOWNTIME
  • INHERITED-DOWNTIME
  • FLAPPING
  • PARTIAL-FLAPPING
  • DISABLED
• output : text
• business_impact : 0, 1, 2, 3, 4, 5
• long_output : text
• cluster_uuid : text
• cluster_name : text
• cluster_display_name : text
  

Exemple

Obtenir un UUID

Hôtes et Clusters

Pour récupérer l'UUID d'un hôte ou d'un cluster il suffit de se rendre dans sa page de configuration sur l'UI de Configuration, ou de le sélectionner dans l'UI de Visualisation. Il se trouve alors dans l'URL de la page comme sur les screens suivants:

Il est aussi possible de récupérer les uuid directement par le biais des requêtes apis : all-monitored-elements, host et cluster.

Checks attachés

Pour récupérer l'UUID d'un check attaché à un hôte ou à un cluster,

Obtenir un uuid

il suffit de se rendre dans sa page de configuration sur l'UI de Configuration

en y rajoutant l'UUID de l'hôte ou du cluster sur lequel il est attaché, suivi d'un tiret. Dans l'interface de Visualisation, il peut être trouvé directement dans l'URL en ouvrant le détail du check:

Macros Shinken

Des macros sont également disponibles sur Shinken pour utiliser l'UUID d'un hôte/cluster/check.

Exemple d'utilisation

Ces macros peuvent être utilisées par exemple dans les URL externes. Par exemple:

L'URL externe de cet hôte amène directement sur le volet Graphiques de l'hôte en question

Test de performance

Sur une machine avec 1782 hôtes, le broker n'a aucune latence à la réception de 15 requêtes api par seconde de 10 sources différentes (150 au total) et renvoi le résultat en moins de 0.01 seconde.