monitoring
Différences
Ci-dessous, les différences entre deux révisions de la page.
Les deux révisions précédentesRévision précédenteProchaine révision | Révision précédente | ||
monitoring [2012/04/24 18:06] – [Haute Disponibilité] ajout section exploitation gde | monitoring [2019/11/28 08:47] (Version actuelle) – update installation et conf postgresql gde | ||
---|---|---|---|
Ligne 1: | Ligne 1: | ||
====== Monitoring & Métrologie ====== | ====== Monitoring & Métrologie ====== | ||
- | [[http:// | + | ===== Installation zabbix ===== |
- | Pour la métrologie, | + | |
- | ===== plugin | + | Nécessite pas grand chose pour l' |
- | Nous utiliserons les plugins qui viennent par défaut avec shinken, ou les plugin nagios. | + | * hostname : zabbix |
+ | * DNS : zabbix.faimaison.net | ||
+ | * CPU : 1vCPU | ||
+ | * RAM : 1G | ||
+ | * DD : 30GB | ||
- | ==== nagios-plugin ==== | + | Nous partons d'une base debian buster (10) et nous utilisons |
- | + | ||
- | pour installer tous les plugins déjà créé par la communauté, | + | |
+ | ==== installation du répository zabbix et des paquets ==== | ||
< | < | ||
- | /usr/local/shinken/install -p nagios-plugins | + | # wget https://repo.zabbix.com/zabbix/4.4/ |
+ | # dpkg -i zabbix-release_4.4-2+buster_all.deb | ||
+ | # apt update | ||
+ | # apt install | ||
</ | </ | ||
- | ===== PNP4nagios ===== | + | postgresql est installé par dépendance, |
- | Pour faire nos graph, nous allons reposer sur pnp4nagios. Voici comment l' | + | ==== creation BDD et schema zabbix ==== |
< | < | ||
- | /usr/local/shinken/install | + | # su - postgres |
+ | $ pg_createcluster 11 zabbix | ||
+ | $ createuser --pwprompt zabbix | ||
+ | $ createdb -O zabbix zabbix | ||
+ | $ exit | ||
+ | # zcat /usr/share/doc/zabbix-server-pgsql/ | ||
</ | </ | ||
- | la configuration | + | ==== configuration |
- | ==== Configuration ==== | ||
- | La configuration consiste surtout à intégrer les graphs | + | utilisation |
- | pour se faire il faut éditer le fichier /// | + | <code postgresql> |
+ | # DB Version: 11 | ||
+ | # OS Type: linux | ||
+ | # DB Type: oltp | ||
+ | # Total Memory (RAM): 1 GB | ||
+ | # CPUs num: 1 | ||
+ | # Data Storage: hdd | ||
- | < | + | max_connections = 300 |
- | # Use PNP graphs in the WebUI | + | shared_buffers = 256MB |
- | define module{ | + | effective_cache_size = 768MB |
- | | + | maintenance_work_mem = 64MB |
- | | + | checkpoint_completion_target = 0.9 |
- | | + | wal_buffers = 7864kB |
+ | default_statistics_target = 100 | ||
+ | random_page_cost = 4 | ||
+ | effective_io_concurrency = 2 | ||
+ | work_mem = 436kB | ||
+ | min_wal_size = 2GB | ||
+ | max_wal_size = 4GB | ||
+ | </code> | ||
- | } | + | |
+ | S' | ||
+ | < | ||
+ | DBHost= | ||
+ | DBName=zabbix | ||
+ | DBUser=zabbix | ||
+ | DBPassword=< | ||
</ | </ | ||
+ | DBHost est vide pour utiliser les socket UNIX. | ||
+ | ==== Conf frontweb et redémarrage ==== | ||
+ | Dans /// | ||
- | ===== Configuration ===== | + | <code php> |
+ | php_value max_execution_time 300 | ||
+ | php_value memory_limit 128M | ||
+ | php_value post_max_size 16M | ||
+ | php_value upload_max_filesize 2M | ||
+ | php_value max_input_time 300 | ||
+ | php_value max_input_vars 10000 | ||
+ | php_value always_populate_raw_post_data -1 | ||
+ | php_value date.timezone Europe/ | ||
+ | </ | ||
- | ==== commun ==== | + | certbot, paquets zabbix utilise apache2 donc : |
- | Chaque serveur Faimaison est monitoré sur les points suivant : | + | < |
+ | # apt install certbot | ||
+ | # apt install python-certbot-apache | ||
+ | # certbot --apache -d zabbix.faimaison.net | ||
+ | </ | ||
- | * **[[monitoring/ | + | Redémarrer l'ensemble |
- | * **[[monitoring/ | + | |
- | * **[[monitoring/ | + | |
- | * **ram** & **swap** : utilisation de la ram et swap | + | |
- | * **[[monitoring/ | + | |
- | * **ntp** : vérifie décalage | + | |
- | ==== services ==== | + | < |
+ | # systemctl restart zabbix-server apache2 zabbix-agent | ||
+ | # systemctl enable zabbix-server apache2 zabbix-agent | ||
+ | </ | ||
- | Services à monitorer : | + | ==== Setup ==== |
- | * **SSH** : vérifier la disponibilitée du port 22 | + | Se connecter sur zabbix.faimaison.net/ |
+ | compléter l' | ||
- | ==== unique pour les hosts ==== | ||
- | === methyl_box | + | ===== Monitoring server |
- | * **HTTP** : pour le site (test port 80 + parse page index) | + | FIXME |
- | * **DNS** : résolution de nom de faimaison.net | + | |
- | * **Postgresql** : vérifier le port 5432 ? | + | |
- | === chomsky | + | ==== installation agent ==== |
+ | Il n'y a pas de nécessité à garder une version identique des agents avec le serveur. Ainsi, nous pouvons utiliser le paquet par défaut sur debian. Toutefois, attention a ne pas avoir un écart trop grand car on perd des fonctionnalités | ||
- | * **GIT** : accès aux dépôts git (read-only) | + | < |
+ | # apt install zabbix-agent | ||
+ | </ | ||
- | === zorun_box | + | ==== Configuration agent ==== |
- | * **GIT** : accès aux dépôts git (read-only) | + | === Rendre agent actif === |
+ | un agent actif, est un agent qui récupère tout seul sa configuration sur le serveur et pousse de lui-même les informations au serveur sans attendre d' | ||
+ | Pour se faire, s' | ||
- | ==== Active et Passive checks ==== | + | < |
+ | ServerActif=89.234.176.134 | ||
+ | </ | ||
- | Différent type de récupération des données peuvent être faites. nous pouvons sois demander au serveur monitoré d' | + | === chiffrement === |
- | Il existe plusieurs méthode pour réaliser des active checks. | + | <WRAP center round important 60%> |
+ | Nécessite d' | ||
+ | </ | ||
- | ^ type de check ^ description ^ | + | 2 méthodes sont possible : |
- | |check_by_ssh | execute une commande distante par ssh| | + | |
- | |nrpe | protocole particulier qui va interroger le serveur avec un agent| | + | |
- | |check_mk| comme nrpe mais en plus efficace **FIXME**| | + | |
- | De manière générale, il faut éviter les connexion inutile. Le principe de check passif est interessant mais demande à mettre à jour chaque serveurs si une modification commune doit être faite. | + | == génération PKS == |
- | nrpe et check_mk centralise la chose sur le serveur shinken, et pourrait être plus simple à gérer dans le cadre de l'association. | + | nous utilisons içi gnuTLS |
+ | < | ||
+ | $ psktool -u psk_identity -p zabbix.psk -s 32 | ||
+ | | ||
+ | Key stored to zabbix.psk | ||
+ | |||
+ | $ cat zabbix.psk | ||
+ | psk_identity: | ||
+ | </ | ||
- | ===== Exploitation ===== | + | retirer la partie " |
- | ==== emplacements ==== | + | == paramètre agent zabbix |
- | de manière générale, pour la configuration tous ce trouve dans // | + | s' |
- | /usr/local/shinken/etc/ //. | + | < |
+ | $ chown zabbix: | ||
+ | </code> | ||
+ | |||
+ | ajouter les paramètre suivant dans le fichier zabbix_agentd.conf | ||
+ | |||
+ | < | ||
+ | TLSConnect=psk | ||
+ | TLSAccept=psk | ||
+ | TLSPSKFile=/ | ||
+ | TLSPSKIdentity=PSK 001 | ||
+ | </ | ||
- | Et pour les plugin il faut aller dans // / | + | == configuration serveur == |
- | cette endroit qu'en définit | + | |
- | ^ nom ^ chemin absolu ^ commentaires ^ | + | au niveau de la configuration de l' |
- | |définition des hosts | / | + | |
- | |déclaration des services | / | + | |
- | |emplacements des templates pour hosts|/ | + | |
- | ==== ajout d'un host ==== | + | {{:: |
- | Pour ajouter un host : | + | === Découverte automatique === |
+ | ajouter une entrée dans /// | ||
< | < | ||
- | define host{ | + | HostMetadata=Linux |
- | | + | HostMetadataItem=system.uname |
- | contact_groups | + | </ |
- | host_name | + | |
- | address | + | |
- | icon_set | + | |
- | } | + | |
- | </ | + | |
- | * **use** : permet | + | nécessite |
- | * **contact_groups** : permet | + | créer action |
- | * **host_name** : nom à faire apparaitre (pour l' | + | |
- | * **address** : indispensable pour joindre la machine. | + | |
- | * **icon_set** : l'icon a utiliser pour l' | + | |
- | ===== Haute Disponibilité | + | ===== Droits d' |
- | En cas d'indisponibilité du serveur principal, un spare peut prendre le relais. Mais ceci reste à définir. | + | L' |
- | ===== Backup ===== | + | Afin de trouver un équilibre entre ce qui est disponible à certaine population ou non, nous allons avoir besoin d' |
- | Shinken dispose | + | ==== Type de groupe d'utilisateurs ==== |
- | < | + | === administrateurs zabbix === |
- | / | + | |
- | </ | + | |
+ | Cette population a le droit de tous sur l' | ||
- | Par défaut, les sauvegardes sont faites dans le répertoire /// | + | === Les administrateurs === |
+ | Cette popuplation a le droit de voir toutes les machines, intervenir pour réaliser un acknowledge sur les problèmes. Elle s' | ||
- | ==== lister le backup ==== | + | === gérant de réseau de quartiers |
- | pour voir toutes | + | Cette population ne doit voir que les machines accessibles sur le quartier où celle-ci se situe |
- | < | + | ==== Tags ==== |
- | / | + | |
- | </ | + | |
- | ===== logs ===== | + | Pour réussir à segmenter les accès aux différentes machines nous devons recourir aux tags. nous pouvons mettre les clés que nous voulons avec les valeurs que nous souhaitons. Par la suite, il suffit de dire qu'un groupe d' |
- | shinken s' | + | Tags suggéré : |
+ | ^ tags ^ type de valeur | ||
+ | | quartier | ||
monitoring.1335290815.txt.gz · Dernière modification : 2013/01/01 22:59 (modification externe)