- ClickStack المُدار
- ClickStack مفتوح المصدر
يفترض هذا الدليل أنك أكملت دليل البدء الخاص بـ Managed ClickStack وقمت بتدوين بيانات اعتماد الاتصال.
1
اختر الخدمة
اختر الخدمة التي تحمل علامة Managed ClickStack من صفحة ClickHouse Cloud الرئيسية.
3
تنزيل بيانات تجريبية
لتعبئة واجهة المستخدم ببيانات تجريبية، نزّل الملف التالي:بيانات تجريبيةيحتوي هذا الملف على أمثلة على السجلات والمقاييس والتتبعات من OpenTelemetry demo المتاح للعامة - وهو متجر تجارة إلكترونية بسيط قائم على الخدمات المصغّرة. انسخ هذا الملف إلى الدليل الذي تختاره.
4
تحميل بيانات تجريبية
لتحميل هذه البيانات، نرسلها ببساطة إلى نقطة نهاية HTTP الخاصة بـ OTel collector الذي تم نشره.شغّل الأمر التالي لإرسال البيانات إلى OTel collector:يحاكي هذا مصادر السجلات والتتبعات والمقاييس عبر OTLP وهي ترسل البيانات إلى OTel collector. في بيئة الإنتاج، قد تكون هذه المصادر مكتبات العملاء للغات البرمجة أو حتى OTel collectors أخرى.بالعودة إلى عرض
Search، ينبغي أن ترى أن تحميل البيانات قد بدأ (اضبط النطاق الزمني على Last 1 hour إذا لم تظهر البيانات):سيستغرق تحميل البيانات بضع دقائق. انتظر حتى يكتمل التحميل قبل الانتقال إلى الخطوات التالية.5
استكشاف الجلسات
لنفترض أننا تلقّينا بلاغات تفيد بأن مستخدمينا يواجهون مشكلات عند الدفع مقابل السلع. يمكننا الاطّلاع على تجربتهم باستخدام إمكانات إعادة تشغيل الجلسات في HyperDX.حدّد
Client Sessions من القائمة اليسرى.يتيح لنا هذا العرض رؤية جلسات الواجهة الأمامية لمتجرنا الإلكتروني. وتظل الجلسات مجهولة الهوية إلى أن يبدأ المستخدمون إتمام الشراء ويحاولوا إكمال الدفع.لاحظ أن بعض الجلسات المرتبطة بعناوين بريد إلكتروني تتضمّن خطأً، ما قد يؤكد البلاغات عن المعاملات الفاشلة.حدّد trace يتضمّن حالة فشل وبريدًا إلكترونيًا مرتبطًا. يتيح لنا العرض التالي إعادة تشغيل جلسة المستخدم ومراجعة مشكلته. اضغط على play لمشاهدة الجلسة.تُظهر الإعادة المستخدم وهو يتنقّل في الموقع ويضيف عناصر إلى سلّة التسوق. لا تتردد في الانتقال إلى جزء لاحق من الجلسة حيث يحاول إكمال عملية الدفع.لم يتمكن المستخدم من إتمام الطلب من دون ظهور خطأ واضح. مرّر إلى أسفل اللوحة اليسرى التي تحتوي على أحداث الشبكة ووحدة التحكّم من متصفح المستخدم. ستلاحظ ظهور خطأ 500 عند إجراء استدعاء /api/checkout.حدّد هذا الخطأ 500. لا يشير كلٌّ من Overview وColumn Values إلى مصدر المشكلة، سوى أن الخطأ غير متوقَّع، ما يؤدي إلى Internal Error.6
استكشاف التتبعات
انتقل إلى علامة التبويب
Trace لرؤية التتبّع الموزّع بالكامل.مرّر إلى أسفل التتبّع لرؤية مصدر الخطأ، وهو span خدمة checkout. حدِّد span خدمة Payment.حدِّد علامة التبويب Column Values ومرّر إلى الأسفل. يمكننا أن نرى أن المشكلة مرتبطة بامتلاء الذاكرة المؤقتة.عند التمرير للأعلى والعودة إلى التتبّع، يمكننا أن نرى أن السجلات مرتبطة بـ span، وذلك بفضل الإعداد الذي أجريناه سابقًا. وهذا يوفّر سياقًا إضافيًا.لقد تبيّن لنا أن الذاكرة المؤقتة تمتلئ في خدمة الدفع، مما يمنع اكتمال عمليات الدفع.7
استكشاف السجلات
للمزيد من التفاصيل، يمكننا الرجوع إلى
Search:حدِّد Logs من المصادر وطبِّق عامل تصفية على خدمة payment.يمكننا أن نرى أنه رغم أن المشكلة حديثة، فإن عدد المدفوعات المتأثرة مرتفع. علاوة على ذلك، يبدو أن ذاكرة تخزين مؤقت مرتبطة بمدفوعات Visa هي سبب هذه المشكلات.8
مقاييس المخطط
رغم أنه أُدخل خطأ بوضوح في الشيفرة، يمكننا استخدام المقاييس للتأكد من حجم ذاكرة التخزين المؤقت. انتقل إلى عرض
Chart Explorer.حدّد Metrics كمصدر للبيانات. أكمل أداة إنشاء المخططات لرسم Maximum لـ visa_validation_cache.size (Gauge)، ثم اضغط زر play. من الواضح أن ذاكرة التخزين المؤقت كانت تزداد قبل أن تصل إلى حجمها الأقصى، وبعد ذلك بدأت الأخطاء بالظهور.