> ## 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.
# Demo days - 2026-08-07
> ClickStack demo days بتاريخ 2026-08-07
## صفحة تفاصيل التنبيه مع سجل التقييمات
*عرض توضيحي من [@wrn14897](https://github.com/wrn14897)*
تحتوي صفحة التنبيهات حاليًا على شريط للسجل وزر للأخطاء. تبدو مفيدة إلى أن تحاول استخدامها للإجابة عن أي سؤال.
يظهر الخطأ ضمن مستند التنبيه نفسه، لذا تعرض الصفحة أحدث حالة بدلًا من سجل فعلي. ولا يمكنك معرفة ما إذا كان التنبيه قد أُطلق، أو ما إذا كان قد فشل سابقًا، أو ما إذا كان يواكب جدول تقييمه. ظهر ذلك أثناء العمل على أداء التنبيهات، حين اتضح أن العرض الحالي مُربك فعلًا، وليس مجرد عرض مقتضب.
تسجل صفحة التفاصيل الجديدة كل تقييم كحدث. ويتيح لك نطاق زمني فحص أي فترة من السجل، مع عرض حالات الإطلاق والحل بشكل منفصل وواضح.
يظهر التجميع بصورة منفصلة في الجدول. إذا كان التنبيه يستخدم `GROUP BY`، يمكنك فتح تقييم ومعرفة المجموعات التي أُطلق التنبيه فيها وتلك التي لم يُطلق فيها بدقة. ويهم هذا التمييز عندما يتجاوز جزء فقط من النتيجة العتبة. تُخزَّن الأخطاء أيضًا ضمن إدخالات السجل الفردية، بحيث يمكنك معرفة ما الذي فشل ومتى، بما في ذلك خطأ استعلام ClickHouse الأصلي.
توضح أعمدة التوقيت ما إذا كان التنبيه يواكب جدوله. تسجل مدة الاستعلام الوقت المستغرق في تنفيذ استعلام ClickHouse. إذا كان التنبيه مجدولًا كل دقيقة لكن استعلامه يستغرق ثلاث دقائق، فالتأخيرات حتمية وليست غامضة. وتعرض مدة webhook الوقت المستغرق لإرسال النتيجة إلى وجهتها.
تجعل الحاويات المتخطاة التراكم الناتج ظاهرًا. وتعني القيمة سبعة أن سبع نوافذ تقييم مجدولة قد فاتت، ثم عولجت لاحقًا.
**طلبات السحب ذات الصلة:** [#2833](https://github.com/hyperdxio/hyperdx/pull/2833) نموذج القراءة لتقييمات التنبيهات وGET /alerts/:id/evaluations، [#2834](https://github.com/hyperdxio/hyperdx/pull/2834) حفظ أخطاء تقييمات التنبيهات والتحليلات في AlertHistory، [#2835](https://github.com/hyperdxio/hyperdx/pull/2835) صفحة تفاصيل التنبيه مع سجل التقييمات
## قياس تبنّي أدوات المقاييس في MCP باستخدام التقييمات
*عرض توضيحي من [@karl-power](https://github.com/karl-power)*
هذا هو السيناريو الثالث، وربما الأخير، للمقاييس ضمن إطار عمل التقييمات. وقد وُضع عمدًا بين السيناريوهين الآخرين.
يتحقق سيناريو `metric-saturation` الحالي مما إذا كان الوكيل يستطيع استخدام أدوات المقاييس عند إجباره على ذلك. أما سيناريو `deploy-regression` الجديد، فيتحقق مما إذا كان يختار استخدامها من تلقاء نفسه. يتوقف النشر التدريجي لـ `checkout-api` بعد ثلاث كبسولات من أصل ست. ويتسبب الإصدار الجديد في ظهور `TypeError` لرموز العروض الترويجية ذات القيمة الثابتة، ما يؤدي إلى إرجاع رمز 500 في نحو 7–8% من عمليات إتمام الشراء، ولكن على الكبسولات المحدّثة فقط ولتلك الرموز فقط.
لا شيء من ذلك موسوم للوكيل. تأتي أقوى دلالة من تصنيف عمليات إتمام الشراء الفاشلة حسب اسم الكبسولة، ثم مطابقة تلك الكبسولات مع سجلات أحداث النشر. تؤكد المقاييس المُعدّة مسبقًا وقت بدء حالات الفشل، لكنها لا تكشف انقسام الكبسولات أو العيب الكامن. يمكن للوكيل تجاهل المقاييس تمامًا مع الاستمرار في حل السيناريو. وهذا ما يجعل أي استخدام للمقاييس طبيعيًا لا مفروضًا.
هناك بضعة فخاخ كي لا يكون المسار واضحًا أكثر من اللازم. يحدث نشر غير ذي صلة قبل دقائق من بدء حالات الفشل، فيما ترتفع موجة غير ضارة من تحذيرات الإيقاف عند الحدود نفسها التي تظهر فيها الأخطاء الفعلية.
كشف بناء السيناريو أيضًا عن مواضع يمكن فيها لـ MCP أن يوضح للوكلاء بشكل أفضل أنواع المقاييس وأسماءها المتاحة. وتجعل التغييرات الناتجة كليهما أسهل اكتشافًا.
التحسن متواضع، والمقارنة صريحة بشأن ذلك. تحقق الوكلاء نتائج جيدة بالفعل من دون التغييرات. لكن معها، يصلون إلى المقاييس المفيدة أسرع بكثير في عدة عمليات تشغيل. وتضيق الفجوة مع Fable، فهو ببساطة النموذج الأقدر هنا.
تحركت إحدى النتائج في الاتجاه المعاكس. سجل Opus نتيجة أسوأ قليلًا مع تغييرات المقاييس في بضع عمليات تشغيل. ويحتاج ذلك إلى مزيد من البيانات قبل أن يفسره أحد على نحو متسرع.
للمرة الأولى، قاس إطار عمل التقييمات تحسنًا في كيفية إتاحة MCP للمقاييس. ولم نعد مضطرين إلى الاعتماد كليًا على ما إذا كان التغيير يبدو أفضل.
يأتي بعد ذلك عدد كافٍ من عمليات التشغيل لفهم نتيجة Opus، يتبعه ترتيب للشيفرة التي تقف وراءها.
**طلبات السحب ذات الصلة:** [#2730](https://github.com/hyperdxio/hyperdx/pull/2730) إضافة سيناريو deploy-regression (قياس تبنّي أدوات المقاييس الطبيعي)، [#2717](https://github.com/hyperdxio/hyperdx/pull/2717) تعزيز سيناريو metric-saturation، [#2694](https://github.com/hyperdxio/hyperdx/pull/2694) تقييم تبنّي أدوات المقاييس والإبلاغ عنه، [#2855](https://github.com/hyperdxio/hyperdx/pull/2855) إتاحة المقاييس الموجزة عبر MCP
## الجداول الموزعة، المُدرَّجات التكرارية وعمليات البحث الأسرع عن التتبعات
*عرض توضيحي من [@pulpdrew](https://github.com/pulpdrew)*
تتضمن هذه المرة مجموعة من الإصلاحات الصغيرة، جاء عدد منها استجابةً لملاحظات فريق ClickHouse. أبسطها كان غياب زر مسح في أحد أقسام المرشحات، بينما كان موجودًا في جميع الأقسام الأخرى. ولا يزال خيار «مسح الكل» العام ضمن قائمة الرغبات.
كانت حالة الجدول الموزع أكثر تعقيدًا. بعض الجداول المستهدفة الأساسية لا تعرّف كل الأعمدة التي يعرضها الجدول الموزع. يشغّل ClickStack استعلام `SELECT *` عند تحميل تفاصيل الصف كاملةً، وهو ما يفشل تمامًا في هذا الإعداد. كانت اللوحة الجانبية للصف تعرض خطأً بالفعل، لكن الصف الموسّع لم يكن يعرضه، ولم يوضح أي منهما سبب إصدار ClickStack لاستعلام `SELECT *` من الأساس. يعرض كلا العرضين الآن الخطأ ضمن سياق كافٍ لجعل الإرشادات مفيدة.
واجهت المقاييس مشكلتين منفصلتين. أولًا، لم يكن جدول المُدرَّج التكراري الأُسّي يُحفَظ مطلقًا في مصادر المقاييس. لم يكن ذلك مهمًا حتى أُضيف دعم المُدرَّجات التكرارية الأُسّية مؤخرًا. وكان المستخدم الذي يفتح مصدرًا موجودًا وغير مكتمل يرى الحقل مملوءًا عبر استنتاج المخطط، فيفترض بشكل معقول أنه لا يحتاج إلى تغيير شيء، ولا يحفظه أبدًا.
لم يعد استنتاج المخطط يُشغَّل لمجرد فتح مصدر موجود. بل يُشغَّل الآن عند إنشاء مصدر مقاييس أو تغيير قاعدة بياناته، مما يوضح أن الجدول المستنتج لا يزال بحاجة إلى الحفظ.
كانت القائمة المنسدلة للتجميع تعرض أيضًا المتوسط والحد الأدنى والحد الأقصى ودوالًا أخرى لمقاييس المُدرَّجات التكرارية، رغم أن المُدرَّجات التكرارية لا تدعم أيًا منها. وكان اختيار أحدها يؤدي إلى الفشل عند تشغيل الاستعلام أو حفظ البلاطة. هذه الخيارات مخفية الآن لمقاييس المُدرَّجات التكرارية والمُدرَّجات التكرارية الأُسّية. ويرفض مسار `query_tile` الخاص بـ MCP هذه الخيارات أيضًا للبلاطات المحفوظة، بما يتوافق مع واجهة المستخدم بدلًا من أن يجد طريقته الإبداعية الخاصة للفشل.
إصلاح حد السلسلة أكثر دقة. عندما ينتج `GROUP BY` عدة سلاسل، يمكنك تعيين حد للاحتفاظ بأعلى N سلاسل وفقًا للقيمة القصوى. في وضع النسبة، كان الترتيب يستخدم البسط فقط. وكان ذلك يفضّل البسوط الكبيرة بدلًا من النسب المرتفعة فعليًا، مما يسمح لسلسلة ذات بسط كبير ومقام كبير بالقدر نفسه بإزاحة سلسلة ذات نسبة أعلى فعلًا. يستخدم الترتيب الآن النسبة المعروضة في الرسم.
تغيّر أيضًا التعيين الافتراضي للمصدر في صفحة البحث. كان يختار سابقًا أول مصدر مُعدّ، حتى لو كان ذلك المصدر يحتوي على مقاييس أو جلسات. وقد يصل المستخدمون إلى خطأ مصدر غير متوافق بسبب خيار لم يتخذوه. يعيّن البحث الآن افتراضيًا أول مصدر مفعّل يمكنه استخدامه فعليًا.
كان اختيار تتبع من اللوحة الجانبية لسجل يخفي وراءه أيضًا عملية بحث مكلفة. كان HyperDX يبحث باستخدام الـ span ومعرّف التتبع فقط، متجاهلًا قسم الطابع الزمني والمفاتيح الأساسية. ويصبح ذلك بطيئًا في عمليات النشر ذات الحجم الكبير. أصبحت عملية البحث الآن مقيّدة بنطاق تاريخ مستنتج من المصدر، مع رجوع مقصود إلى استعلام غير مقيّد عندما لا تشمل النافذة النتيجة. ومن الأمثلة التي تبرز أهمية هذا الرجوع سجل مرتبط بـ span بدأ قبل عدة ساعات.
أُضيفت الروابط العميقة لأسماء المصادر في الأسبوع السابق، وتبعها سؤال عادل تمامًا عن كيفية اكتشاف المستخدمين لها. كانت معاملات URL التي تقبلها كل صفحة تُعامل بالفعل كعقد، لذا أصبحت موثقة الآن بهذه الصفة. مرشحات المصدر هي الاستثناء الوحيد لأنها لا تزال خاصة بـ ClickHouse فقط في الوقت الحالي. وأضافت مراجعة توثيق منفصلة حقول تهيئة المصدر، مثل روابط الـ span، لتغطي الإضافات الحديثة وبعض الأمور التي أُغفلت ببساطة.
**طلبات السحب ذات الصلة:** [#2771](https://github.com/hyperdxio/hyperdx/pull/2771) تحسين حالة خطأ `SELECT *` في الجدول الموزّع وتوسيعها لتشمل الصفوف الموسّعة، [#2817](https://github.com/hyperdxio/hyperdx/pull/2817) الكشف التلقائي عن جداول المقاييس فقط عند تغيير اختيار قاعدة البيانات، [#2794](https://github.com/hyperdxio/hyperdx/pull/2794) عدم استنتاج جداول المقاييس للمصادر التي تحتوي على جداول بالفعل (مفتوح)، [#2793](https://github.com/hyperdxio/hyperdx/pull/2793) إخفاء الدوال التجميعية غير المدعومة لمقاييس المُدرَّج التكراري، [#2796](https://github.com/hyperdxio/hyperdx/pull/2796) رفض بلاطات المُدرَّج التكراري المحفوظة ذات aggFns غير المدعومة في query\_tile (مفتوح)، [#2759](https://github.com/hyperdxio/hyperdx/pull/2759) استخدام قيمة النسبة لترتيب حدّ السلاسل في وضع النسبة، [#2769](https://github.com/hyperdxio/hyperdx/pull/2769) منع صفحة البحث من اختيار نوع مصدر غير متوافق افتراضيًا، [#2816](https://github.com/hyperdxio/hyperdx/pull/2816) تقييد البحث عن صف في اللوحة الجانبية بعد عرض التتبّع بنافذة زمنية، [#2836](https://github.com/hyperdxio/hyperdx/pull/2836) إضافة تهيئة لمتغير عامل التصفية
## النسب المئوية للخريطة الحرارية وتحسينات بحث Lucene من المساهمين
*عرض توضيحي من [@pulpdrew](https://github.com/pulpdrew)*
ورد هذا الأسبوع نحو عشرة طلبات سحب من مساهمين خارجيين، ويستحق اثنان منها تنويهًا خاصًا.
الأول، من [@niladrix719](https://github.com/niladrix719)، يضيف سياقًا للنسب المئوية إلى تلميح التمرير في الخريطة الحرارية. فبدلًا من تقدير موضع خلية واحدة بصريًا مقارنةً ببقية الخريطة الحرارية، يمكنك الآن تمرير المؤشر فوقها لمعرفة أن حاوية الـ26 مللي ثانية، على سبيل المثال، تقع عند المئين الخامس والثمانين ضمن المدد المعروضة.
أما الثاني فهو سلسلة من تحسينات بحث Lucene من [@shuvamk](https://github.com/shuvamk).
تعمل النطاقات غير المحدودة الآن بشكل صحيح. يتحول `Duration:[* TO 500]` إلى شرط `<= 500` بدلًا من مطالبة ClickHouse بتحويل السلسلة `*` إلى `UInt64`، وهي نتيجة متوقعة تمامًا. وأصبحت الأقواس المعقوفة مدعومة أيضًا لحدود النطاقات الحصرية.
تكتسب إصلاحات الإفلات أهمية أكبر لأن هذه الأخطاء كانت تُرجع نتائج غير صحيحة بدلًا من ظهور خطأ. تنتقل مصطلحات حقول Lucene مباشرةً إلى نمط `ILIKE`، حيث تشير الشرطة السفلية إلى أي محرف واحد، وتشير علامة النسبة المئوية إلى أي تسلسل من المحارف. لذلك، كان البحث عن `ServiceName:user_service` يطابق أيضًا قيمًا مثل `user-service` و`user.service`. وتُفلت هذه المحارف الوصفية الآن قبل وصول الاستعلام إلى ClickHouse.
يمنع إصلاح منفصل الإفلات المزدوج لفهرسات Map الفرعية في عمليات البحث الرقمية والمنطقية. إذ كان الشرط المُنشأ يعامل التعبير بأكمله كمعرّف واحد بدلًا من إجراء lookup في Map.
تم أيضًا تحديث الأمثلة داخل التطبيق في مبدّل لغة Lucene لتغطية صيغ النطاقات الجديدة.
**طلبات السحب ذات الصلة:** [#2789](https://github.com/hyperdxio/hyperdx/pull/2789) عرض سياق النسبة المئوية في تلميح التمرير للخريطة الحرارية، [#2779](https://github.com/hyperdxio/hyperdx/pull/2779) دعم حدود النطاقات المفتوحة والحصرية وغير الرقمية، [#2774](https://github.com/hyperdxio/hyperdx/pull/2774) إفلات المحارف الوصفية لـ LIKE في مصطلحات البحث، [#2841](https://github.com/hyperdxio/hyperdx/pull/2841) إفلات فهرسات Map الفرعية مرة واحدة في عمليات البحث الرقمية وBool، [#2837](https://github.com/hyperdxio/hyperdx/pull/2837) إضافة أمثلة لبنية Lucene الجديدة
## مقاييس RED في البحث عن التتبعات
*عرض توضيحي من [@alex-fedotyev](https://github.com/alex-fedotyev)*
**هذا عمل استكشافي، ولا يوجد التزام بإصداره.**
يستخدم البحث عن التتبعات حاليًا المُدرَّج التكراري العددي نفسه المستخدم في البحث عن السجلات، والمُلوَّن بحسب مستوى السجل. يوضح لك ذلك عدد التتبعات المعروضة، لكنه لا يكشف إلا القليل جدًا عن أدائها.
يستبدل عرض النتائج المقترح هذا المُدرَّج التكراري بمقاييس RED لمصادر التتبعات. يظهر معدل النقل على شكل أشرطة تعدّ الـ spans. ويمكن عرض الأخطاء إما كمعدل مئوي في خط أو كحجم خام في أشرطة. ويعرض مخطط المدة المتوسط وp95 وp99 مباشرةً من عمود المدة الخام في المصدر.
الخريطة الحرارية هي العرض الأكثر إثارة للاهتمام. ففي العرض التوضيحي، تكشف على الفور تقريبًا عن خدمة تتزايد مدتها باستمرار. كما تُظهر شكل توزيع زمن الاستجابة، وهو ما قد يخفيه اتجاه النسب المئوية وحده.
ما تزال التكلفة الجانب غير المحسوم. إذ ينفذ البحث عن التتبعات بالفعل عددًا كبيرًا من الاستعلامات لكل عملية بحث، وستتطلب إضافة المزيد من عمليات التجميع تحسينات في الأداء قبل المضي قدمًا في ذلك.
يسرّنا تلقي ملاحظاتكم حول هذا السلوك.
**طلبات السحب ذات الصلة:** [#2826](https://github.com/hyperdxio/hyperdx/pull/2826) لعرض مقاييس RED في عرض نتائج البحث عن التتبعات (مفتوح، استكشافي)
## أعمدة مخصصة للسجلات في المكوّن الإضافي ClickHouse Grafana
*عرض توضيحي من إعداد [@alex-fedotyev](https://github.com/alex-fedotyev)*
أبلغ عدد من العملاء عن المشكلة نفسها قبل بضعة أسابيع: إذ جعل عرض السجلات المضغوط في المكوّن الإضافي لـGrafana من الصعب رؤية الأعمدة والحقول الإضافية في سجلاتهم.
يضيف هذا التغيير إعداد Columns إلى قسم السجلات في تكوين مصدر البيانات. ويوجد هذا الإعداد على مستوى مصدر البيانات بدلاً من الاستعلامات الفردية، لذا يبقى الخيار محفوظًا لجميع مستخدمي ذلك المصدر بدلاً من إعادة تطبيقه في كل مرة.
يمكنك اختيار أي عمود من الجدول. ويضيف المكوّن الإضافي هذه الأعمدة إلى تسميات السجلات بأسمائها الفعلية، مما يتيح استخدامها في جميع أنحاء Grafana. تظهر في قائمة Fields على اليسار وفي تفاصيل صف السجل، حيث توجد مجموعة Fields جديدة إلى جانب Resource attributes وLog attributes، مع إجراءات التصفية للإدراج والاستبعاد نفسها. وفي عرض الجدول، تعمل كعوامل تصفية فعلية للأعمدة.
كل ذلك يعتمد على الاستعلام نفسه. ومن دون هذا التكوين، لا تظهر تلك الحقول في أي من هذه المواضع، وهو بالضبط مصدر الإحباط وراء هذا الطلب.
وردت التقارير من كلا جانبي مسألة المخطط. يستخدم بعض العملاء OpenTelemetry، لكنهم يضيفون أعمدتهم الخاصة. ويستخدم آخرون مخططات مخصصة بالكامل ويحتفظون بالحقول في أعمدة فعلية بدلاً من سمات المورد أو السجل، لأسباب خاصة بهم. ولم تتمكن أي من المجموعتين من رؤية تلك القيم في Grafana على الإطلاق.
كان التغيير لا يزال قيد المراجعة عند تقديم هذا العرض التوضيحي، مع أمل تضمينه في إصدار المكوّن الإضافي للأسبوع التالي. يتوفر مزيد من السياق في [منشور ClickHouse Grafana plugin 4.20](https://clickhouse.com/blog/clickhouse-grafana-plugin-4-20).
**طلبات السحب ذات الصلة:** [grafana/clickhouse-datasource#2108](https://github.com/grafana/clickhouse-datasource/pull/2108) استعراض السجلات وتصفيتها حسب أي عمود في جدول السجلات (كان مفتوحًا وقت العرض التوضيحي)
## وضع حدّ للسلاسل عالية الكاردينالية عند المصدر
*عرض توضيحي من إعداد [@brandon-pereira](https://github.com/brandon-pereira)*
قد تُنتج استجابة عالية الكاردينالية مئات الآلاف من الصفوف لمخطط واحد. وقبل رسم أي شيء، يتعين على العميل تحويل كل صف إلى JSON. في لوحة معلومات مثقلة، تكلّف هذه العملية أكثر من الاستعلام نفسه. كما قد يستنفد `GROUP BY` غير المقيّد ذاكرة الخادم قبل وصول النتيجة إلى المتصفح.
يمنع النهج الجديد معظم هذه الصفوف من مغادرة ClickHouse. تتضمن الاستعلامات الآن إعدادات للحد الأقصى للصفوف وللصفوف المجمّعة، وكلاهما محدد حاليًا بـ 5,000. وهذا الرقم، بصراحة، مجرد تقدير لسقف معقول. وعندما تشير الاستجابة إلى تجاوز حدّ ما، يعرض المخطط تحذيرًا بأن الاستعلام أعاد بيانات كثيرة جدًا.
يستند ذلك إلى تحسين سابق للواجهة الأمامية يحدّ العرض بـ 250 سلسلة. إذ كان الاحتفاظ بعشرات الآلاف من السلاسل في الذاكرة أثناء رسم نحو مئة خط يدفع استهلاك علامات تبويب المتصفح إلى عدة غيغابايت ويجعل التحويم والتحريك بطيئين.
يظل كلا الحدّين ساريين. يجلب `GROUP BY` غير الملائم الآن نحو 5,000 صف ويعرض 250 منها. وتبقى خيارات "تحميل الكل" الصريحة متاحة للحالات التي تحتاج فيها فعلًا إلى كل البيانات.
يظل الحل الأمثل للمخطط الذي يتجاوز أيًا من الحدّين مرارًا هو تحسين SQL: أضف حدًا أو اجعل `GROUP BY` أكثر انتقائية.
**طلبات السحب ذات الصلة:** [#2802](https://github.com/hyperdxio/hyperdx/pull/2802) وضع حدّ لسلاسل المخططات الزمنية عالية الكاردينالية مع خيارات لتجاوز الحد عبر تحميل الكل، [#2856](https://github.com/hyperdxio/hyperdx/pull/2856) وضع حدّ لتكلفة البلاطة الخاصة بـ SQL الخام عند المصدر عبر حدّ للصفوف/الكاردينالية من جهة الخادم (مفتوح)
## الأمثلة النموذجية، من مخطط المقاييس إلى التتبّع
*عرض توضيحي من إعداد [@jordan-simonovski](https://github.com/jordan-simonovski)*
تربط الأمثلة النموذجية مقياسًا مُجمّعًا بحدث فردي، يكون عادةً تتبّعًا. إذا أظهر مُدرَّج تكراري لزمن الاستجابة قفزة في المئين التاسع والتسعين إلى 2.4 ثانية، فقد يشير مثال نموذجي إلى طلب حقيقي استغرق 2.4 ثانية ويفتح تتبّعه.
عندما يسجّل تطبيق قياسًا داخل span نشط، يضمّنه OpenTelemetry في التجميع المعتاد. يحدّد عامل تصفية الأمثلة النموذجية ما إذا كان هذا القياس مؤهلًا، ثم يحتفظ خزان صغير بعدد محدود من الأمثلة لتصديرها إلى جانب نقطة المقياس المُجمّعة. يحمل كل مثال نموذجي قيمته الأصلية وطابعه الزمني، ومعرّفي التتبّع والـ span، وأي سمات أُسقطت من التدفق المُجمّع.
يوفّر الخزان الصغير سياقًا ملموسًا دون تصدير كل قياس خام أو إرفاق `trace_id` وقيم أخرى عالية الكاردينالية بكل سلسلة مقاييس. يظل المثال النموذجي مجرد مثال، وليس بالضرورة أسوأ طلب أو عينة ممثلة إحصائيًا. كما يعتمد نجاح حل رابطه على المُصدِّر والواجهات الخلفية المعنية وما إذا كان التتبّع المشار إليه قد تم الاحتفاظ به.
يستخدم العرض التوضيحي واجهة Prometheus خلفية عبر نقطة نهاية الوكيل `query_exemplars` التي دُمجت في اليوم السابق. إذا كانت النافذة المطلوبة طويلة جدًا، تُضيّقها نقطة النهاية بدلًا من رفض الاستعلام.
تأتي بيانات اختبار من OpenTelemetry Collector يرسل مقاييس الـ span. وأثناء معالجته للـ span، يحوّلها المجمّع إلى مقاييس تتضمن أمثلة نموذجية مرتبطة بمعرّف التتبّع. ثم تظهر هذه الأمثلة كعلامات على مخطط المقاييس. ويعرض التمرير فوقها قيمة المثال وطابعه الزمني إلى جانب بياناته الوصفية للتتبّع، مع زر يفتح التتبّع مباشرةً. يعمل ذلك جيدًا، وكانت سرعته معقولة حتى الآن.
الإعدادات خاصة بكل بلاطة. فعّل الأمثلة النموذجية على المخطط، ثم اختر مصدر التتبّع الذي ينبغي أن يحل الروابط. تدعم الميزة حاليًا مقاييس السلسلة الواحدة فقط، كما أنها لا تزال خلف علامة على مستوى النشر بالإضافة إلى زر التبديل الخاص بكل مخطط.
كشف الاختبار عن بعض الأخطاء الصغيرة، كان آخرون قد اكتشفوا بعضها بالفعل بصورة مستقلة، لكن مسار Prometheus جاهز عمليًا. يأتي ClickHouse بعد ذلك. سيستعلم هذا المسار عن الأمثلة النموذجية مباشرةً من جدول المقاييس، مما يتيح للفرق التي تبني المقاييس من بيانات التتبّع المسار نفسه للعودة إلى تتبّع فردي.
**طلبات السحب ذات الصلة:** [#2805](https://github.com/hyperdxio/hyperdx/pull/2805) اشتقاق مقاييس الطلبات مع أمثلة نموذجية للتتبّع من الـ span (مفتوح)، [#2806](https://github.com/hyperdxio/hyperdx/pull/2806) إضافة /v1/prometheus/query\_exemplars وتعزيز الوكيل، [#2807](https://github.com/hyperdxio/hyperdx/pull/2807) تقسيم أكبر ملفين للمخططات إلى أدلة، [#2808](https://github.com/hyperdxio/hyperdx/pull/2808) طبقة أمثلة نموذجية لمخططات المقاييس ومخططات الوقت في PromQL (مفتوح)، [#2809](https://github.com/hyperdxio/hyperdx/pull/2809) قبول إعدادات الأمثلة النموذجية في البلاطات التي أنشأتها واجهة API والوكيل (مفتوح)
## مساعدات استيراد Terraform والتصدير الدفعي
*عرض توضيحي من [@jordan-simonovski](https://github.com/jordan-simonovski)*
تتضمن لوحات المعلومات وعمليات البحث المحفوظة وتنبيهات عمليات البحث المحفوظة الآن زر «تصدير إلى Terraform». ويتيح هذا للفرق ضم الموارد الحالية إلى إدارة Terraform عبر موفر ClickHouse، دون كتابة كتل الاستيراد يدويًا أو تخمين أسماء أنواع الموارد وتنسيقات المعرّفات.
كان ما أثار التساؤلات في العرض التوضيحي هو الناتج نفسه. يُنشئ الزر كتلة `import` ويترك تعريف المورد الكامل لـ Terraform. فإضافة كتلة مورد وحدها لا تعني أن Terraform يتولى إدارة المورد الحالي؛ فقد يحاول بدلًا من ذلك إنشاء مورد آخر أو الكتابة فوق المورد الموجود. يعالج سير عمل الاستيراد الأحدث في Terraform هذا الفرق على النحو الصحيح.
الصق كتلة الاستيراد المُنشأة في إعداداتك، ثم شغّل `terraform plan` مع توجيه `-generate-config-out` إلى ملف مثل `generated.tf`. يفحص Terraform المورد الحالي ويكتب كتلة المورد المقابلة. بعد استيراده، يصبح المورد جزءًا من حالة Terraform، وتديره عمليات التطبيق اللاحقة بدلًا من محاولة إعادة إنشائه في ClickStack.
تتضمن إعدادات الفريق أيضًا تصديرًا دفعيًا ينزّل ملفًا واحدًا يشمل جميع الموارد المدعومة. في العرض التوضيحي، شمل ذلك 70 لوحة معلومات، ونحو 40 تنبيهًا و55 عملية بحث محفوظة. كما يدعم webhooks وsources.
تُستثنى الأسرار عمدًا من واجهة V2 API. إذ لا يعيد طلب `GET` سوى ما تعرضه واجهة المستخدم بالفعل، لذا يتضمن الاتصال مضيفه واسم المستخدم، لا كلمة المرور. وفّر السر المفقود عند استخدام الإعدادات المُنشأة.
**طلبات السحب ذات الصلة:** [#2741](https://github.com/hyperdxio/hyperdx/pull/2741) إضافة مساعدات استيراد Terraform لموارد ClickStack
*عرض توضيحي من [@elizabetdev](https://github.com/elizabetdev)*
تباعدت البطاقات في لوحات المعلومات المخصصة والبطاقات المستندة إلى الإعدادات المسبقة بصريًا، مما أثار سؤالًا بديهيًا: لماذا لم تكن تستخدم المكوّن نفسه منذ البداية؟ أصبحت تستخدمه الآن. يغلّف مكوّن ChartCard المشترك المخططات المستقلة بالعناصر الأساسية نفسها المستخدمة في بلاطات لوحة المعلومات، ما يحافظ على اتساق الحدود والحشو وفاصل الرأس الممتد بعرض كامل دون الحاجة إلى مطابقتها يدويًا. كان توحيد المسارين في مكوّن واحد أكثر تعقيدًا مما توقعنا، لكنهما يعرضان الآن الشيء نفسه داخليًا. لا يزال هناك بعض العمل اللاحق للبطاقات التي لا تحتوي على عناصر تحكم إلى اليمين، إذ يجب أن تحافظ على ارتفاع متسق.
أُجريت أيضًا مجموعة من التحسينات الأصغر، يستهدف عدد منها تحديدًا مظهر ClickStack في لقطات الشاشة وفيديوهات العرض التوضيحي. كان عنصر التحكم المقسّم يرسم خط القائمة كحدّ حول مربع بارتفاع صفري، ما أدى إلى تراكب الحافتين العلوية والسفلية ليبدو كأنه خط بعرض 2px. أصبح الآن حدًا حقيقيًا بعرض 1px. وأُعيدت صياغة ألوان الأزرار للسبب نفسه.
أُصلح شعار open source في الوضع الفاتح أيضًا. كنا نبدّل سابقًا بين النسقين باستخدام عامل تصفية CSS يعكس جميع الألوان، بما فيها الشعار، ولذلك كان الوضع الفاتح يعرض لون العلامة التجارية الخاطئ. واتضح أن الشعار نفسه يعمل في كلا النسقين، لذا لم تعد هناك حاجة إلى التفرع حسب النسق.
أصبح النقر على الصفوف في Search يعمل بصورة صحيحة مجددًا أيضًا. كان السلوك السابق مقصودًا، لكنه لم يكن يبدو كذلك. فقد كانت اللوحة الجانبية قد تُفتح فوق الصف الذي نقرت عليه، فتبدو وكأن الجزء المعروض من الشاشة لم يتغير. يؤدي النقر داخل منطقة اللوحة الجانبية الآن إلى تحديثها، بينما يؤدي النقر خارجها إلى إغلاقها.
أضفنا أيضًا مكونات Alert دلالية لحالات التحذير والنجاح إلى جانب حالات الخطر. وتوجّه مهارات الوكلاء الجديدة أي استخدام للنص التحذيري أو الأحمر الخام نحو Alert، بدلًا من السماح بتضمين لون من لوحة Mantine مباشرةً.
الجزء الأخير مخصص لاستكشاف التصميم فقط. هذه نماذج أولية، ونرحب بالملاحظات بشدة.
بدأ الأمر بمشكلة محددة في محرر البلاطة: كانت نافذة مشروطة تفتح لوحة جانبية، تفتح بدورها نافذة مشروطة أخرى، وكانت ضغطة واحدة على Escape تغلق المكدس بأكمله بدلًا من إعادتك مستوى واحدًا إلى الخلف. ومن هناك، اتسع نطاق العمل ليشمل نظرة أوسع على لوحات المعلومات.
يستبدل المقترح الفصل بين لوحات المعلومات المحفوظة والمؤقتة بالمسودات. يؤدي النقر على “لوحة معلومات جديدة” إلى إنشاء مسودة خاصة لا يراها سواك. وعندما تصبح جاهزة، يمكنك حفظها للفريق. يمكنك أيضًا نقل لوحة معلومات الفريق مجددًا إلى المسودات أو التخلص منها بالكامل. يغطي هذا ما تفعله لوحات المعلومات المؤقتة اليوم دون إجبارك على اتخاذ هذا القرار مسبقًا. مفهوم واحد بدلًا من اثنين.
ستحصل المفضلة على عرض قائمة إلى جانب البطاقات، إذ يمكن لصفحة من البطاقات الكبيرة أن تدفع ما تبحث عنه بعيدًا نحو أسفل الشاشة. ستُختصر Templates في صف واحد. وسيدعم التصفية حسب tag أكثر من tag واحدة، مع الفرز حسب الاسم أو آخر مشاهدة، بدلًا من اعتبار tag واحدة محددة وسيلة التنظيم الوحيدة المتاحة.
سيرسو محرر البلاطة لوحة إعداداته على اليمين بدلًا من فتح لوحة جانبية. وسيدمج أيضًا المسارين الحاليين للإعدادات في path واحد واضح ومتوقع.
**طلبات السحب ذات الصلة:** [#2829](https://github.com/hyperdxio/hyperdx/pull/2829) إضافة مكوّن ChartCard مشترك وترحيل استخدامات ChartBox، [#2814](https://github.com/hyperdxio/hyperdx/pull/2814) تحسين نسق Mantine (tabs، خلفية الشيفرة، عنصر التحكم المقسّم)، [#2704](https://github.com/hyperdxio/hyperdx/pull/2704) رموز ألوان دلالية مضبوطة وفق AA وبدائل Alert/Text، [#2714](https://github.com/hyperdxio/hyperdx/pull/2714) توثيق بدائل Alert/Text/danger الدلالية، [#2682](https://github.com/hyperdxio/hyperdx/pull/2682) إغلاق اللوحات الجانبية الخاصة بـ Search وsession عند النقر خارجها، [#2721](https://github.com/hyperdxio/hyperdx/pull/2721) نقل محرر البلاطة إلى لوحة جانبية مع لوحة إعدادات راسية (لا يزال مفتوحًا). لا يوجد طلب سحب لإعادة تصميم المسودات والمفضلة، فهي نماذج أولية في هذه المرحلة.