Skip to main content

مقدمة

أُعدّ هذا الدليل لمن يرغب في بناء حل رصد قائم على SQL باستخدام ClickHouse، مع التركيز على السجلات والتتبعات. وهو يغطي جميع جوانب بناء هذا الحل، بما في ذلك اعتبارات إدخال البيانات، وتحسين المخططات بما يناسب أنماط الوصول لديك، واستخراج البنية من السجلات غير المهيكلة. لا يوفّر ClickHouse وحده حلاً جاهزًا للاستخدام مباشرةً في مجال رصد. لكنه يمكن أن يُستخدم كمحرك تخزين عالي الكفاءة لبيانات رصد، مع قدرة على تحقيق معدلات ضغط لا تُضاهى وأزمنة استجابة فائقة السرعة للاستعلامات. ولكي تتمكن من استخدام ClickHouse ضمن حل رصد، ستحتاج إلى كلٍّ من واجهة مستخدم وإطار عمل لجمع البيانات. ونحن نوصي حاليًا باستخدام Grafana لتصور إشارات رصد وOpenTelemetry لجمع البيانات (وكلاهما من التكاملات المدعومة رسميًا).
ليس OpenTelemetry فحسبمع أن توصيتنا هي استخدام مشروع OpenTelemetry ‏(OTel) لجمع البيانات، يمكن أيضًا بناء معماريات مماثلة باستخدام أطر عمل وأدوات أخرى مثل Vector وFluentd (راجع مثالًا باستخدام Fluent Bit). كما تتوفر أيضًا أدوات تصور بديلة، منها Superset وMetabase.

لماذا تستخدم ClickHouse؟

أهم ميزة في أي مخزن مركزي لـ رصد هي قدرته على تجميع كميات هائلة من بيانات السجلات وتحليلها والبحث فيها بسرعة عبر مصادر متنوعة. ويُبسّط هذا التمركز استكشاف المشكلات وإصلاحها، مما يسهّل تحديد الأسباب الجذرية لانقطاعات الخدمة. ومع تزايد حساسية المستخدمين تجاه الأسعار، واعتبارهم تكلفة هذه العروض الجاهزة مرتفعة وغير متوقعة مقارنةً بالقيمة التي تقدمها، أصبحت الحاجة إلى تخزين سجلات منخفض التكلفة ويمكن التنبؤ به، مع أداء استعلامات مقبول، أكثر أهمية من أي وقت مضى. وبفضل أدائه وكفاءته من حيث التكلفة، أصبح ClickHouse المعيار الفعلي لمحركات تخزين logging وتتبّع في منتجات رصد. وبشكل أكثر تحديدًا، فإن الأسباب التالية تجعل ClickHouse مناسبًا بصورة مثالية لتخزين بيانات رصد:
  • Compression - تحتوي بيانات رصد عادةً على حقول تكون قيمها مأخوذة من مجموعة محدودة، مثل رموز HTTP أو أسماء الخدمات. ويعني التخزين column-oriented في ClickHouse، حيث تُخزَّن القيم بترتيب منظّم، أن هذه البيانات تنضغط بكفاءة عالية جدًا، خاصةً عند دمج ذلك مع مجموعة من codecs المتخصصة لبيانات time-series. وعلى عكس مخازن البيانات الأخرى التي تتطلب عادةً مساحة تخزين تقارب الحجم الأصلي للبيانات، وغالبًا ما تكون بصيغة JSON، يضغط ClickHouse السجلات وآثار التتبع بمتوسط يصل إلى 14x. وإلى جانب تحقيق وفورات كبيرة في التخزين لعمليات نشر رصد واسعة النطاق، يساعد هذا الضغط أيضًا على تسريع الاستعلامات لأن كمية أقل من البيانات تحتاج إلى القراءة من disk.
  • Fast Aggregations - تعتمد حلول رصد بدرجة كبيرة على عرض البيانات بصريًا من خلال charts، مثل الخطوط التي تُظهر معدلات الأخطاء أو المخططات الشريطية التي تُظهر مصادر الزيارات. وتُعد aggregations، أو GROUP BYs، عنصرًا أساسيًا لتشغيل هذه charts، والتي يجب أن تكون أيضًا سريعة ومتجاوبة عند تطبيق filters ضمن workflows لتشخيص المشكلات. ويُعد التنسيق column-oriented في ClickHouse، إلى جانب محرك vectorized query execution، مثاليًا لإجراء aggregations سريعة، بينما يتيح sparse indexing تصفية البيانات بسرعة استجابةً لإجراءات المستخدم.
  • Fast Linear scans - بينما تعتمد التقنيات البديلة على الفهارس المعكوسة للاستعلام السريع عن السجلات، فإن ذلك يؤدي في العادة إلى ارتفاع استهلاك disk والموارد. ومع أن ClickHouse يوفر الفهارس المعكوسة كنوع فهرسة إضافي اختياري، فإن الفحوصات الخطية متوازية بدرجة كبيرة وتستخدم جميع الأنوية المتاحة على الجهاز (ما لم يُضبط خلاف ذلك). وهذا يتيح نظريًا فحص عشرات الجيجابايت في الثانية (مضغوطة) للعثور على التطابقات باستخدام عوامل مطابقة النصوص المحسّنة للغاية.
  • Familiarity of SQL - تُعد SQL لغة شائعة ومألوفة لجميع المهندسين. وبعد أكثر من 50 عامًا من التطوير، أثبتت نفسها بوصفها اللغة الفعلية لتحليلات البيانات، ولا تزال ثالث أكثر لغات البرمجة شعبية. ورصد ليست سوى مشكلة بيانات أخرى تُعد SQL مثالية لها.
  • Analytical functions - يوسّع ClickHouse معيار ANSI SQL بوظائف تحليلية صُممت لجعل استعلامات SQL أبسط وأسهل كتابةً. وهذه الوظائف ضرورية إذا كنت تجري تحليل الأسباب الجذرية حيث يلزم تفكيك البيانات وتحليلها من زوايا متعددة.
  • Secondary indices - يدعم ClickHouse الفهارس الثانوية، مثل bloom filters، لتسريع أنماط استعلامات محددة. ويمكن تمكينها اختياريًا على مستوى العمود، مما يمنح المستخدم تحكمًا دقيقًا ويتيح له تقييم المفاضلة بين التكلفة والأداء.
  • Open-source & Open standards - باعتباره database مفتوح المصدر، يتبنّى ClickHouse المعايير المفتوحة مثل OpenTelemetry. كما أن القدرة على المساهمة والمشاركة الفعالة في المشاريع تُعد ميزة جذابة، مع تجنّب تحديات الارتباط بمورّد واحد.

