Skip to main content

​
الاتصالات بين طبقة التحكم في ClickHouse وVPC الخاصة بـ BYOC لديك

تحافظ طبقة التحكم في ClickHouse Cloud على عدة أنواع من الاتصالات لتشغيل نشر BYOC الخاص بك ودعمه:

​
واجهات برمجة تطبيقات موفّر السحابة مقابل Kubernetes API

من السهل الخلط بين مساري تحكم منفصلين. ويختلفان من حيث مصدر حركة المرور، وطريقة المصادقة، وإمكانية تطبيق Tailscale: باختصار: لا يمكن استخدام Tailscale إلا لحركة مرور Kubernetes API واستكشاف الأخطاء وإصلاحها. تنشأ استدعاءات الإدارة الموضّحة أعلاه دائمًا من شبكة ClickHouse Cloud وتنتهي عند نقاط نهاية الموفّر — ولا يمكن توجيهها عبر Tailscale، لأنها لا تدخل شبكتك أصلًا. كما تُستدعى واجهات برمجة تطبيقات موفّر السحابة من الاتجاه المعاكس، عبر وحدات تحكم تعمل داخل عنقودك — وحدة تحكم موازن التحميل، وبرنامج تشغيل CSI، وautoscaler، ووحدة تحكم DNS، وcert-manager. وتستخدم هذه الاستدعاءات هويات داخل العنقود وتخرج عبر مسار الخروج الخاص بك، لذا تظهر في سجل التدقيق لديك بهوية مختلفة وعنوان مصدر مختلف عن استدعاءات الإدارة. راجع الاتصالات الصادرة.

​
حدود الأذونات بناءً على منشأ الشبكة

إذا كانت مؤسستك تقيّد تولّي IAM role أو استدعاءات Cloud API بناءً على منشأ الشبكة (على سبيل المثال، AWS SCPs أو شروط وثوق الدور التي تستخدم aws:SourceIp أو aws:SourceVpc)، فستمنع هذه الشروط أتمتة ClickHouse، لأن الاستدعاءات تصدر بشكل مشروع من شبكة ClickHouse Cloud لا من شبكتك. استثنِ الأدوار التي أنشأها ClickHouse من هذه الشروط، أو تواصل مع ClickHouse للحصول على نطاقات عناوين IP الصادرة الحالية إذا كان عليك استخدام allowlist بناءً على المنشأ. يصف القسم التالي كيفية استخدام شبكة خاصة الخاصة بـ Tailscale لاستكشاف الأخطاء وإصلاحها وللوصول الاختياري لأغراض الإدارة.

​
شبكة Tailscale الخاصة

يوفّر Tailscale اتصالًا عبر شبكة خاصة قائمًا على مبدأ انعدام الثقة بين خدمات الإدارة في ClickHouse Cloud ونشر BYOC لديك. وتتيح هذه القناة الآمنة لمهندسي ClickHouse تنفيذ مهام استكشاف الأخطاء وإصلاحها وعمليات الإدارة من دون الحاجة إلى وصول وارد عبر الشبكة العامة أو إعدادات VPN معقّدة؛ إذ تُجري العوامل نفسها اتصالات صادرة فقط وتحتاج إلى وصول صادر إلى الإنترنت للوصول إلى خدمة تنسيق Tailscale.

​
نظرة عامة

ينشئ Tailscale نفق شبكة خاصًا ومشفّرًا بين طبقة التحكم في ClickHouse (ضمن VPC الخاصة بـ ClickHouse) وdata plane الخاص بـ BYOC لديك (ضمن VPC الخاصة بك). ويُستخدم هذا الاتصال حصريًا من أجل:
  • عمليات الإدارة: خدمات الإدارة في ClickHouse التي تنسّق مع البنية التحتية لـ BYOC لديك
  • وصول استكشاف الأخطاء وإصلاحها: وصول مهندسي ClickHouse إلى خوادم Kubernetes API وجداول النظام في ClickHouse لأغراض التشخيص
  • الوصول إلى المقاييس: تتيح لوحات المراقبة المركزية في ClickHouse الوصول إلى المقاييس من Prometheus Stack المنشور داخل VPC الخاصة بـ BYOC لديك، مما يوفّر لمهندسي ClickHouse إمكانية الرصد داخل البيئة.
