أيام ClickStack التجريبية - 2026-08-15

عرض توضيحي من @pulpdrew تُعد متغيرات لوحة المعلومات التغيير الرئيسي هذا الأسبوع. وهي مبنية على نموذج عوامل التصفية الذي تستخدمه لوحات المعلومات بالفعل، إذ يمكن إتاحة أي عامل تصفية موجود أو جديد كمتغير. يستخدم المتغير اسم العرض لعامل التصفية افتراضيًا. وإذا احتوى هذا الاسم على أحرف خاصة، أو اشترك عاملا تصفية في اسم العرض نفسه، فيمكنك تعيين اسم مخصص للمتغير. ويبقى الاسم المخصص ثابتًا حتى إذا أُعيدت تسمية عامل التصفية لاحقًا. تعرض صفحة التهيئة الاسم الذي تحتاج إلى استخدامه كمرجع، وبمجرد تمكين المتغير يظهر أيضًا في تلميح عامل التصفية. تدعم مخططات Raw SQL عدة طرق لاستخدام المتغيرات. يوسّع $__filter($var) التحديد الحالي لمتغير واحد. وهو المكافئ أحادي المتغير لماكرو $__filters الحالي، الذي يوسّع جميع عوامل التصفية. أما الإضافة الأهم فهي $__conditionalAll(condition, $var). وسيطتها الأولى شرط، والثانية متغير. عندما يكون للمتغير تحديد، يُضمَّن الشرط في الاستعلام. وعند عدم وجود تحديد، يصبح التعبير بأكمله 1 = 1 ولا يؤثر في التصفية. ويتيح ذلك عمليات الربط بين المصادر. إذ يمكن للوحة المعلومات تعيين رموز حالة التتبعات إلى error أو info، ما يسمح لعامل تصفية الشدة المعرّف لجدول السجلات بتصفية جدول التتبعات. اختر error على مستوى لوحة المعلومات، فيُصفّي استعلام التتبعات بحسب حالة الخطأ. يقترح الإكمال التلقائي كل متغير متاح والتنسيقات التي يدعمها. وبناءً على اقتراح من Brandon، يعرض الآن التوسعة الفعلية ضمن السطر باستخدام التحديد الحالي. تتضمن اقتراحات الماكرو توسعاتها أيضًا، ويشرح قسم توثيق جديد وظيفة كل ماكرو. ويتحقق النظام من المراجع إلى متغيرات غير موجودة والماكروهات المستدعاة بوسيطات غير صحيحة. تستخدم مخططات المنشئ الاستبدال نفسه للمتغيرات في معظم الحقول القابلة للتحرير، سواء في مدخلات SQL أو Lucene. تعمل المتغيرات في WHERE وGROUP BY وHAVING وORDER BY، مع الإكمال التلقائي والتحقق نفسيهما. تدعم حقول Lucene المتغيرات، ولكن ليس الماكروهات. وتوفر حقول منشئ SQL الماكروهات المتعلقة بالمتغيرات بدلًا من المجموعة الكاملة المتاحة في Raw SQL. للتنبيهات قاعدة صارمة واحدة: يُقيَّم كل متغير باستخدام قيمته الفارغة. إذا أشار استعلام تنبيه إلى متغيرات، يحذرك المحرر قبل حفظه. تعرض المعاينة وSQL المُنشأ التوسعة الفارغة، بما في ذلك في صفحة تفاصيل التنبيه، وتطبّق مهمة التنبيه تلك القيم الفارغة عند تشغيلها. تظل تهيئة المتغيرات محجوبة خلف NEXT_PUBLIC_ENABLE_DASHBOARD_VARIABLES. عند عدم تهيئة أي متغيرات، لا يتغير سلوك لوحة المعلومات. طلبات السحب ذات الصلة: #2836 إضافة تهيئة متغير عامل التصفية، #2873 استبدال المتغيرات في مخططات Raw SQL، #2874 الإكمال التلقائي والتحقق لمتغيرات SQL في لوحة المعلومات، #2901 دعم متغيرات لوحة المعلومات في مربعات منشئ المخططات، #2910 توسيع المتغيرات كقيم فارغة في استعلامات التنبيهات، #2923 دعم استعلامات قيم المتغيرات التابعة، #2937 دعم الماكروهات المتداخلة ومراجع المتغيرات في الماكروهات، #2944 إضافة متغيرات لوحة المعلومات إلى واجهة API الخارجية عرض توضيحي من إعداد @wrn14897 حتى الآن، كان التنبيه يوفّر شريطًا للسجل وقليلًا من المعلومات الأخرى. ولم يكن هناك الكثير مما يمكن فحصه لفهم ما يفعله التنبيه فعليًا. تعرض صفحة التفاصيل الجديدة كل عملية تقييم. وبالنسبة إلى التنبيهات المجمّعة، توضّح المجموعة التي أطلقت التنبيه والقيمة التي تجاوزت العتبة. ويتضمن كل إدخال أيضًا مدة استعلام ClickHouse، مع عرض إعدادات التنبيه إلى جانبه. يستحق عمود الحاويات المُعبّأة بأثر رجعي بعض التوضيح. عند تفويت تقييم، تُعالج عملية التشغيل التالية الحاوية المفقودة لسد الفجوة. ولذلك، تشير أي حاويات مُعبّأة بأثر رجعي إلى أن التنبيه متأخر عن الجدول الزمني. ويترك استعلام ClickHouse البطيء الآن أثرًا مرئيًا بدلًا من تأخير التقييمات اللاحقة بصمت. تتوافق علامات المخطط مع بداية الحاوية التي جرى تقييمها، مما يسهّل معرفة وقت إطلاق التنبيه ووقت عودته إلى الحالة OK. يمكنك أيضًا تحرير تنبيه أو حذفه مباشرةً من صفحة التفاصيل. لا حاجة إلى العودة إلى النافذة المنبثقة للبحث المحفوظ أو محرر بلاطة لوحة المعلومات. ولا يزال استكشاف إمكانية نقل مزيد من إعدادات التنبيه إلى هذه الصفحة جاريًا. تظل الصفحة متاحة خلف NEXT_PUBLIC_ENABLE_ALERT_DETAILS. طلبات السحب ذات الصلة: #2833 نموذج قراءة لتقييمات التنبيهات وGET /alerts/:id/evaluations، #2834 حفظ أخطاء تقييمات التنبيهات والتحليلات في AlertHistory، #2835 صفحة تفاصيل التنبيه مع سجل التقييمات، #2928 محاذاة علامات مخطط التنبيه مع بداية الحاوية التي جرى تقييمها، #2931 السماح بتحرير التنبيهات وحذفها من صفحة تفاصيل التنبيه عرض توضيحي من @brandon-pereira تتضمن التنبيهات المُفعَّلة الآن زر «تحقيق». ويؤدي النقر عليه إلى بدء تحقيق في دفتر ملاحظات من صفحة التنبيهات أو صفحة تفاصيل التنبيه. الهدف النهائي هو بدء هذه التحقيقات تلقائيًا عند تفعيل تنبيه. فالزر خطوة وسيطة مفيدة، وليس الشكل النهائي المقصود. تتضمن كل أداة على خادم ClickStack MCP الآن أيضًا تلميحات للتعليقات التوضيحية. سابقًا، لم يكن الخادم يوضح ما إذا كانت أداة للقراءة فقط، أو ما إذا كانت أداة أخرى تعدّل البيانات أو تحذفها. تمنح إضافة readOnlyHint وdestructiveHint العملاء معلومات كافية للتعامل مع تلك الأدوات بصورة مختلفة. يمكن لعمليات القراءة أن تتم دون مقاطعة، بينما يمكن أن تنتظر الإجراءات المدمرة موافقة صريحة. وحذف تنبيه مثال واضح؛ إذ ينبغي طلب تأكيدك قبل حدوث ذلك. يؤثر التغيير الأخير في الأدوات التي يختارها الوكلاء من البداية. فقد ازداد استخدام clickstack_sql مع توسّع مجموعة الأدوات في غياب سياسة اختيار واضحة. وكان الوكلاء يلجؤون إلى SQL الخام حتى عندما تكون أدوات الإنشاء أنسب. ولا تقتصر أهمية ذلك على صحة الاستعلامات. إذ ينشئ SQL الخام بلاطات نتائج ثابتة، بينما تنتج أدوات الإنشاء، clickstack_table وclickstack_timeseries وclickstack_search، بلاطات يمكنك النقر عليها والانتقال منها إلى تحليل محوري. يوجّه MCP الآن الوكلاء إلى أدوات الإنشاء هذه أولًا، ويخصص SQL الخام للاستعلامات التي لا يمكنهم التعبير عنها باستخدامها. تحسنت درجات التقييم بشكل ملحوظ بعد هذا التغيير. طلبات السحب ذات الصلة: #2838 إضافة تعليقات توضيحية لأدوات MCP (readOnlyHint وغيرها) إلى جميع الأدوات، و#2840 توجيه الوكلاء نحو أدوات إنشاء الاستعلامات بدلًا من SQL الخام، و#2870 توجيه وكلاء لوحة المعلومات إلى عوامل تصفية البلاطات لكل سلسلة. لا يتوفر لزر «تحقيق» نفسه طلب سحب عام يمكن الارتباط به. عرض توضيحي من @wrn14897 كان وضع عدة مقاييس في مخطط واحد يتطلب سابقًا تشغيل استعلام ClickHouse واحد لكل سلسلة، ثم دمج مجموعات النتائج في Node أو المتصفح. وكان المخطط الذي يضم N من السلاسل ينتج N من الاستعلامات. تُصرَّف المخططات متعددة السلاسل الآن إلى استعلام SQL واحد. تصبح كل سلسلة عبارة عن CTE، ويقوم ClickHouse بدمجها في النهاية. وتتبع النسب النهج نفسه: إذ تُنتَج كلتا السلسلتين في استعلام واحد، وتُحسب النسبة في الإسقاط النهائي. تقليل عدد الاستعلامات هو الفائدة المباشرة. كما يضع شكل الاستعلام نفسه الأساس لصيغ المقاييس. تحتاج الصيغة إلى إتاحة كل سلسلة كأعمدة في علاقة واحدة حتى يمكن التعبير عنها في SELECT النهائي. وهذا بالضبط ما ينتجه المصرّف الآن، وقد بدأ العمل على الصيغ بالفعل. كشف التغيير عن مشكلة انحدار واحدة. تعذر عرض بطاقات المقاييس متعددة السلاسل عندما كانت تجمع بين عمليات تجميع تنتج أعدادًا عشرية وأعدادًا صحيحة. وكان الجمع بين quantile لمُدرَّج تكراري، الذي يعيد Float64، وcount لمُدرَّج تكراري، الذي يعيد Int64، كافيًا لإثارة هذه المشكلة. مرّر UNION ALL المركب وpivot كل سلسلة عبر العمود نفسه، مما أدى إلى توسيع ClickHouse للنوع إلى Variant(Float64, Int64). وقد أُصلحت هذه الحالة الآن. طلبات السحب ذات الصلة: #2858 توسيع تغطية اختبار int لدمج المقاييس متعددة السلاسل، #2859 نقل حساب دمج المقاييس متعددة السلاسل إلى ClickHouse، #2907 تغطية alert-task لبطاقات المقاييس متعددة السلاسل، #2916 إصلاح مخططات المقاييس متعددة السلاسل التي تمزج عمليات تجميع float وint، #2872 نموذج تعبير الصيغة، #2908 عرض الصيغ في استعلام المقياس المركب، #2909 واجهة مستخدم محرر المخططات لصيغ المقاييس عرض توضيحي من @pulpdrew كشف اختبار متغيرات لوحة المعلومات عن تراجع مستقل: إذ توقف الإكمال التلقائي في Lucene عن العمل بصمت في كل مكان تقريبًا. وكانت صفحة Search المكان الوحيد الذي ظل يعمل فيه. يتعلق التغيير الآخر بصفحة Join Team، حيث يعيّن المستخدمون المدعوون كلمة مرورهم. لم تكن الصفحة تعرض متطلبات كلمة المرور، رغم أن الواجهة الخلفية كانت تفرضها. وكان إدخال قيمة غير صالحة يؤدي إلى ظهور رسالة عامة تقول: “كلمة المرور غير صالحة”، ما يترك المستخدم ليخمن السياسة. أصبحت هذه المتطلبات ظاهرة الآن. كما كشف فحص المكوّن المشترك الذي يعرضها عن اختلافين مع الواجهة الخلفية: الأحرف الخاصة التي تُحتسب والحد الأقصى لطول كلمة المرور. وقد صُحّح كلاهما. طلبات السحب ذات الصلة: #2902 لاستعادة الإكمال التلقائي في Lucene، #2904 لعرض متطلبات كلمة المرور في صفحة Join Team