Quelqu’un a-t-il déjà essayé ceci derrière Cloudflare sans exposer les métriques à tout le public ?
Le problème est que l’IP d’origine de Prometheus ne se trouve pas à l’endroit habituel dans les en-têtes HTTP lorsqu’il est derrière Cloudflare (ou pratiquement n’importe quel proxy).
Existe-t-il un moyen de le rendre accessible uniquement via HTTP ou d’ajouter un sous-domaine supplémentaire à Discourse pour créer un certificat SSL ?
Le rendre accessible via une adresse IP ou un sous-domaine supplémentaire qui pourrait être configuré en mode transparent dans Cloudflare serait deux options. L’autre serait probablement de modifier le plugin pour vérifier un en-tête HTTP différent. Je pense que ce serait X-Forwarded-For ou CF-Connecting-IP. Je suis juste le genre de gars qui est capable de faire ça. Ce dernier serait probablement la solution la plus intelligente.
Toute aide est appréciée.
EDIT : Je viens de réaliser que Cloudflare utilise lui-même très bien la bonne IP derrière Cloudflare. C’est soit le plugin qui fait quelque chose de différent de Cloudflare lui-même, soit…
C’est exactement ce que je ne veux pas faire. Je préférerais ne pas avoir beaucoup de choses supplémentaires qui se déroulent sur le serveur de production, car il est déjà très sollicité par le trafic du forum. De plus, si je dois faire un proxy inverse, je n’aurais probablement pas besoin d’exécuter Grafana et Prometheus localement, car je pourrais facilement simplement faire un proxy inverse de /metrics en IP et sans https - mais tout cela semble bancal. Je pensais qu’il pourrait y avoir une meilleure façon.
Ce n’est pas grand-chose. C’est une surcharge assez faible.
Oh, attendez. Mais si vous avez configuré les choses de manière à ce que l’adresse IP distante correcte parvienne à Discourse, alors vous pouvez simplement définir l’adresse IP distante là où vous exécutez Prometheus et cela fonctionnera. C’est ce que j’ai fait avec certains sites que j’ai surveillés. Je suis à peu près sûr que c’est la raison pour laquelle DISCOURSE_PROMETHEUS_TRUSTED_IP_ALLOWLIST_REGEX a été ajouté.
Utilisez-vous le modèle Cloudflare ? (La manière recommandée de faire les choses est d’utiliser un véritable CDN et de laisser Discourse décider quelles choses doivent être proxyfiées, mais vous ne voulez pas faire cela non plus.)
C’est exactement ce qui ne fonctionne pas pour moi.
J’utilise une machine de test qui n’est pas proxifiée par Cloudflare. J’y ai configuré l’exportateur Prometheus avec DISCOURSE_PROMETHEUS_TRUSTED_IP_ALLOWLIST_REGEX défini sur mon serveur de surveillance et les choses fonctionnent bien.
Sur la machine de production, il en va de même.
Oui, j’utilise le modèle Cloudflare
templates:
- "templates/postgres.template.yml"
- "templates/redis.template.yml"
- "templates/web.template.yml"
- "templates/web.ratelimited.template.yml"
## Décommentez ces deux lignes si vous souhaitez ajouter Lets Encrypt (https)
- "templates/web.ssl.template.yml"
- "templates/web.letsencrypt.ssl.template.yml"
- "templates/cloudflare.template.yml"
et les adresses IP dans l’administration des utilisateurs sont correctes.
Je suis très satisfait de la façon dont Cloudflare fonctionne jusqu’à présent et cela a déjà beaucoup aidé avec la protection DDOS, donc je préférerais ne pas passer à une autre solution CDN - du moins je ne vois pas de raison.
Concernant l’exportateur Prometheus, je ne suis pas sûr pourquoi, mais il ne semble pas faire la vérification d’IP de la même manière que Discourse le fait généralement. Je ne suis pas assez compétent en Ruby pour faire valider cette hypothèse dans le code, mais cela me rend très curieux.
Si votre communauté est du genre à attirer des attaques DDOS, alors Cloudflare est une excellente solution.
Oh, il s’exécute sur son propre port, il contourne donc NGINX, ce que ce modèle modifie, c’est pourquoi c’est différent. Donc, si vous voulez qu’il ait https, vous auriez besoin d’un nginx externe pour le faire, je pense. Ou accédez-y simplement directement via http et faites confiance au fait que la restriction au niveau de l’IP est suffisante (et faites confiance aux réseaux intermédiaires).
Je ne suis pas sûr si nous parlons de la même chose. Je parlais du plugin d’exportation (ce fil de discussion en parle) et non de prometheus. L’exportateur ne semble pas gérer la vérification IP de la même manière que Discourse lui-même - ou sinon le problème ne devrait pas exister, n’est-ce pas ?
J’ai réussi pour l’instant. En voyant le tableau de bord exemple de @sam, je me demande comment j’intégrerais les données redis et postgres. Probablement avec deux exportateurs distincts. Je me demande juste comment je ferais la connexion à postgres et redis dans Discourse