يُستخدم Tailscale فقط لعمليات الإدارة واستكشاف الأخطاء وإصلاحها. ولا يُستخدم مطلقًا في حركة الاستعلامات أو للوصول إلى بيانات العملاء. تظل جميع بيانات العملاء داخل حساب الـ cloud الخاص بك، ولا تُنقل أبدًا عبر اتصالات Tailscale.

​
كيف يعمل Tailscale في BYOC

لكل خدمة أو نقطة نهاية يلزم الوصول إليها عبر Tailscale، ينشر ClickHouse BYOC ما يلي:
  1. تسجيل عنوان Tailnet: تسجّل كل نقطة نهاية عنوان tailnet فريدًا (مثل k8s.xxxx.us-east-1.aws.byoc.clickhouse-prd.com لخادم واجهة برمجة تطبيقات Kubernetes)
  2. حاوية وكيل Tailscale: تعمل حاوية وكيل Tailscale في عنقود Kubernetes لديك، وتكون مسؤولة عن:
    • الاتصال بخادم التنسيق في Tailscale
    • تسجيل الخدمات لتصبح قابلة للاكتشاف
    • تنسيق إعداد الشبكة مع كبسولات Nginx
  3. كبسولة Nginx: كبسولة Nginx تقوم بما يلي:
    • إنهاء حركة مرور TLS الواردة من Tailscale
    • توجيه حركة المرور إلى عناوين IP المناسبة داخل عنقود Kubernetes لديك

​
عملية الاتصال بالشبكة

تتم عملية إنشاء اتصال Tailscale عبر الخطوات التالية:
  1. الاتصال الأولي:
    • يتصل وكلاء Tailscale على كلا الطرفين (بيئة مهندس ClickHouse وعنقود BYOC Kubernetes لديك) بخادم التنسيق في Tailscale
    • يسجّل وكيل العنقود خدمة Kubernetes لتصبح قابلة للاكتشاف
    • يجب على مهندسي ClickHouse التصعيد داخليًا ليتمكنوا من رؤية الخدمة
  2. نمط الاتصال:
    • النمط المباشر: تحاول الوكلاء إنشاء اتصال مباشر عبر نفق لاجتياز NAT
    • نمط الترحيل: إذا فشل النمط المباشر، يعود الاتصال إلى نمط الترحيل عبر خادم Tailscale DERP ‏(بروتوكول الترحيل الموزّع المشفّر)
  3. التشفير:
    • جميع الاتصالات مشفّرة من طرف إلى طرف
    • يُنشئ كل وكيل Tailscale زوج مفاتيح عام/خاص خاصًا به (على غرار PKI)
    • تظل حركة البيانات مشفّرة بغض النظر عما إذا كانت تستخدم النمط المباشر أو نمط الترحيل

​
ميزات الأمان

اتصالات صادرة فقط:
  • تُنشئ وكلاء Tailscale في عنقود Kubernetes لديك اتصالات صادرة إلى خوادم التنسيق/الترحيل الخاصة بـ Tailscale
  • لا حاجة إلى أي اتصالات واردة — لا يلزم أن تسمح أي قواعد في Security Group بحركة مرور واردة إلى وكلاء Tailscale
  • يقلّل ذلك من سطح الهجوم ويبسّط تهيئة أمان الشبكة
التحكم في الوصول:
  • يجب على المهندسين طلب الوصول عبر سير عمل موافقة داخلي قبل أن يتمكن Tailscale من توجيههم إلى نقطة نهاية العميل
  • يكون الوصول محدد المدة وتنتهي صلاحيته تلقائيًا
  • تخضع جميع عمليات الوصول للتدقيق والتسجيل
