الانتقال إلى الإنتاج

الانتقال إلى الإنتاج باستخدام ClickStack

عند نشر ClickStack في بيئة الإنتاج، هناك عدة اعتبارات إضافية لضمان الأمان والاستقرار والإعداد الصحيح. وتختلف هذه الاعتبارات بحسب النسخة المستخدمة - مفتوحة المصدر أو المُدارة - .

ClickStack المُدار

بالنسبة إلى عمليات النشر في بيئات الإنتاج، يُوصى باستخدام Managed ClickStack. فهو يطبّق ممارسات الأمان القياسية في المجال افتراضيًا، بما في ذلك التشفير المعزّز، والمصادقة والاتصال، وعناصر التحكّم بالوصول المُدارة، كما يوفّر المزايا التالية:

• التوسّع التلقائي لقدرات الحوسبة بصورة مستقلة عن التخزين
• احتفاظ منخفض التكلفة وعمليًا غير محدود بالاعتماد على التخزين الكائني
• إمكانية عزل أعباء عمل القراءة والكتابة بشكل مستقل باستخدام Warehouses.
• المصادقة المدمجة
• نسخ احتياطية مؤتمتة
• ترقيات سلسة

اتبع أفضل الممارسات هذه في ClickHouse Cloud عند استخدام Managed ClickStack.

​

تأمين الإدخال

افتراضيًا، لا يكون ClickStack OpenTelemetry Collector مؤمّنًا عند نشره خارج التوزيعات مفتوحة المصدر، ولا يتطلب مصادقة على منافذ OTLP الخاصة به.

لتأمين الإدخال، حدّد رمز مصادقة عند نشر collector باستخدام متغير البيئة OTLP_AUTH_TOKEN. راجع “تأمين الـ collector” لمزيد من التفاصيل.

​

إنشاء مستخدم للإدخال

يُوصى بإنشاء مستخدم مخصّص لـ OTel collector للإدخال إلى Managed ClickHouse، ولضمان إرسال البيانات المُدخلة إلى قاعدة بيانات محددة مثل otel. راجع “إنشاء مستخدم للإدخال” لمزيد من التفاصيل.

​

تهيئة Time To Live (TTL)

تأكّد من أن Time To Live (TTL) قد جرت تهيئته بالشكل المناسب لعملية نشر Managed ClickStack لديك. فهذا يتحكّم في مدة الاحتفاظ بالبيانات، وغالبًا ما يلزم تعديل القيمة الافتراضية البالغة 3 أيام.

​

تقدير الموارد

يوفّر ما يلي نموذجًا لتقدير موارد الحوسبة والتخزين المطلوبة لنشر ClickStack استنادًا إلى حجم الإدخال المتوقع. القيم الناتجة هي تقديرات فقط ويجب استخدامها بوصفها خط أساس أوليًا - وليست إجابة مُلزِمة. تعتمد المتطلبات الفعلية على تعقيد الاستعلامات، والتزامن، وسياسات الاحتفاظ، والتفاوت في معدل نقل الإدخال. راقب استخدام الموارد دائمًا وقم بالتوسعة حسب الحاجة.

جميع الأرقام تستند إلى الإدخال الخام غير المضغوط

كل رقم في هذه الصفحة - معدل النقل (MB/s، TB/month)، وتقدير CPU، والتخزين - مُعبَّر عنه من حيث حجم الإدخال الخام غير المضغوط، أي حجم البيانات كما تنتجها تطبيقاتك وتُرسَل إلى OpenTelemetry Collector قبل تطبيق أي ضغط.

هذا هو الرقم الذي ينبغي تقديره استنادًا إلى مسارات السجلات والتتبعات والمقاييس الحالية لديك. أرقام التخزين في الجدول أدناه مطبَّق عليها بالفعل نسبة ضغط 10x المفترضة لهذا الحجم الخام.

عند نشر ClickStack، خصّص موارد حوسبة لتغطية فئتَي عمل مستقلتين: الإدخال والاستعلام.

فئة العمل	الموارد المقدّرة
الإدخال	1 vCPU لكل 10 MB/s من معدل نقل الإدخال المستدام
الاستعلام	1 vCPU لكل 1 QPS ولكل 10 MB/s من معدل نقل الإدخال المستدام

