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).

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.

Fichiers sysfs faciles à accéder pour voir les compteurs des interfaces réseau sans passer par une commande ou parser des sorties plus ou moins obsolètes comme ifconfig. Exemple pour le rx :
/sys/class/net//statistics/rx_bytes
/sys/class/net//statistics/rx_packets

Pas super intuitif d'aller sur un host pour faire un graph qui regroupe des métriques de plusieurs machines mais y'a de la bonne doc donc on va pas se plaindre :)

Run the next command to see where is the library snmp.so that was installed from the php5-snmp package:
find / | grep snmp.so
Ils disent :
Copy the path that shows to path where apache lampp needs.
Example from my machine:
cp /usr/lib/php5/20060613+lfs/snmp.so /opt/lampp/lib/php/extensions/no-debug-non-zts-20060613/

Sur cette base j'ai pu installer la lib snmp dans une install lampp 32 bits sur un OS 64 bits.
La version de l'API php (la date là-haut) de wheezy correspond à celle du lampp en question (coup de pot). Donc il suffit de wget comme un porc les paquet i386 wheezy de php5-snmp et libsnmp15, coller la snmp.so dans /opt/lampp/lib/php/extensions/no-debug-non-zts-20100525/ et les lib directement dans /opt/lampp/lib comme un goret et ouf ça passe.

En tous cas je sais pas pourquoi lampp ça existe mais je vois vraiment pas l'intérêt à part se faire mal.

Quelques pages décrivant les MIBS standard un peu moins mal fichues que ce que j'avais déjà trouvé.