> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-mintlify-8c05c8a2.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# مجموعة البيانات التجريبية البعيدة
> بدء الاستخدام مع ClickStack ومجموعة بيانات تجريبية بعيدة
export const Image = ({img, alt, size}) => {
return
;
};
**يفترض هذا الدليل أنك نشرت ClickStack مفتوح المصدر باستخدام [إرشادات الصورة الشاملة](/ar/clickstack/getting-started/oss)، أو [الوضع المحلي فقط](/ar/clickstack/deployment/local-mode-only)، وأكملت إنشاء المستخدم الأولي. أو يمكنك بدلاً من ذلك تخطي الإعداد المحلي بالكامل والاتصال مباشرةً بالعرض التوضيحي المستضاف لـ ClickStack على [play-clickstack.clickhouse.com](https://play-clickstack.clickhouse.com)، والذي يستخدم مجموعة البيانات هذه.**
يستخدم هذا الدليل مجموعة بيانات تجريبية مستضافة على ClickHouse playground العام في [sql.clickhouse.com](https://sql.clickhouse.com)، ويمكنك الاتصال بها من عملية نشر ClickStack المحلية لديك.
**غير مدعوم في ClickStack المُدار**
قواعد البيانات البعيدة غير مدعومة عند استخدام ClickStack المُدار. لذلك، مجموعة البيانات هذه غير مدعومة.
وتتضمن هذه المجموعة نحو 40 ساعة من البيانات المأخوذة من نسخة ClickHouse من العرض التجريبي الرسمي لـ OpenTelemetry (OTel). ويُعاد تشغيل البيانات كل ليلة مع تعديل الطوابع الزمنية لتتوافق مع النافذة الزمنية الحالية، مما يتيح للمستخدمين استكشاف سلوك النظام باستخدام السجلات والتتبعات والمقاييس المدمجة في HyperDX.
**اختلافات البيانات**
نظرًا إلى أن مجموعة البيانات يُعاد تشغيلها يوميًا بدءًا من منتصف الليل، فقد تختلف العروض المرئية الدقيقة بحسب وقت استكشافك للعرض التجريبي.
## سيناريو العرض التوضيحي
في هذا العرض التوضيحي، نحقق في حادثة تتعلق بموقع تجارة إلكترونية يبيع التلسكوبات والملحقات المرتبطة بها.
أفاد فريق دعم العملاء بأن المستخدمين يواجهون مشكلات في إكمال عمليات الدفع عند صفحة إتمام الشراء. وقد صُعِّدت المشكلة إلى فريق هندسة موثوقية الموقع (SRE) للتحقيق فيها.
وباستخدام HyperDX، سيحلل فريق SRE السجلات والتتبعات والمقاييس لتشخيص المشكلة وحلّها، ثم سيراجع بيانات الجلسات للتأكد من أن استنتاجاته تتوافق مع سلوك المستخدمين الفعلي.
## العرض التجريبي
يستخدم هذا العرض التوضيحي [نسخة متفرعة يتولى ClickStack صيانتها](https://github.com/ClickHouse/opentelemetry-demo) من تطبيق العرض التجريبي الرسمي.
### بنية العرض التوضيحي
يتكوّن العرض التوضيحي من خدمات مصغّرة مكتوبة بلغات برمجة مختلفة، تتواصل فيما بينها عبر gRPC وHTTP، بالإضافة إلى مولّد حمل يستخدم Locust لمحاكاة حركة مرور المستخدمين. وقد عُدِّلت الشيفرة المصدرية الأصلية لهذا العرض التوضيحي لاستخدام [تهيئة ClickStack البرمجية](/ar/clickstack/ingesting-data/sdks/index).
*المصدر: [https://opentelemetry.io/docs/demo/architecture/](https://opentelemetry.io/docs/demo/architecture/)*
يمكن العثور على مزيد من التفاصيل حول العرض التوضيحي في:
* [وثائق OpenTelemetry](https://opentelemetry.io/docs/demo/)
* [نسخة fork التي تحتفظ بها ClickStack](https://github.com/ClickHouse/opentelemetry-demo)
## خطوات العرض التوضيحي
**قمنا بتزويد هذا العرض التوضيحي بأدوات الرصد باستخدام [ClickStack SDKs](/ar/clickstack/ingesting-data/sdks/index)، مع نشر الخدمات على Kubernetes، وجمع المقاييس والسجلات منها أيضًا.**
### الاتصال بالخادم التجريبي
**وضع 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`: اتركه فارغًا
### عدّل المصادر
**وضع Local-Only**
يمكن تخطي هذه الخطوة إذا نقرت على `Connect to Demo Server` عند النشر في الوضع المحلي. عند استخدام هذا الوضع، ستُضاف البادئة `Demo_` إلى أسماء المصادر، مثل `Demo_Logs`
مرّر للأعلى إلى `Sources` وعدّل كلًّا من `Logs` و`Traces` و`Metrics` و`Sessions` لاستخدام قاعدة البيانات `otel_v2`.
قد تحتاج إلى إعادة تحميل الصفحة للتأكد من ظهور القائمة الكاملة لقواعد البيانات ضمن كل مصدر.
### اضبط الإطار الزمني
اضبط الوقت لعرض جميع البيانات من `1 day` السابق باستخدام منتقي الوقت في أعلى اليمين.
قد تلاحظ فرقًا طفيفًا في عدد الأخطاء في المخطط الشريطي ضمن قسم النظرة العامة، مع زيادة طفيفة باللون الأحمر في عدة أشرطة متتالية.
سيختلف موضع الأشرطة بحسب وقت تنفيذ الاستعلام على مجموعة البيانات.
### التصفية لإظهار الأخطاء
لإبراز مواضع ظهور الأخطاء، استخدم عامل التصفية `SeverityText` وحدد `error` لعرض الإدخالات ذات مستوى الخطأ فقط.
يجب أن يصبح الخطأ أكثر وضوحًا:
### تحديد أنماط الأخطاء
باستخدام ميزة Clustering في HyperDX، يمكنك تحديد الأخطاء تلقائيًا وتجميعها في أنماط ذات دلالة. وهذا يسرّع عملية التحليل عند التعامل مع كميات كبيرة من السجلات والتتبعات. لاستخدام هذه الميزة، حدِّد `Event Patterns` من قائمة `Analysis Mode` في اللوحة اليسرى.
تكشف مجموعات الأخطاء عن مشكلات مرتبطة بعمليات الدفع الفاشلة، بما في ذلك نمطًا مُسمّى `Failed to place order`. وتشير مجموعات أخرى أيضًا إلى مشكلات في خصم المبالغ من البطاقات وامتلاء الذاكرات المؤقتة.
لاحظ أن مجموعات الأخطاء هذه يُرجَّح أنها ناتجة عن خدمات مختلفة.
### استكشف نمطًا من الأخطاء
انقر على أكثر تجمّعات الأخطاء وضوحًا، والتي ترتبط بالمشكلة المُبلَّغ عنها والمتعلقة بقدرة المستخدمين على إتمام المدفوعات: `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.`
### استكشف البنية التحتية
لقد حدّدنا خطأً مرتبطًا بالتخزين المؤقت يُرجَّح أنه يتسبّب في فشل عمليات الدفع. وما زلنا بحاجة إلى تحديد مصدر هذه المشكلة في بنية الخدمات المصغّرة لدينا.
ونظرًا إلى مشكلة التخزين المؤقت، فمن المنطقي التحقّق من البنية التحتية الأساسية — فربما توجد مشكلة في الذاكرة في الكبسولات المرتبطة؟ في ClickStack، تكون السجلات والمقاييس موحّدة وتُعرض ضمن السياق، مما يسهّل اكتشاف السبب الجذري بسرعة.
حدِّد علامة التبويب `Infrastructure` لعرض المقاييس المرتبطة بالكبسولات الأساسية لخدمة `frontend`، ثم وسِّع النطاق الزمني إلى `1d`:
لا يبدو أن المشكلة مرتبطة بالبنية التحتية — إذ لم تتغيّر أي مقاييس بشكل ملحوظ خلال الفترة الزمنية، سواء قبل الخطأ أو بعده. أغلِق علامة تبويب البنية التحتية.
### استكشاف تتبّع
في ClickStack، تُربط بيانات التتبّع أيضًا تلقائيًا بكلٍ من السجلات والمقاييس. لنستكشف التتبّع المرتبط بالسجل الذي اخترناه لتحديد الخدمة المسؤولة.
حدِّد `Trace` لعرض التتبّع المرتبط. وعند التمرير لأسفل في العرض التالي، يمكننا أن نرى كيف يستطيع HyperDX إظهار التتبّع الموزّع عبر الخدمات المصغّرة، مع ربط spans في كل خدمة. ومن الواضح أن عملية الدفع تتضمن عدة خدمات مصغّرة، بما فيها تلك التي تنفّذ إتمام الشراء وتحويل العملات.
ومن خلال التمرير إلى أسفل العرض، يمكننا أن نرى أن خدمة `payment` هي المتسببة في الخطأ، الذي ينتقل بدوره صعودًا عبر سلسلة الاستدعاءات.
### البحث في التتبعات
لقد تبيّن أن المستخدمين يفشلون في إتمام عمليات الشراء بسبب مشكلة في ذاكرة التخزين المؤقت ضمن خدمة الدفع. دعونا نستكشف التتبعات الخاصة بهذه الخدمة بمزيد من التفصيل لنرى ما إذا كان بإمكاننا معرفة المزيد عن السبب الجذري.
انتقل إلى عرض `Search` الرئيسي عبر تحديد `Search`. بدّل مصدر البيانات إلى `Traces` وحدد عرض `Results table`. **تأكد من أن النطاق الزمني لا يزال مضبوطًا على آخر يوم.**
يعرض هذا العرض جميع التتبعات خلال آخر يوم. نحن نعلم أن المشكلة تنشأ في خدمة الدفع لدينا، لذا طبّق عامل التصفية `payment` على `ServiceName`.
إذا طبّقنا تجميع الأحداث على التتبعات عبر تحديد `Event Patterns`، فسنتمكن فورًا من رؤية مشكلة ذاكرة التخزين المؤقت في خدمة `payment`.
### استكشاف البنية التحتية لأحد التتبّعات
انتقل إلى عرض النتائج بالنقر على `Results table`. صفِّ الأخطاء باستخدام عامل التصفية `StatusCode` والقيمة `Error`.
اختر الخطأ `Error: Visa cache full: cannot add new item.`، ثم انتقل إلى علامة التبويب `Infrastructure` ووسّع الإطار الزمني إلى `1d`.
من خلال ربط التتبّعات بالمقاييس، نرى أن الذاكرة وCPU قد ارتفعا في خدمة `payment`، قبل أن يهبطا إلى `0` (ويمكن إرجاع ذلك إلى إعادة تشغيل كبسولة)، ما يشير إلى أن مشكلة ذاكرة التخزين المؤقت تسببت في مشكلات على مستوى الموارد. ويمكننا توقّع أن ذلك قد أثّر في أوقات إتمام الدفع.
### Event deltas لتسريع تحديد السبب
تساعد Event Deltas في إبراز الحالات الشاذة من خلال إرجاع التغيّرات في الأداء أو معدلات الأخطاء إلى مجموعات فرعية محددة من البيانات، مما يسهّل الوصول سريعًا إلى السبب الجذري.
رغم أننا نعلم أن خدمة `payment` لديها مشكلة في `cache` تتسبب في زيادة استهلاك الموارد، فإننا لم نحدّد السبب الجذري بشكل كامل بعد.
عُد إلى عرض جدول النتائج وحدّد الفترة الزمنية التي تتضمن الأخطاء لتضييق نطاق البيانات. احرص على تحديد عدة ساعات تسبق الأخطاء، وإن أمكن عدة ساعات بعدها أيضًا (إذ قد تكون المشكلة لا تزال مستمرة):
أزل عامل تصفية الأخطاء، ثم اختر `Event Deltas` من قائمة `Analysis Mode` على اليسار.
تعرض اللوحة العلوية توزيع المدد الزمنية، مع ألوان تشير إلى كثافة الأحداث (عدد `spans`). وعادةً ما تكون المجموعة الفرعية من الأحداث الواقعة خارج نطاق التركز الرئيسي هي الأجدر بالتحقيق.
إذا حدّدنا الأحداث التي تزيد مدتها على `1ms`، وطبّقنا عامل التصفية `Filter by selection`، فسنتمكن من تحليل الفروق بين الأحداث "الطبيعية" والمجموعة عالية الكثافة من `spans` ذات المدة القريبة من 0ms:
ومع إجراء التحليل على هذه المجموعة الفرعية من البيانات، نرى أن `spans` التابعة لـ "background" خارج التحديد هي في الغالب معاملات Visa، والمرتبطة باستجابات 0ms بسبب أخطاء `cache`.
### استخدام المخططات البيانية لمزيد من السياق
في 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`.
### استكشاف المقاييس لمزيد من السياق
أخيرًا، لنرسم حجم الذاكرة المؤقتة كمقياس لنرى كيف تغيّر بمرور الوقت، ما يمنحنا سياقًا إضافيًا.
أكمل القيم التالية:
* `Data Source`: `Metrics`
* `Metric`: `Maximum`
* `SQL Column`: `visa_validation_cache.size (gauge)` (اكتب فقط `cache` للإكمال التلقائي)
* `Where`: `ServiceName: payment`
* `Group By`: ``
يمكننا أن نرى كيف ازداد حجم الذاكرة المؤقتة على مدى 4-5 ساعات (على الأرجح بعد عملية نشر برمجي) قبل أن يصل إلى حجم أقصى قدره `100,000`. ومن `Sample Matched Events` نرى أن أخطاءنا ترتبط بوصول الذاكرة المؤقتة إلى هذا الحد، وبعد ذلك سُجِّل حجمها على أنه `0`، كما عادت الاستجابات أيضًا خلال `0s`.
باختصار، من خلال استكشاف السجلات والتتبعات وأخيرًا المقاييس، توصلنا إلى ما يلي:
* تكمن المشكلة في خدمة الدفع
* أدى تغيّر في سلوك الخدمة، وعلى الأرجح بسبب عملية نشر، إلى زيادة بطيئة في حجم ذاكرة Visa المؤقتة على مدى 4-5 ساعات، حتى بلغ الحد الأقصى `100,000`.
* تسبب هذا في زيادة استهلاك الموارد مع ازدياد حجم الذاكرة المؤقتة، وعلى الأرجح بسبب تنفيذ غير جيد
* مع ازدياد حجم الذاكرة المؤقتة، تدهور أداء مدفوعات Visa
* عند بلوغ الحجم الأقصى، بدأت الذاكرة المؤقتة في رفض المدفوعات، وسجّلت حجمها على أنه `0`.
### استخدام الجلسات
تتيح لنا الجلسات إعادة تشغيل تجربة المستخدم، بما يوفّر عرضًا مرئيًا لكيفية وقوع الخطأ من منظور المستخدم. وعلى الرغم من أنها لا تُستخدم عادةً لتشخيص الأسباب الجذرية، فإنها مفيدة لتأكيد المشكلات التي يبلّغ عنها العملاء إلى فريق الدعم، كما يمكن أن تكون نقطة انطلاق لاستقصاء أعمق.
في HyperDX، تكون الجلسات مرتبطة بالتتبعات والسجلات، مما يوفّر رؤية كاملة للسبب الأساسي.
على سبيل المثال، إذا زوّدك فريق الدعم بعنوان البريد الإلكتروني لمستخدم واجه مشكلة في الدفع `Ronny.Windler@gmail.com`، فغالبًا ما يكون البدء بجلسة هذا المستخدم أكثر فاعلية من البحث مباشرةً في السجلات أو التتبعات.
انتقل إلى علامة التبويب `Client Sessions` من القائمة اليسرى، ثم تأكد من ضبط مصدر البيانات على `Sessions` والفترة الزمنية على `Last 1 day`:
ابحث عن `SpanAttributes.userEmail: Ronny.Windler` للعثور على جلسة عميلنا. سيؤدي تحديد الجلسة إلى عرض أحداث المتصفح ووحدات span المرتبطة بجلسة العميل على اليسار، مع إعادة عرض تجربة المستخدم في المتصفح على اليمين:
### إعادة عرض الجلسات
يمكن إعادة عرض الجلسات بالضغط على زر ▶️. ويتيح التبديل بين `Highlighted` و`All Events` مستويات مختلفة من تفصيل الـ `span`، حيث يبرز الخيار الأول الأحداث الرئيسية وحالات الخطأ.
إذا مررنا إلى أسفل الـ `spans`، يمكننا رؤية خطأ `500` مرتبطًا بـ `/api/checkout`. ويؤدي تحديد زر ▶️ لهذا الـ `span` تحديدًا إلى نقل إعادة العرض إلى هذه النقطة من الجلسة، مما يتيح لنا تأكيد تجربة العميل — إذ يبدو أن الدفع لا يعمل ببساطة من دون ظهور أي خطأ.
وباختيار الـ `span`، يمكننا تأكيد أن السبب كان خطأً داخليًا. وبالنقر على علامة التبويب `Trace` والتمرير عبر الـ `spans` المرتبطة، يمكننا التأكد من أن العميل كان بالفعل ضحية لمشكلة الـ `cache` لدينا.
يستعرض هذا العرض التوضيحي حادثة واقعية تتعلق بفشل عمليات الدفع في تطبيق للتجارة الإلكترونية، موضحًا كيف يساعد ClickStack على كشف الأسباب الجذرية من خلال السجلات والتتبعات والمقاييس وإعادة تشغيل الجلسات ضمن عرض موحّد - استكشف [أدلة البدء](/ar/clickstack/example-datasets/index) الأخرى لدينا للتعمق أكثر في ميزات محددة.