Demo days - 2026-08-07

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