عزل الاستعلامات عن الإدخال

في معظم عمليات النشر المُدارة ذاتيًا، يشترك الإدخال والاستعلام في العُقد نفسها. في هذه الحالة، استخدم إجمالي وحدات CPU بوصفه خط الأساس. التوسعة المعزولة - حيث يتم تخصيص حوسبة الإدخال وحوسبة الاستعلام بشكل مستقل - مدعومة في ClickHouse Cloud عبر مجمّعات حوسبة منفصلة، والمعروفة أيضًا باسم Warehouses.

الافتراضات

• نسبة ضغط 10x للتخزين - وهي عادةً تقدير متحفظ للسجلات والتتبعات.
• اتفاقيات مستوى الخدمة للاستعلامات عند P50 بمقدار 1.5 ثانية وعند P99 بمقدار 5 ثوانٍ.
• نفترض أن معظم الاستعلامات تُجرى على البيانات الحديثة، وفق توزيع لوغاريتمي طبيعي تبلغ ذروته عند نحو ساعة واحدة ويمتد حتى نحو ست ساعات. قد يرغب المستخدمون في تخصيص حوسبة مخصصة للاستعلام عن البيانات الأقدم. في ClickHouse Cloud يمكن أن تكون هذه الحوسبة خاملة (وبالتالي لا تترتب عليها تكاليف) عندما لا تكون قيد الاستخدام.
• رغم أن حوسبة الاستعلام يمكن توسيعها بشكل مستقل عن حوسبة الإدخال، فإنها تظل مرتبطة جوهريًا بحجم الإدخال. ونفترض أنه مع زيادة الإدخال، تزداد كثافة البيانات، ما يؤدي إلى أحجام مسح أكبر وقت الاستعلام، وبالتالي إلى متطلبات أعلى لحوسبة الاستعلام.

يوفّر الجدول التالي أمثلة على تقدير الموارد استنادًا إلى زيادة معدل نقل الإدخال بالميغابايت في الثانية، إلى جانب أحجام البيانات المقابلة بالتيرابايت في الشهر. ويفترض ذلك متوسطًا مستدامًا قدره 1 QPS من ClickStack عبر جميع أنواع الاستعلامات (البحث، لوحات المعلومات، والتنبيهات).

MB/s	TB/month	وحدات CPU للإدخال	وحدات CPU للاستعلام	إجمالي وحدات CPU	إجمالي التخزين (شهريًا) (GB)
10	25.92	1	3	4	2,592
20	51.84	2	6	8	5,184
50	129.6	5	15	20	12,960
100	259.2	10	30	40	25,920
200	518.4	20	60	80	51,840
500	1,296	50	150	200	129,600
1000	2,592	100	300	400	259,200

لمزيد من التفاصيل حول تحسين افتراضات تقدير الحجم لبيئتك، راجع “تحسين افتراضات تقدير الحجم لبيئتك”.

​

عزل أعباء عمل الرصد

إذا كنت تضيف ClickStack إلى خدمة ClickHouse Cloud حالية تدعم بالفعل أعباء عمل أخرى، مثل تحليلات التطبيقات في الوقت الفعلي، فإن عزل حركة مرور الرصد يُوصى به بشدة.

استخدم Managed Warehouses لإنشاء خدمة فرعية مخصّصة لـ ClickStack. يتيح لك ذلك ما يلي:

• عزل حمل الإدخال والاستعلامات عن التطبيقات الحالية
• توسيع أعباء عمل الرصد بشكل مستقل
• منع استعلامات الرصد من التأثير في تحليلات الإنتاج
• مشاركة مجموعات البيانات الأساسية نفسها عبر الخدمات عند الحاجة

يضمن هذا النهج بقاء أعباء العمل الحالية لديك دون تأثر، مع السماح لـ ClickStack بالتوسع بشكل مستقل مع نمو بيانات الرصد.

​

عزل أعباء عمل القراءة والكتابة

