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/03/25 13:22] – [Passive checks] ajout bla bla sur active checks 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 nagios ===== | + | Nécessite pas grand chose pour l' |
- | afin de garder une consistence entre chacun de nos outils, et mieux maitriser notre techno. nous allons developpez nos propre plugin nagios. | + | * hostname : zabbix |
+ | * DNS : zabbix.faimaison.net | ||
+ | * CPU : 1vCPU | ||
+ | * RAM : 1G | ||
+ | * DD : 30GB | ||
- | Sur le choix de la technologie employé, nos allons resté sur du python quand on doit les écrire. Autrement, nous utiliserons les plugins qui viennent par défaut avec shinken | + | Nous partons d'une base debian buster (10) et nous utilisons les paquets officiel de zabbix en utilisant |
- | ===== Configuration ===== | + | ==== installation du répository zabbix et des paquets |
+ | < | ||
+ | # wget https:// | ||
+ | # dpkg -i zabbix-release_4.4-2+buster_all.deb | ||
+ | # apt update | ||
+ | # apt install zabbix-server-pgsql zabbix-frontend-php php-pgsql zabbix-apache-conf | ||
+ | </ | ||
- | ==== commun ==== | + | postgresql est installé par dépendance, |
- | Chaque serveur Faimaison est monitoré sur les points suivant : | + | ==== creation BDD et schema zabbix ==== |
- | * **[[monitoring/ | + | < |
- | * **[[monitoring/ | + | # su - postgres |
- | * **[[monitoring/ | + | $ pg_createcluster 11 zabbix |
- | * **ram** & **swap** : utilisation de la ram et swap | + | $ createuser --pwprompt zabbix |
- | * **[[monitoring/disk|disk]]** : espace disque de chaque partition | + | $ createdb -O zabbix zabbix |
- | * **ntp** : vérifie décalage par rapport à un server ntp donné | + | $ exit |
+ | # zcat /usr/ | ||
+ | </ | ||
- | ==== services | + | ==== configuration postgresql |
- | Services à monitorer : | ||
- | * **HTTP** : pour le site (test port 80 + parse page index) | + | utilisation de pgtune |
- | * **DNS** : résolution | + | |
- | * **SSH** : test de connexion ssh (test port 22) | + | |
- | * **GIT+SSH** : accès aux dépôts git | + | |
- | * **GIT** | + | |
- | ==== Active et Passive checks ==== | + | |
- | Différent type de récupération des données peuvent être faites. nous pouvons sois demander au serveur monitoré d' | + | <code postgresql> |
+ | # DB Version: 11 | ||
+ | # OS Type: linux | ||
+ | # DB Type: oltp | ||
+ | # Total Memory | ||
+ | # CPUs num: 1 | ||
+ | # Data Storage: hdd | ||
- | Il existe plusieurs méthode pour réaliser des active checks. | + | max_connections = 300 |
+ | shared_buffers = 256MB | ||
+ | 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 | ||
+ | </ | ||
- | ^ type de check ^ description ^ | ||
- | |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 | + | S' |
- | nrpe et check_mk centralise la chose sur le serveur shinken, et pourrait être plus simple à gérer dans le cadre de l' | + | < |
+ | DBHost= | ||
+ | DBName=zabbix | ||
+ | DBUser=zabbix | ||
+ | DBPassword=< | ||
+ | </ | ||
- | ===== Haute Disponibilité ===== | + | DBHost est vide pour utiliser les socket UNIX. |
- | En cas d' | + | ==== Conf frontweb et redémarrage ==== |
- | ===== Backup ===== | ||
- | Shinken dispose de son propre système de backup. Ce qui est sauvegardé n' | + | Dans /// |
+ | |||
+ | <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/ | ||
+ | </ | ||
+ | |||
+ | certbot, paquets zabbix utilise apache2 donc : | ||
< | < | ||
- | / | + | # apt install |
+ | # apt install python-certbot-apache | ||
+ | # certbot --apache | ||
</ | </ | ||
+ | Redémarrer l' | ||
- | Par défaut, les sauvegardes sont faites dans le répertoire /// | + | < |
+ | # systemctl restart zabbix-server apache2 zabbix-agent | ||
+ | # systemctl enable zabbix-server apache2 zabbix-agent | ||
+ | </code> | ||
+ | ==== Setup ==== | ||
- | ==== lister le backup ==== | + | Se connecter sur zabbix.faimaison.net/ |
+ | compléter l' | ||
- | pour voir toutes les backup faites : | + | |
+ | ===== Monitoring server | ||
+ | |||
+ | FIXME | ||
+ | |||
+ | ==== 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 | ||
< | < | ||
- | / | + | # apt install |
</ | </ | ||
+ | ==== Configuration agent ==== | ||
+ | |||
+ | === 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' | ||
+ | |||
+ | < | ||
+ | ServerActif=89.234.176.134 | ||
+ | </ | ||
+ | |||
+ | === chiffrement === | ||
+ | |||
+ | <WRAP center round important 60%> | ||
+ | Nécessite d' | ||
+ | </ | ||
+ | |||
+ | 2 méthodes sont possible : | ||
+ | |||
+ | == génération PKS == | ||
+ | nous utilisons içi gnuTLS | ||
+ | < | ||
+ | $ psktool -u psk_identity -p zabbix.psk -s 32 | ||
+ | Generating a random key for user ' | ||
+ | Key stored to zabbix.psk | ||
+ | | ||
+ | $ cat zabbix.psk | ||
+ | psk_identity: | ||
+ | </ | ||
+ | |||
+ | retirer la partie " | ||
+ | |||
+ | == paramètre agent zabbix == | ||
+ | |||
+ | s' | ||
+ | < | ||
+ | $ chown zabbix: / | ||
+ | </ | ||
+ | |||
+ | ajouter les paramètre suivant dans le fichier zabbix_agentd.conf | ||
+ | |||
+ | < | ||
+ | TLSConnect=psk | ||
+ | TLSAccept=psk | ||
+ | TLSPSKFile=/ | ||
+ | TLSPSKIdentity=PSK 001 | ||
+ | </ | ||
+ | |||
+ | == configuration serveur == | ||
+ | |||
+ | au niveau de la configuration de l' | ||
+ | |||
+ | {{:: | ||
+ | |||
+ | === Découverte automatique === | ||
+ | |||
+ | ajouter une entrée dans /// | ||
+ | < | ||
+ | HostMetadata=Linux | ||
+ | HostMetadataItem=system.uname | ||
+ | </ | ||
+ | |||
+ | nécessite d' | ||
+ | créer action pour créer host et ajouter le template | ||
+ | |||
+ | ===== Droits d' | ||
+ | |||
+ | L' | ||
+ | |||
+ | Afin de trouver un équilibre entre ce qui est disponible à certaine population ou non, nous allons avoir besoin d' | ||
+ | |||
+ | ==== Type de groupe d' | ||
+ | |||
+ | === administrateurs zabbix === | ||
+ | |||
+ | Cette population a le droit de tous sur l' | ||
+ | |||
+ | === Les administrateurs === | ||
+ | |||
+ | Cette popuplation a le droit de voir toutes les machines, intervenir pour réaliser un acknowledge sur les problèmes. Elle s' | ||
+ | |||
+ | === gérant de réseau de quartiers === | ||
+ | |||
+ | Cette population ne doit voir que les machines accessibles sur le quartier où celle-ci se situe | ||
+ | |||
+ | ==== Tags ==== | ||
+ | |||
+ | 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' | ||
+ | |||
+ | Tags suggéré : | ||
+ | ^ tags ^ type de valeur | ||
+ | | quartier | ||
monitoring.txt · Dernière modification : 2019/11/28 08:47 de gde