للاطلاع على سياسة الوصول إلى البيانات كاملةً — وما الذي يمكن للمهندسين الاطلاع عليه، والمصادقة المستندة إلى الشهادات، والتدقيق من جهة العميل — راجع ClickHouse data access.

​
وصول خدمات الإدارة

بشكل افتراضي، تصل خدمات إدارة ClickHouse إلى عنقود Kubernetes الخاص بـ BYOC عبر نقطة النهاية العامة لخادم API، والتي تتحكم بها كل سحابة بطريقة مختلفة — في AWS عبر قائمة سماح IP لا تحتوي إلا على عناوين NAT gateway التابعة لـ ClickHouse، وفي GCP وAzure عبر IAM السحابي. راجع كشف خادم API الخاص بـ Kubernetes للاطلاع على التفاصيل الخاصة بكل سحابة. التكوين الاختياري لـ Private Endpoint:
  • يمكنك تهيئة خادم واجهة برمجة تطبيقات Kubernetes لاستخدام نقطة نهاية خاصة فقط
  • في هذه الحالة، تصل خدمات الإدارة إلى خادم واجهة برمجة التطبيقات عبر Tailscale (بشكل مشابه لوصول المهندسين عند استكشاف الأخطاء وإصلاحها) أو، في AWS، عبر VPC Lattice (راجع Kubernetes API Private Connection)
  • بشكل افتراضي، يُحتفَظ بنقطة النهاية العامة كآلية احتياطية لاحتياجات التحقيق الطارئة والدعم؛ وبمجرد التحقق من الوصول الخاص، يمكن تعطيلها بالكامل بالتنسيق مع ClickHouse

​
تدفّق حركة مرور الشبكة

تدفّق اتصال Tailscale:
  1. وكيل Tailscale في عنقود Kubernetes الخاصة بك → خادم التنسيق في Tailscale (صادر)
  2. وكيل Tailscale على جهاز المهندس → خادم التنسيق في Tailscale (صادر)
  3. يُنشأ اتصال مباشر أو مُرحَّل بين الوكيلين
  4. تتدفّق حركة المرور المشفّرة عبر النفق المُنشأ
  5. ينهي كبسولة Nginx في عنقود Kubernetes الخاصة بك اتصال TLS ويوجّه الحركة إلى الخدمات الداخلية
عدم نقل بيانات العملاء:
  • تُستخدم اتصالات Tailscale فقط للإدارة واستكشاف الأخطاء وإصلاحها
  • لا تمرّ حركة مرور الاستعلامات وبيانات العملاء مطلقًا عبر Tailscale
  • تظل جميع بيانات العملاء داخل حساب السحابة الخاص بك
لمزيد من التفاصيل التقنية حول كيفية تنفيذ Tailscale في BYOC، راجع مقالة المدوّنة Building ClickHouse BYOC on AWS. ولمعرفة ما يمكن لمهندسي ClickHouse الاطلاع عليه بعد الاتصال وكيف يدقّق ClickHouse هذا الوصول، راجع ClickHouse data access.

​
حدود الشبكة

يقدّم هذا القسم رؤية firewall لعملية نشر BYOC: أي كل connection يعبر حدود شبكة BYOC الخاصة بك في أي من الاتجاهين. وينطبق ذلك على AWS وGCP وAzure؛ وحيثما يختلف سلوك المنصات السحابية، تُذكر المنصة المعنية صراحةً. المصطلحات المستخدمة في هذا القسم:
  • Inbound: حركة المرور الداخلة إلى شبكة BYOC الخاصة بك — VPC على AWS، أو شبكة VPC على GCP، أو VNet على Azure.
  • Outbound: حركة المرور التي تنشأ داخل شبكة BYOC الخاصة بك وتُرسل إلى destination خارجي.
  • Public: endpoint يمكن الوصول إليه من public internet.
  • Private: endpoint لا يمكن الوصول إليه إلا عبر path خاص — اقتران VPC/VNet، أو AWS PrivateLink، أو GCP Private Service Connect، أو Azure Private Link، أو Tailscale.

