> ## Documentation Index
> Fetch the complete documentation index at: https://clickhouse.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# مجموعة البيانات التجريبية البعيدة
> بدء الاستخدام مع ClickStack ومجموعة بيانات تجريبية بعيدة
export const Image = ({img, alt, size = "lg"}) => {
const normalizedSize = ["sm", "md", "lg"].includes(size) ? size : "lg";
return ;
};
**يفترض هذا الدليل أنك نشرت ClickStack مفتوح المصدر باستخدام [إرشادات الصورة الشاملة](/docs/ar/clickstack/getting-started/oss)، أو [الوضع المحلي فقط](/docs/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 البرمجية](/docs/ar/clickstack/ingesting-data/sdks/index).
*المصدر: [https://opentelemetry.io/docs/demo/architecture/](https://opentelemetry.io/docs/demo/architecture/)*
يمكن العثور على مزيد من التفاصيل حول العرض التوضيحي في:
* [وثائق OpenTelemetry](https://opentelemetry.io/docs/demo/)
* [التفرّع الذي تتولى ClickStack صيانته](https://github.com/ClickHouse/opentelemetry-demo)
## خطوات العرض التوضيحي
**قمنا بتزويد هذا العرض التوضيحي بأدوات الرصد باستخدام [ClickStack SDKs](/docs/ar/clickstack/ingesting-data/sdks/index)، مع نشر الخدمات على Kubernetes، وجمع المقاييس والسجلات منها أيضًا.**
**الوضع المحلي فقط**
يمكن تخطي هذه الخطوة إذا نقرت على `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`: اتركه فارغًا
**الوضع المحلي فقط**
يمكن تخطي هذه الخطوة إذا نقرت على `Connect to Demo Server` عند النشر في الوضع المحلي. وإذا كنت تستخدم هذا الوضع، فستُسبق أسماء المصادر بالبادئة `Demo_`، مثل `Demo_Logs`
مرّر للأعلى إلى `Sources`، ثم عدّل كل مصدر من المصادر — `Logs` و`Traces` و`Metrics` و`Sessions` — لاستخدام قاعدة البيانات `otel_v2`.
قد تحتاج إلى إعادة تحميل الصفحة للتأكد من ظهور القائمة الكاملة لقواعد البيانات ضمن كل مصدر.
اضبط النطاق الزمني لعرض جميع البيانات من `1 day` السابقة باستخدام منتقي الوقت في الزاوية العلوية اليمنى.
قد تلاحظ اختلافًا طفيفًا في عدد الأخطاء في المخطط الشريطي ضمن قسم النظرة العامة، مع زيادة طفيفة باللون الأحمر في عدة أشرطة متتالية.
سيختلف موضع الأشرطة حسب وقت الاستعلام عن مجموعة البيانات.
لإبراز حالات ظهور الأخطاء، استخدم عامل التصفية `SeverityText` وحدد `error` لعرض السجلات ذات مستوى الخطأ فقط.
ينبغي أن يصبح الخطأ أكثر وضوحًا:
باستخدام ميزة التجميع العنقودي في 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، ترتبط traces تلقائيًا أيضًا بكلٍ من logs وmetrics. لنستكشف الـ trace المرتبط بالسجل الذي اخترناه لتحديد الخدمة المسؤولة.
حدِّد `Trace` لعرض الـ trace المرتبط. وعند التمرير إلى أسفل هذا العرض، يمكننا رؤية كيف يستطيع HyperDX عرض الـ trace الموزّع عبر الخدمات المصغّرة، مع ربط 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` (ويمكن أن نعزو ذلك إلى إعادة تشغيل البود) — مما يشير إلى أن مشكلة `cache` تسببت في مشكلات على مستوى الموارد. ويمكننا توقّع أن هذا قد أثّر في أزمنة إتمام عمليات الدفع.
تساعد 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`.
أخيرًا، لنرسم حجم `cache` كمقياس لمعرفة كيف تغيّر بمرور الوقت، مما يمنحنا سياقًا إضافيًا.
أكمل القيم التالية:
* `Data Source`: `Metrics`
* `Metric`: `Maximum`
* `SQL Column`: `visa_validation_cache.size (gauge)` (اكتب فقط `cache` للإكمال التلقائي)
* `Where`: `ServiceName: payment`
* `Group By`: ``
يمكننا أن نرى كيف ازداد حجم `cache` على مدى 4-5 ساعات (على الأرجح بعد عملية نشر برمجي) قبل أن يصل إلى حدٍّ أقصى قدره `100,000`. ومن خلال `Sample Matched Events` نرى أن أخطاءنا ترتبط بوصول `cache` إلى هذا الحد، وبعد ذلك سُجِّل بحجم `0` مع عودة الاستجابات أيضًا خلال `0s`.
باختصار، من خلال استكشاف السجلات، والتتبعات، وأخيرًا المقاييس، توصلنا إلى ما يلي:
* تكمن المشكلة في خدمة الدفع
* أدّى تغيّر في سلوك الخدمة، على الأرجح بسبب عملية نشر، إلى زيادة بطيئة في `cache` الخاص بـ Visa على مدى 4-5 ساعات، حتى بلغ حدًا أقصى قدره `100,000`.
* تسبّب ذلك في زيادة استهلاك الموارد مع نمو حجم `cache`، وعلى الأرجح يعود هذا إلى تنفيذ غير محكم
* ومع نمو `cache`، تراجع أداء مدفوعات Visa
* وعند بلوغ الحد الأقصى للحجم، بدأ `cache` في رفض المدفوعات، وسجّل حجمه على أنه `0`.
تتيح لنا الجلسات إعادة تشغيل تجربة المستخدم، ما يوفّر عرضًا مرئيًا لكيفية وقوع الخطأ من منظور المستخدم. ورغم أنها لا تُستخدم عادةً لتشخيص الأسباب الجذرية، فإنها مفيدة لتأكيد المشكلات التي يبلّغ عنها العملاء إلى فريق الدعم، كما يمكن أن تشكّل نقطة انطلاق لاستقصاء أعمق.
في HyperDX، ترتبط الجلسات بالتتبعات والسجلات، مما يوفّر رؤية متكاملة للسبب الأساسي.
على سبيل المثال، إذا زوّدك فريق الدعم بعنوان البريد الإلكتروني لمستخدم واجه مشكلة في الدفع `Ronny.Windler@gmail.com`، فغالبًا ما يكون البدء بجلسة هذا المستخدم أكثر فاعلية من البحث مباشرةً في السجلات أو التتبعات.
انتقل إلى علامة التبويب `Client Sessions` من القائمة اليسرى، ثم تأكد من ضبط مصدر البيانات على `Sessions` والفترة الزمنية على `Last 1 day`:
ابحث عن `SpanAttributes.userEmail: Ronny.Windler` للعثور على جلسة عميلنا. سيؤدي تحديد الجلسة إلى عرض أحداث المتصفح ووحدات span المرتبطة بجلسة العميل على اليسار، مع إعادة عرض تجربة المستخدم داخل المتصفح على اليمين:
يمكن إعادة تشغيل الجلسات بالضغط على الزر ▶️. ويتيح التبديل بين `Highlighted` و`All Events` مستويات مختلفة من درجة تفصيل الـ spans، إذ يبرز الخيار الأول الأحداث الرئيسية والأخطاء.
إذا مررنا إلى أسفل الـ spans، يمكننا رؤية خطأ `500` مرتبطًا بـ `/api/checkout`. ويؤدي اختيار الزر ▶️ لهذا الـ span تحديدًا إلى نقل إعادة التشغيل إلى هذه النقطة من الجلسة، مما يتيح لنا التأكد من تجربة العميل — إذ يبدو أن الدفع ببساطة لا يعمل من دون ظهور أي خطأ.
من خلال تحديد الـ span، يمكننا التأكد من أن السبب كان خطأً داخليًا. وبالنقر على علامة التبويب `Trace` ثم التمرير عبر الـ spans المرتبطة، يمكننا التأكد من أن العميل كان بالفعل ضحية لمشكلة الـ cache لدينا.