مجموعة البيانات التجريبية البعيدة

بدء الاستخدام مع ClickStack ومجموعة بيانات تجريبية بعيدة

يفترض هذا الدليل أنك نشرت ClickStack مفتوح المصدر باستخدام إرشادات الصورة الشاملة، أو الوضع المحلي فقط، وأكملت إنشاء المستخدم الأولي. أو يمكنك بدلاً من ذلك تخطي الإعداد المحلي بالكامل والاتصال مباشرةً بالعرض التوضيحي المستضاف لـ ClickStack على play-clickstack.clickhouse.com، والذي يستخدم مجموعة البيانات هذه.

يستخدم هذا الدليل مجموعة بيانات تجريبية مستضافة على ClickHouse playground العام في sql.clickhouse.com، ويمكنك الاتصال بها من عملية نشر ClickStack المحلية لديك.

غير مدعوم في ClickStack المُدار

قواعد البيانات البعيدة غير مدعومة عند استخدام ClickStack المُدار. لذلك، مجموعة البيانات هذه غير مدعومة.

وتتضمن هذه المجموعة نحو 40 ساعة من البيانات المأخوذة من نسخة ClickHouse من العرض التجريبي الرسمي لـ OpenTelemetry (OTel). ويُعاد تشغيل البيانات كل ليلة مع تعديل الطوابع الزمنية لتتوافق مع النافذة الزمنية الحالية، مما يتيح للمستخدمين استكشاف سلوك النظام باستخدام السجلات والتتبعات والمقاييس المدمجة في HyperDX.

اختلافات البيانات

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

​

سيناريو العرض التوضيحي

في هذا العرض التوضيحي، نحقق في حادثة تتعلق بموقع تجارة إلكترونية يبيع التلسكوبات والملحقات المرتبطة بها.

أفاد فريق دعم العملاء بأن المستخدمين يواجهون مشكلات في إكمال عمليات الدفع عند صفحة إتمام الشراء. وقد صُعِّدت المشكلة إلى فريق هندسة موثوقية الموقع (SRE) للتحقيق فيها.

وباستخدام HyperDX، سيحلل فريق SRE السجلات والتتبعات والمقاييس لتشخيص المشكلة وحلّها، ثم سيراجع بيانات الجلسات للتأكد من أن استنتاجاته تتوافق مع سلوك المستخدمين الفعلي.

​

العرض التجريبي

يستخدم هذا العرض التوضيحي نسخة متفرعة يتولى ClickStack صيانتها من تطبيق العرض التجريبي الرسمي.

​

بنية العرض التوضيحي

يتكوّن العرض التوضيحي من خدمات مصغّرة مكتوبة بلغات برمجة مختلفة، تتواصل فيما بينها عبر gRPC وHTTP، بالإضافة إلى مولّد حمل يستخدم Locust لمحاكاة حركة مرور المستخدمين. وقد عُدِّلت الشيفرة المصدرية الأصلية لهذا العرض التوضيحي لاستخدام تهيئة ClickStack البرمجية.

المصدر: https://opentelemetry.io/docs/demo/architecture/

يمكن العثور على مزيد من التفاصيل حول العرض التوضيحي في:

• وثائق OpenTelemetry
• نسخة fork التي تحتفظ بها ClickStack

​

خطوات العرض التوضيحي

قمنا بتزويد هذا العرض التوضيحي بأدوات الرصد باستخدام ClickStack SDKs، مع نشر الخدمات على Kubernetes، وجمع المقاييس والسجلات منها أيضًا.

1. ​

   الاتصال بالخادم التجريبي

   وضع Local-Only

   يمكنك تخطي هذه الخطوة إذا نقرت على Connect to Demo Server عند النشر في الوضع المحلي. وإذا كنت تستخدم هذا الوضع، فستُضاف البادئة Demo_ إلى المصادر، مثل Demo_Logs

   انتقل إلى Team Settings وانقر على Edit ضمن Local Connection:

   أعِد تسمية الاتصال إلى Demo ثم أكمل النموذج التالي باستخدام تفاصيل الاتصال التالية الخاصة بالخادم التجريبي:

   • Connection Name: Demo
   • Host: https://sql-clickhouse.clickhouse.com
   • Username: otel_demo
   • Password: اتركه فارغًا