​
المكافئات لدى كل مزوّد

تستخدم بقية هذه الصفحة أسماء محايدة لا ترتبط بسحابة بعينها. ويوضّح هذا الجدول ما يقابلها لدى كل مزوّد: تخرج حركة البيانات المتجهة إلى الإنترنت العام من شبكة BYOC لديك عبر مجموعة صغيرة وثابتة من عناوين NAT في كل سحابة، بما يتيح لك تحديدها ضمن ضوابط الخروج الخاصة بك. اطلب من فريق ClickHouse القيم الحالية الخاصة بعملية النشر لديك. أما على AWS وGCP، فتُستثنى حركة البيانات المتجهة إلى واجهات برمجة تطبيقات التخزين الخاصة بالمزوّد نفسه: إذ تسلك المسار الخاص المذكور في الصف أعلاه ولا تمر مطلقًا عبر NAT gateway.

​
الاتصالات الواردة

قد يظهر أحيانًا منفذان على موازنات التحميل هذه لكنهما ليسا موجّهين للعملاء: المنفذ TCP 15021 يخدم فحوصات السلامة الخاصة بالمزوّد على بوابة الدخول ولا يحمل أي حركة استعلامات، أما واجهة MySQL (المنفذ 3306) فليست مكشوفة حاليًا في BYOC — راجع الأسئلة الشائعة. يصدر شهادة بوابة الدخول برنامج cert-manager من جهة إصدار شهادات ACME عامة (Let’s Encrypt) باستخدام تحقق DNS-01، وتُخزَّن كسرّ Kubernetes داخل الـ cluster الخاص بك. وتبقى الحركة بين بوابة الدخول وحاويات ClickHouse داخل شبكة BYOC لديك — راجع الحركة داخل الشبكة. يعتمد تحديد أي من موازني التحميل يكون مفعّلًا افتراضيًا على نموذج الشبكات لديك. فمع VPC مُدار من ClickHouse، تحصل كل خدمة على موازن التحميل العام محميًا بقائمة وصول بعناوين IP، ويمكن تفعيل موازن التحميل الخاص إلى جانبه. أما مع VPC مُدار من العميل فتنعكس الإعدادات الافتراضية: يُفعَّل موازن التحميل الخاص وحده، ولا يكون لخدماتك أي سطح دخول عام ما لم تُضِف واحدًا. راجع الاتصال بخدمة BYOC لديك. وحيثما كان المسار العام مفعّلًا، نوصي بشدة بتهيئة filter لعناوين IP، ويمكنك إضافة مسار خاص — راجع إعداد الشبكات الخاصة — ثم تعطيل الوصول العام كليًا. لاحظ أن ترشيح عناوين IP يُطبَّق على مستوى وسيط الدخول، لذا قد تبدو منافذ موازن التحميل مفتوحة عند الفحص بينما تُرفض الاتصالات القادمة من مصادر غير مدرجة.
بخلاف المستمعين المذكورين أعلاه، لا يوجد SSH، ولا مضيف حصين، ولا بيانات اعتماد إدارية دائمة. ولا تمر حركة الاستعلامات مطلقًا عبر بنية تحتية مملوكة لـ ClickHouse في أي من الاتجاهين: إذ يتصل عملاؤك مباشرة ببوابة الدخول داخل شبكتك الخاصة.ويمكن تفعيل منافذ بروتوكولات إضافية لكل عملية نشر — والوصول الأصلي المصادق عليه بالشهادات وArrow Flight هما المثالان الحاليان — لذا تأكد مع فريق ClickHouse من مجموعة المنافذ الدقيقة الخاصة بعملية النشر لديك قبل كتابة قواعد جدار الحماية اعتمادًا على هذا الجدول.

