Planifier le déploiement
Un système de supervision doit répondre aux enjeux attendus. La 1ère étape indispensable est d'obtenir l'accord de déploiement en mode projet afin de définir en détail toutes les étapes et contraintes, et notamment :
- Numbre de checks à superviser
- Fréquence des checks
- Méthode de supervision des checks Passif versus Actif
- Protocoles utilisés pour l'acquisition de données
Planning your deployment
A monitoring system needs to meet the expected requirements. The first thing you need to do is to get your management buy-in on deploying a monitoring and data acquisition system to meet corporate goals. The second is to define the scope of the monitoring system and its particularities.
- Number of checks to supervise
- check frequency
- Method of supervising the checks Passive versus Active
- Protocol used for data acquisition (ping, SSH, NSCA, TSCA, SNMP, NRPE, NSCAweb, collectd, scripts, etc)
- Retention duration for performance data
- For each status or performance data determine if it meets the scope and goals of the project.
How Shinken Enterprise is scalable
Shinken can scale out horizontally on multiple servers or vertically with more powerful hardware. Shinken deals automatically with distributed status retention. There is also no need to use external clustering or HA solutions.
Scalability can be described through a few key metrics
- Number of hosts + checks supervised
- Number of active checks per second (type of active check having a major impact!)
- Number of checks results per second (hosts and checks combined)
And to a less extent, as performance data is not expected to overload a Graphite server instance (Which a single server can do up to 80K updates per second with millions of metrics) with a hardware RAID 10 of SSD disks.
Passive versus Active
Passive checks do not need to be scheduled by the monitoring server. Data acquisition and processing is distributed to the monitored hosts permitting lower acquisition intervals and more data points to be collected.
Active checks benefit from Shinken Enterprise's powerful availability algorithms for fault isolation and false positive elimination.
A typical large installation should make use of both types of checks.
Scaling the broker
- Durée de rétention des données de performance
- Pour chaque statut ou donnée de performance, définir les exigences à atteindre .
Niveau de scalabilité de Shinken Enterprise
Shinken Enterprise peut être scalé horizontalement et verticalement . Il va gérer automatiquement la rétention distribuée de statuts. Il n'est pas nécessaire de rajouter un cluster externe ou une architecture en HA. .
La scalabilité peut se décrire à travers plusieurs points
- Nombre d'hôtes et de checks supervisés
- Nombre de checks actifs par seconde (le type a également un impact énorme t!)
- Nombre de résultats de checks par seconde
Et à un niveau moindre, les données de performance ne devant pas surcharger le serveur graphite
Passif versus Actif
Les checks passifs n'ont pas besoin d'être planifiés sur le serveur de supervision. L'acquisition de donnés et le processing sont distribués aux hôtes supervisés permettant de réduire les intervalles d'acquisition en augmentant les points de collecte.
Les checks actifs bénéficient des algorithmes puissants de Shinken Enterprise.
Une installation importante doit bénéficier des 2 types de checks.
Scalier le broker
Le broker est un élément clé de la scalabilité de l'architecture. Un seul broker peut être actif par scheduler. Un broker peut processer des messages de plusieurs schedulers. Dans la plupart des déploiements, Livestatus est le module broker qui met à disposition les informations de statut aux frontends web The broker is a key component of the scalable architecture. Only a single broker can be active per scheduler. A broker can process broks (messages) from multiple schedulers. In most modern deployments, Livestatus is the broker module that provides status information to the web frontends. (Nagvis, Multisite, Thruk, etc.) or ou à l'interface graphique intégrée à Shinken Enterprise's own WebUI module. The broker needs memory and processing power.Le broker a besoin de mémoire et de puissance de calcul.
...
Modèle de dépendance
Shinken Enterprise has a great dependency resolution model. Automatic root cause isolation, at a host level, is one method that Shinken Enterprise provides. This is based on explicitly defined parent/child relationships. This means that on a check or host failure, it will automatically reschedule an immediate check of the parent(s). Once the root failure(s) are found, any children will be marked as unknown status instead of soft down.This model is very useful in reducing false positives. What needs to be understood is that it depends on defining a dependency tree. A dependency tree is restricted to single scheduler. Shinken Enterprise provides a distributed architecture, that needs at least two trees for it to make sense.a un grand modèle de gestion des dépendances. La détection automatique de problème source au niveau de l'hôte est une des méthodes proposée par Shinken Enterprises. Cela se fait à travers la définition claire des liens parents/enfants. Cela signifie que sur un problème, le système va automatiquement replanifier une vérification du ou des parents définis. Une fois que le problème source est identifié, tous les enfants seront marqués en statut inconnu..
Ce modèle est très pratique pour réduire les faux positifs. Ce qui est important, c'est la définition de l'arbre de dépendances. Cet arbre est limité à un seul scheduler.
Splitting trees by a logical grouping makes sense. This could be groups of checks, geographic location, network hierarchy or other. Some elements may need to be duplicated at a host level (ex. ping check) like common critical elements comme certains éléments critiques (core routers, datacenter routers, AD, DNS, DHCP, NTP, etc.). A typical tree will involve clients, servers, network paths and dependent checks.
Scaling the acquisition daemons
Typically pollers and Schedulers use up the most network, CPU and memory resources. Use the distributed architecture to scale horizontally on multiple commodity servers. Use at least a pair of Scheduler daemons on each server. Your dependency model should permit at least two trees, preferably 4.
Passive acquisition methods
Metrics or performance data (in a Nagios way) are embedded with check results. A check result can have zero or more performance metrics associated with it.
Theses are transparently passed off to systems outside of Shinken Enterprise using a Broker module. The Graphite broker module can easily send more than 2000 metrics per second. We have not tested the upper limit. Graphite itself can be configured to reach upper bounds of 80K metrics per second.
If a metric does not need its own check, it should be combined with a similar natured check being run on the server. checks are the expensive commodity, as they have all the intelligence like to them such as timeouts, retries, dependencies, etc. With Shinken 1.2 and fast servers, you should not exceed **60K checks*for optimum performance.
Un arbre typique va inclure des clients, serveurs, chemin réseau, et checks associés .
Scaler les démons d'acquisition
Typiquement, les pollers et schedulers utilisent le plus de ressources réseau, mémoire et CPU . Utilisez l'architecture distribuée pour scaler horizontalement sur plusieurs serveurs basiques. Utilisez au moins une paire de Scheduler sur chaque serveur . Votre modèle doit permettre au moins 2 arbres, idéalement 4..
Méthode d'acquisition passive
Les données de performance ou métrics (mode Nagios) sont intégrés dans les retours de checks . Un retour pour n'avoir aucun ou plusieurs metrics associés.
Ceux-ci sont transférés de manière transparente aux systèmes externes via le Broker. Le broker Graphite peut envoyer plus de 2000 metrics par seconde. Graphite peut être configuré pour atteindre plus de 80K metrics par seconde.
Si un metric n'a pas besoin de son propre check, il doit être associé à un check de nature similaire . Les checks sont les composants les plus "chers", Vous ne devriez pas excéder les **60K checks* pour des performances optimisées.
Protocoles recommandés pour l'acquisition passiveRecommended protocols for scalable passive acquisition
- Ws_Arbiter (Used by GLPI)
- NSCA (generic collection)
Log management methods
System and application logs should be gathered from servers and network devices. For this a centralized logging and analysis system is required.
Méthode de gestion des Log
Les logs système et réseau doivent être récoltées depuis les serveurs et équipements réseau. Pour cela, un système centralisé est requis :.
Nous suggérons les systèmes suivantsSuggested centralized logging systems:
- OSSEC+Splunk
- loglogic