صيغ المقاييس في محرر المخططات
عرض توضيحي من قبل @wrn14897
أصبح بإمكان مخططات المقاييس إجراء عمليات حسابية. فحتى هذا الأسبوع، لم يكن وجود مقياسين في المخطط نفسه يعني سوى خطين اثنين، دون أي وسيلة للجمع بينهما.
تُوسم السلاسل في المخطط بالأحرف
A وB وC وهكذا، ويتيح لك صف الصيغة بناء سلسلة مشتقة من هذه المراجع. فالصيغة A / (A + B + C) * 100 تمنحك معدل استخدام قائمة الانتظار، ويمكنك بالطريقة نفسها حساب التشبّع من أعداد الرسائل المستلمة والمُرسلة في collector.
يمكنك إضافة عدة صيغ إلى مخطط واحد، واختيار ما إذا كنت تريد عرض سلاسل المعاملات إلى جانب النتيجة أم عرض الصيغة وحدها، ومزج سلاسل من مقاييس مختلفة. كما تعمل التنبيهات على الصيغ أيضاً.
أما العمليات الحسابية نفسها فتجري داخل ClickHouse؛ إذ تُصرَّف كل صيغة من شجرة تركيب مُتحقَّق منها إلى استعلام المقياس المركَّب، فيحسبها ClickHouse ضمن استعلام واحد بدلاً من أن يضم التطبيق النتائج لاحقاً. تتحول كل سلسلة إلى تعبير جدول شائع، ثم تُقيَّم الصيغة على النتيجة المضمومة.
تُحتسب المعاملات الناقصة أصفاراً، لذا تظهر المجموعة التي لا أخطاء فيها بقيمة 0% بدلاً من N/A. ويُغلَّف كل مقام قسمة بـ nullif(..., 0)، بحيث يظهر المقام الصفري أو الناقص فجوةً لا صفراً أو خطأ.
ونقل تحديث لاحق كلاً من HAVING وORDER BY وLIMIT إلى عملية الضم النهائية بدلاً من تطبيقها على كل فرع UNION. ففي السابق كانت هذه الجمل تُنفَّذ في نطاق لا تتوفر فيه أسماء المخرجات الظاهرة للمستخدم، ما كان يعني ترشيح كل سلسلة على حدة قبل الضم، مع بقاء ترتيب الصفوف النهائي غير حتمي.
يقبل حقل الإدخال مراجع الأحرف والعمليات الحسابية البسيطة، لا أي SQL اعتباطي في الوقت الحالي. وتظهر مراجع السلاسل غير المعروفة والتعبيرات المشوهة والتعبيرات المكوّنة من ثوابت فقط بشكل فوري أسفل حقل الإدخال. ويمنع التحقق نفسه عمليتي الحفظ والتشغيل، بحيث لا يصل أي تعبير غير صالح إلى ClickHouse.
لا تُدعم العوامل على مستوى البتات ودوال ClickHouse بعد، ولا سبب أعمق لذلك؛ فهذا ببساطة ما توقفت عنده النسخة الأولى، ودعم التعبيرات على نطاق أوسع أمر يمكننا إضافته لاحقاً.
وطُرح في النقاش أمران لم يُنفَّذا بعد: لا يمكن للصيغ أن تشير إلى صيغ أخرى، فلا يمكنك ربط F1 بـ F2؛ كما أن عناصر التحكم بإظهار وإخفاء كل سلسلة على حدة ستكون أجدى من مفتاح تبديل المعاملات على مستوى المخطط بأكمله، فإخفاء A وB مع إبقائهما ضمن الصيغة هو ما يريده الناس فعلاً.
وطُرح أيضاً سؤال وجيه عن المدى الذي يمكن دفع عمليات الضم إليه قبل أن تفقد جدواها. وكل من استخدم القسمة في PromQL يعرف نمط الفشل: عملية ضم لا تطابق كما هو متوقع فتعيد نتيجة فارغة بصمت.
طلبات السحب ذات الصلة: #2908 عرض الصيغ في استعلام المقياس المركَّب، #2909 واجهة محرر المخططات لصيغ المقاييس، #2946 تطبيق HAVING/ORDER BY/LIMIT على ضم المقياس المركَّب بدلاً من فروع كل سلسلة، #2952 دعم الصيغ عبر واجهات برمجة تطبيقات، #2953 دعم الصيغ لمصادر أحداث السجلات والتتبعات
متغيرات لوحة المعلومات التابعة والماكرو
عرض توضيحي من قبل @pulpdrew
تحقّق طلبان من طلبات عرض الأسبوع الماضي.
أصبح بإمكان تعريفات عوامل التصفية الآن الإشارة إلى متغيرات أخرى في عبارة
WHERE الخاصة بها، بحيث تستطيع قائمة منسدلة تحديد نطاق قائمة أخرى. فعامل تصفية الخطورة الذي يشير إلى عامل تصفية اسم الخدمة يبدأ فارغًا، وبمجرد اختيارك خدمة، لا يعرض سوى مستويات الخطورة الموجودة لتلك الخدمة.
ولا يزال الاستعلام عن الخيارات يجري حتى عندما لا يكون هناك أي تحديد في المتغير المُشار إليه. استخدم $__filters أو $__conditionalAll إذا أردت تعبئة القيم في تلك الحالة، إذ إن التعبير المجرد <expression> IN ($var) لا يعيد شيئًا ما لم يكن لدى $var تحديد. وتوضح تلميحة الآن سبب ذلك، بدلًا من تركك أمام قائمة فارغة دون تفسير. كما يعمل الإكمال التلقائي للمتغيرات والماكرو في حقل WHERE داخل نافذة عامل التصفية.
ويمكنك إنشاء تبعيات دائرية، لكنها لا تسبب ضررًا فعليًا لأن المتغيرات تُستبدل بتحديداتها بدلًا من أن تُقيَّم بشكل تعاودي.
وأصبح الماكرو الآن يوسّع المتغيرات المُمرَّرة كوسائط، لذا يعمل $__timeFilter($TimeColumn). اختر عمود طابع زمني من متغير، ليتوسّع الماكرو إلى عامل تصفية الطابع الزمني الكامل حوله. ويجب الآن أن تستخدم المتغيرات المُمرَّرة إلى $__filter و$__conditionalAll صيغة $var؛ فقد كان الشكل المجرد var مقبولًا سابقًا، وهو تساهل لم يكن يثمر سوى اللبس في الغالب.
وتفهم كل من واجهة برمجة التطبيقات الخارجية v2 وMCP Server المتغيرات، ما يعني أن Terraform يدعمها أيضًا. ويستطيع الوكيل بناء لوحة معلومات تتضمن عوامل تصفية متغيرة وأخرى ذات بث، وقوائم منسدلة تابعة، وبطاقات تشير إلى تلك المتغيرات مباشرةً أو عبر ماكرو. وتصدر أدوات الإنشاء والحفظ والتصحيح تحذيرًا عند استخدام المتغيرات في مواضع لن تعمل فيها.
كما تقبل أدوات بطاقات الاستعلام قيم المتغيرات، بحيث يستطيع الوكيل التحقق من عمليات الاستبدال الخاصة به قبل تسليم لوحة المعلومات.
طلبات السحب ذات الصلة: #2923 دعم استعلامات قيم المتغيرات التابعة، #2937 دعم الماكرو المتداخل ومراجع المتغيرات داخل الماكرو، #2944 إضافة متغيرات لوحة المعلومات إلى واجهة برمجة التطبيقات الخارجية، #2951 دعم متغيرات لوحة المعلومات في MCP Server
مخططات أدوات MCP التي يقبلها العملاء الصارمون
عرض تقديمي من @teeohhem
أبلغ أحد العملاء بأنه لم يتمكن من استخدام خادم MCP الخاص بنا مع الوكيل لديه على الإطلاق.
تعرض بعض أطر عمل الوكلاء قائمة الأدوات المتاحة وتتحقق من صحة كل مخطط إدخال قبل إرسالها إلى مزوّد النموذج. وإذا كان أحد المخططات غير صالح، فإن الإطار يرفض قائمة الأدوات بأكملها لا الأداة المخالفة وحدها، مما يجعل الخادم يبدو معطّلاً تماماً.
كثير من بيئات تشغيل الوكلاء أكثر تسامحاً، لكن بعضها ليس كذلك. وبالنسبة إلى العملاء المتأثرين، كان فصل الخادم هو السبيل الوحيد لإعادة الوكيل إلى العمل.
يوجد الآن اختبار يؤكد أن مخطط الإدخال لكل أداة هو JSON Schema صالح وفق المسودة 2020-12، بحيث لا يمكن لأداة جديدة أن تعطّل العملاء الصارمين بالطريقة نفسها مرة أخرى.
طلبات السحب ذات الصلة: #2925 إصدار مخططات إدخال أدوات صالحة وفق المسودة 2020-12، #2971 الإعلان عن مستوى الكمّية بوصفه تعداداً نصياً
مفاتيح الوصول الشخصية إلى واجهة برمجة التطبيقات القابلة للتدوير
عرض توضيحي من قبل @teeohhem
أصبح بالإمكان الآن تدوير مفاتيح الوصول الشخصية إلى واجهة برمجة التطبيقات من Team Settings ← API & Agents.
يُستخدم المفتاح بوصفه رمز bearer لواجهة برمجة التطبيقات الخارجية v2 ولخادم MCP. وكان في السابق يُولَّد مرة واحدة عند إنشاء الحساب دون إمكانية تغييره إطلاقًا، فكان التعامل مع تسرّب أحد المفاتيح يعني حذف المستخدم.
يجري التدوير فورًا ودون فترة سماح، مع بقاء جلسة المتصفح مسجَّلة الدخول. وتوخَّ الحذر هنا: فالمفتاح يخصّ الحساب لا الفريق. فإذا كنت تنتمي إلى عدة فرق، وجب تحديث كل ما يستخدم ذلك المفتاح فيها جميعًا.
ويعرض Enterprise تحذيرًا يوضّح ذلك. أما في التثبيت مفتوح المصدر ذي الفريق الواحد فلا داعي للتحذير، ولذلك لا يظهر هناك.
وهناك قيدان مقصودان. فالمسار
PATCH /me/accessKey لا يقبل أي معرّف مستخدم لأن المعرّف يأتي من الجلسة، ومن ثمّ لا يمكنه إلا تدوير مفتاح المُستدعي نفسه.
كما أن هذا المسار غير متاح عبر واجهة برمجة التطبيقات الخارجية v2 المصادَق عليها بـ bearer، إذ يمكن أصلًا استخدام المفتاح المسرَّب هناك لقراءة نفسه، والسماح له بالتدوير أيضًا سيتيح لشخص ما حجب المالك عن أدواته الخاصة.
طلبات السحب ذات الصلة: #2926 جعل مفاتيح الوصول الشخصية إلى واجهة برمجة التطبيقات قابلة للتدوير
مفاتيح مرتبة أبجديًا في تبويب Column Values
عرض توضيحي من قبل @teeohhem
أصبحت المفاتيح في تبويب Column Values ضمن اللوحة الجانبية للصف مرتبة أبجديًا في كل مستوى تداخل، لكلٍّ من السجلات والتتبعات.
كانت شجرة JSON تعرض المفاتيح سابقًا وفق ترتيب التخزين الفيزيائي في ClickHouse، وهو ترتيب يبدو عشوائيًا عمليًا. فعمود من نوع
Map مثل ProfileEvents، الذي يضم 125 مفتاحًا، لم يكن له ترتيب واضح يمكن تتبعه، وبالتالي كان العثور على مفتاح واحد يستلزم قراءة القائمة بأكملها.
أما الجانب الأقل وضوحًا من المشكلة فهو أن كل مستوى محدود بـ 50 صفًا، وكان الاقتطاع يجري قبل الترتيب. لذا كانت الـ 50 مفتاحًا التي تظهر لك مجموعة جزئية اعتباطية، ولم يكن هناك سبيل للوصول إلى البقية سوى “Expand 75 more properties”.
أما الآن فيجري الترتيب في TreeNode قبل اقتطاع القائمة، كما أنه يراعي الأرقام، فيأتي key2 قبل key10.
طلبات السحب ذات الصلة: #2943 ترتيب مفاتيح عارض JSON أبجديًا
Storybook كنظام تصميم قابل للتصفح
عرض توضيحي من @elizabetdev
لم يعد Storybook مجرد sandbox للمكوّنات، بل أصبح نظام تصميم قابلاً للتصفح. ويتبع الشريط الجانبي هذا الترتيب: الإرشادات ← العلامة التجارية ← الأيقونات ← رموز التصميم ← المكوّنات.
يعرض قسم الإرشادات ملفات
agent_docs بصيغة Markdown مباشرةً، فيجتمع في مكان واحد كلٌّ من code style والنُّسق وتخطيط الصفحة وألوان تصور البيانات. وهذا موجّه للوكلاء بقدر ما هو موجّه للأشخاص؛ فتوجيه أحد الوكلاء إلى المستند نفسه الذي يقرأه عضو جديد في الفريق يساعد على إبقاء المكوّنات المولَّدة متسقة مع كل ما هو قائم بالفعل.
يضم قسما العلامة التجارية والأيقونات شعارات HyperDX وClickStack وأيقوناتنا المخصصة، ومنها IconAiNotebook. ويمكنك نسخ ملفات SVG أو تنزيلها، مع إرشادات حول متى تستخدم أيقونة خطية متوافقة مع Tabler ومتى تستخدم علامة تجارية.
بدأ هذا العمل بالأيقونات لأن الشرائح كانت تستخدم أي أيقونة تبدو قريبة بما يكفي. فإذا احتجت علامةً لعرض تقديمي، فخذها من هنا.
يتيح شريط أدوات العلامة التجارية التبديل بين HyperDX وClickStack، بينما يغطي شريط أدوات النسق الوضعين الفاتح والداكن، ما يسمح بفحص المكوّنات الجديدة بجميع التوليفات قبل إطلاقها. أما قصص المكوّنات التي كانت غير مصنّفة فأصبحت الآن مندرجة تحت Components/، مع إتاحة مكوّنات بطاقات مخطط إلى جانبها.
وقد ظهر أمران خلال هذا العمل. فمتغيرات CSS الخاصة بالخطوط في Storybook باتت موجودة على <html> بما يطابق التطبيق، فلم يعد نص المتن ولا عناصر popover المنقولة تُعرض بخط Times.
كما أننا لا نستخدم مجموعة أيقونات Tabler بشكل متسق. فعلى الأرجح تحتاج PromQL إلى أيقونة خاصة بها، في حين تُمثَّل المقاييس والتتبّعات حالياً بأيقونات مختلفة في مواضع مختلفة. وأصبح Storybook هو المرجع الذي يُتبع في ذلك.
شغّله محلياً باستخدام yarn workspace @hyperdx/app storybook.
طلبات السحب ذات الصلة: #2935 تحويل Storybook إلى نظام تصميم قابل للتصفح
اللوحة اللونية categorical في مخططات المدرَّج التكراري
عرض تقديمي من @elizabetdev
كانت مخططات المدرَّج التكراري، بما فيها Request Latency في لوحة معلومات Services، مثبَّتة برمجيًا على اللون
#50FA7B. واللون الأخضر النيوني ليس جزءًا من اللوحة اللونية للمخططات ولا يوفّر تباينًا كافيًا، كما كانت التلميحة تعرض “Number of events” باللون نفسه.
أصبح المخطط الآن يحصل على chart-blue عبر getColorFromCSSToken، وتستخدم تلميحته المكوّنين المشتركين ChartTooltipContainer وChartTooltipItem، ما يجعلها متوافقة مع المخططات الخطية والشريطية والدائرية.
كذلك أُزيل رابط View events من التلميحة، إذ كان generateSearchUrl مقبولًا في المدرَّج التكراري الداخلي وفي التلميحة، لكنه لم يُمرَّر قط من DBHistogramChart، ولذلك لم يظهر الرابط أبدًا في بيئة الإنتاج.
فالمستدعي الوحيد لا يملك أي مُنشئ لعنوان URL للبحث خاص بحاوية المدة، كما أن تصفية الأحداث ضمن نطاق زمن استجابة معيّن تُعدّ ميزة قائمة بذاتها لا مجرد إصلاح للتوصيل.
تحسينات صغيرة، لكنها تتراكم.
طلبات السحب ذات الصلة: #2949 استخدام اللوحة اللونية categorical في مخططات المدرَّج التكراري