​
كشف خادم واجهة برمجة تطبيقات Kubernetes

تختلف طريقة وصول خدمات الإدارة الخاصة بـ ClickHouse إلى خادم واجهة برمجة تطبيقات Kubernetes، وما الذي يقيّد هذا الوصول، باختلاف السحابة:
  • AWS (EKS): يقتصر نقطة النهاية العامة على نطاقات CIDR الخاصة بحركة egress لدى ClickHouse من خلال قائمة CIDR للوصول العام في العنقود. ويمكن تحويله إلى وصول خاص فقط عبر Tailscale أو VPC Lattice — راجع اتصال خاص بواجهة برمجة تطبيقات Kubernetes.
  • GCP (GKE): تكون الـ nodes خاصة دائمًا. ويتم الوصول إلى طبقة التحكم عبر نقطة النهاية المستندة إلى DNS (*.gke.goog)، مع الترخيص عبر permission الخاصة بـ IAM container.clusters.connect على الـ service account المنتحَل بدلًا من IP allow list. وينتهي الـ request عند واجهة Google الأمامية لا داخل شبكة VPC لديك، إلا أنه يبقى مسار وصول إلى طبقة التحكم الخاص بالعنقود لديك، لذا تعامل معه على أنه وصول وارد. ويمكن تعطيل نقطة النهاية العامة المنفصلة المستندة إلى IP، لتصبح نقطة النهاية المستندة إلى DNS المسار الوحيد إلى طبقة التحكم — راجع اتصال خاص بواجهة برمجة تطبيقات Kubernetes.
  • Azure (AKS): يتم الوصول إلى خادم واجهة برمجة تطبيقات Kubernetes عبر اسم النطاق العام المؤهل بالكامل الخاص به، مع الترخيص عبر Microsoft Entra ID إلى جانب Azure RBAC. ولا تُطبَّق نطاقات IP المصرّح بها لخادم API افتراضيًا؛ تواصل مع ClickHouse إذا كانت سياستك تستلزمها. ويمكن بدلًا من ذلك إنشاء العنقود بوصفه عنقودًا خاصًا يُوصَل إليه عبر Azure Private Link، مع تعطيل اسم النطاق العام المؤهل بالكامل الخاص به — راجع اتصال خاص بواجهة برمجة تطبيقات Kubernetes.
لا يمكن نقل سوى حركة واجهة برمجة تطبيقات Kubernetes وحركة استكشاف الأخطاء وإصلاحها إلى مسار خاص. أما استدعاءات الإدارة الموجهة إلى واجهات برمجة التطبيقات الخاصة بموفّر السحابة لديك فتنشأ من شبكة ClickHouse Cloud ولا يمكن توجيهها عبر هذا المسار — راجع واجهات برمجة تطبيقات موفّر السحابة مقابل واجهة برمجة تطبيقات Kubernetes، وهو يغطي أيضًا استدعاءات واجهة برمجة تطبيقات المزوّد التي تجريها وحدات التحكم داخل العنقود الخاص بك.

​
وصول استكشاف الأخطاء وإصلاحها

وارد، خاص يصل مهندسو ClickHouse Cloud إلى النشر الخاص بك لأغراض استكشاف الأخطاء وإصلاحها عبر Tailscale فقط، ولا يستخدمون الإنترنت العام مطلقًا، وذلك على جميع السحابات. والوصول يُمنح عند الحاجة ويستند إلى الشهادات: يطلبه المهندس عبر سير عمل موافقة داخلي، فتُصدر المنصة بيانات اعتماد قصيرة الأجل خاصة بكل مهندس، تنتهي صلاحيتها تلقائيًا. ولا توجد هوية إدارية مشتركة ولا وصول دائم. راجع الوصول إلى بيانات ClickHouse للاطلاع على السياسة الكاملة، بما في ذلك الجداول التي يمكن للمهندسين قراءتها.

