Tout ceci est formidable, mais dans cet article, nous allons voir en détail comment mettre en place un Prometheus sans magie, avec découverte des services dans Consul : back to basics.
Cas d’école
Pour être certain que tout le monde comprenne bien cet exemple, je suis revenu à une preuve de concept ultra-simplifié. Il s’agit d’avoir sur une seule et même machine :
- Un serveur Prometheus, qui est chargé de la collecte des métriques auprès de différentes targets.
- Un service node_exporter, qui expose les métriques d’un système Linux selon les conventions attendues par Prometheus.
- Un service Consul, qui va servir de point de vérité pour que le node_exporter s’enregistre et que Prometheus voit cette nouvelle target.
Le but du jeu va donc être ici de voir la configuration minimale nécessaire pour que Prometheus découvre le service node_exporter et commence à en collecter les métriques.
Node Exporter
Le service node_exporter expose un serveur web avec une unique url /metrics qui permet à Prometheus de venir collecter les métriques périodiquement.
Pour enregistrer ce service dans Consul, nous allons simplement poser un fichier de configuration dans /etc/consul.d/node_exporter.json :
{
"service": {
"name": "node_exporter",
"tags": ["monitor"],
"port": 9100
}
}
Le port spécifié ici doit bien correspondre à votre configuration node_exporter. Nous démarrons notre agent Consul en ciblant ce répertoire de configuration :
consul agent -config-dir=/etc/consul.d
Prometheus
À ce stade, Consul tourne, il existe bien un service pointant notre node_exporter dans une des clés Consul, mais Prometheus n’est pas encore à l’écoute. Pour cela, il faut utiliser un fichier de configuration prometheus.yml contenant quelque chose comme ceci :
scrape_configs:
- job_name: consul
consul_sd_configs:
- server: 'localhost:8500'
relabel_configs:
- source_labels: [__meta_consul_tags]
regex: .*,monitor,.*
action: keep
- source_labels: [__meta_consul_service]
target_label: service
Que se passe-t-il ici ? Nous avons un job de scraping de métriques défini par Service Discovery Consul (consul_sd_configs). Il est cependant possible qu’il y ait beaucoup de services déclarés dans Consul. Si on ne restreint pas, notre Prometheus va perdre du temps et de l’énergie à requêter des tas de targets invalides.
Le premier élément de la section relabel_configs est là pour filtrer la liste des services fournis par Consul, en se basant sur la présence de tags. Ici nous acceptons comme target Prometheus uniquement les services taggés “monitor” dans Consul.
Même si c’est l’exemple ici, l’indirection par Consul est facultative. Si vous préférez écrire directement la liste de vos targets dans la configuration Prometheus, libre à vous.
Conclusion
Vous savez maintenant que Prometheus n’est pas fait que pour les plate-formes de conteneurs. Vous devriez pouvoir transposer cet exemple simplissime chez vous. Prometheus est vraiment un bon outil qui mérite qu’on se penche dessus. Vous pouvez même l’utiliser pour votre monitoring de parc legacy.
De nombreux exporters existent, pour des métriques ElasticSearch, MySQL, Redis, Kafka, Ceph, SNMP, et bien d’autres. Tout le monde devrait y trouver son compte.
Have fun. Hack in peace.
