اختلافات البياناتنظرًا إلى أن مجموعة البيانات يُعاد تشغيلها يوميًا بدءًا من منتصف الليل، فقد تختلف العروض المرئية الدقيقة بحسب وقت استكشافك للعرض التجريبي.
سيناريو العرض التوضيحي
العرض التجريبي
معمارية العرض التوضيحي
خطوات العرض التوضيحي
1
الاتصال بالخادم التجريبي
الوضع المحلي فقطيمكن تخطي هذه الخطوة إذا نقرت على
Connect to Demo Server عند النشر في الوضع المحلي. عند استخدام هذا الوضع، ستبدأ أسماء المصادر بالبادئة Demo_، مثل Demo_LogsTeam Settings وانقر على Edit بجانب Local Connection:أعد تسمية الاتصال إلى Demo، ثم أكمل النموذج التالي باستخدام تفاصيل الاتصال التالية الخاصة بالخادم التجريبي:Connection Name:DemoHost:https://sql-clickhouse.clickhouse.comUsername:otel_demoPassword: اتركه فارغًا
2
عدّل المصادر
الوضع المحلي فقطيمكن تخطي هذه الخطوة إذا نقرت على
Connect to Demo Server عند النشر في الوضع المحلي. وإذا كنت تستخدم هذا الوضع، فستُسبق أسماء المصادر بالبادئة Demo_، مثل Demo_LogsSources، ثم عدّل كل مصدر من المصادر — Logs وTraces وMetrics وSessions — لاستخدام قاعدة البيانات otel_v2.قد تحتاج إلى إعادة تحميل الصفحة للتأكد من ظهور القائمة الكاملة لقواعد البيانات ضمن كل مصدر.
3
عدّل النطاق الزمني
اضبط النطاق الزمني لعرض جميع البيانات من
1 day السابقة باستخدام منتقي الوقت في الزاوية العلوية اليمنى.قد تلاحظ اختلافًا طفيفًا في عدد الأخطاء في المخطط الشريطي ضمن قسم النظرة العامة، مع زيادة طفيفة باللون الأحمر في عدة أشرطة متتالية.سيختلف موضع الأشرطة حسب وقت الاستعلام عن مجموعة البيانات.
4
صفِّ لعرض الأخطاء
لإبراز حالات ظهور الأخطاء، استخدم عامل التصفية
SeverityText وحدد error لعرض السجلات ذات مستوى الخطأ فقط.ينبغي أن يصبح الخطأ أكثر وضوحًا:5
حدّد أنماط الأخطاء
باستخدام ميزة التجميع العنقودي في 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، ترتبط traces تلقائيًا أيضًا بكلٍ من logs وmetrics. لنستكشف الـ trace المرتبط بالسجل الذي اخترناه لتحديد الخدمة المسؤولة.حدِّد
Trace لعرض الـ trace المرتبط. وعند التمرير إلى أسفل هذا العرض، يمكننا رؤية كيف يستطيع HyperDX عرض الـ trace الموزّع عبر الخدمات المصغّرة، مع ربط 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 (ويمكن أن نعزو ذلك إلى إعادة تشغيل البود) — مما يشير إلى أن مشكلة cache تسببت في مشكلات على مستوى الموارد. ويمكننا توقّع أن هذا قد أثّر في أزمنة إتمام عمليات الدفع.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:TracesMetric:MaximumSQL Column:DurationWhere:ServiceName: paymentTimespan:Last 1 day
سيُظهر النقر على
▶️ كيف تدهور أداء المدفوعات بمرور الوقت.إذا ضبطنا Group By على SpanAttributes['app.payment.card_type'] (اكتب فقط card للاستكمال التلقائي)، فسنتمكن من رؤية كيف تدهور أداء الخدمة في معاملات Visa مقارنةً بـ Mastercard:لاحظ أنه بمجرد حدوث الخطأ، تُعاد الاستجابات خلال 0s.13
سياق إضافي حول استكشاف المقاييس
أخيرًا، لنرسم حجم
cache كمقياس لمعرفة كيف تغيّر بمرور الوقت، مما يمنحنا سياقًا إضافيًا.أكمل القيم التالية:Data Source:MetricsMetric:MaximumSQL Column:visa_validation_cache.size (gauge)(اكتب فقطcacheللإكمال التلقائي)Where:ServiceName: paymentGroup By:<empty>
cache على مدى 4-5 ساعات (على الأرجح بعد عملية نشر برمجي) قبل أن يصل إلى حدٍّ أقصى قدره 100,000. ومن خلال Sample Matched Events نرى أن أخطاءنا ترتبط بوصول cache إلى هذا الحد، وبعد ذلك سُجِّل بحجم 0 مع عودة الاستجابات أيضًا خلال 0s.باختصار، من خلال استكشاف السجلات، والتتبعات، وأخيرًا المقاييس، توصلنا إلى ما يلي:- تكمن المشكلة في خدمة الدفع
- أدّى تغيّر في سلوك الخدمة، على الأرجح بسبب عملية نشر، إلى زيادة بطيئة في
cacheالخاص بـ Visa على مدى 4-5 ساعات، حتى بلغ حدًا أقصى قدره100,000. - تسبّب ذلك في زيادة استهلاك الموارد مع نمو حجم
cache، وعلى الأرجح يعود هذا إلى تنفيذ غير محكم - ومع نمو
cache، تراجع أداء مدفوعات Visa - وعند بلوغ الحد الأقصى للحجم، بدأ
cacheفي رفض المدفوعات، وسجّل حجمه على أنه0.
14
استخدام الجلسات
تتيح لنا الجلسات إعادة تشغيل تجربة المستخدم، ما يوفّر عرضًا مرئيًا لكيفية وقوع الخطأ من منظور المستخدم. ورغم أنها لا تُستخدم عادةً لتشخيص الأسباب الجذرية، فإنها مفيدة لتأكيد المشكلات التي يبلّغ عنها العملاء إلى فريق الدعم، كما يمكن أن تشكّل نقطة انطلاق لاستقصاء أعمق.في HyperDX، ترتبط الجلسات بالتتبعات والسجلات، مما يوفّر رؤية متكاملة للسبب الأساسي.على سبيل المثال، إذا زوّدك فريق الدعم بعنوان البريد الإلكتروني لمستخدم واجه مشكلة في الدفع
Ronny.Windler@gmail.com، فغالبًا ما يكون البدء بجلسة هذا المستخدم أكثر فاعلية من البحث مباشرةً في السجلات أو التتبعات.انتقل إلى علامة التبويب Client Sessions من القائمة اليسرى، ثم تأكد من ضبط مصدر البيانات على Sessions والفترة الزمنية على Last 1 day:ابحث عن SpanAttributes.userEmail: Ronny.Windler للعثور على جلسة عميلنا. سيؤدي تحديد الجلسة إلى عرض أحداث المتصفح ووحدات span المرتبطة بجلسة العميل على اليسار، مع إعادة عرض تجربة المستخدم داخل المتصفح على اليمين:15
إعادة عرض الجلسات
يمكن إعادة تشغيل الجلسات بالضغط على الزر ▶️. ويتيح التبديل بين
Highlighted وAll Events مستويات مختلفة من درجة تفصيل الـ spans، إذ يبرز الخيار الأول الأحداث الرئيسية والأخطاء.إذا مررنا إلى أسفل الـ spans، يمكننا رؤية خطأ 500 مرتبطًا بـ /api/checkout. ويؤدي اختيار الزر ▶️ لهذا الـ span تحديدًا إلى نقل إعادة التشغيل إلى هذه النقطة من الجلسة، مما يتيح لنا التأكد من تجربة العميل — إذ يبدو أن الدفع ببساطة لا يعمل من دون ظهور أي خطأ.من خلال تحديد الـ span، يمكننا التأكد من أن السبب كان خطأً داخليًا. وبالنقر على علامة التبويب Trace ثم التمرير عبر الـ spans المرتبطة، يمكننا التأكد من أن العميل كان بالفعل ضحية لمشكلة الـ cache لدينا.