متى ينبغي استخدام ClickHouse للرصد

يتطلّب استخدام ClickHouse لبيانات الرصد من المستخدمين تبنّي الرصد القائم على SQL. نوصي بقراءة هذه التدوينة للتعرّف على تاريخ الرصد القائم على SQL، ولكن باختصار: يكون الرصد القائم على SQL مناسبًا لك إذا:
  • كنت أنت أو أعضاء فريقك على دراية بـ SQL (أو ترغبون في تعلّمه)
  • كنت تفضّل الالتزام بالمعايير المفتوحة مثل OpenTelemetry لتجنّب الارتهان وتحقيق القابلية للتوسّع.
  • كنت مستعدًا لتشغيل منظومة مدفوعة بابتكار البرمجيات مفتوحة المصدر، من الجمع إلى التخزين والتصور.
  • كنت تتوقع نموًا إلى أحجام متوسطة أو كبيرة من بيانات الرصد الخاضعة للإدارة (أو حتى أحجامًا كبيرة جدًا)
  • كنت تريد التحكّم في TCO (إجمالي تكلفة الملكية) وتجنّب تصاعد تكاليف الرصد.
  • كنت لا تستطيع، أو لا تريد، أن تبقى عالقًا بفترات احتفاظ قصيرة لبيانات الرصد لديك لمجرّد التحكّم في التكاليف.
قد لا يكون الرصد القائم على SQL مناسبًا لك إذا:
  • كان تعلّم SQL (أو حتى توليده!) غير جذاب لك أو لأعضاء فريقك.
  • كنت تبحث عن تجربة رصد متكاملة ومعلّبة من البداية إلى النهاية.
  • كانت أحجام بيانات الرصد لديك صغيرة جدًا بحيث لا تُحدث فرقًا يُذكر (مثلًا <150 GiB)، وليس من المتوقع أن تنمو.
  • كانت حالة الاستخدام لديك تعتمد بكثافة على المقاييس وتحتاج إلى PromQL. في هذه الحالة، لا يزال بإمكانك استخدام ClickHouse للسجلات والتتبّع إلى جانب Prometheus للمقاييس، مع توحيد ذلك في طبقة العرض باستخدام Grafana.
  • كنت تفضّل الانتظار حتى تنضج المنظومة أكثر ويصبح الرصد القائم على SQL أكثر جاهزية للاستخدام المباشر.