تتيح Warehouses أيضًا فصل أعباء عمل الإدخال والاستعلام الخاصة بـ ClickStack نفسه على قدرات حوسبة مخصّصة، بحيث يستهدف الإدخال خدمة للقراءة والكتابة، بينما تعمل ClickStack UI على خدمة للقراءة فقط. وهذه هي طوبولوجيا الإنتاج المُوصى بها لعمليات النشر الأكبر. راجع “عزل أعباء عمل القراءة والكتابة”.

بالنسبة إلى عمليات النشر الأكبر أو إرشادات تقدير الحجم المخصّصة، يُرجى التواصل مع الدعم للحصول على تقدير أدق.

ClickStack مفتوح المصدر

​

أمان الشبكة والمنافذ

بشكل افتراضي، يكشف Docker Compose المنافذ على المضيف، مما يجعلها قابلة للوصول من خارج الحاوية - حتى لو كانت أدوات مثل ufw (جدار الحماية المبسّط) مُفعَّلة. يعود هذا السلوك إلى حزمة شبكات Docker، التي يمكنها تجاوز قواعد جدار الحماية على مستوى المضيف ما لم يُضبط ذلك صراحةً.

التوصية:

اعرض المنافذ الضرورية لبيئة الإنتاج فحسب، وتشمل عادةً نقاط نهاية OTLP وخادم API والواجهة الأمامية.

على سبيل المثال، احذف تعيينات المنافذ غير الضرورية أو علّق عليها في ملف docker-compose.yml الخاص بك:

ports:
  - "4317:4317"  # OTLP gRPC
  - "4318:4318"  # OTLP HTTP
  - "8080:8080"  # Only if needed for the API
# Avoid exposing internal ports like ClickHouse 8123 or MongoDB 27017.

راجع توثيق شبكات Docker للاطلاع على تفاصيل عزل الحاويات وتقوية ضوابط الوصول.

​

تهيئة سر الجلسة

في بيئة الإنتاج، يجب تعيين قيمة قوية وعشوائية لمتغير البيئة EXPRESS_SESSION_SECRET الخاص بـ ClickStack UI (HyperDX)، لحماية بيانات الجلسة والحيلولة دون التلاعب بها.

إليك كيفية إضافته إلى ملف docker-compose.yml الخاص بك لخدمة التطبيق:

  app:
    image: ${IMAGE_NAME_HDX}:${IMAGE_VERSION}
    ports:
      - ${HYPERDX_API_PORT}:${HYPERDX_API_PORT}
      - ${HYPERDX_APP_PORT}:${HYPERDX_APP_PORT}
    environment:
      FRONTEND_URL: ${HYPERDX_APP_URL}:${HYPERDX_APP_PORT}
      HYPERDX_API_KEY: ${HYPERDX_API_KEY}
      HYPERDX_API_PORT: ${HYPERDX_API_PORT}
      HYPERDX_APP_PORT: ${HYPERDX_APP_PORT}
      HYPERDX_APP_URL: ${HYPERDX_APP_URL}
      HYPERDX_LOG_LEVEL: ${HYPERDX_LOG_LEVEL}
      MINER_API_URL: 'http://miner:5123'
      MONGO_URI: 'mongodb://db:27017/hyperdx'
      NEXT_PUBLIC_SERVER_URL: http://127.0.0.1:${HYPERDX_API_PORT}
      OTEL_SERVICE_NAME: 'hdx-oss-api'
      USAGE_STATS_ENABLED: ${USAGE_STATS_ENABLED:-true}
      EXPRESS_SESSION_SECRET: "super-secure-random-string"
    networks:
      - internal
    depends_on:
      - ch-server
      - db1

يمكنك إنشاء مفتاح سري قوي باستخدام openssl:

openssl rand -hex 32

تجنّب إيداع الـ secrets في نظام التحكم بالإصدارات. في بيئة الإنتاج، يُنصح باستخدام أدوات إدارة متغيرات البيئة (مثل Docker Secrets أو HashiCorp Vault أو إعدادات CI/CD الخاصة بكل بيئة).

​

تأمين الإدخال

يجب أن تتم عملية الاستيعاب بالكامل عبر منافذ OTLP التي يكشفها توزيع ClickStack من مُجمِّع OpenTelemetry (OTel). يستلزم هذا افتراضيًا مفتاح API استيعاب آمنًا يُولَّد عند بدء التشغيل. يُعدّ هذا المفتاح ضروريًا عند إرسال البيانات إلى منافذ OTel، ويمكن العثور عليه في واجهة HyperDX UI ضمن Team Settings → API Keys.