2. ​

   عدّل المصادر

   وضع Local-Only

   يمكن تخطي هذه الخطوة إذا نقرت على Connect to Demo Server عند النشر في الوضع المحلي. عند استخدام هذا الوضع، ستُضاف البادئة Demo_ إلى أسماء المصادر، مثل Demo_Logs

   مرّر للأعلى إلى Sources وعدّل كلًّا من Logs وTraces وMetrics وSessions لاستخدام قاعدة البيانات otel_v2.

   قد تحتاج إلى إعادة تحميل الصفحة للتأكد من ظهور القائمة الكاملة لقواعد البيانات ضمن كل مصدر.

3. ​

   اضبط الإطار الزمني

   اضبط الوقت لعرض جميع البيانات من 1 day السابق باستخدام منتقي الوقت في أعلى اليمين.

   قد تلاحظ فرقًا طفيفًا في عدد الأخطاء في المخطط الشريطي ضمن قسم النظرة العامة، مع زيادة طفيفة باللون الأحمر في عدة أشرطة متتالية.

   سيختلف موضع الأشرطة بحسب وقت تنفيذ الاستعلام على مجموعة البيانات.

4. ​

   التصفية لإظهار الأخطاء

   لإبراز مواضع ظهور الأخطاء، استخدم عامل التصفية SeverityText وحدد error لعرض الإدخالات ذات مستوى الخطأ فقط.

   يجب أن يصبح الخطأ أكثر وضوحًا:

5. ​

   تحديد أنماط الأخطاء

   باستخدام ميزة Clustering في HyperDX، يمكنك تحديد الأخطاء تلقائيًا وتجميعها في أنماط ذات دلالة. وهذا يسرّع عملية التحليل عند التعامل مع كميات كبيرة من السجلات والتتبعات. لاستخدام هذه الميزة، حدِّد Event Patterns من قائمة Analysis Mode في اللوحة اليسرى.

   تكشف مجموعات الأخطاء عن مشكلات مرتبطة بعمليات الدفع الفاشلة، بما في ذلك نمطًا مُسمّى Failed to place order. وتشير مجموعات أخرى أيضًا إلى مشكلات في خصم المبالغ من البطاقات وامتلاء الذاكرات المؤقتة.

   لاحظ أن مجموعات الأخطاء هذه يُرجَّح أنها ناتجة عن خدمات مختلفة.

6. ​

   استكشف نمطًا من الأخطاء

   انقر على أكثر تجمّعات الأخطاء وضوحًا، والتي ترتبط بالمشكلة المُبلَّغ عنها والمتعلقة بقدرة المستخدمين على إتمام المدفوعات: Failed to place order.

   سيعرض ذلك قائمة بجميع حالات ظهور هذا الخطأ المرتبطة بخدمة frontend:

   حدِّد أيًّا من الأخطاء الناتجة. ستُعرض البيانات الوصفية للسجلات بالتفصيل. ويشير التمرير عبر كلٍّ من Overview وColumn Values إلى وجود مشكلة في بطاقات الدفع بسبب امتلاء ذاكرة التخزين المؤقت:

   failed to charge card: could not charge the card: rpc error: code = Unknown desc = Visa cache full: cannot add new item.

7. ​

   استكشف البنية التحتية

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

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

   حدِّد علامة التبويب Infrastructure لعرض المقاييس المرتبطة بالكبسولات الأساسية لخدمة frontend، ثم وسِّع النطاق الزمني إلى 1d:

   لا يبدو أن المشكلة مرتبطة بالبنية التحتية — إذ لم تتغيّر أي مقاييس بشكل ملحوظ خلال الفترة الزمنية، سواء قبل الخطأ أو بعده. أغلِق علامة تبويب البنية التحتية.

8. ​

   استكشاف تتبّع

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

   حدِّد Trace لعرض التتبّع المرتبط. وعند التمرير لأسفل في العرض التالي، يمكننا أن نرى كيف يستطيع HyperDX إظهار التتبّع الموزّع عبر الخدمات المصغّرة، مع ربط spans في كل خدمة. ومن الواضح أن عملية الدفع تتضمن عدة خدمات مصغّرة، بما فيها تلك التي تنفّذ إتمام الشراء وتحويل العملات.

   ومن خلال التمرير إلى أسفل العرض، يمكننا أن نرى أن خدمة payment هي المتسببة في الخطأ، الذي ينتقل بدوره صعودًا عبر سلسلة الاستدعاءات.

