Pour l’instant, si j’ai bien compris, pour qu’une instance Prometheus puisse récupérer des données depuis le point de terminaison /metrics, nous devons ajouter l’adresse IP de cette machine dans la liste autorisée en modifiant DISCOURSE_PROMETHEUS_TRUSTED_IP_WHITELIST_REGEX.
Existe-t-il une autre méthode pour faire cela ? Notre instance Discourse se trouve derrière le proxy DNS de Cloudflare et ne voit pas l’adresse IP réelle des utilisateurs finaux. Je préférerais vraiment si nous pouvions trouver un moyen de le faire avec des clés API, bien que cela semble peu probable en raison des restrictions concernant la façon dont Prometheus peut ingérer les données.
Dans ce cas, Discourse ne fonctionne pas correctement et vous devez ajouter le modèle Cloudflare.
Je pense que cela fonctionnerait. Avez-vous essayé ? Oh, mais je ne pense pas que vous puissiez demander à Grafana d’insérer les clés dans l’en-tête, c’est pourquoi j’ai ajouté cette fonctionnalité dès le départ.
Alors Discourse est cassé et vous devez ajouter le modèle Cloudflare.
Ah, que voulez-vous dire par « modèle Cloudflare » ?
Je pense que cela fonctionnerait. L’avez-vous essayé ? Ah, mais je ne pense pas que vous puissiez demander à Grafana d’insérer les clés dans l’en-tête, c’est pourquoi j’ai ajouté cette fonctionnalité dès le début.
Oui, je l’ai fait. Prometheus ne permet toujours pas d’en-têtes arbitraires dans les configurations de scraping. Donc, il n’y a aucun moyen pour moi de récupérer les métriques de Discourse dans Prometheus si je ne peux pas mettre en liste blanche l’adresse IP du serveur Prometheus, ce qui n’est pas possible dans mon cas.
Il y a probablement d’autres personnes qui exécutent leurs instances Discourse derrière des proxies comme Cloudflare. Donc, avec cette hypothèse à l’esprit, je crois que nous devrons ajuster un peu l’exportateur.
L’API de Discourse utilise ses propres en-têtes Api-Key et Api-Username au lieu d’une méthode quelque peu standardisée comme l’authentification HTTP de base (qui est prise en charge par le sous-système de scraping de Prometheus). Donc, je n’ai vraiment aucun moyen d’utiliser cela dans ma configuration.
cloudflare.template.yml a été activé. Mais si j’ai bien compris, cela servait uniquement à désactiver la limitation du débit pour le trafic provenant des adresses IP de Cloudflare.
Pour l’instant, voici à quoi ressemble ma configuration Prometheus :
Le problème que je rencontre actuellement est que Discourse ne parvient pas à voir l’adresse IP réelle d’une requête. Ainsi, pour que l’approche de la liste blanche fonctionne, j’ai essayé ceci :
J’ai ajouté l’adresse IPv6 de mon serveur Prometheus à la variable d’environnement DISCOURSE_PROMETHEUS_TRUSTED_IP_WHITELIST_REGEX dans app.yml.
J’ai codé en dur l’adresse IPv6 réelle du forum dans /etc/hosts sur le serveur Prometheus. Maintenant, le forum peut voir l’adresse IP de mon serveur Prometheus et lui accorder l’accès.
J’ai encore d’autres problèmes. Par exemple, j’exécute Prometheus dans un conteneur. Le fichier /etc/hosts de l’hôte n’est pas partagé à l’intérieur du conteneur. Ainsi, il continue de résoudre l’adresse du forum vers une adresse IP Cloudflare et échoue lors de l’authentification.
Je pourrais partager /etc/hosts de l’hôte dans le conteneur Docker avec -v /etc/hosts:/etc/hosts au démarrage de Prometheus, mais cela entraîne une erreur comme :
Get "https://forum-behind-cloudflare-dns-proxy.com:443/metrics": dial tcp [<ipv6-address>]:443: connect: cannot assign requested address
Maintenant, je dois simplement résoudre ce problème.
Édition n°1 : J’ai aussi trouvé la solution. IPv6 était désactivé à l’intérieur du conteneur Docker. Je peux le corriger en activant IPv6 dans le conteneur Docker ou simplement en utilisant --net=host.
Êtes-vous derrière un proxy inverse ? Vous devez configurer nginx pour permettre à la requête distante réelle d’atteindre Discourse. Je pense que l’article Exécuter d’autres sites web sur la même machine que Discourse pourrait vous donner un indice pour résoudre ce problème.
L’instance Discourse tourne bien derrière un proxy inverse. Ce proxy est fourni par Cloudflare, et nous ne sommes que sur le plan Pro, sans possibilité de transmettre l’adresse IP réelle du client jusqu’à l’instance Discourse depuis Cloudflare. Quoi qu’il en soit, mon problème est déjà résolu.
Le tableau de bord Grafana devrait probablement être mis à jour à présent. Au fil du temps, l’exportateur Prometheus a été mis à jour et ne transmet plus certaines métriques, mais le tableau de bord Grafana est toujours configuré pour lire les valeurs de ces métriques (désormais) inexistantes.