All links of one day
in a single page.
<Previous day - Next day>

rss_feedDaily RSS Feed
floral_left The Daily Shaarli floral_right
——————————— Tuesday 07, May 2019 ———————————
monitoring -
Lié depuis la page de Proxmox comme outil de stockage/centralisation de données de monitoring implémenté en natif, graphite est un petit outil simple qui permet de stocker/gérer n'importe quelle série de données.
La partie serveur est dans Debian stretch. La partie lecture (API/Web) n'est que dans les backports…

À partir du README Debian (/usr/share/doc/graphite-web/README.Debian), j'ai dû faire cela pour qu'il tombe en marche :
sudo touch /var/lib/graphite/graphite.db
sudo chown _graphite:_graphite /var/lib/graphite/graphite.db
sudo chmod 0600 /var/lib/graphite/graphite.db
sudo chown _graphite:_graphite /var/lib/graphite/
sudo chmod 0700 /var/lib/graphite/
(éditer /etc/graphite/local_settings.py au besoin)

Pour la partie Django/web :
sudo -u _graphite /bin/bash  -c 'graphite-manage migrate --run-syncdb'
sudo -u _graphite /bin/bash -c '/usr/bin/django-admin runserver --settings graphite.settings 0.0.0.0:8080'
sudo -u _graphite /bin/bash  -c 'graphite-manage createsuperuser'

Le serveur HTTP intégré à Django pour les tests/développement n'a pas voulu me servir les fichiers statiques, même en mode debug. En suivant des tuto, j'ai pu utiliser uwsgi à la place…
sudo -u _graphite uwsgi --plugin python,http --http 0.0.0.0:8080 --chdir /usr/share/graphite-web/ --wsgi-file /usr/share/graphite-web/graphite.wsgi --master --processes 4 --threads 2 --stats 127.0.0.1:9191 --static-map /static=/usr/share/graphite-web/static/
Ce service HTTP est utile soit pour accéder directement à graphite-web (mais j'ai pas trouvé super pratique même si ça fait le boulot), soit accéder au données via l'API, via d'autres outils.

Pour la partie stockage/serveur, simplement installer le paquet graphite-carbon a suffit.
monitoring -
Souvent cité comme visualiseur de données de Graphite, Grafana est un outil web de visualisation de données arbitraires. Comme il n'est pas lié à un format de données ou une base de données précise, il est obligé d'être très souple, ce qui est plutôt pratique MAIS forcément on doit tout définir à la main… ce qui les a conduit à mettre en place un espace d'échange de "dashboards" communautaire plutôt pratique.
Pour l'installation, j'ai juste pris le deb fourni, dans une VM dédié… ça juste marche et puis c'est tout. Après on peut se balader dans l'interface, ça fait très web 2.0 lourd appli etc. mais en vrai c'est quand même pratique d'avoir ses graph interactifs, de pouvoir zoomer/voir précisément, etc.
Il y a un mécanisme de "commit" des modifications, ce qui fait qu'on ne risque pas trop de "casser" ses graph par erreur.
En plus de Proxmox, j'ai aussi installé un collectd (paquet dispo dans Debian) qui envoie dans Graphite. Le grafana a donc accès à ces deux sources via l'API de Graphite.
Le dashboard qui a marché immédiatement pour collectd (les autres avaient des problèmes d'accès aux données, genre sous-dossier vs '.' etc.) est : https://grafana.com/dashboards/9576
Dans les variables du dashboard, ils ont pensé à laisser une variable pour le nom du serveur ce qui fait qu'on a un menu déroulant pour passer de l'un à l'autre, pratique.
Pour l'instant le seul "problème" de Grafana outre le côté appli web, c'est que le format des dates est hard-codé de partout, on ne peut pas le changer, et est à l'américaine, ce qui est confusionnant pour nous… https://github.com/grafana/grafana/issues/1459

Je pense qu'avec proxmox + collectd + graphite + grafana on a moyen de faire quelque chose de vraiment propre pour surveiller une infrastructure (probablement plus propre qu'avec un outil tout fait comme zabbix, mais beaucoup moins clé en main car les données et le visualiseur sont décorrélés donc il faut passer du temps à tout définir, ou tomber sur un dashboard tout fait qui répond au problème).
systemd -
Je squate de plus en plus /dev/shm sans soucis pour tout ce qui est temporaire/calcul, soit pour économiser des écritures sur carte SD (ou même SSD avant), soit pour la rapidité d'accès et je n'ai jamais eu de problème. Je vais là simplement parce que c'est un tmpfs (~ ramdisk) qui est souvent disponible, en tous cas sur du Debian(-like).
Mais il semblerait que par défaut systemd soit supposé vider les fichiers à la fin de la session d'un utilisateur (typiquement quand on quitte la dernière connexion SSH à une machine). J'ai rencontré ce "problème" seulement maintenant… en mode gros WTF.
Bon à savoir donc (et si vraiment on veut on peut facilement le désactiver avec RemoveIPC=no dans logind.conf apparemment).
-