Skip to main content

​
عوامل تصفية المصدر، متاحة الآن في كل مكان

عرض توضيحي من إعداد @pulpdrew
أصبحت عوامل تصفية المصدر متاحة الآن في جميع أنحاء لوحة معلومات الخدمات. اختر مصدر trace أو log مع عامل تصفية لاسم الخدمة، وستنتظر لوحة المعلومات حتى تختار قيمة قبل تشغيل الاستعلامات. ثم يُطبَّق عامل التصفية هذا بشكل متسق على كل مخطط واستعلام ولوحة جانبية. ويتبع trace waterfall السلوك نفسه، إذ يرث أي عوامل تصفية للمصدر من صفحة Search عند فتح span، مع إتاحة إضافة عوامل تصفية أخرى. كما حُدِّثت صفحة Sessions بحيث تنتقل عوامل تصفية المصدر إلى الشريط الجانبي ولوحة trace والعروض المتداخلة. وُسِّعت أيضًا ميزة الإكمال التلقائي لعوامل تصفية المصدر. كانت متاحة سابقًا في صفحة Search فقط، لكنها تعمل الآن في كل موضع يدعم عوامل تصفية المصدر، بما في ذلك لوحات المعلومات. داخليًا، يحل الإكمال التلقائي الآن keys وvalues عبر مصادر متعددة، حتى عندما تكون لكل مصدر مجموعته الخاصة من عوامل التصفية. وتتوافر التحسينات نفسها في كلٍّ من محرر Raw SQL وكل حقل إدخال لعامل تصفية المصدر في query builder. طلبات السحب ذات الصلة: #2331 إضافة تحديد نطاق المصدر إلى عوامل تصفية لوحة المعلومات، #2459 إظهار أيقونة على البطاقات التي تحتوي على عوامل تصفية مستبعدة ومحددة النطاق بالمصدر

​
لوحات معلومات أفضل مُنشأة بالذكاء الاصطناعي للمخططات المخصصة

عرض توضيحي من @pulpdrew
واجه مستخدم ينشئ لوحات معلومات بالذكاء الاصطناعي استنادًا إلى مخطط مخصص مشكلات كبيرة في الأداء. وكان السبب الجذري أن بطاقات Raw SQL المُنشأة تضمّنت نطاقًا زمنيًا ثابتًا بدلًا من استخدام وحدات ماكرو عامل تصفية الوقت في لوحة المعلومات، لذا لم يؤثر تغيير النطاق الزمني للوحة المعلومات في النتائج. كما كانت إحدى البطاقات تُجري التصفية على عمود timestamp من نوع عدد صحيح بطريقة تتجاوز المفتاح الأساسي، ما فرض فحصًا كاملًا للجدول. لمعالجة ذلك، يوضح مخطط MCP الخاص ببطاقات لوحة معلومات Raw SQL الآن صراحةً أنه ينبغي للوكلاء استخدام وحدات ماكرو عامل تصفية الوقت في لوحة المعلومات. وتحذّر ClickStack UI أيضًا عندما تفتقر بطاقة SQL مُنشأة إلى هذه الوحدات، مما يسهّل اكتشاف المشكلة قبل حفظ لوحة المعلومات. بعد نشر التغييرات، أدى تشغيل prompt الأصلي للعميل مجددًا إلى إنشاء SQL يستخدم وحدات الماكرو الصحيحة، ما أسفر عن لوحة معلومات أسرع بكثير. طلبات السحب ذات الصلة: #2473 توجيه الوكلاء إلى استخدام وحدات الماكرو في بطاقات Raw SQL

​
تجزئة أبسط لمقاييس OTel، وفكرة لمفتاح أساسي

