Skip to main content

​
الأسئلة الشائعة

​
ما البيانات التي تغادر بيئتي؟

هناك مساران لإرسال البيانات إلى الخارج، وكلاهما عبر اتصالات صادرة ينشئها الموصل بنفسه: مسار الكشط الذي ينقل البيانات الوصفية التشغيلية باستمرار، وجلسات الدعم التي تفعّلها وتعيد معلومات التشخيص. يرسل الكاشط نتائج مجموعة ثابتة من جداول النظام (metric_log وasynchronous_metric_log وtables وwarnings وserver_settings افتراضيًا)، وإشارات دورية عن الصحة والحالة، وحالة المثيل والنسخ الاحتياطية، ومقاييس الموصل نفسه. تستبعد مجموعة الكشط الافتراضية عمدًا system.query_log، لذلك لا يغادر نص SQL الخام، ولا أي قيم حرفية أو بيانات شخصية يتضمنها، عبر مسار الكشط ما لم تضفه صراحةً. أثناء الجلسة، تتضمن قائمة السماح الافتراضية للجداول system.processes، الذي يعرض نص الاستعلامات المباشرة؛ أزله من قائمة السماح إذا كان يجب أن يبقى ذلك مخفيًا. أثناء جلسة دعم نشطة، تعيد أداة استكشاف الأخطاء وإصلاحها أيضًا مخرجات الأوامر، محصورة في جداول ClickHouse المدرجة في قائمة السماح وعروض Kubernetes المتاحة للقراءة فقط، بما في ذلك سجلات البودات، وتخضع لتنقيح البيانات (أنماط مدمجة لعناوين IP وبيانات الاعتماد والرموز المميزة والمفاتيح، بالإضافة إلى أنماطك الخاصة) قبل إرسالها. تبقى بيانات جداولك ونسخك الاحتياطية وسجل الاستعلامات (system.query_log وsystem.text_log) في بيئتك دون استثناء. الاستثناءات الموثقة هي: تُنقل الصفوف من جداول سجل المقاييس المدرجة في قائمة السماح (system.metric_log وsystem.asynchronous_metric_log) مع كل عملية كشط، ويكون نص الاستعلام المباشر مرئيًا أثناء الجلسة عبر system.processes ما لم تزله من قائمة السماح، وتغادر سجلات البودات المقروءة أثناء جلسة دعم Kubernetes بعد تنقيحها. تتوفر القائمة الكاملة للاتصالات الصادرة في صفحة نموذج الامتيازات.

​
كيف أسحب صلاحية وصول ClickHouse؟

بالترتيب التصاعدي:
  1. إنهاء الوصول التفاعلي. عطّل الجلسة باستخدام: sudo clicklink clctl troubleshoot session disable على مضيف الـVM، أو باستخدام الأمر نفسه مع --gateway-url عبر إعادة توجيه المنفذ في Kubernetes (تجد الأوامر الدقيقة في صفحة جلسات الدعم). عند عدم وجود جلسة نشطة، ترفض أداة استكشاف الأخطاء وإصلاحها تنفيذ أي أمر، حتى لو كان الاتصال قائماً.
  2. منع الجلسات المستقبلية. أفرغ قائمة السماح الخاصة بالمشغّل (إذ تؤدي قائمة السماح الفارغة إلى إغلاق البوابة) أو عطّل البوابة؛ على الـVM، تظل إدارة الجلسات المحلية متاحة للمستخدم root على المضيف. راجع دليل التكوين.
  3. قطع اتصال ClickHouse Cloud. احظر حركة الخروج إلى نقطة نهاية الموصل على مستوى الشبكة، أو أفرغ networkPolicy.allowEgressCIDRs ضمن CNI مفروض؛ إذ يعمل الموصل للاتصالات الصادرة فقط، لذلك لا يملك ClickHouse Cloud مساراً وارداً لاستعادة الاتصال. تستمر عمليات القراءة المحلية من ClickHouse إلى أن توقف أعباء العمل أو تلغي تثبيتها، وهذا هو الإيقاف النهائي.
  4. إلغاء بيانات الاعتماد. احذف مستخدمي ClickHouse ‏pcm_scraper وpcm_troubleshooter، واحذف أسرار الموصل (Kubernetes) أو الملفات الموجودة ضمن /etc/clicklink ‏(VM).
  5. إزالة الموصل بالكامل. راجع العمليات.

​
هل يمكنني تشغيله في بيئة معزولة عن الشبكة أو عبر مراياي الخاصة؟

