source: Nicolargo
Le nombre de projets gravitant autour de Glances étant devenu assez important, j'ai dessiné le schéma suivant (à partir du service en ligne Gliffy pour les plus curieux d'entre vous):
Le cœur de Glances (source disponible sur le Github officiel) est représenté en vert.
On trouve ensuite en bleu les projets composant son écosystème:
Cet article L’écosystème autour de Glances est apparu en premier sur Le blog de NicoLargo.
De retour de congés avec dans ma besace une nouvelle version de Glances qui sera la dernière version majeure de la série 1.x. La prochaine version sera donc une 2.x avec notamment un gros travail initial de refactoring/découpage du code en modules car le script initial atteint une taille critique (plus de 4400 lignes) qui commence à le rendre difficilement évolutif.
Mais revenons donc à nos moutons pour parler de cette version de Glances 1.7:
Pour ceux d'entre vous qui découvrent Glances dans ce billet, c'est un projet que j'ai lancé maintenant il y a 2 ans pour palier à un manque dans les outils de supervision système. En effet, j'utilisais tout un tas de logiciels (netstat, top, ntop, ifstat, dstat...) pour investiguer les éventuels problèmes de performance sur un système d'exploitation. Mais aucun ne permettait une visualisation simple (via un terminal par une connexion SSH) et rapide (sur un seul écran) des statistiques nécessaires. Glances était née.
Cette version apporte, en plus de son lot de corrections de bugs, d'améliorations des performances et de la documentation de nouvelles fonctionnalité que nous allons détailler ensemble
L'objectif qui se cache derrière cette nouvelle fonction est de pouvoir, en un clin d'oeil, voir l'état d'un ensemble de processus regroupés ensemble sous une même thématique.
Par exemple, sur un machine hébergeant un serveur Web dynamique, la supervision des processus "importants" peut se découper de la manière suivante:
On a donc 5 objets à superviser. Dans Glances, la définition de ces objets est faite via le fichier de configuration glances.conf. Chaque objet est défini par:
et optionnellement par:
Note: par défaut, Glances par sur le principe ou le groupe ne contient qu'un seul processus (donc countmin = countmax = 1)
Ainsi, la configuration de l'objet n°1 (on peut définir jusqu'à 10 objets) correspondant au serveur Web Nginx est donc la suivante:
[monitor] list_1_description=Serveur Web Nginx list_1_regex=.*nginx.* list_1_command=nginx -v list_1_countmin=1 list_1_countmax=4
Dans Glances, l'affichage des objets se fait de la manière suivante:
La couleur détermine l'état de l'objet. Si le nombre de processus:
Comme pour toutes les autres statistiques importantes de Glances, le changement des états est logué.
En mode client/serveur la liste des items est défini au niveau serveur. Une nouvelle entrée dans l'API permet au client de récupérer la liste sur le serveur.
Sur certain système, notamment les NAS, la température des disques est un critére important à surveiller. En partant de ce postulat, MendelGusmao a développé un module optionnel (activable en passant l'option -y au lancement de Glances) permettant d'aller récupérer la température des disques sur le daemon HDDTemp qui doit être lancé sur votre machine (voir ici les instructions d'installation de HDDTemp sur Debian/Ubuntu).
Sur ma machine (qui ne comporte qu'un seul disque dur), j'obtiens l'affichage suivant:
Il est bien sûr possible de définir les seuils d'alertes dans la section [hddtemperature] du fichier de configuration de Glances. Les valeurs par défaut sont: CAREFUL=45 / WARNING = 52 / CRITICAL = 60 (en ° celcus).
J'ai reçu plusieurs demandes d'utilisateur de Glances souhaitant superviser la capacité de la batterie (notamment dans le cas d'utilisation de nano PC autonomes). Premier problème, PsUtil ne remonte pas ce genre de statistiques (du moins dans la version actuelle 1.0). Après une rapide et non exhaustive recherche sur le net d'une bibliothéque Python permettant d'obtenir simplement les informations disponibles sur les systèmes Linux j'ai du me résoudre à coder moi même quelque chose. C'est donc ainsi que Batinfo est apparu il y a quelques semaines.
L'intégration de la librairie Batinfo a été ensuite une formalité et Glances propose donc, si une ou plusieurs batteries sont détectés, l'affichage du pourcentage de capacité restante au milieu du footer:
Limitation: cette statistique est uniquement disponible sur les systèmes Linux.
Le traitement de la liste comprenant les processus est un des facteur principaux de la consommation CPU de Glances. Sur certain système (notamment les nanos PC comme les Raspberry Pi), il est conseillé de réduire le taux de rafraichissement des statistiques pour faire baisser cette consommation CPU. Cependant, si vous avez besoin d'un taux de rafraichissement important sans avoir besoin du détail des processus alors l'option -r codé par J.Renner est faite pour vous. En lançant Glances avec l'option -r, vous allez désactiver tout les traitements des processus (liste dynamique, monitored process list...) et ainsi disposer d'un Glances faiblement consommateur de CPU.
Sur ma machine de développement, l'utilisation de cette option fait passer la consommation CPU de 2.9% à 0.3%.
Une version précédante de Glances voyait apparaître une option (activable en appuyant sur la touche '1' dans Glances) permettatn d'afficher le détail de la CPU par coeur et non plus globalement. Une nouvelle option sur la ligne de commande (-1) permet de lancer par défaut ce mode d'affichage.
Enfin un vrai support IPv6 pour le mode client serveur de Glances.
A tester simplement et localement avec:
glances -s -B ::0
pour lancer le serveur en mode IPv6 avec un bind sur toutes les interfaces.
Puis ensuite on lance le client sur le localhost IPv6:
glances -c ::1
Quelques autre petites nouveautés:
Tout d'abord un grand merci aux principaux contributeurs de cette nouvelle version:
Ensuite, je compte sur vous pour tester cette nouvelle version qui est dès à présent disponible sous Pypi (les packages Debian, BSD, Windows et Mac ne devrait pas trop tarder).
Si vous avez installé Glances via Pypi (ce que je conseille), une mise à jour peut se faire simplement via la ligne de commande:
sudo pip install --upgrade Glances
Pour une installation toute fraîche (pour les nouveaux venus ayant les droits root):
sudo pip install Glances
ou la commande équivalente pour une installation locale (pour les nouveaux venus sans les droits root):
pip install --user Glances
Si vous préférerez utiliser les packages Debian/Ubuntu, Windows et Mac OS, il va falloir attendre un peu que mes "packagers" attitrés bossent un peu.
J'attend vos retours sur les commentaires suivants ou vos retour de bug/demande d'amélioration sur le site du dépôt officiel.
Cet article Présentation des nouveautés de Glances 1.7 est apparu en premier sur Le blog de NicoLargo.
Pas trop le temps de bloguer en ce moment entre le boulot, le développement de la prochaine version de Glances et... la préparation de la conf de présentation du Raspberry Pi que j'ai faite jeudi dernier dans le cadre des SophiaConf 2013.
Voici donc le support de présentation que j'ai utilisé et qui est bien sûr ré-utilisable comme tout ce que je publie sur ce site (licence CC BY 3.0).
Elle est disponible à partir de ce lien ou en cliquant sur l'image ci-dessous (j'ai utilisé le framework de présentation Shower).
Pour avoir une version PDF, il suffit d'ouvrir la présentation dans votre navigateur Web et de faire imprimer vers PDF !
Cet article Support de présentation SophiaConf 2013 – Raspberry Pi est apparu en premier sur Le blog de NicoLargo.
Je souhaitais ajouter dans Glances un plugin permettant de superviser l'état des batteries. J'ai donc commencé à chercher une librairie Python permettant de s'acquiter le plus simplement possible de cette tache qui sous un système GNU/Linux consiste à analyser le répertoire /sys/class/power_supply maintenu à jour par le noyau Linux.
Comme je n'ai pas trouvé mon bonheur, j'ai donc décidé de développer un librairie Python: BatInfo.
Les sources de cette librairie sont disponibles sur Github en licence LGPL.
L'installation sur votre système peut se faire simplement via la librairie Pypi:
sudo pip install batinfo
L'utilisation de la librairie dans vos développement Python est la suivante, on commence par inclure la librairie:
import batinfo
Puis on créé une instance (bat) de la classe principale (batteries):
bat = batinfo.batteries()
On peut récupérer les données brutes (format JSON) en utilisant:
bat.stat [{"status": "Full", "capacity": 50, "name": "CMB1", "uevent": "POWER_SUPPLY_NAME=CMB1\nPOWER_SUPPLY_STATUS=Full\nPOWER_SUPPLY_PRESENT=1\nPOWER_SUPPLY_TECHNOLOGY=Li-ion\nPOWER_SUPPLY_CYCLE_COUNT=0\nPOWER_SUPPLY_VOLTAGE_MIN_DESIGN=10800000\nPOWER_SUPPLY_VOLTAGE_NOW=12496000\nPOWER_SUPPLY_CURRENT_NOW=0\nPOWER_SUPPLY_CHARGE_FULL_DESIGN=5800000\nPOWER_SUPPLY_CHARGE_FULL=5800000\nPOWER_SUPPLY_CHARGE_NOW=3900000\nPOWER_SUPPLY_CAPACITY=100\nPOWER_SUPPLY_MODEL_NAME=CP293550-01\nPOWER_SUPPLY_MANUFACTURER=Fujitsu\nPOWER_SUPPLY_SERIAL_NUMBER=01A-Z100320001158Z", "alarm": 0, "charge_full": 5800000, "voltage_now": 12496000, "serial_number": "01A-Z100320001158Z", "cycle_count": 0, "current_now": 0, "charge_now": 3900000, "voltage_min_design": 10800000, "path": "/sys/class/power_supply/CMB1", "technology": "Li-ion", "manufacturer": "Fujitsu", "type": "Battery", "model_name": "CP293550-01", "present": 1, "charge_full_design":5800000}]
Les données brutes se présentent sous la forme d'une liste de dictionnaire (un dictionnaire par batterie présente sur votre système). Comme la plupart du temps les machines (portable) ont une seule batterie, on peut avoir le dictionnaire associé à cette première batterie avec:
bat.stat[0] {"status": "Full", "capacity": 100, "name": "CMB1", "uevent": "POWER_SUPPLY_NAME=CMB1\nPOWER_SUPPLY_STATUS=Full\nPOWER_SUPPLY_PRESENT=1\nPOWER_SUPPLY_TECHNOLOGY=Li-ion\nPOWER_SUPPLY_CYCLE_COUNT=0\nPOWER_SUPPLY_VOLTAGE_MIN_DESIGN=10800000\nPOWER_SUPPLY_VOLTAGE_NOW=12496000\nPOWER_SUPPLY_CURRENT_NOW=0\nPOWER_SUPPLY_CHARGE_FULL_DESIGN=5800000\nPOWER_SUPPLY_CHARGE_FULL=5800000\nPOWER_SUPPLY_CHARGE_NOW=3900000\nPOWER_SUPPLY_CAPACITY=100\nPOWER_SUPPLY_MODEL_NAME=CP293550-01\nPOWER_SUPPLY_MANUFACTURER=Fujitsu\nPOWER_SUPPLY_SERIAL_NUMBER=01A-Z100320001158Z", "alarm": 0, "charge_full": 5800000, "voltage_now": 12496000, "serial_number": "01A-Z100320001158Z", "cycle_count": 0, "current_now": 0, "charge_now": 3900000, "voltage_min_design": 10800000, "path": "/sys/class/power_supply/CMB1", "technology": "Li-ion", "manufacturer": "Fujitsu", "type": "Battery", "model_name": "CP293550-01", "present": 1, "charge_full_design":5800000}
Les statistiques présentes dans le dictionnaire dépende de votre batterie. Mais on retrouve un certain nombre d'informations génériques comme par exemple la capacité restante (en %):
bat.stat[0].capacity 50
la capacité maximale:
bat.stat[0].charge_full 5800000
ou encore la capacité courante:
bat.stat[0].charge_now 3900000
On peut aussi avoir des informations constructeurs:
bat.stat[0].manufacturer 'Fujitsu' bat.stat[0].technology 'Li-ion'
En espérant que cette librairie soit utile à certains. Si vous avez des remarques/rapports de bug à faire, merci d'utiliser le Github: https://github.com/nicolargo/batinfo/issues
Il ne me reste plus, pour ma part, qu'à intégrer cela dans Glances.
Cet article BatInfo, une lib Python pour vos batteries est apparu en premier sur Le blog de NicoLargo.
Cette phrase a été prononcée au moins une fois par toute personne ayant administré les règles de Firewall d'un serveur. Les conséquences vont du simple blocage d'une application critique (dont on s’aperçoit de l'indisponibilité au prochain "check" sur son serveur de monitoring) à la perte de connexion pure et simple vers la machine (même pour corriger sa boulette).
Pour éviter de se retrouver dans cette situation et ainsi éviter les rires et moqueries des collègues, voici quelques pistes que j'utilise pour administrer mes règles IpTables sur mes serveurs Debian.
Il y a plusieurs écoles pour gérer les règles de Firewall. Celle proposée par le wiki officiel de Debian repose sur l'utilisation exclusive des commandes iptables-save et iptables-restore qui permettent respectivement de sauvegarder et de restaurer une configuration IpTables existante.
Pour ma part, je préfère inclure ces commandes dans un script de plus haut niveau que je positionne dans le répertoire /etc/init.d et qui sera donc lancé au démarrage du serveur. Ce fichier firewall.sh est disponible sur mon GitHub DebianPostInstall ou via Gist.
En voici une version à ce jour:
Par défait le script met en place les règles suivantes:
L'utilisation de ce script est standard, ainsi pour appliquer les règles de Firewall:
sudo service firewall.sh start
Pour supprimer les règles de Firewall (attention votre serveur sera ainsi exposé aux attaques extérieures puisqu'aucunes restriction d'accès ne sera appliquée):
sudo service firewall.sh clear
Attention: Il est également possible d'utiliser cette commande avec l'option stop (sudo service firewall.sh stop), mais il faut être conscient que toutes les connexions, entrantes et sortantes seront alors interdites (même votre SSH !!!). Cette commandes est donc à éviter bannir si l'on utilise une connexion à distance pour administrer son serveur...
On entre ici dans le vif du sujet de ce billet: Comment procéder quand on doit modifier les règles de sécurité ?
La première chose à faire est d'être sûr d'avoir les connaissances nécessaires avant de toucher à quoi que ce soit. Cela peut sembler évident, mais faire des copier/coller de règles trouver sur le net et que l'on ne maîtrisent pas est, sans aucun doute, le meilleur moyen de tout faire planter. Pour modifier les tables IpTables, il faut donc avoir un verni de connaissance général sur le protocole TCP/IP (notamment les notions d'adresses et de port sources/destinations). On trouve pour cela quelques très bon cours en ligne comme celui de chez Developpez.com ou bien la bible de Tanenbaum: Réseaux 5em édition aux éditions Pearson. Bien évidemment, il faut également connaitre les rudiments de la commande IpTables en lisant la documentation officielle (disponible en Français) et notamment la section sur le filtrage de paquets.
On peut passer aux choses sérieuses en identifiant les règles courantes grâce à la commande:
sudo iptables -n -L -v --line-numbers
On obtiendra alors une sortie dépendante des règles actives (exemple pour un de mes serveurs):
Chain INPUT (policy DROP 13 packets, 1398 bytes) num pkts bytes target prot opt in out source destination 1 381M 138G fail2ban-ALL tcp -- * * 0.0.0.0/0 0.0.0.0/0 2 495K 83M fail2ban-SSH tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 3 251M 23G fail2ban-HTTP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 4 380M 138G fail2ban-ALL tcp -- * * 0.0.0.0/0 0.0.0.0/0 5 606M 241G ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 6 64473 3711K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 7 12M 653M ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 8 1 44 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:1337 9 55724 3343K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:4949 10 85 4064 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5001 11 53603 3216K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:61209 12 13 532 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:123 13 224K 21M ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:161 14 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:5001 15 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 16 230K 22M ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 17 4822K 289M ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 18 3684K 435M LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 19 0 0 ACCEPT tcp -- * * 88.190.254.200 0.0.0.0/0 tcp spt:20 Chain FORWARD (policy DROP 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination Chain OUTPUT (policy DROP 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 98M 183G ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0 2 253M 912G ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 3 1 84 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 4 0 0 ACCEPT tcp -- * * 0.0.0.0/0 195.20.242.89 tcp dpt:80 5 0 0 ACCEPT tcp -- * * 0.0.0.0/0 212.211.132.32 tcp dpt:80 6 0 0 ACCEPT tcp -- * * 0.0.0.0/0 212.211.132.250 tcp dpt:80 7 179 10740 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:21 8 276 14700 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 9 1254 75180 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:25 10 91789 5507K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 11 12940 776K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 12 688K 46M ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpts:1024:65534 13 90M 5705M ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 14 30171 2293K ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:123 15 0 0 ACCEPT tcp -- * * 0.0.0.0/0 88.190.254.200 tcp dpt:21 16 78 3120 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 17 78 3120 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable Chain fail2ban-ALL (2 references) num pkts bytes target prot opt in out source destination 1 761M 277G RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 2 0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 Chain fail2ban-HTTP (1 references) num pkts bytes target prot opt in out source destination 1 251M 23G RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 Chain fail2ban-SSH (1 references) num pkts bytes target prot opt in out source destination 1 10 1568 DROP all -- * * 61.155.150.217 0.0.0.0/0 2 408K 77M RETURN all -- * * 0.0.0.0/0 0.0.0.0/0
Une fois que vous avez identifié la règle IpTables à ajouter dans votre configuration, il est maintenant temps de passer à l'action.
Ne jamais, jamais, modifier directement la table avec une commande IpTables sur un serveur en production...
Plusieurs solutions sont possibles, personnellement, j'utilise la méthodologie suivantes:
Les lignes de commandes correspondantes sont:
sudo cp /etc/init.d/firewall.sh /tmp/ sudo vim /tmp/firewall.sh sudo sh /tmp/firewall.sh test sudo cp /tmp/firewall.sh /etc/init.d/ sudo service firewall.sh restart
Ainsi, en cas de problème dans les règles, le serveur ne sera indisponible que pendant 30 secondes. Dans le cas "pas de bol" ou le serveur crache durant ces 30 secondes alors les anciennes règles seront rechargées au redémarrage.
Si vous ne souhaitez pas mettre en place un tel script de démarrage des règles de Firewall, il est quand même possible (même si je ne le conseille pas pour avoir une vue d'ensemble des règles à appliquer) de reproduire la méthodologie d'écrite dans le chapitre précédant.
Ainsi, il est tout à fait possible d'utiliser une commande du type:
sudo iptables-save > /etc/iptables.backup && sudo iptables <nouvelle regle a appliquer> && sleep 30 && sudo iptables-restore < /etc/iptables.backup
Comment gérez-vous vos règles de Firewall sur vos serveurs GNU/Linux ? Des astuces à partager avec nous dans les commentaires ?
Cet article Ma méthode pour gérer les règles IpTables est apparu en premier sur Le blog de NicoLargo.