Pas toujours simple de s'y retrouver :
https://github.com/coreos/prometheus-operator
https://github.com/coreos/prometheus-operator/tree/master/contrib/kube-prometheus

La différence entre ces deux là est expliqué dans le README : https://github.com/coreos/prometheus-operator#prometheus-operator-vs-kube-prometheus

Ce qu'il faut retenir, c'est que si l'on veut une solution end-to-end de monitoring de son cluster, il faut utiliser kube-prometheus qui installe le prometheus operator et plein d'autres choses. D'après le Readme de kube prometheus, le projet s'utilise comme une lib qui permet de générer des manifests yaml qu'on va ensuite apply.

Le projet a aussi été packagé avec helm. Si on veut custom les manifests, ça a l'air plus facile à utiliser que le jsonnet de kube prometheus :
https://github.com/helm/charts/tree/master/stable/prometheus-operator

à tester sur serveurs perso

via pierrick

"prometheus only pull"

On peut aussi faire du push de manière détournée

• https://github.com/prometheus/node_exporter/blob/master/README.md#textfile-collector

bien bien cet ebook, des parties très interessantes sur la comprehension des valeurs qu'il faut remonter (average = useless, median = better, 90/95percentile = the best)

En revanche toutes les parties technique qui dévrivent l'installation/configuration bof bof.. ça prends de la place, on les lit pas et si on veut vraiment mettre tout ça en place, on va se plonger dans les docs officielles et pas suivre betement le livre.

Mais quand même cool pour les premiers chapitres où il explique son approche.

Quelques retours :

Pas forcément évident à installer, je suis parti sur la version "standalone" == on installe toute l'archi sur un seul host, ce qui est suffisant pour tester ou bien pour une petite infra.

Pour résumer il faut du redis, du rabbitmq (donc erlang), ensuite sensu (sensu-server sensu-client sensu-api) et enfin le dashboard libre uchiwa.
Ensuite côté clients, simplement le daemon sensu-client qui tourne (et bien configuré pour joindre le rabbitmq)

La doc est plutot bien faite mais parfois incomplete, beaucoup de partie "coming soon"...

Quelques ressentis à chaud :

• clairement Sensu n'est pas une solution out of the box facile à mettre en place/configurer, il faut le voir comme un framework et il y a pas mal de boulot avant d'arriver à une solution qui tourne. L'avantage c'est qu'on en fait ce qu'on en veut, c'est très souple.
• l'approche des checks est originale : on peut les configurer côté serveur (manière traditionnelle) ou bien côté client. Dans ce dernier cas, le client execute ses checks comme un grand et balance ses résultats. Pas besoin de configuration côté serveur, ça simplifie la gestion de configuration.
• le dashboard uchiwa est très basique, à confirmer mais je n'ai pas l'impression qu'on puisse effectuer des actions comme sur nagios du genre "planifier un downtine" ou bien "désactiver les notifications ou un check" etc C'est seulement du read only sur l'etat actuel de la plateforme
• il existe plusieurs types de checks : les check classiques qui retourne 0,1,2 (meme modele que nagios) pour dire si OK/WARNING/CRITICAL et les checks "metrics" qui retourne des listes de "clé valeur timestamp" qu'on peut forward à son systeme de stockage timeseries comme par exemple graphite. Je trouve l'idée assez séduisante de tout avoir au même endroit, ça permettrait de se passer de collectd.

On pourrait passer d'une stack : Nagios/collectd/graphite/grafana/statsd à une stack Sensu/Graphite/grafana/statsd

Je compléterai si je reviens dessus.

EDIT: je retire ce que j'ai dis sur uchiwa : on peut "stash" un service ou un host ce qui empeche de créer des events (alertes) à posteriori.

Du monitoring gratuit */5 minutes pour dépanner sur de petits projets

via Doo