Hat das schon jemand hinter Cloudflare ausprobiert, ohne Metriken für die gesamte Öffentlichkeit zugänglich zu machen?
Das Problem ist, dass die ursprüngliche IP von Prometheus hinter Cloudflare (oder im Grunde jedem Proxy) nicht an der üblichen Stelle in den HTTP-Headern steht.
Gibt es eine Möglichkeit, dies nur über HTTP zugänglich zu machen oder eine zusätzliche (Sub-)Domain zu Discourse hinzuzufügen, um dafür ein SSL-Zertifikat zu erstellen?
Es über eine IP oder eine zusätzliche Subdomain zugänglich zu machen, die in Cloudflare in den transparenten Modus geschaltet werden könnte, wären zwei Optionen. Die andere wäre wahrscheinlich, das Plugin so zu modifizieren, dass es einen anderen HTTP-Header prüft. Ich denke, es sollte X-Forwarded-For oder CF-Connecting-IP sein. Ich bin nur der Typ, der dazu in der Lage ist. Letzteres wäre wahrscheinlich die klügste Lösung.
Jede Hilfe wird geschätzt.
EDIT: Mir ist gerade aufgefallen, dass Cloudflare selbst die richtige IP hinter Cloudflare sehr gut nutzt. Entweder macht das Plugin etwas anderes als Cloudflare selbst oder… :denkend:
Das ist genau das, was ich nicht tun möchte. Ich möchte nicht, dass auf dem Produktionsserver, der bereits stark durch Forenverkehr ausgelastet ist, viele zusätzliche Dinge passieren. Außerdem, wenn ich einen Reverse-Proxy einrichten müsste, bräuchte ich wahrscheinlich Grafana und Prometheus nicht lokal auszuführen, da ich /metrics einfach über IP und ohne HTTPS weiterleiten könnte – aber das klingt alles nach einer Notlösung. Ich dachte, es gäbe einen besseren Weg.
Es sind nicht viele Dinge. Der Aufwand ist ziemlich gering.
Oh, warte. Aber wenn du die Dinge so eingerichtet hast, dass die richtige Remote-IP bei Discourse ankommt, dann kannst du die Remote-IP einfach auf den Server setzen, auf dem du Prometheus ausführst, und es wird funktionieren. Das habe ich mit einigen Seiten gemacht, die ich überwacht habe. Ich bin mir ziemlich sicher, dass deshalb DISCOURSE_PROMETHEUS_TRUSTED_IP_ALLOWLIST_REGEX hinzugefügt wurde.
Verwendest du die Cloudflare-Vorlage? (Der empfohlene Weg ist die Verwendung eines echten CDN und die Überlassung der Proxy-Entscheidungen an Discourse, aber das möchtest du ja auch nicht.)
Das ist genau das, was bei mir nicht funktioniert.
Ich benutze eine Testmaschine, die nicht von Cloudflare weitergeleitet wird. Ich habe den Prometheus-Exporter dort eingerichtet, zusammen mit DISCOURSE_PROMETHEUS_TRUSTED_IP_ALLOWLIST_REGEX, der auf meinen Monitoring-Server gesetzt ist, und die Dinge funktionieren gut.
Auf der Produktionsmaschine funktioniert das Gleiche nicht.
Ja, ich benutze die Cloudflare-Vorlage
templates:
- "templates/postgres.template.yml"
- "templates/redis.template.yml"
- "templates/web.template.yml"
- "templates/web.ratelimited.template.yml"
## Uncomment these two lines if you wish to add Lets Encrypt (https)
- "templates/web.ssl.template.yml"
- "templates/web.letsencrypt.ssl.template.yml"
- "templates/cloudflare.template.yml"
und die IP-Adressen in den Benutzereinstellungen sehen gut aus.
Ich bin bisher sehr zufrieden damit, wie Cloudflare funktioniert, und es hat bereits viel zum Schutz vor DDOS beigetragen, daher würde ich lieber nicht zu einer anderen CDN-Lösung wechseln - zumindest sehe ich keinen Grund dafür.
Was den Prometheus-Exporter angeht, bin ich mir nicht sicher, warum, aber er scheint die IP-Prüfung nicht auf die gleiche Weise durchzuführen, wie es Discourse generell tut. Ich bin nicht gut genug in Ruby, um diese Annahme im Code zu validieren, aber ich bin sehr neugierig darauf.
Wenn Ihre Community DDOS-Angriffe anzieht, ist Cloudflare eine großartige Lösung.
Oh, er läuft auf seinem eigenen Port, also umgeht er NGINX, was diese Vorlage ändert, deshalb ist er anders. Wenn Sie also möchten, dass er HTTPS hat, bräuchten Sie meiner Meinung nach einen externen NGINX dafür. Oder greifen Sie einfach direkt über HTTP darauf zu und vertrauen Sie darauf, dass die IP-basierte Beschränkung gut genug ist (und vertrauen Sie den dazwischenliegenden Netzwerken).
Ich bin mir nicht sicher, ob wir über dasselbe sprechen. Ich sprach über das Exporter-Plugin (dieser Thread handelt davon), nicht über Prometheus. Der Exporter scheint die IP-Prüfung nicht auf die gleiche Weise zu handhaben wie Discourse selbst – oder sonst dürfte das Problem nicht bestehen, oder?
Ich habe es jetzt zum Laufen gebracht. Wenn ich das Dashboard-Beispiel von @sam sehe, frage ich mich, wie ich Redis- und Postgres-Daten einbringen würde. Wahrscheinlich mit zwei separaten Exportern. Ich frage mich nur, wie ich die Verbindung zu Postgres und Redis innerhalb von Discourse herstellen würde