​
الاتصالات الصادرة

​
Billing scraper

Outbound، Private يجمع مُجمِّع الفوترة (billing scraper) بيانات الاستخدام من ClickHouse ويرسلها إلى حاوية التخزين مملوك لـ ClickHouse Cloud — S3 على AWS، وCloud Storage على GCP، وBlob Storage على Azure. ويعمل كحاوية جانبية (sidecar) إلى جانب حاوية ClickHouse server، حيث يجمع (scrape) دوريًا مقاييس CPU والذاكرة من جداول النظام في ClickHouse. وتُفهرَس السجلات بمعرّف الخدمة مبهم واسم الـ pod. أما الطلبات ضمن الـ Region نفسه فتسلك المسار الخاص إلى واجهات storage API الخاصة بالـ provider والمدرجة في Provider equivalents، ومن ثمّ لا تمر هذه الحركة عبر الإنترنت العام (public internet) على AWS أو GCP.
لا ينقل هذا الـ stream سوى مقاييس النظام والبيانات الوصفية التشغيلية. فهو لا يحتوي على أي rows من الجداول، ولا على أي column values، ولا على نص query خام.

​
Alerts

Outbound، Public يُهيَّأ AlertManager لإرسال التنبيهات إلى ClickHouse Cloud عندما تكون حالة ClickHouse cluster الخاص بك غير سليمة. وقد جرى تقليص payloads التنبيهات في BYOC عن قصد لتقتصر على اسم التنبيه ومعرّف الخدمة. تبقى مجموعة بيانات المراقبة الكاملة داخل حسابك الخاص على كل سحابة. وميّز هنا بين أمرين، لأن لكل منهما حدودًا مختلفة:
  • مُصدَّرة بشكل مستمر. بيانات telemetry المقلَّصة الخاصة بالاستخدام والحالة الصحية، الموصوفة في مُجمِّع الفوترة، إضافة إلى payloads التنبيهات هذه، هي بيانات observability الوحيدة التي تُكتب في الأنظمة المملوكة لـ ClickHouse. أما remote-write من Prometheus إلى ClickHouse Cloud فهو معطّل في builds الخاصة بـ BYOC.
  • تُقرأ في مكانها. تستعلم لوحات معلومات Monitoring الخاصة بـ ClickHouse، وكذلك مهندسوها عند وجود escalation معتمد، عن Prometheus stack العاملة داخل الـ cluster وعن logs الخاصة بك عبر Tailscale — راجع Tailscale Private Network. ولا بد أن تصل نتائج الاستعلامات إلى الأدوات الموجودة في جانب ClickHouse حتى تُعرض، إلا أنه لا يُحفظ أي شيء هناك ولا تغادر البيانات الأساسية حسابك إطلاقًا.
تعتمد المقاييس على stack مكوّنة من Prometheus وThanos تعمل داخل الـ cluster الخاص بك، مع إمكانية الاحتفاظ بها لمدة طويلة اختياريًا في حاوية التخزين داخل حسابك الخاص؛ وعند تفعيل هذا الاحتفاظ، تغادر عمليات الكتابة شبكة BYOC الخاصة بك متجهة إلى storage API الخاص بالمزوّد، لكن البيانات تبقى داخل حسابك. أما logs فتُكتب حاليًا إلى وحدات التخزين المرفقة بعُقد ClickHouse لديك؛ وفي تحديث لاحق ستُكتب إلى LogHouse، وهو مخزن logs مبني على ClickHouse يعمل هو الآخر داخل شبكة BYOC الخاصة بك.

​
حالة الخدمة

