Versions Compared

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

Description

Le receiver-module-webservice est Le WebService-receiver est le module qui permet de recevoir des résultats passifs pour des hôtes ou checks via statuts et des contextes d'éléments en mode Passif ( voir la page Mode actif et mode passif ) via une API HTTP(s).

Configuration du module Webservice

Ce module met à disposition une écoute HTTP qui écoute les requêtes HTTP POST et effectue des actions sur hôtes, clusters et checks.

  • Le Web Service Le module écoute sur port TCP 7760 TCP 7760 ( par défaut ). 
  • Il supporte les accès authentifiés ou anonymes. 

La configuration se défini définit dans le fichier de configuration du module ( présent par défaut dans /etc/shinken/modules/ws-receiver.cfg ). receiver-module-webservice.cfg ). 

Ce module permet notamment de recevoir et traiter les statuts envoyés par les traps SNMP ( Voir la page Script d'interprétation des traps avec le module receiver-module-webservice )

Activation du module

Le module receiver-module-webservice est un module qui peut être activé seulement sur le démon Receiver.

  • L'activation du module s'effectue en ajoutant le nom de ce module dans le fichier de configuration du démon Receiver.
  • Pour se faire, ouvrez le fichier de configuration du Receiver à l'emplacement /etc/shinken/receivers/nom_du_receiver.cfg, et ajouter le nom de votre module "receiver-module-webservice".

Exemple : par défaut, nous livrons un module dont le nom est "receiver-module-webservice" :

Code Block
define receiver {
    [...]
    modules                   Module 1, Module 2, Module 3, receiver-module-webservice
    [...]
}


Pour prendre en compte le changement de configuration, redémarrez l'Arbiter :


Code Block
service shinken-arbiter restart

Configuration

La configuration du module se trouve par défaut dans le fichier /etc/shinken/modules/receiver-module-webservice.cfg

  • Vous trouverez aussi un fichier d'exemple avec le chemin suivant : /etc/shinken-user-example/configuration/daemons/receiver/receiver-module-webservice/receiver-module-webservice-example.cfg

Exemple de fichier de configuration

Code Block
languagebashjs
#===============================================================================
# WebService-ReactionnerReceiver   (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               receiver-module-webservice
    # 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 authentificationauthentication =========
    # You can use HTTP basic authentificationauthentication method for this module.
    # If username is set to anonymous and password is commented, then
    # no authentificationauthentication will be required.
    username                 anonymous
    #password                secret


}

Les valeurs peuvent être :

  • module_name: définit un nom unique pour le module
  • module_type: doit être ws_arbiter
  • host: adresse de l'interface réseau sur laquelle effectuer l'écoute. 0.0.0.0 signifie "toutes les interfaces"
  • port: port TCP à écouter
  • use_ssl et ssl_cert / ssl_key : permet que le module écoute sur le port en SSL (protocole HTTPS) et d'utiliser des certificats
  • username et password: si mis à "anonymous" aucune accréditation nécessaire. Si vous mettez un nom utilisateur/mot de passe, une authentification est nécessaire
Note
titleActivation du module

Pour activer le module, ajouter simplement à votre Receiver le module ws-receiver à la liste des modules dans le fichier de configuration du receiver.cfg

Sur une architecture distribuée importante, si vous avez plusieurs Receivers, vous pourrez activer un module ws-receiver par Receiver.

Utilisation du module Webservice

Le webservice du Receiver écoute des requêtes HTTP pour ensuite effectuer des actions sur les hôtes/clusters ou checks concernés.

Un simple curl ou appel HTTP dans votre programme suffit pour envoyer des actions à Shinken.

/push_check_result:  soumettre le résultat de check passif sur un hôte ou un check

Paramètres de l'appel

NomDescription
Méthode HTTP
POST
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

Exemple:

No Format
curl -u user:password -X POST -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

Comme lors de l'écriture d'un check, le résultat du check peut être séparé du résultat long par un retour à la ligne.

Lors de l'envoi du résultat d'un check passif d'un hôte ou check, un retour à la ligne peut également être utilisé pour séparer résultat et résultat long.

L'exemple suivant permet d'envoyer un résultat et résultat long:

No Format
curl -u user:password -X POST -d $'host_name=host-checked&service_description=service-checked&return_code=0&output=shourt_update\nlong_output' http://shinken-srv:7760/push_check_result
Info

