[comment]: # ({6d5b9456-fe9e2978}) # 2 Bonnes pratiques de configuration [comment]: # ({/6d5b9456-fe9e2978}) [comment]: # ({663732c3-28bc317f}) ### Vue d'ensemble Cette section présente les bonnes pratiques pour configurer Zabbix afin d'obtenir des performances optimales et une facilité d'utilisation maximale. Les recommandations sont basées sur les conseils des développeurs Zabbix ainsi que sur l'expérience pratique des formateurs Zabbix et des ingénieurs du support. Chaque installation Zabbix est unique, et certaines de ces recommandations peuvent ne pas convenir à votre configuration spécifique. Cependant, il est recommandé de s'efforcer de suivre ces recommandations autant que possible afin d'éviter les problèmes potentiels courants. :::notetip Si vous pensez que cette page pourrait être améliorée, nous serions ravis d'avoir votre avis ! Veuillez mettre en surbrillance le texte concerné et appuyer sur **ctrl+Enter** pour signaler une erreur ou partager vos commentaires. ::: [comment]: # ({/663732c3-28bc317f}) [comment]: # ({5cfb221c-072ed520}) ### Hôtes et éléments [comment]: # ({/5cfb221c-072ed520}) [comment]: # ({f17bceb0-330dd01f}) #### Définition d'un hôte Un hôte dans Zabbix n'est pas une machine ou un périphérique physique, mais une entité logique. À des fins de supervision, vous pouvez créer des hôtes distincts pour une base de données ou, par exemple, une machine virtuelle. Vous pouvez également créer un hôte générique *John's laptop* et superviser toutes les métriques sous cet hôte. La meilleure pratique consiste à créer un hôte distinct pour chaque instance indépendante, telle qu'une machine virtuelle, une base de données, un conteneur ou un commutateur réseau. En adoptant cette approche, vous pourrez : 1. Éviter l'encombrement des données de supervision en ayant des éléments, des déclencheurs et des notifications d'alerte distincts pour chaque hôte. 2. Affiner les niveaux d'accès des utilisateurs. Vous pouvez configurer [user-roles](/manual/web_interface/frontend_sections/users/user_roles) pour autoriser l'accès à la consultation et/ou à la configuration de certains hôtes uniquement. Voir aussi [le principe du moindre privilège](/manual/best_practices/security/access_control#principle-of-least-privilege). [comment]: # ({/f17bceb0-330dd01f}) [comment]: # ({e32f8a5d-8db12f37}) #### Hôtes avec des éléments dupliqués Si vous avez plusieurs hôtes similaires, tels que *Network switch 1* et *Network switch 2*, Zabbix propose plusieurs façons de recréer rapidement l'hôte. Vous pouvez simplement cloner un hôte avec toutes ses métriques en appuyant sur le bouton Clone, mais dans ce cas, pour mettre à jour un élément plus tard, vous devrez le faire manuellement sur chaque hôte. La meilleure pratique consiste à créer un modèle avec toutes les métriques requises, par exemple *Network switch template*. Regroupez ensuite les hôtes similaires dans un groupe d'hôtes ; pour l'exemple ci-dessus, il pourrait s'agir de *Network switches*. Désormais, dans la section *Data Collection -> Hosts*, vous pouvez filtrer tous les hôtes par groupe d'hôtes et utiliser le bouton *Mass update* pour lier le modèle à tous vos commutateurs réseau. [comment]: # ({/e32f8a5d-8db12f37}) [comment]: # ({657d4bfb-1a8f9462}) #### Éléments dépendants Afin de réduire au minimum le nombre de requêtes vers l'entité cible, Zabbix permet de créer des éléments maîtres et des éléments dépendants. Dans ce cas, l'élément maître collecte un grand ensemble d'informations en une seule requête. Ensuite, les éléments dépendants peuvent être configurés pour extraire des données spécifiques de cet ensemble via le prétraitement et les stocker comme des métriques individuelles. Par exemple, l'élément maître peut collecter une réponse JSON ou XML contenant plusieurs métriques, ou exécuter une requête de base de données qui renvoie plusieurs colonnes de données (par exemple, le nombre de connexions ouvertes, les connexions abandonnées, le nombre maximal de connexions simultanées autorisées et le nombre total cumulé de connexions depuis le démarrage), et les éléments dépendants analyseront et stockeront chaque valeur requise séparément. La meilleure pratique pour cette configuration consiste à supprimer l'historique de l'élément maître juste après la collecte et à ne conserver que les données des éléments dépendants. [comment]: # ({/657d4bfb-1a8f9462}) [comment]: # ({5372cab0-773f6eb4}) ### Serveurs et proxies Si tous les hôtes se trouvent dans le même réseau local que le serveur Zabbix et qu’il n’existe aucune contrainte de scalabilité ou de performance, vous n’avez peut-être pas besoin d’un proxy. Dans des environnements plus vastes ou plus complexes, la supervision directe des hôtes par le serveur Zabbix peut ne pas être suffisante. L’ajout d’un proxy et l’affectation d’une partie des hôtes à ce proxy permettent une répartition plus équilibrée de la charge. La bonne pratique consiste à ajouter un proxy Zabbix lorsque : 1. Vous supervisez plusieurs hôtes à l’aide de diverses méthodes de collecte de métriques derrière un pare-feu. Le proxy collectera les données des hôtes et les transmettra au serveur Zabbix, ce qui réduit le besoin d’ouvrir plusieurs ports de pare-feu. 2. Vous supervisez des sites distants, des succursales et/ou des réseaux. En cas d’interruption du réseau entre le serveur Zabbix et vos sites distants, les proxies Zabbix déployés sur ces sites continueront la collecte des données et renverront les données collectées au serveur Zabbix dès que la connexion réseau sera rétablie. 3. Vous disposez d’un déploiement à grande échelle et souhaitez réduire la charge sur le serveur Zabbix et améliorer les performances. La définition d’un déploiement à grande échelle est très large et dépend non seulement du nombre d’hôtes, mais aussi du nombre de valeurs collectées par seconde. [comment]: # ({/5372cab0-773f6eb4})