Outbound، Public يرسل مُصدِّر الحالة (State Exporter) معلومات عن حالة خدمة ClickHouse وحالة النسخ الاحتياطي — أي أحداث الحالة التشغيلية، وليس محتويات النسخ الاحتياطي — إلى queue مملوكة لـ ClickHouse Cloud: SQS على AWS، وPub/Sub على GCP، وService Bus على Azure. وهذا ما يمكّن ClickHouse Cloud console من عرض حالة الخدمة التي تعمل في حسابك.

​
حركة المرور داخل الشبكة

حركة المرور بين المكوّنات داخل الـ cluster — من ClickHouse إلى ClickHouse Keeper، ومع الـ operator، ومن الـ Ingress إلى pods الخاصة بـ ClickHouse، وعمليات الـ scrape الخاصة بالمراقبة — لا تغادر شبكة BYOC الخاصة بك مطلقًا. ويقوم كل provider بتشفير حركة المرور بين instances الخاصة به على مستوى طبقة الشبكة: راجع AWS وGCP وAzure. حركة المرور الصادرة (egress) غير مقيّدة افتراضيًا على مستوى Security Group وقواعد الـ firewall وnetwork security group؛ أما الوجهات التي يجري الاتصال بها فعليًا فهي الواردة في الاتصالات الصادرة. ويمكن بدلًا من ذلك استخدام firewall اختياري للحركة الصادرة لكل service لفرض allowlist للوجهات — تواصل مع فريق ClickHouse إذا كنت بحاجة إليه.

​
تدقيق الحدود

نظرًا لأن مستوى البيانات بالكامل يعمل داخل حسابك، يمكنك مراقبة التدفقات الموضحة في هذه الصفحة بأدواتك الخاصة. بعض المصادر مفعّلة افتراضيًا، وبعضها الآخر تُفعّله بنفسك:
  • مسار تدقيق السحابة (CloudTrail أو Cloud Audit Logs أو سجل Activity في Azure): كل عملية role assumption، أو impersonation لحساب خدمة، أو تسجيل دخول service principal تقوم به أتمتة ClickHouse، وكل استدعاء لواجهة برمجة تطبيقات السحابة يجري باستخدامه.
  • سجلات التدفق (VPC Flow Logs أو سجلات تدفق VPC أو سجلات تدفق NSG): الاتصالات المذكورة أعلاه التي تعبر شبكتك — دخول العملاء، وكل تدفق صادر، وقناة Tailscale. فعّل هذه السجلات بنفسك إن أردت الاحتفاظ بها. ويُستثنى من ذلك الوصول الإداري إلى خادم واجهة برمجة تطبيقات Kubernetes: فما دام الـ endpoint العام قيد الاستخدام، ينتهي الاتصال عند endpoint طبقة التحكم المُدار لدى مزودك لا داخل شبكتك، ولذلك لا يظهر في سجلات التدفق لديك. ابحث عنه بدلًا من ذلك في سجلات تدقيق Kubernetes وفي مسار تدقيق السحابة؛ فهو لا يظهر في سجلات التدفق إلا بعد تحويل خادم واجهة برمجة تطبيقات Kubernetes إلى endpoint خاص.
  • سجلات تدقيق Kubernetes: على AWS، تُسلَّم سجلات طبقة التحكم في EKS بما فيها سجل التدقيق إلى مجموعة سجلات CloudWatch في حسابك؛ وعلى GCP وAzure، تواصل مع الدعم لتأكيد أو تفعيل تدقيق طبقة التحكم لعنقودك.
  • سجلات الوصول إلى التخزين الكائني على حاويات البيانات والنسخ الاحتياطية لديك، وعلى حاوية الاحتفاظ طويل الأمد بالمراقبة حيثما فعّلت ذلك.
  • جدول system.query_log الخاص بك: كل statement يُنفَّذ بواسطة أتمتة ClickHouse أو بواسطة أحد المهندسين، مع الهوية المرتبطة به.
آخر تعديل في ٢٨ سبتمبر ٢٠٢٦