هل جرب أحد هذا خلف Cloudflare دون فتح المقاييس للجمهور بالكامل؟
المشكلة هي أن عنوان IP الأصلي لـ Prometheus ليس في المكان المعتاد في رؤوس HTTP عند وجوده خلف Cloudflare (أو أي وكيل بشكل أساسي).
هل هناك أي طريقة لجعل هذا متاحًا عبر HTTP فقط أو إضافة نطاق فرعي إضافي إلى Discourse لإنشاء شهادة SSL له؟
إن جعله متاحًا عبر عنوان IP أو نطاق فرعي إضافي يمكن تبديله إلى الوضع الشفاف في Cloudflare سيكون خيارين. الآخر سيكون على الأرجح تعديل المكون الإضافي للتحقق من رأس HTTP مختلف. يجب أن يكون X-Forwarded-For أو CF-Connecting-IP أعتقد. أنا مجرد الشخص الذي يمكنه فعل ذلك. الأخير سيكون على الأرجح الحل الأذكى.
أي مساعدة موضع تقدير.
تحرير: لقد أدركت للتو أن Cloudflare نفسها تستخدم عنوان IP الصحيح خلف Cloudflare بشكل جيد جدًا. إما أن المكون الإضافي يفعل شيئًا مختلفًا عن Cloudflare نفسها أو …
هذا بالضبط ما لا أريد فعله. أفضل عدم وجود الكثير من الأشياء الإضافية التي تحدث على خادم الإنتاج لأن هذا الخادم مثقل بالفعل بحركة مرور المنتدى. أيضًا، إذا احتجت إلى القيام بـ reverse proxy، فربما لن أحتاج إلى تشغيل Grafana و Prometheus محليًا حيث يمكنني بسهولة reverse proxy /metrics خارج IP وبدون HTTPS - ولكن كل هذا يبدو مخترقًا. اعتقدت أنه قد تكون هناك طريقة أفضل.
ليس الأمر بالكثير من الأشياء. إنه ذو حمل منخفض جدًا.
أوه، انتظر. ولكن إذا كان لديك إعدادات بحيث يصل عنوان IP البعيد الصحيح إلى Discourse، فيمكنك ببساطة تعيين عنوان IP البعيد إلى المكان الذي تقوم فيه بتشغيل Prometheus وسيعمل. هذا ما فعلته مع بعض المواقع التي راقبتها. أنا متأكد من أن هذا هو سبب إضافة DISCOURSE_PROMETHEUS_TRUSTED_IP_ALLOWLIST_REGEX.
هل تستخدم قالب Cloudflare؟ (الطريقة الموصى بها هي استخدام شبكة توصيل محتوى حقيقية والسماح لـ Discourse بتحديد الأشياء التي سيتم توجيهها، ولكنك لا تريد فعل ذلك أيضًا.)
أنا أستخدم جهاز اختبار غير موجه بواسطة Cloudflare. لقد قمت بإعداد مُصدِّر Prometheus هناك مع تعيين DISCOURSE_PROMETHEUS_TRUSTED_IP_ALLOWLIST_REGEX إلى خادم المراقبة الخاص بي وتعمل الأمور بشكل جيد.
على الجهاز الإنتاجي، نفس الشيء لا يعمل.
نعم، أنا أستخدم قالب Cloudflare
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"
وعناوين IP في مسؤول المستخدمين تبدو جيدة.
أنا سعيد جدًا بكيفية عمل Cloudflare حتى الآن وقد ساعد الكثير بالفعل في الحماية من هجمات DDoS، لذا أفضل عدم التحول إلى حل شبكة توصيل محتوى مختلف - على الأقل لا أرى سببًا لذلك.
فيما يتعلق بمُصدِّر Prometheus، لست متأكدًا من السبب ولكن يبدو أنه لا يقوم بفحص IP بنفس الطريقة التي يقوم بها Discourse بشكل عام. أنا لست مؤهلاً بما يكفي في Ruby للتحقق من هذا الافتراض في الكود ولكني فضولي جدًا بشأنه.
إذا كان مجتمعك يجذب هجمات DDOS، فإن Cloudflare يعد حلاً رائعًا.
أوه، إنه يعمل على منفذه الخاص، لذا فهو يتجاوز NGINX، وهو ما يغيره هذا القالب، ولهذا السبب يختلف. لذا، إذا كنت تريده أن يدعم HTTPS، فستحتاج إلى nginx خارجي للقيام بذلك، على ما أعتقد. أو يمكنك الوصول إليه مباشرة عبر HTTP والثقة في أن تقييد مستوى IP كافٍ (والثقة في الشبكات الفاصلة).
لست متأكدًا مما إذا كنا نتحدث عن نفس الشيء. كنت أتحدث عن المكون الإضافي للمُصدِّر (هذا الموضوع يدور حوله) وليس عن prometheus. يبدو أن المُصدِّر لا يتعامل مع فحص IP بنفس طريقة تعامل discourse نفسها - أو بخلاف ذلك لا ينبغي أن تكون المشكلة موجودة، أليس كذلك؟
لقد نجحت في ذلك الآن. بالنظر إلى لوحة معلومات المثال الخاصة بـ @sam ، أتساءل كيف يمكنني إدخال بيانات redis و postgres. من المحتمل أن يتم ذلك باستخدام مصدرين منفصلين. أتساءل فقط كيف يمكنني الاتصال بـ postgres و redis داخل Discourse
