Contexte
Ce guide vous permettra d'installer ou de mettre à jour Shinken Entreprise sur un serveur Linux.
Une fois le guide d'installation suivi, vous aurez rapidement accès à l'interface de Configuration et de Visualisation de Shinken dans une architecture par défaut, c'est-à-dire sur un serveur simple, sur lequel tous les démons seront activés.
Si vous mettez en place une architecture distribuée, après avoir terminé l'installation de Shinken sur vos différents serveurs, il vous faudra passer à la phase de configuration de vos démons (noms et IP des serveurs, royaume, spare, Tag des Pollers, rétention..).
En ce qui concerne la procédure de mise à jour, le script "d'update" vous permettra de mettre à jour votre serveur Shinken de manière complète, même si quelques démons sont seulement activés. La configuration de votre serveur Shinken ne sera pas modifiée.
| Warning | ||
|---|---|---|
| ||
Lors de l'installation de Shinken Entreprise, le système de gestion de base de données orientée documents MongoDB est mis en place avec la version v3.0.15. Ce système de base de données permettra le bon fonctionnement de l'interface de Configuration et de Visualisation. Utilisé avec une base MongoDB, Graphite, quant à lui, est un outil pour stocker les métriques de vos sondes. Pour ne pas créer de dysfonctionnement, nous vous demandons de ne pas mettre à jour MongoDB / Graphite. Veuillez simplement laisser en place les versions fournies par nos services.
|
Afin de prévenir tout risque, les démons Shinken Entreprise refuseront de démarrer si la version installée de MongoDB n'est pas celle préconisée.| Panel | ||
|---|---|---|
| ||
|
Installation de Shinken Entreprise
Prérequis
Environnement requis : RHEL/Centos 6.6, 7.2, 7.3, 7.4, 7.5, 7.6, 7.7, 7.8, 7.9 [ 64bits ]
Shinken Entreprise a choisi les distributions produites par Red Hat: Red Hat Enterprise Linux (RHEL) et CentOS (Community enterprise Operating System). Ces distributions Linux, principalement destinées aux serveurs, sont stables, performantes et compatibles avec une très grande majorité des environnements professionnels. La distribution CentOS est elle aussi très performante (basée sur une distribution commerciale RHEL de qualité).
| Info | ||
|---|---|---|
| ||
Lors d'une installation de distribution Redhat Enterprise Linux (commerciale), il faut rattacher votre souscription Redhat à votre système. Voici les commandes à utiliser depuis le serveur: 1/ subscription-manager register et il faut également l'attacher à l'OS en cours: 2/ subscription-manager attach Yum pourra alors être utilisée correctement, car l'abonnement sera valide. (et donc Shinken pourra être installé) |
Extraction du package et installation
Installation automatique :
Il faut être loggué en tant que root,
| Code Block | ||
|---|---|---|
| ||
$id uid=0(root) gid=0(root) |
Et que le umask du compte root soit à 0022
| Code Block | ||
|---|---|---|
| ||
$umask 0022 |
« Dé-tarez » le package qui vous a été transmis :
- tar zxvf shinken-enterprise_V02.07.XX-LANGUAGE.tar.gz
- Cela vous créera un répertoire shinken-entreprise contenant le script d’installation et les dépendances nécessaires à l’installation.
Déplacez-vous à la base du répertoire shinken-entreprise (cd shinken-enterprise_V02.07.XX-LANGUAGE) et exécutez le script :
| Code Block |
|---|
./install.sh |
Il installera Shinken Entreprise et ses composants automatiquement.
- Le SDK VMWare qui nécessitait une installation manuelle dans les versions précédentes est maintenant installé automatiquement.
- Pour obtenir plus d'informations sur la consommation des démons et améliorer le fonctionnement de Shinken lorsqu'il est installé sur une machine virtuelle VMWare, le paquet "open-vm-tools" doit être installé manuellement :
| Code Block |
|---|
yum install open-vm-tools |
Vérification du bon fonctionnement
Vérification :
Pour vérifier que Shinken Entreprise est bien installé, configuré et fonctionnel, lancez la commande :
| Code Block |
|---|
shinken-healthcheck |
Votre licence Shinken Enterprise n'est pas installée, c'est normal, dirigez-vous dans la section Clé de licence plus bas sur cette page afin d'installer votre clé.
| Tip |
|---|
L'installation complète fera sur le même serveur :
Pour une installation distribuée, voir la page Architecture Distribuée |
Accès aux interfaces web
Interface Utilisateur (UI) de configuration
Une fois Shinken Enterprise installé, pour accéder à l'UI de configuration, vous devez pointer votre navigateur Web vers l'adresse affichée durant l'installation.
Par défaut, l'interface de configuration est accessible sur le port dédié 7766 (via le protocole HTTP). Par exemple : http://192.168.0.1:7766
| Info |
|---|
| L'adresse IP (ou FQDN si votre résolution DNS est opérationnelle) correspond à votre serveur hébergeant le démon Synchronizer. |
Voir la page Paramétrage de l'interface de Configuration pour plus d'information.
Interface Utilisateur (UI) de visualisation
Une fois Shinken Enterprise installé, pour accéder à l'UI de visualisation, vous devez pointer votre navigateur Web vers l'adresse affichée durant l'installation.
- Par défaut, l'interface de configuration est accessible sur le port dédié 7767 (via le protocole HTTP). Par exemple : http://192.168.0.1:7767
| Info |
|---|
| L'adresse IP (ou FQDN si votre résolution DNS est opérationnelle) correspond à votre serveur hébergeant le démon Broker. |
Voir la page Paramétrage de l'interface de Visualisation pour plus d'information.
Intégration du guide d'utilisateur dans le package
Le guide d'utilisateur (en français) est maintenant intégré au package d'installation.
Vous pouvez le retrouver dans : shinken-enterprise_V02.07.XX-LANGUAGE.tar.gz/tools/documentation/ui-visualisation/
Il vous suffira qu'un utilisateur, via son navigateur internet, ouvre le fichier "index.html" afin de pouvoir parcourir le guide d'utilisateur, contenant la documentation liée à l'UI de visualisation.
Installation (Mode avancé)
| Anchor | ||||
|---|---|---|---|---|
|
Installation partiellement automatique (active seulement les démons sélectionnés ) :
Il faut être loggué en tant que root,
| Code Block | ||
|---|---|---|
| ||
$id uid=0(root) gid=0(root) |
Et que le umask du compte root soit à 0022
| Code Block | ||
|---|---|---|
| ||
$umask 0022 |
« Dé-tarez » le package qui vous a été transmis :
- tar zxvf shinken-enterprise_V02.07.XX-LANGUAGE.tar.gz
- Cela vous créera un répertoire shinken-entreprise contenant le script d’installation et les dépendances nécessaires à l’installation.
Déplacez-vous dans le répertoire (cd shinken-enterprise_V02.07.XX-LANGUAGE) et lancez la commande ./install.sh mais avec des options basées sur les démons que vous souhaitez activer :
- --pollernode: active le démon Poller (dédié au lancement des checks)
--reactionnernode: active le démon Reactionner (dédié au lancement des notifications)
--schedulernode: active le démon Scheduler (planificateur des checks)
--arbiternode: active le démon Arbiter (rôle de distribution centrale)
--receivernode: active le démon Receiver (reçois les checks passifs)
--synchronizernode: active le démon Synchronizer (gère la configuration)
--brokernode: active le démon Broker (export des données pour les interfaces de visualisation)
| Info | ||
|---|---|---|
| ||
Vous pouvez par exemple installer Shinken Enterprise et activer directement le Scheduler et le Poller en même temps en tapant la commande
|
Pour vérifier que les démons sélectionnés de Shinken Entreprise sont bien mis à jour, configurés et fonctionnels, lancez la commande :
| Code Block |
|---|
shinken-healthcheck |
Shinken-healthcheck vérifiera alors que Shinken Entreprise est bien configuré et en cours d'exécution (seulement pour les démons installés)
- Après l'installation initiale, si vous souhaitez activer/désactiver des démons, utilisez la commande d'activation détaillée dans le chapitre Activation/Désactivation des démons.
- Lors d'une mise à jour, le script update.sh prend en compte les démons qui sont activés ou non.
Les différents addons sont automatiquement activés lors de l'installation:
- nagvis-shinken-architecture: Activé lors d'une installation d'un Arbiter (plus de détails dans la page de documentation dédiée: Activation et configuration de la fonctionnalité)
- nagvis: Activé lors d'une installation d'un Broker (plus de détails dans la page de documentation dédiée: NagVis ( Addon ))
Mise en place automatique du chiffrement
Vous pouvez mettre en place le Chiffrement des données sensibles de façon automatique au moment de l'installation.
| Tip |
|---|
Si vous n'avez jamais activé le chiffrement des données sensibles, nous vous conseillons de procéder à l’installation sans activer le chiffrement et de découvrir la fonctionnalité par la lecture du chapitre Chiffrement des données sensibles. |
Une clé de chiffrement sera alors générée lors du processus d'installation et la base de données du Synchronizer sera chiffrée.
Pour cela, lancez la commande suivante :
| Code Block |
|---|
./install.sh --activate-encryption <nom de clé> --disable-important-notices-user-input |
Le paramètre --activate-encryption permet d'activer le chiffrement ; le nom de la clé est optionnel ; il vous sera demandé lors de l'exécution du programme d'installation si vous ne le précisez pas.
Le paramètre --disable-important-notices-user-input permet de désactiver les prompts vous demandant confirmation avant de continuer le processus.
Il vous est cependant fortement conseillé de lire les informations fournies lors de l'installation.
| Warning |
|---|
La mise en place automatique du chiffrement nécessite dans tous les cas d'effectuer l'export et la sauvegarde de la clé générée lors du processus. Veuillez consulter shinken-protected-fields-keyfile-export pour plus d'informations. |
Shinken-healthcheck vous permettra de vérifier la bonne configuration des démons et du chiffrement.
Mise en place d'un serveur sans connexion internet
Dans le cas d'un serveur qui n'a pas de connexion internet, il faut lancer l'installeur avec le paramètre suivant:
--disable-add-public-epel : permet de ne pas installer le repository epel sur le serveur
- --disable-epel (DEPRECATED): ancien nom du paramètre, sera supprimé dans le futur
| Warning | ||
|---|---|---|
| ||
Il est à noter que le serveur doit avoir un accès à un repository yum valide (ayant également les paquets présents dans epel) en cas de conflits de versions des rpm entre ce que propose l'installeur et ce qui est déjà installé sur le serveur. |
Faire l'installation sur un serveur avec des repository internes ( non publics ) fixés sur une version précise
Dans le cas d'un serveur qui n'a accès qu'à des "repository" internes qui ne sont pas forcément synchronisés sur les dernières versions des "repository" centos/redhat officiel, le comportement de base de l'installeur et le script d'update sont de mettre à jour tous les packages si une mise à jour est possible, mais ceci peux entrainer des problèmes si l'installeur a une mise à jour à faire trop récente par rapport à ce qu'il a de disponible dans ses "repository".
Dans ce cas, il faut lancer avec l'option qui demande à ne pas mettre à jour les paquets s'ils sont déjà installés :
--package-update-only-on-conflict : permet de ne pas chercher à mettre à jour les paquets déjà installés et ainsi tente d'éviter d'installer des paquets trop à jour par rapport au "repository" interne qui n'est pas à jour.
| Warning | ||
|---|---|---|
| ||
Il est a noté que le serveur doit tout de même avoir accès à un "repository" valide, et des conflits de paquets peuvent survenir dans le cas de nouveaux paquets installés et que dans ce cas seul yum requêtant les "repository" peut les résoudre ( arrive dans le cas de paquets de l'installeur trop à jour par rapport à ce qui est disponible dans le repository ). |
Faire l'installation sur un serveur RedHat non enregistré sur les repository RedHat
Si un serveur RedHat a un accès uniquement à des "repository" locaux, il ne sera pas enregistré directement chez RedHat. La vérification de l'installeur et du script d'update sur les RedHat se base sur la vérification de cette connexion afin de déterminer si le serveur a bien accès aux "repository". Ici cette vérification va bloquer l'installation alors que le serveur a bien accès à des "repository" locaux. Il faut alors utiliser l'option suivante :
- --skip-redhat-subscription-check: permets de ne pas lancer la vérification de la souscription du serveur auprès de RedHat ( qui doit avoir tout de même accès à des repository locaux ).
Mise à jour de Shinken Entreprise
Prérequis
Environnement : RHEL/Centos 6.6, 7.2, 7.3, 7.4, 7.5, 7.6, 7.7, 7.8 et 7.9 [64bits] avec d'une version antérieure déjà installée.
| Note | ||
|---|---|---|
| ||
Pour mettre à jour d'une version mineure à la majeure suivante, il faut faire attention de bien avoir la dernière itération de cette version. - Par exemple, pour la mise à jour en V02.07.XX, il faut s'assurer d'avoir installé la V02.06.03 (dernière V02.06) avant d'effectuer la mise à jour. - L'installation de la même version est possible afin de pouvoir réinstaller la même version si celle-ci a été altérée. - N'hésitez pas à vérifier ce point avec votre revendeur ou Shinken Solutions. |
Extraction et mise à jour
Mise à jour:
Il faut être loggué en tant que root,
| Code Block | ||
|---|---|---|
| ||
$id uid=0(root) gid=0(root) |
Et que le umask du compte root soit à 0022
| Code Block | ||
|---|---|---|
| ||
$umask 0022 |
« Dé-tarez » le package qui vous a été transmis :
- tar zxvf shinken-enterprise_V02.07.XX-LANGUAGE.tar.gz
- Cela vous créera un répertoire shinken-entreprise contenant le script de mise à jour et les dépendances nécessaires à la mise à jour.
Déplacez-vous dans le répertoire shinken-entreprise ( cd shinken-enterprise_V02.07.XX-LANGUAGE ) et exécutez le script :
| Code Block |
|---|
./update.sh |
Tout comme dans le cas de l'installation, si le serveur n'a accès qu'à des repository internes (qui ne sont pas forcément à jour par rapport aux repository centos/redhat officiels), il faut lancer avec:
--package-update-only-on-conflict : permets de ne pas chercher à mettre à jour les paquets déjà installés et ainsi tente d'éviter d'installer des paquets trop à jour par rapport au repository interne qui n'est pas à jour
- --skip-redhat-subscription-check: permets de ne pas lancer la vérification de la souscription du serveur auprès de RedHat ( qui doit avoir tout de même accès à des repository locaux ).
Ainsi, la mise à jour:
- Il mettra à jour Shinken Entreprise mais n'aura aucune incidence sur le dossier de configuration de /etc/shinken, évitant tout risque d’écrasement d'une configuration que vous auriez définie.
- Au lieu d'écraser votre paramétrage, des fichiers "*.cfg.rpmnew" seront ajoutés. De nouvelles propriétés pourront figurer dans ces fichiers, il est donc conseillé de parcourir ces fichiers et si besoin, récupérer ces nouvelles propriétés pour les intégrer dans votre architecture.
- Avant la mise à jour, une sauvegarde de la configuration et des données utilisateur est effectuée et placée dans /tmp. Ces sauvegardes sont nommées de la manière suivante: "backup-preupdate-version-NUMERO_VERSION".
| Warning | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
En cas d'erreur lors de la mise à jour, le script update.sh peut s'interrompre pour que vous puissiez corriger le problème. Les erreurs les plus courantes sont les suivantes :
En cas de doute, n'hésitez pas à contacter votre support. |
Vérification du bon fonctionnement
Pour vérifier que Shinken Entreprise est bien mis à jour, configuré et fonctionnel, lancez la commande :
| Code Block |
|---|
shinken-healthcheck |
Mise à jour des checks via la source cfg-file-shinken
Lors de l'installation de Shinken, nous incluons de nombreux checks (via des modèles du Pack Shinken, Linux, Windows,..).
Ces éléments de ces packs (checks, modèles, commandes) sont disponibles au travers de la source "cfg-file-shinken" :
| Panel |
|---|
|
Lors d'une update, nous vous fournissons également toutes les mises à jour de ces packs, nous vous conseillons donc d'activer la source et de bien regarder les mises à jour possibles, via les éléments qui apparaîtront en "nouveau" et en "différence".
| Info |
|---|
Si vous avez déjà fait des personnalisations sur les éléments de ces packs, soyez vigilant avant d'appliquer les différences. |
| Anchor | ||||
|---|---|---|---|---|
|
Clé de licence Shinken Enterprise
Une fois Shinken Enterprise installé, la commande shinken-healthcheck lancée depuis votre serveur Arbiter affichera un message d'erreur au sujet de la licence:
La licence par défaut installée est une licence d'essai. Vous ne pourrez placer en supervision qu'un très faible nombre d'hôtes.
| Panel |
|---|
|
Le service Commercial de Shinken Enterprise a dû vous envoyer une licence nominative vous permettant d'utiliser pleinement le produit.
La licence est un fichier qui a le nom suivant : user.key et cette licence est nominative et limitée dans le temps.
Pour l'installer, rien de plus simple, il suffit de :
- Placer ce fichier sur le serveur hébergeant l'Arbiter et sur les serveurs hébergeant le ou les UIs de Visualisation , dans le chemin suivant : /etc/shinken/user.key
- Redémarrez alors Shinken Enterprise via la commande : service shinken restart
Relancez alors la commande shinken-healthcheck le message d'erreur de licence doit avoir disparu et voici un exemple d'information de licence valide :
| Panel |
|---|
|
Si vous n'avez pas de clé de licence ou que celle-ci a expiré, contactez-nous : contact@shinken-solutions.com
Résolution des problèmes liés à l'installation/mise à jour
Lors de l'installation des dépendances, si une machine n'est pas connectée à internet ou connectée à un repository privé, il arrive que les scripts d'installation ou de mise à jour échouent.
Dans ce cas, des fichiers sont créés dans le "home" de l'utilisateur avec lequel est effectuée l'installation/mise à jour. Ces fichiers contiennent plus de détails sur les erreurs rencontrées et peuvent être envoyés à votre contact de support Shinken Entreprise pour la correction du problème.
Pour chaque installation/mise à jour, un dossier est créé dans ~/shinken/versions_and_patch_installations/ et nommé de la manière suivante :
- Pour une installation:
| Code Block |
|---|
YYYY-MM-DD-HHhMMmSS-install-VXX.XX.XX |
- Pour une mise à jour:
| Code Block |
|---|
YYYY-MM-DD-HHhMMmSS-update-VXX.XX.XX |
Ces dossiers contiennent les données suivantes:
- Affichage du script d'installation (installation seulement): shinken.enterprise.install.log
Détails d'installation des paquets: shinken.enterprise.install.detail.log
Nettoyage de la configuration: sanatize.update.log
Affichage du script de mise à jour (mise à jour seulement): shinken.enterprise.update.log
- Backup de la configuration et données utilisateur (mise à jour seulement)
En cas de soucis avec les installations de packages via yum, les erreurs seront présentes dans les fichiers:
- /tmp/install.txt
- /tmp/install_bogus.txt
| Panel |
|---|
|
Cas spécifique de la mise à jour d'un cluster Mongo
Dans la version V02.07.00, la base Mongodb est mise à jour. Lorsque Mongodb a été configuré pour fonctionner en tant que cluster, le comportement du script de mise à jour de Shinken Entreprise a été modifié pour prendre en compte cette configuration particulière. Des explications détaillées sont présentes dans la page de documentation dédiée: Mise à jour d'un cluster Mongodb