السجلات والتتبعات

تتألف حالة استخدام Observability من ثلاث ركائز أساسية متميزة: Logging وTracing وMetrics. ولكل منها أنواع بيانات وأنماط وصول مختلفة. نوصي حاليًا باستخدام ClickHouse لتخزين نوعين من بيانات Observability:
  • السجلات - السجلات هي تسجيلات زمنية للأحداث التي تقع داخل النظام، وتلتقط معلومات تفصيلية عن جوانب مختلفة من عمليات البرمجيات. وتكون البيانات في السجلات عادةً غير منظَّمة أو شبه منظَّمة، وقد تتضمن رسائل الخطأ، وسجلات نشاط المستخدم، وتغييرات النظام، وأحداثًا أخرى. وتُعد السجلات ضرورية لاستكشاف الأخطاء وإصلاحها، واكتشاف الشذوذ، وفهم الأحداث المحددة التي تسبق المشكلات داخل النظام.
  • التتبعات - ترصد التتبعات رحلة الطلبات أثناء مرورها عبر خدمات مختلفة في نظام موزّع، فتوضح مسار هذه الطلبات وأداءها. وتكون البيانات في التتبعات عالية التنظيم، إذ تتكوّن من spans وtraces ترسم كل خطوة يمر بها الطلب، بما في ذلك معلومات التوقيت. وتوفّر التتبعات رؤى قيّمة حول أداء النظام، مما يساعد على تحديد مواطن الاختناق ومشكلات زمن الاستجابة وتحسين كفاءة الخدمات المصغّرة.
المقاييسرغم إمكانية استخدام ClickHouse لتخزين بيانات المقاييس، فإن هذه الركيزة لا تزال أقل نضجًا في ClickHouse، إذ لم يكتمل بعد دعم ميزات مثل تنسيق بيانات Prometheus وPromQL.

التتبّع الموزّع

يُعدّ التتبّع الموزّع ميزةً بالغة الأهمية في رصد. والأثر الموزّع، أو ببساطة الأثر، يوضّح مسار الطلب عبر النظام. يبدأ الطلب من مستخدم نهائي أو تطبيق، ثم ينتشر عبر النظام، وعادةً ما ينتج عن ذلك تدفّق من الإجراءات بين الخدمات المصغّرة. ومن خلال تسجيل هذا التسلسل وإتاحة ربط الأحداث اللاحقة ببعضها، يمكن لمستخدم رصد أو لمهندس موثوقية الموقع (SRE) تشخيص المشكلات في مسار التطبيق مهما بلغت درجة تعقيد المعمارية أو حتى إن كانت serverless. يتكوّن كل أثر من عدة spans، ويُعرف الـ span الأول المرتبط بالطلب باسم root span. ويلتقط هذا الـ root span الطلب بالكامل من بدايته إلى نهايته. وتوفّر الـ spans اللاحقة المتفرعة من الجذر رؤى تفصيلية حول الخطوات أو العمليات المختلفة التي تحدث أثناء معالجة الطلب. ومن دون تتبّع، قد يكون تشخيص مشكلات الأداء في نظام موزّع بالغ الصعوبة. كما يسهّل تتبّع عملية استكشاف الأخطاء وإصلاحها وفهم الأنظمة الموزّعة، من خلال توضيح تسلسل الأحداث داخل الطلب أثناء انتقاله عبر النظام. يعرض معظم مزوّدي رصد هذه المعلومات على هيئة مخطط شلالي، مع إظهار التوقيت النسبي باستخدام أشرطة أفقية بأحجام متناسبة. على سبيل المثال، في Grafana: بالنسبة إلى المستخدمين الذين يحتاجون إلى فهم أعمق لمفاهيم السجلات والآثار، نوصي بشدة بالاطلاع على توثيق OpenTelemetry.
آخر تعديل في ٢٣ يوليو ٢٠٢٦