On note dans l'exemple précédent que la chaine de caractères passées dans le curl pour les données POST est passée avec:

Code Block
$'chaine'

et non

Code Block
"chaine"

pour ordonner au check d'interpréter les caractères d'échappement ANSI et passer un véritable '\n' au lieu de '\' suivi de 'n'.

Cette astuce fonctionne si le shell utilisé est bash et peut ne pas être utilisable dans d'autres shells, ou si la requête est envoyée via un autre outil ou via un script dans un autre langage.

Détails des sections composant le fichier de configuration

Identification du module

Il est possible de définir plusieurs instances de module de type receiver-module-webservice dans votre architecture Shinken.

  • Chaque instance devra avoir un nom unique.
NomTypeUnitéDéfautCommentaire
Code Block
module_name
Texte---receiver-module-webservice

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

Doit être unique.

Code Block
module_type
Texte---ws_arbiterNe peut être modifié.

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

Code Block
languagejs
#======== Listening address ========= 
# host: IPv4 address to listen to. 
# note: 0.0.0.0 = all interfaces. 
host 0.0.0.0 

# port to listen 
port 7760

Il est 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.

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


NomTypeUnitéDéfautCommentaire
Code Block
host
TexteAdresse IPv40.0.0.0L'interface réseau sur laquelle le module "receiver-module-webservice" va écouter.
Code Block
port
TextePort réseau7760Port réseau sur lequel le module "receiver-module-webservice" va écouter.

Sécurisation de la communication avec le module

Code Block
# 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

L'API du module est accessible via HTTP. Il est recommandé d'utiliser le protocole HTTPS pour chiffrer la communication avec le module.

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 :


NomTypeUnitéDéfautCommentaire
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
TexteChemin/etc/shinken/certs/server.certChemin vers le certificat SSL utilisé par le protocole HTTPS.
Code Block
ssl_key
TexteChemin/etc/shinken/certs/server.keyChemin vers la clé SSL utilisée par le protocole HTTPS.

Authentification HTTP

Code Block
languagejs
#======== HTTP authentication =========
# You can use HTTP basic authentication method for this module.
# If username is set to anonymous and password is commented, then
# no authentication will be required.
username anonymous
#password secret

Afin d'être authentifié auprès du module, il est possible de configurer les identifiants à utiliser dans les requêtes, dans la configuration du module grâce aux paramètres suivants :


NomTypeUnitéDéfautCommentaire
Code Block
 username 
Texte---anonymousNom d'utilisateur.
Code Block
 password
Texte---secretMot de passe.



Info

Lors d'une requête curl, les identifiants se renseignent grâce à l'option -u

Code Block
languagejs
curl -u anonymous:secret -X POST ...

/acknowledge: Mettre un Prise en compte sur un hôte, un cluster ou un check

Paramètres de l'appel

NomDescription
Méthode HTTP
POST
action

Options disponibles: add, delete. Ajoute un supprime la prise en compte.

Par défaut: add

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.
sticky

Option présente dans Shinken Framework, dépréciée dans Shinken Entreprise.

Si sticky=1, la prise en compte est automatiquement enlevée lorsque l'état est OK. Si sticky=2, la prise en compte est automatiquement enlevée lorsque l'état change, peu importe l'état (Warning → Critique par exemple).

Par défaut, sticky=1.

persistent

Option présente dans Shinken Framework, dépréciée dans Shinken Entreprise.

Si persistent=1, la prise en compte sera toujours présente après un redémarrage des services Shinken. Dans Shinken Entreprise, ce comportement est celui par défaut et ne peut pas être changé.

Exemple:
No Format
curl -u user:password -X POST -d "time_stamp=$(date +%s)&host_name=host-checked&service_description=service-checked&comment=Nous sommes entrain de corriger le problème&notify=1" http://shinken-srv:7760/acknowledge

/downtime: Mettre une période de maintenance sur un hôte, un cluster ou un check

Paramètres de l'appel

NomDescription
Méthode HTTP
POST
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 période de maintenance (optionnel)
start_time
Sous forme de timestamp: correspond à l'heure du début de la période de maintenance
end_time
Sous forme de timestamp: correspond à l'heure de fin de la période de maintenance
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.Exemple:
No Format
curl -u user:password -X POST -d "time_stamp=$(date +%s)&host_name=host-checked&service_description=service-checked&comment=Maintenance en cours&author=shinken_admin" http://shinken-srv:7760/downtime