أيام ClickStack التجريبية - 2026-07-31

عرض توضيحي من @pulpdrew أُضيف دعم مبدئي للاستعلام عن مقاييس المُدرَّجات التكرارية الأُسّية في OpenTelemetry. كان بإمكانك تسجيل أحد هذه المقاييس في مصدر بيانات، لكن لم تكن هناك طريقة للاستعلام عنه. وتدعم أداة إنشاء الاستعلامات الآن عمليات العد والكميات المئوية. تتشابه المُدرَّجات التكرارية الأُسّية مع المُدرَّجات التكرارية ذات الحاويات الصريحة، لكن حدود حاوياتها تُحسب باستخدام قوى العدد اثنين بدلاً من تخزينها لكل حاوية. يتحكم المقياس في قوة العدد اثنين المستخدمة. ينتج عن المقياس الأعلى حاويات أصغر، بينما تُزيح الإزاحة الحدود نحو مضاعفات أعلى أو أدنى. ويسجل عدد كل حاوية عدد الملاحظات الواقعة ضمن ذلك النطاق. تظل القيم القصوى والدنيا والمجموع والمتوسط غير مدعومة، بما يتوافق مع التنفيذ الحالي للمُدرَّجات التكرارية الصريحة. وهذه الحقول اختيارية في نموذج بيانات OpenTelemetry، لذا لا نفترض وجودها. كما يوضح العرض التوضيحي، فإن SQL المُولَّد طويل وليس أنيقًا بشكل خاص. وأداؤه مقبول ولا يستهلك الذاكرة بالكامل، لكن هذا ليس سوى دعم وظيفي مبدئي. الأداء هو محور العمل التالي، ويجري بالفعل إعداد مخطط محدَّث من شأنه أن يجعل هذه الاستعلامات أسرع بكثير. في الوقت الحالي، لا يُعرض بشكل صحيح إلا نوع عرض السلاسل الزمنية. وهذا يتوافق مع نوع مقياس المُدرَّج التكراري الحالي. طلبات السحب ذات الصلة: #2687 ميزة: إظهار مقاييس المُدرَّجات التكرارية الأُسّية في القائمة المنسدلة لاسم المقياس، #2697 ميزة: تنفيذ الكمية المئوية والمجموع لمقاييس المُدرَّجات التكرارية الأُسّية، #2705 ميزة: دعم المُدرَّجات التكرارية الأُسّية في MCP، #2707 إصلاح: دعم تجميعات الكمية المئوية للمُدرَّج التكراري عبر أعمدة ليست سمات عرض توضيحي من @pulpdrew تعرض مخططات SQL الخام الآن تحذيرًا عند غياب وحدات الماكرو المتوقعة. جاء هذا التغيير استجابةً لتذكرة دعم من مستخدم كان ينشئ عددًا كبيرًا من مخططات SQL الخام ويتلقى نتائج مربكة باستمرار. ينبغي أن تتضمن استعلامات لوحة المعلومات وحدات ماكرو لعوامل التصفية وجدول المصدر. كما ينبغي أن تتضمن مخططات السلاسل الزمنية وحدات ماكرو للنطاق الزمني والفاصل الزمني. سابقًا، لم تكن هذه الفحوصات تُجرى إلا بعد إرفاق تنبيه بالبلاطة. أما الآن، فتُجرى لكل مخطط SQL خام، لذا تؤدي إزالة وحدة ماكرو إلى ظهور تحذير في المحرر بدلًا من إنشاء مخطط محيّر لاحقًا. يراعي التحقق أيضًا تبعيات كل وحدة ماكرو. تتطلب وحدتا ماكرو جدول المصدر وعوامل التصفية تحديد مصدر، رغم أن مخططات SQL الخام لا تحتاج إلى مصدر بخلاف ذلك. لذلك، يؤدي استخدام أي منهما دون تحديد مصدر إلى ظهور خطأ بدلًا من تحذير. إنه تغيير صغير، لكنه ينبغي أن يسهّل العثور على مشكلات SQL الخام دون الحاجة إلى التواصل مع الدعم. طلبات السحب ذات الصلة: #2742 ميزة: التحذير من params/macros المفقودة في SQL Editor عرض توضيحي يقدّمه @pulpdrew طلب فريق LogHouse طريقة أكثر استقرارًا للربط بالمصادر. يدير الفريق بيئة تسجيل السجلات في ClickHouse Cloud ويوفّر المصادر برمجيًا باستخدام البنية التحتية كشيفرة. تتغير معرّفات المصادر عند إعادة إنشاء مصدر، كما تختلف بين بيئات التطوير والمرحلة التجهيزية والإنتاج، مما يجعل أي رابط يستند إلى معرّف عرضة للتعطل. ونظرًا إلى أنهم يربطون بـ ClickStack من أنظمة التنبيه وGrafana، لم يكن من العملي الحفاظ على مجموعة منفصلة من معرّفات المصادر لكل بيئة. تقبل معلمة URL source الآن اسم المصدر إلى جانب معرّفه. يمكن التحكم بالأسماء عند توفير المصادر، لذا يمكن أن يعمل الرابط نفسه في كل بيئة. أُضيف الدعم مبدئيًا إلى صفحة البحث، ثم وسّعه طلب سحب لاحق ليشمل كل صفحة تتضمن معلمة مصدر، بما في ذلك Chart Explorer وخريطة الخدمات والجلسات ولوحة معلومات الخدمات ولوحة معلومات Kubernetes. تركز معظم النقاش اللاحق على سهولة اكتشاف هذه الميزة. فهي عمليًا واجهة برمجة تطبيقات عبر URL، ومن غير المرجح أن يكتشفها المستخدمون مصادفةً. أحد الخيارات هو استخدام الأسماء بدلًا من المعرّفات افتراضيًا، لكن تعارض الأسماء يجعل ذلك غير آمن. وشملت الاقتراحات الأخرى إتاحة الروابط عبر زر المشاركة، وأن تنشئها agents عبر MCP، وتوثيق واجهة برمجة التطبيقات عبر URL توثيقًا مناسبًا. وستستفيد النطاقات الزمنية النسبية من التوثيق نفسه. يمكن أيضًا توسيع المراجع المستندة إلى الأسماء لتشمل لوحات المعلومات. وعندئذٍ يمكن لسير عمل البنية التحتية كشيفرة توفير المصادر واستيراد لوحات المعلومات وربط كل شيء تلقائيًا. تتطابق عمليات استيراد لوحات المعلومات عبر واجهة المستخدم بالفعل مع المصادر حسب الاسم، لذا تقتصر الفجوة المتبقية في الغالب على مسارات العمل البرمجية. طلبات السحب ذات الصلة: #2746 feat: قبول أسماء المصادر بالإضافة إلى المعرّفات في معلمات URL، #2758 feat: دعم الروابط العميقة لأسماء المصادر في صفحات إضافية عرض توضيحي من @elizabetdev يجري العمل على تحديد موضع إعدادات عرض المخططات. نقلها التغيير الأصلي بشكل مضمن إلى يمين محرر البلاطة بدلًا من فتحها في درج منفصل. سابقًا، كان محرر البلاطة نافذة مشروطة، وكانت إعدادات العرض تُفتح في درج فوقها. وكان الضغط على Escape مرة واحدة يغلق كليهما، كما أن وجود درج فوق نافذة مشروطة لم يكن يبدو مناسبًا. أصبح طلب السحب أكثر تعقيدًا عندما استلزم الأمر أيضًا تكديس إعدادات السلاسل فوقها، لذا تراجعنا خطوة وبدأنا النظر إلى الصفحة بصورة أشمل. لا يزال العمل في مرحلة المخطط الهيكلي. يضع التصميم الحالي الإعدادات في لوحة مثبتة ويطبّق التغييرات تلقائيًا، مما يتيح لك رؤية النتيجة في الوقت الفعلي دون الضغط على زر Apply. تتمثل الخطة في إنهاء إعادة التصميم قبل إعادته إلى طلب السحب الحالي. ويُتعامل مع الموجود حاليًا كنموذج أولي، لا سيما لأن التصميم الجديد يغيّر أيضًا أجزاءً من صفحة لوحة المعلومات. طلبات السحب ذات الصلة: #2721 feat(dashboards): نقل محرر البلاطة إلى درج مع لوحة إعدادات مثبتة عرض توضيحي من @elizabetdev هذا استكشاف مبكر لصفحة Explore موحّدة قد تحل في نهاية المطاف محل Search وعمليات البحث المحفوظة وChart Explorer، من خلال نقطة دخول واحدة. يستند هذا الطرح إلى ما تعلمناه من إعادة تصميم عارض التتبعات. وبدلاً من تغيير التجربة للجميع دفعة واحدة، ستُطلق الصفحة الجديدة خلف علامة ميزة لمجموعة صغيرة من المستخدمين. وسنستغل تلك الفترة لاكتشاف المشكلات وإصلاحها قبل طرحها على نطاق أوسع. وإذا لم تنجح الفكرة، فستبقى تجربة ولن تُطلق. وهذه نتيجة مقبولة تماماً. تبدأ الصفحة باختيار نوع الإشارة. ويؤدي اختيار التتبعات أو السجلات أو المقاييس إلى تكييف بقية التجربة وفقاً لذلك. فعند اختيار السجلات مثلاً، تحصل على عرض القائمة وأنماط الأحداث والسلاسل الزمنية والتصورات الأخرى المتاحة حالياً في Chart Explorer. ينبغي أن يكون بالإمكان مواصلة التحقيق دون التنقل بين الصفحات. قد تبدأ بقائمة، ثم تنتقل إلى رقم أو جدول مجمّع، وتضيف النتيجة إلى لوحة معلومات، ثم تكتب استعلاماً مخصصاً إذا احتجت إلى مزيد من التحكم. تتضمن الصفحة عدة أفكار أصغر، معظمها مستوحى من ملاحظات المستخدمين. سيعمل محرر الاستعلامات بصورة أقرب إلى محرر SQL، مما يلغي الفروقات الحالية في سلوك الإكمال التلقائي. وستظهر الأخطاء والتحذيرات أثناء التحرير بدلاً من الانتظار حتى تشغيل الاستعلام. ستتوفر للأعمدة أداة اختيار مخصصة. لم يدرك مستخدم واحد على الأقل أن تغيير عبارة SELECT يتحكم في الأعمدة التي تظهر في الجدول. وباستخدام أداة الاختيار، يؤدي النقر على حقل إلى تحديث SQL ويتيح لك الفرز حسب ذلك الحقل. وتظل عبارة SELECT متاحة للمستخدمين المتقدمين. ستظهر العروض المحفوظة أيضاً في الصفحة، بحيث يمكنك الاستكشاف دون حفظ، ثم حفظ العرض الحالي في مكانه. وسيُعرض SQL المُولَّد بشكل مضمن. لا يزال الكثير مفقوداً، بما في ذلك بعض التصورات المتاحة في Chart Explorer اليوم. وسيستمر التصميم في التغير مع إضافة تلك العناصر. طلبات السحب ذات الصلة: لا يوجد بعد، فهذا استكشاف وليس ميزة مُطلقة عرض توضيحي من إعداد @teeohhem دُمجت ميزة ربط عوامل تصفية لوحة المعلومات. استعرضناها لأول مرة كمسودة قبل عدة أشهر، ثم أوقفنا العمل عليها مؤقتًا أثناء معالجة تأثيراتها على الأداء. يغيّر الربط شكل استعلامات لوحة المعلومات، ولا يحقق دائمًا أفضل استفادة من العروض المادية، لذا سيُطرح كمفتاح تبديل اختياري بدلًا من أن يكون مفعّلًا افتراضيًا. عند تمكين الربط، يؤدي اختيار قيمة في أحد عوامل التصفية إلى تضييق القيم المتاحة في العوامل الأخرى. فعند اختيار خدمة، لا تبقى سوى قيم مستوى الخطورة الموجودة لتلك الخدمة. وعند اختيار معرّف تتبع، لا تبقى سوى معرّفات التتبع الأصلية ذات الصلة. يمنع ذلك المستخدمين من اختيار مجموعات لا تُرجع أي بيانات. يجعل طلب سحب لاحق الربط مدركًا للمصدر. تُجمّع عوامل التصفية حسب المصدر، وتظهر أيقونات سلسلة بين عوامل التصفية المتجاورة التي يمكن أن يضيّق بعضها نطاق بعض. في لوحة معلومات تضم عاملي تصفية للسجلات وعاملي تصفية للتتبعات، ينبغي أن يكون واضحًا أي عوامل التصفية تتفاعل معًا. كانت حالة الاستخدام الأصلية هي لوحة معلومات Kubernetes. ينبغي أن يؤدي اختيار جراب إلى الإبقاء على عمليات النشر والعُقد التي تحتوي على ذلك الجراب فقط. تُجلب القيم المضيّقة عند فتح القائمة المنسدلة، مما يحد من تكلفة عمليات البحث الإضافية. ترك النقاش سؤالين مفتوحين. يُخزّن الإعداد حاليًا لكل مستخدم في مساحة تخزين المتصفح. وكان المتوقع من النقاش أن يرغب المستخدمون في نهاية المطاف بحفظه على مستوى لوحة المعلومات. إن كان الأمر كذلك، فقد يكون من الأفضل الإبقاء على التفضيل على مستوى المستخدم مؤقتًا بدلًا من أن ينافس لاحقًا السلوك على مستوى لوحة المعلومات. السؤال الآخر هو كيفية تصرف عوامل التصفية التابعة أثناء تحميل قيمها. يؤدي اختيار قيمة حاليًا إلى إظهار حالة تحميل داخل القائمة المنسدلة التابعة بدلًا من حظر استخدامها، رغم أن السلوك مع عامل تصفية تابع ثانٍ لا يزال بحاجة إلى التحقق. وكان التفضيل هو إبقاء عوامل التصفية قابلة للاستخدام أثناء تضييق النطاق، مع إظهار أن القائمة لم تكتمل تحديثاتها بعد. لا ينبغي لمن يعرف مسبقًا القيمة التي يريدها أن يضطر إلى انتظار البيانات الوصفية. طلبات السحب ذات الصلة: #2423 feat(dashboards): قيم عوامل التصفية المتتالية (ذات الأوجه)، #2760 feat(dashboards): الاحتفاظ بمفتاح تبديل ربط عامل التصفية وتوضيح الربط ضمن المصدر عرض توضيحي من @MikeShi42 أصغر طلب سحب لهذا الأسبوع مثال جيد أيضًا على تحسين بسيط يستحق الإصلاح. كانت اللوحة الجانبية للصف تُفتح دائمًا على علامة التبويب Overview، المصممة لحقول سجلات OpenTelemetry. أما السجلات التي لا تتبع بنية OTel، فلا تعرض هذه العلامة سوى القليل جدًا من المعلومات المفيدة. لذلك ستنتقل إلى Column Values في كل مرة تفتح فيها صفًا. أصبحت اللوحة تتذكر الآن آخر علامة تبويب استخدمتها وتفتحها مجددًا في المرة التالية. لا حاجة إلى أي إعدادات. سيبقى المستخدمون الذين لا يستخدمون OTel وينتقلون إلى Column Values في هذه العلامة، بينما سيستمر مستخدمو Overview في السلوك الحالي. طلبات السحب ذات الصلة: #2752 feat(app): تذكّر آخر علامة تبويب مستخدمة في اللوحة الجانبية عند فتحها مجددًا