9. ​

   البحث في التتبعات

   لقد تبيّن أن المستخدمين يفشلون في إتمام عمليات الشراء بسبب مشكلة في ذاكرة التخزين المؤقت ضمن خدمة الدفع. دعونا نستكشف التتبعات الخاصة بهذه الخدمة بمزيد من التفصيل لنرى ما إذا كان بإمكاننا معرفة المزيد عن السبب الجذري.

   انتقل إلى عرض Search الرئيسي عبر تحديد Search. بدّل مصدر البيانات إلى Traces وحدد عرض Results table. تأكد من أن النطاق الزمني لا يزال مضبوطًا على آخر يوم.

   يعرض هذا العرض جميع التتبعات خلال آخر يوم. نحن نعلم أن المشكلة تنشأ في خدمة الدفع لدينا، لذا طبّق عامل التصفية payment على ServiceName.

   إذا طبّقنا تجميع الأحداث على التتبعات عبر تحديد Event Patterns، فسنتمكن فورًا من رؤية مشكلة ذاكرة التخزين المؤقت في خدمة payment.

10. ​

    استكشاف البنية التحتية لأحد التتبّعات

    انتقل إلى عرض النتائج بالنقر على Results table. صفِّ الأخطاء باستخدام عامل التصفية StatusCode والقيمة Error.

    اختر الخطأ Error: Visa cache full: cannot add new item.، ثم انتقل إلى علامة التبويب Infrastructure ووسّع الإطار الزمني إلى 1d.

    من خلال ربط التتبّعات بالمقاييس، نرى أن الذاكرة وCPU قد ارتفعا في خدمة payment، قبل أن يهبطا إلى 0 (ويمكن إرجاع ذلك إلى إعادة تشغيل كبسولة)، ما يشير إلى أن مشكلة ذاكرة التخزين المؤقت تسببت في مشكلات على مستوى الموارد. ويمكننا توقّع أن ذلك قد أثّر في أوقات إتمام الدفع.

11. ​

    Event deltas لتسريع تحديد السبب

    تساعد Event Deltas في إبراز الحالات الشاذة من خلال إرجاع التغيّرات في الأداء أو معدلات الأخطاء إلى مجموعات فرعية محددة من البيانات، مما يسهّل الوصول سريعًا إلى السبب الجذري.

    رغم أننا نعلم أن خدمة payment لديها مشكلة في cache تتسبب في زيادة استهلاك الموارد، فإننا لم نحدّد السبب الجذري بشكل كامل بعد.

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

    أزل عامل تصفية الأخطاء، ثم اختر Event Deltas من قائمة Analysis Mode على اليسار.

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

    إذا حدّدنا الأحداث التي تزيد مدتها على 1ms، وطبّقنا عامل التصفية Filter by selection، فسنتمكن من تحليل الفروق بين الأحداث “الطبيعية” والمجموعة عالية الكثافة من spans ذات المدة القريبة من 0ms:

    ومع إجراء التحليل على هذه المجموعة الفرعية من البيانات، نرى أن spans التابعة لـ “background” خارج التحديد هي في الغالب معاملات Visa، والمرتبطة باستجابات 0ms بسبب أخطاء cache.

12. ​

    استخدام المخططات البيانية لمزيد من السياق

    في ClickStack، يمكننا إنشاء مخطط بياني لأي قيمة رقمية من السجلات أو التتبعات أو المقاييس للحصول على سياق أوضح.

    لقد توصلنا إلى ما يلي:

    • تكمن المشكلة في خدمة الدفع
    • ذاكرة التخزين المؤقت ممتلئة
    • أدى ذلك إلى زيادة في استهلاك الموارد
    • منعت المشكلة اكتمال مدفوعات Visa، أو على الأقل تسببت في استغراقها وقتًا طويلًا جدًا حتى تكتمل.

    
    

    حدد Chart Explorer من القائمة اليسرى. أكمل القيم التالية لرسم الوقت المستغرق لإتمام المدفوعات:

    • Data Source: Traces
    • Metric: Maximum
    • SQL Column: Duration
    • Where: ServiceName: payment
    • Timespan: Last 1 day

    
    

    سيؤدي النقر على ▶️ إلى إظهار كيف تدهور أداء المدفوعات بمرور الوقت.

    إذا ضبطنا Group By على SpanAttributes['app.payment.card_type'] (فقط اكتب card للإكمال التلقائي)، فسنتمكن من رؤية كيف تدهور أداء الخدمة في معاملات Visa مقارنةً بـ Mastercard:

    لاحظ أنه بمجرد وقوع الخطأ، يعود زمن الاستجابة إلى 0s.

