Le WebService-receiver est le module qui permet de recevoir des résultats passifs pour des hôtes ou checks via HTTP(s).
If data is POSTed to this page, it will validate the data to determine if it is a service or host check result and submit the data to the Shinken external command queue.
La configuration se défini dans le fichier de configuration du module (présent par défaut dans /etc/shinken/modules/webwervice-reactionner.cfg ).
#===============================================================================
# WebService-Reactionner (webservice)
#===============================================================================
# Daemons that can load this module:
# - receiver
# This module is a webservice that can be used to send checks to Shinken Enterprise
# as POST HTTP(s)
#===============================================================================
define module {
#======== Module identity =========
# Module name. Must be unique
module_name webservices-receiver
# Module type (to load module code). Do not edit.
module_type ws_arbiter
#======== Listening address =========
# host: IP address to listen to.
# note: 0.0.0.0 = all interfaces.
host 0.0.0.0
# port to listen
port 7760
# HTTPs part, enable if you want to set the listening for HTTPS instead of default HTTP.
# disabled by default. Set your own certificates.
use_ssl 0
ssl_cert /etc/shinken/certs/server.cert
ssl_key /etc/shinken/certs/server.key
#======== HTTP authentification =========
# You can use HTTP basic authentification method for this module.
# If username is set to anonymous and password is commented, then
# no authentification will be required.
username anonymous
#password secret
} |
Les valeurs peuvent être :
Pour activer le module, ajouter simplement à votre Reciever le webservices-receiver a la liste des modules dans le fichier de configuration du reactionner.cfg Sur une architecture distribuée importante, si vous avez plusieurs Recievers, vous pourrez activer un module webservices-receiver par Receiver. |
Le webservices-reactionner attends en reception des commandes POSTs.
Utilisé curl ou des appels HTTP dans vos programmes ou script
Paramètre de l'appel
| Nom | Description |
|---|---|
time_stamp | (optionnel) date pour que Shinken puisse déterminer a quel moment a eu lieu la mesure. Par défaut, ce sera la date d'appel de l'API |
host_name | Nom de l'hôte cible |
service_description | Nom du check cible ( si résultat d'un check ) |
return_code | Check: 0 => OK, 1 => WARNING, 2 = CRITICAL, 3 => UNKNOWN Hôte: 0 => OK, 1,2,3 => CRITIQUE |
output | Résultat du check |
long_ouput | Résultat long du check A confirmer si présent |
perf_data ????? | au format normal des métriques (voir la page Les Sondes pour plus de détail ) A confirmer si présent |
Exemple:
curl -u user:password -d "time_stamp=$(date +%s)&host_name=host-checked&service_description=service-checked&return_code=0&output=Everything OK" http://shinken-srv:7760/push_check_result |
Paramètre de l'appel
| Nom | Description |
|---|---|
time_stamp | (optionnel) date pour que Shinken puisse déterminer a quel moment a eu lieu la mesure. Par défaut, ce sera la date d'appel de l'API |
host_name | Nom de l'hôte cible |
service_description | Nom du check cible ( si résultat d'un check ) |
comment | le commentaire de la prise en compte (optionnel) |
notify | 1 ou 0 pour notifier les contacts qui sont signalé sur l'équipement comme recevant les notifications de changement sur cette élément. |
| Author | Par défaut "anonyme". Il peut correspondre un utilisateur lambda non déclaré dans Shinken Enterprise. A confirmer |
| sticky | 1 par défaut. Si 1 alors le contexte acknowledge s'enlève des que l'état repasse OK, si 2 le contexte acknowledge s'enlève des le changement d'un état peu importe lequel ("critical to warning", "warning to critical" par exemple) A confirmer |
Exemple:
curl -u user:password -d "time_stamp=$(date +%s)&host_name=host-checked&service_description=service-checked&comment=Nous sommes entrain de corriger le problème¬ify=1" http://shinken-srv:7760/acknowledge |