عرض توضيحي من @dhable
أصلحت مساهمة من المجتمع تجزئة السمات للمقاييس ذات أعمدة السمات بتنسيق JSON، لكنها أدخلت مسارين مختلفين في الشيفرة. استخدمت مخططات JSON الصيغة متغيرة الوسائط لـ cityHash64، بينما كانت المخططات المستندة إلى Map تدمج ثلاث خرائط أولًا قبل تجزئتها. واتضح أن هذا العمل الإضافي لم يكن ضروريًا. يستخدم كلا نوعي المخططات الآن تنفيذ cityHash64 نفسه، مما يبسّط الشيفرة ويتجنب تخصيصات الخرائط غير الضرورية أثناء التجزئة. كما سلّط هذا العمل الضوء على تحسين محتمل لمخطط مقاييس OpenTelemetry. حاليًا، يخزّن المفتاح الأساسي خريطة السمات كاملةً، مما يزيد من استخدام الذاكرة لأن ClickHouse يحتفظ بالخريطة في الذاكرة كجزء من الفهرس. تتمثل إحدى الأفكار في تجسيد تجزئة للسمات وقت الإدراج واستخدامها بدلًا منها في المفتاح الأساسي. لم يتغير شيء بعد، لكن مع عودة تحديثات مخطط OpenTelemetry إلى دائرة النقاش، فهذا تحسين يستحق إعادة النظر فيه. طلبات السحب ذات الصلة: #2475 توحيد AttributesHash مع الصيغة متغيرة الوسائط لـ cityHash64

​
تحسينات على شرائح عوامل التصفية ومصادر البيانات

عرض توضيحي من إعداد @alex-fedotyev
طُرح هذا الأسبوع تحسينان صغيران لكنهما مفيدان. أصبحت شرائح عوامل التصفية المستبعَدة أسهل قراءةً بكثير، بعد أن أظهرت ملاحظات العملاء أن التنسيق السابق جعل زر الإزالة صعب الرؤية. وهي تستخدم الآن لونًا أحمر أكثر هدوءًا يحسّن التباين في الوضعين الفاتح والداكن. أصبحت إدارة أعداد كبيرة من مصادر البيانات أسهل أيضًا. يمكن الآن إسناد قسم اختياري إلى المصادر، مما يتيح تجميعها في منتقي المصدر. وتستمر المصادر التي لا تحتوي على قسم في الظهور ضمن “أخرى”، لذا لا تتأثر الإعدادات الحالية. كما حُدّث البحث ليطابق أسماء الأقسام، مما يسهّل العثور على المصادر ذات الصلة حتى إذا كنت تتذكر فقط المجموعة التي تنتمي إليها. تُستخدم هذه الميزة حاليًا داخليًا بينما يقيّم الفريق كيفية تنظيم المستخدمين لمصادرهم بصورة طبيعية قبل طرحها على نطاق أوسع. طلبات السحب ذات الصلة: #2478 جعل شرائح عوامل التصفية المستبعَدة مقروءة في النسق الفاتح، #2432 إضافة حقل قسم اختياري إلى مصادر البيانات، #2476 تجميع منتقي مصدر البيانات حسب القسم مع بحث بأسلوب العلامات، #2477 اقتراح أسماء الأقسام الحالية في نموذج المصدر

​
حدود السلاسل لكل مخطط للمخططات عالية الكاردينالية

عرض توضيحي من @wrn14897
يمكن للمخططات الآن تحديد عدد السلاسل التي تُرجعها، مما يساعد على تجنب مشكلات الأداء عند التجميع حسب حقول عالية الكاردينالية، مثل مسار HTTP أو معرّف span. في السابق، كان يمكن لهذه الاستعلامات إنتاج مئات الآلاف من السلاسل، ما يؤدي إلى بطء لوحات المعلومات أو توقفها عن الاستجابة. يمكنك الآن تقييد مخطط بأعلى N من السلاسل، مما يقلل وقت العرض وكمية البيانات المنقولة معًا. يصبح اختيار أفضل السلاسل بكفاءة أكثر تعقيدًا في الاستعلامات المقسمة إلى أجزاء. يحدد التنفيذ الحالي أعلى N من أحدث جزء، ثم يطبق مجموعة السلاسل نفسها على كامل الاستعلام، مع تنفيذ العمل في ClickHouse بدلًا من المتصفح. لا يزال هذا النهج قيد التقييم، وقد يتطور مع إدخال المزيد من تحسينات الاستعلامات. طلبات السحب ذات الصلة: #2449 جعل حد السلاسل اختياريًا ومتسقًا عبر الأجزاء، #2429 تقييد سلاسل time-series المجمعة حسب group-by بأعلى N من السلاسل لمنع نفاد الذاكرة
آخر تعديل في ١٤ أغسطس ٢٠٢٦