13. ​

    استكشاف المقاييس لمزيد من السياق

    أخيرًا، لنرسم حجم الذاكرة المؤقتة كمقياس لنرى كيف تغيّر بمرور الوقت، ما يمنحنا سياقًا إضافيًا.

    أكمل القيم التالية:

    • Data Source: Metrics
    • Metric: Maximum
    • SQL Column: visa_validation_cache.size (gauge) (اكتب فقط cache للإكمال التلقائي)
    • Where: ServiceName: payment
    • Group By: <empty>

    يمكننا أن نرى كيف ازداد حجم الذاكرة المؤقتة على مدى 4-5 ساعات (على الأرجح بعد عملية نشر برمجي) قبل أن يصل إلى حجم أقصى قدره 100,000. ومن Sample Matched Events نرى أن أخطاءنا ترتبط بوصول الذاكرة المؤقتة إلى هذا الحد، وبعد ذلك سُجِّل حجمها على أنه 0، كما عادت الاستجابات أيضًا خلال 0s.

    باختصار، من خلال استكشاف السجلات والتتبعات وأخيرًا المقاييس، توصلنا إلى ما يلي:

    • تكمن المشكلة في خدمة الدفع
    • أدى تغيّر في سلوك الخدمة، وعلى الأرجح بسبب عملية نشر، إلى زيادة بطيئة في حجم ذاكرة Visa المؤقتة على مدى 4-5 ساعات، حتى بلغ الحد الأقصى 100,000.
    • تسبب هذا في زيادة استهلاك الموارد مع ازدياد حجم الذاكرة المؤقتة، وعلى الأرجح بسبب تنفيذ غير جيد
    • مع ازدياد حجم الذاكرة المؤقتة، تدهور أداء مدفوعات Visa
    • عند بلوغ الحجم الأقصى، بدأت الذاكرة المؤقتة في رفض المدفوعات، وسجّلت حجمها على أنه 0.
14. ​

    استخدام الجلسات

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

    في HyperDX، تكون الجلسات مرتبطة بالتتبعات والسجلات، مما يوفّر رؤية كاملة للسبب الأساسي.

    على سبيل المثال، إذا زوّدك فريق الدعم بعنوان البريد الإلكتروني لمستخدم واجه مشكلة في الدفع [e-mail]، فغالبًا ما يكون البدء بجلسة هذا المستخدم أكثر فاعلية من البحث مباشرةً في السجلات أو التتبعات.

    انتقل إلى علامة التبويب Client Sessions من القائمة اليسرى، ثم تأكد من ضبط مصدر البيانات على Sessions والفترة الزمنية على Last 1 day:

    ابحث عن SpanAttributes.userEmail: Ronny.Windler للعثور على جلسة عميلنا. سيؤدي تحديد الجلسة إلى عرض أحداث المتصفح ووحدات span المرتبطة بجلسة العميل على اليسار، مع إعادة عرض تجربة المستخدم في المتصفح على اليمين:

15. ​

    إعادة عرض الجلسات

    يمكن إعادة عرض الجلسات بالضغط على زر ▶️. ويتيح التبديل بين Highlighted وAll Events مستويات مختلفة من تفصيل الـ span، حيث يبرز الخيار الأول الأحداث الرئيسية وحالات الخطأ.

    إذا مررنا إلى أسفل الـ spans، يمكننا رؤية خطأ 500 مرتبطًا بـ /api/checkout. ويؤدي تحديد زر ▶️ لهذا الـ span تحديدًا إلى نقل إعادة العرض إلى هذه النقطة من الجلسة، مما يتيح لنا تأكيد تجربة العميل — إذ يبدو أن الدفع لا يعمل ببساطة من دون ظهور أي خطأ.

    وباختيار الـ span، يمكننا تأكيد أن السبب كان خطأً داخليًا. وبالنقر على علامة التبويب Trace والتمرير عبر الـ spans المرتبطة، يمكننا التأكد من أن العميل كان بالفعل ضحية لمشكلة الـ cache لدينا.

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