نعم. يمكن توفير جميع القطع البرمجية اللازمة وقت التثبيت من داخل نطاقك: انسخ أرشيف CLI وحاوية صورة من releases.clicklink.clickhouse.com والسجل العام إلى مرآتك، ووجّه image.repository إلى مرآتك، ومرّر --chart مع مرجع oci:// أو URL أو أرشيف محلي (مع --chart-version؛ إذ يُستخدم افتراضيًا إصدار CLI نفسه). إذا كانت نقطة نهاية واجهة برمجة تطبيقات الموصل متاحة داخل نطاقك خلف CA خاصة، فإن --api-private-ca ‏(Kubernetes) أو api.tls.ca_file ‏(VM) يتحقق من صحتها باستخدام سلسلة الثقة الخاصة بحزمة التسجيل. للتسجيل دون اتصال مباشر، يستخدم init --handoff حزمة تم الحصول عليها خارج النطاق، بينما يُكمل --no-auto-sign مع init --signed-cert توقيع الشهادة خارج النطاق. راجع المرايا الخاصة وقسم البيئة المعزولة عن الشبكة في Onboarding. لاحظ أن الموصل لا يزال يحتاج، وقت التشغيل، إلى مسار للوصول إلى نقطة نهاية واجهة برمجة تطبيقات الموصل الخاصة بمؤسستك؛ وبدون ذلك، لن يتلقى ClickHouse Cloud أي بيانات قياس عن بُعد.

​
ماذا يحدث إذا توقف الموصل عن العمل؟

لا تتأثر خدمات ClickHouse لديك، إذ إن الموصل يقرأ منها فقط ولا يقع ضمن أي مسار للبيانات. ويتمثل الأثر في فقدان الرؤية، لذا يتوقف ClickHouse Cloud عن تلقي بيانات القياس عن بُعد، وتصبح جلسات الدعم غير متاحة إلى أن يعود الموصل للعمل. على جهاز VM، يخزّن الكاشط البيانات المجمّعة مؤقتًا في /var/lib/clicklink/buffer (لمدة تصل إلى 168 ساعة أو 1024 MB افتراضيًا) كلما تعذر الوصول إلى نقطة نهاية واجهة برمجة التطبيقات، ثم يرسلها عند إعادة الاتصال؛ لذلك لا يؤدي انقطاع نقطة النهاية إلى فقدان بيانات القياس عن بُعد. ويُعاد تشغيل البرنامج الخفي المتعطل بواسطة systemd، وعلى Kubernetes بواسطة kubelet. للتشخيص، تحقّق من نقطة النهاية /livez لكل مكوّن (حقل status في JSON هو المؤشر، وليس رمز HTTP)، وشغّل clicklink clctl preflight (باستخدام sudo على مضيف VM)، إذ يفحص الإعداد والاتصال وإمكانية الوصول إلى ClickHouse والأذونات والقرص دفعة واحدة. راجع العمليات؛ وإذا ظل الموصل غير سليم، فتواصل مع ClickHouse Support.

​
كيف تُدقَّق جلسات الدعم؟

يُضاف كل طلب إلى البوابة وكل أمر لاستكشاف الأخطاء وإصلاحها، سواء قُبل أو حُظر، إلى سجل تدقيق في /var/log/clicklink/troubleshoot-audit.log بتنسيق JSON المحدد بأسطر جديدة، مع إسناد كل إدخال إلى مصدره: تحمل طلبات البوابة البريد الإلكتروني للمشغّل المثبت بالرمز المميز (وليس اسمًا يبلّغه المستخدم بنفسه مطلقًا)، وتسجل تغييرات الجلسات المحلية على VM مستخدم المضيف الذي استدعاها، بينما تسجل الأوامر المنفذة أثناء الجلسة هوية المؤسسة على القناة المُصادَق عليها. وتكون الجلسات نفسها محددة المدة (4 ساعات افتراضيًا، و24 ساعة كحد أقصى)، ويسجل كل تفعيل من فعّله ووقت انتهائه وسببًا اختياريًا، ويعرض ذلك الأمر clicklink clctl troubleshoot session status. اقرأ السجل باستخدام clicklink clctl troubleshoot audit tail؛ في Kubernetes، يُعد هذا الأمر القارئ المدعوم (إذ لا تحتوي صورة runtime على shell)، ومع الإعداد الافتراضي persistence.enabled: true، يُخزَّن السجل على وحدة التخزين الدائمة الخاصة بـ أداة استكشاف الأخطاء وإصلاحها، بحيث يبقى سجل التدقيق محفوظًا عند إعادة جدولة بود. يؤدي تعطيل الاستمرارية إلى ربط سجل التدقيق وحالة الجلسة بعمر بود، ويشير chart نفسه إلى أن هذا الخيار مناسب للتطوير المحلي فقط. تحتفظ عملية التدوير افتراضيًا بـ 5 ملفات، يصل حجم كل منها إلى 128 MB، لمدة 168 ساعة؛ راجع مرجع التكوين لضبط ذلك، وجلسات الدعم للاطلاع على نموذج الثقة الكامل.
آخر تعديل في ٢٦ أغسطس ٢٠٢٦