بالإضافة إلى ذلك، يُوصى بتفعيل TLS لنقاط نهاية OTLP.

​

إنشاء مستخدم للإدخال

يُوصى بإنشاء مستخدم مخصص لـ OTel collector لاستيعاب البيانات في ClickHouse، والتأكد من توجيه عملية الاستيعاب إلى قاعدة بيانات محددة، مثل otel. راجع “إنشاء مستخدم استيعاب” لمزيد من التفاصيل.

​

ClickHouse

ينبغي للمستخدمين الذين يديرون نسخة ClickHouse الخاصة بهم الالتزام بأفضل الممارسات التالية.

​

أفضل ممارسات الأمان

إذا كنت تدير نسخة ClickHouse الخاصة بك، فمن الضروري تفعيل TLS (أمان طبقة النقل)، وفرض المصادقة، واتباع أفضل الممارسات لتقوية ضوابط الوصول. راجع منشور المدونة هذا للاطلاع على أمثلة واقعية حول الأخطاء الشائعة في الإعداد وكيفية تجنبها.

يوفر ClickHouse OSS ميزات أمان قوية جاهزة للاستخدام دون الحاجة إلى إعداد مسبق. غير أن تفعيل هذه الميزات يستلزم بعض الضبط والتهيئة:

• استخدم TLS عبر tcp_port_secure و<openSSL> في config.xml. راجع guides/sre/configuring-tls.
• عيّن كلمة مرور قوية للمستخدم default أو عطّله.
• تجنّب تعريض ClickHouse للوصول الخارجي ما لم يكن ذلك مقصودًا صراحةً. افتراضيًا، لا يستمع ClickHouse إلا على localhost ما لم يتم تعديل listen_host.
• استخدم طرق المصادقة مثل كلمات المرور، والشهادات، ومفاتيح SSH، أو وسائل المصادقة الخارجية.
• قيّد الوصول باستخدام تصفية عناوين IP وعبارة HOST. راجع sql-reference/statements/create/user#user-host.
• فعّل التحكم في الوصول المستند إلى الدور (RBAC) لمنح امتيازات دقيقة. راجع operations/access-rights.
• افرض الحصص والحدود باستخدام quotas وsettings profiles وأوضاع القراءة فقط.
• شفّر البيانات المخزنة واستخدم تخزينًا خارجيًا آمنًا. راجع operations/storing-data وcloud/security/CMEK.
• تجنّب تضمين بيانات الاعتماد في الشيفرة بشكل ثابت. استخدم named collections أو أدوار IAM في ClickHouse Cloud.
• دقّق في الوصول والاستعلامات باستخدام سجلات النظام وسجلات الجلسات.

راجع أيضاً المصادقات الخارجية وإعدادات تعقيد الاستعلام لإدارة المستخدمين وفرض حدود الاستعلامات والموارد.

​

أذونات المستخدم لواجهة ClickStack UI

لا يحتاج مستخدم ClickHouse المخصص لـ ClickStack UI إلا إلى أن يكون مستخدمًا بصلاحية readonly مع إمكانية تعديل الإعدادات التالية:

• max_rows_to_read (بحد أدنى يصل إلى مليون واحد)
• read_overflow_mode
• cancel_http_readonly_queries_on_client_close
• wait_end_of_query

بشكل افتراضي، يمتلك المستخدم default في كلٍّ من OSS وClickHouse Cloud هذه الصلاحيات، غير أنه يُنصح بإنشاء مستخدم جديد بهذه الصلاحيات.

​

ضبط مدة البقاء (TTL)

تأكد من ضبط مدة البقاء (TTL) بالشكل المناسب لنشر ClickStack لديك. يتحكم هذا الإعداد في مدة الاحتفاظ بالبيانات - وغالبًا ما تحتاج القيمة الافتراضية البالغة 3 أيام إلى تعديل.

​

إرشادات MongoDB

اتبع قائمة التحقق الأمني الرسمية لـ MongoDB.