Grafana: السماح بتعيين مخصص لقيمة متغير القالب -> عرض النص

يمكنك القيام بذلك باستخدام لوحات المعلومات المكتوبة. لكنك مرحب بك لمحاولة تنفيذه في لوحات معلومات json العادية / المحفوظة.

+1

أنا أيضًا يمكنني استخدام نسخة أبسط من هذا على الأقل. شيء مثل التعيين المكون من A -> B

في السيناريو الخاص بي ، أرغب في تحديد اسم كيان في القائمة المنسدلة للمتغير (CustomerName1 ، CustomerName2 ، إلخ) ولكن استخدم معرفًا رقميًا داخليًا عندما يتعلق الأمر باسم المقياس.
طلبات التطبيق. $ customer1_ID.count

+1

الاندماج من # 3138

على سبيل المثال ، عند إنشاء متغير قالب مخصص بقيم fooBar و baz_quuxInternal ، لتتمكن من جعل واجهة المستخدم تعرض مربعات الاختيار مثل "Foo bar" و "Baz".

هذا شائع بشكل خاص عند استخدام الصفوف المتكررة والمتغير المخصص لتقليل التكرار ، ولكن قد لا تكون مقاييس المستوى الأعلى سهلة الاستخدام.

يمكن للمرء أن يدعم هذا لقيم القالب التي تم الاستعلام عنها (مثل خصائص الجرافيت) أيضًا باستخدام regex (إذا كان الاستبدال عامًا). دعم Regex موجود بالفعل ، ولكنه ينطبق على كل من القيمة المستخدمة والتسمية. إن استخدامها للقيمة فقط سيكون ذا قيمة.

على سبيل المثال ، إذا كان استعلام الجرافيت يوسع kafka.messagesByTopic.myservice_* للاستخدام في القوالب ، فقد يرغب المرء في أن تقوم واجهة المستخدم بنزع البادئة. ولكن عند استخدامها في اللوحات الفعلية ، يجب تضمين البادئة. يمكن حل هذا الأمر (في Grafana 2.x وما بعده) الآن حيث يمكن تضمين متغيرات القالب في خاصية مترية ، لذلك يمكن للمرء أن يرمز البادئة في جميع المقاييس في جميع اللوحات والصفوف ، ولكن من الأفضل تجنب ذلك.

بمجرد وجود قيم "التسمية" هذه ، سيكون من المفيد أن تكون قادرًا على الوصول إليها داخل اللوحات أيضًا. مثل عند تضمين متغير في عنوان صف و / أو لوحة. إما أن نجعلها تستخدم التسمية بشكل افتراضي (إذا كانت مضمنة في حقل العنوان) ، أو ربما مع بعض الصيغ البديلة (على سبيل المثال ، $$Variable ، أو أي شيء آخر)

http://play.grafana.org/dashboard/db/test؟editview=templating يعرض "تسمية المتغير" كخيار. هل يمكن إغلاق هذا؟

تحرير: لقد أسأت فهم الخطأ ، آسف! :) الاستمرار في.

هذا مجرد خيار للحصول على اسم مألوف للمتغير ، وليس قيم المتغير

+1

+1

+1

+1

+1

+1

ما هي حالة هذا؟
هل ممكن عمل ذلك ؟

هل هذا ممكن للنهائي 3.0؟
يبدو وكأنه ميزة ينتظرها كثير من الناس. بمن فيهم أنا :-)

+1
عادةً ما أستخدم جزءًا من التعبيرات العادية التي تبدو مروعة للمستخدمين.

+1

+1

+1
بدون هذا ، تكون تعبيرات regex غير قابلة للاستخدام في متغيرات القالب.

+1

+1

+1

+1

+1

+1

تضمين التغريدة

لقد نفذت هذا لخدمة داخلية تستخدم Grafana. نظرًا لأننا نستخدم uuids للمضيفين (لذا فإن التغيير في اسم المضيف لا يفقد سجل المقاييس وعددًا من الأشياء الأخرى) ، كان من غير المقبول إظهار هذه المستخدمات للمستخدم. لقد أجريت تصحيحًا محددًا لحالة الاستخدام الخاصة بنا حيث اكتشفنا قيم uuid وترجمتها باستخدام نقطة نهاية http لتطبيقنا. هذا يعمل بشكل جيد بالنسبة لنا ولكني أفضل القيام بشيء عام ومقبول في المنبع.

هل من المقبول إضافة خيار "variable_translation_url" يشير إلى عنوان url يمكنه إجراء التعيين؟ (مع رمز ترخيص اختياري إذا لزم الأمر) أو variable_translation_script الذي يشير إلى javascript src التي يمكن تنزيلها وربطها بـ templateValuesSrv.js في النقاط التي تتطلب الترجمة (إذا تم تعيين هذا الخيار)؟

هل يمكنك مشاركة كود templateValuesSrv.js لك؟ اريد ان اجربها.

ZhuWanShan هذا في الأساس هو:

https://github.com/sangoma/grafana/commit/fa109c23bc92c3121173579afbd87a04d7e2f523

لاحظ أنك سترى طريقتين هناك. كان الهدف الأول هو أن يكون أكثر عمومية ، حيث يقدم نوعًا جديدًا لمتغير القالب "http" ، مع خاصية "استعلام" التي تشير إلى عنوان url HTTP لإجراء التعيين (راجع _getHttpVariableOptions). في وقت لاحق قمت بتطبيق طريقة ثانية تكتشف ما إذا كان نص الخيار (قيمة العرض) يطابق UUID regex ، وتفرض تعيين أي متغير هو ذلك باستخدام استدعاء HTTP مشفر إلى / api / v1 / nodes / grafana-hosts / الذي يقوم بإرجاع تعيين جميع الخيارات. لقد نجح ذلك حتى الآن ، ما عليك سوى الحصول على توجيه حول كيفية تحويل هذا إلى طريقة عامة.

+1

+1

بالنسبة لأي شخص مهتم ، تمكنت من حل حالة الاستخدام الخاصة بي باستخدام المكون الإضافي Simple JSON Datasource .

ومع ذلك ، فإن المكون الإضافي لا يدعم حاليًا الاستعلامات المتغيرة للقالب ولكن تم دمج طلب السحب الذي يعمل على إصلاح المشكلة في النموذج الرئيسي. يجب أن يتبع إصدار Grafana.net المحدث من المكون الإضافي في مرحلة ما.

باستخدامه يمكنك استخدام نقاط نهاية HTTP المخصصة كمصادر بيانات في Grafana. عليهم فقط تنفيذ 4 طرق . عند استخدامها مع متغيرات القالب المستندة إلى الاستعلام ، ستتلقى نقطة نهاية HTTP طلب واجهة برمجة تطبيقات /search وسيكون النص كائن JSON بالشكل: { "target": "{template query content here}" } . يمكنك تحليل محتوى الاستعلام كيفما تريد.

سيؤدي إرجاع مجموعة من القيم من نقطة النهاية إلى إنشاء قائمة أساسية بقيم متغير القالب ["custom value 1", "custom value 2"] بالصيغة: [{ "text": "custom value 1", value: 0 }] حيث تكون الخاصية text هي القيمة المرجعة لكل عنصر مصفوفة وخاصية value هي فهرس المتغير في مصفوفة الإرجاع.

بدلاً من ذلك ، يمكنك إرجاع مجموعة من كائنات النص / القيمة [{ "text": "label", "value": 123 }] وسيستخدم Grafana الخاصية text كتسمية لمتغير القالب ، وخاصية value كقيمة أولية لـ متغير القالب.

من الممكن إدخال متغيرات القالب الأخرى ديناميكيًا في الاستعلام في نموذج regex وإرسالها إلى نقطة النهاية ديناميكيًا للمعالجة.

لن يحل هذا جميع سيناريوهات التعرج ، ولكن وجود مصدر بيانات HTTP عشوائي يمكن استخدامه لمتغيرات القالب ، بما في ذلك الحقن الديناميكي لمتغيرات القالب الأخرى في استعلام القالب هو أداة جيدة.

أنا إنسان.

+1

+1

+1

+1

+1

+1

+1000

+1

+2

سيكون من المفيد للغاية الحصول على هذا. في الواقع ، لدي مجموعة من الكائنات التي لها اسم و uuid. أرغب في عرض الاسم ، لكن احتفظ بمعرف uuid في المتغير.

سيكون من الرائع أن نفعل شيئًا مثل:

الاستعلام (موجود): اعرض قيم العلامة من "vcd_vm" مع مفتاح = "uuid" حيث "OrgVdc" = ~ / ^ $ vDC $ /)

التصنيف (جديد): اعرض قيم العلامة من "vcd_vm" مع مفتاح = "name" حيث "uuid" = ~ / ^ $ tag $ /)

+1

+1

+1

+1

+1

+1

+1

سيكون رائعًا إذا أخذ متغير القالب "Custom" كمدخلات كلاً من قائمة "القيم" وقائمة "التصنيفات" (بشكل أساسي ، تجزئة / ديكت مخصص)

+1

+1

قد يكون هذا مفيدًا لبيانات AWS CloudFront ، كما تم تصديرها من قبل المصدر الرسمي للساعة السحابية. يتم عرض بيانات CloudFront بواسطة المعرفات ، والتي لا يستخدمها الإنسان. من السهل جدًا على الأشخاص الذين ينظرون إلى الرسوم البيانية مشاهدة "foo.example.com؛ bar.example.com" بدلاً من "EAUUWLGUQEPFWV؛ EVWWU9PGWIB" ...

+1

أولاً ، شكرًا لك على تطوير منتج رائع ومشاركته مع العالم!

هل هناك أي مؤشر على احتمال تنفيذ ذلك في الأشهر المقبلة؟ أنا أحاول فقط تقييم إلى أي مدى يكون من المنطقي المضي قدمًا وتنفيذ الحل البديل الذي اقترحه meverett أو انتظار ذلك.

يعد تنفيذ ذلك عبر نقطة نهاية HTTP حلاً أنيقًا لنسخة عامة للغاية من هذه المشكلة ، ولكن يبدو أنها مبالغة في الكثير من حالات الاستخدام الموضحة هنا (بما في ذلك حالاتي) حيث يكون كل ما هو مطلوب هو تعيين أساسي ثابت على عدد متواضع من "ودية عرض اسم أزواج "->" اسم قاعدة البيانات غير مألوف ".

@ svet-b fwiw ، انتقلنا لاستخدام اقتراحmeverett وكان غير مؤلم ونظيف. بضع ساعات فقط لإنشاء المكوِّن الإضافي لمصدر البيانات.

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

يعمل حل meverett بشكل جيد ، ولكنه يكون قصيرًا عند استخدامه مع متغيرات متعددة القيم لأنه لا يمكن تصنيف السلسلة إلا بعلامات من (في حالتي) influxdb. أي اقتراحات للحلول هناك؟ :)

+1

+1

+1

+1

+1

مرحبًا بالجميع ، نظرًا لأن هذه المشكلة تتعرض للاصطدام بشكل منتظم ، فقد قررت تجميع مثال على تطبيق ويب Node.js يستخدم الحل أعلاه .

إنه أمر أساسي جدًا ، لكنه يطبق بشكل كامل النمط الذي أذكره في تعليقي الأصلي. وإذا كان بإمكانك الاستمرار في وضع بيانات البحث الخاصة بك في ملف JSON واحد لا يتم تحديثه كثيرًا ، فقد يعمل فقط خارج الصندوق.

بخلاف ذلك ، يمكنك استخدامه كنقطة بداية وتوسيعه للوصول إلى بيانات الاسم المستعار الخاصة بك من أي مصدر تريده (برمجته أنت بالطبع) وتقديمه من خلال التطبيق بطريقة يمكن أن يستهلكها المكون الإضافي SimpleJson لمصدر البيانات ويمكن استخدامه لقيادة تسمية / تعيين متغير للقالب.

يوجد هنا مستودع مثال تطبيق الويب.

آمل أن يساعد. لقد تلقيت بعض الطلبات من وقت لآخر أطلب المزيد من المساعدة / الشرح لإعداد الحل.

هتافات

+1

+1

شكرًا على الحل المؤقت ، meverett . لقد قمت بإنشاء مستودع باستخدام Dockerfile لإنشاء حاوية Docker لتشغيل الحل الخاص بك. تم إعداده لأخذ data.json مخصصًا من جانب Dockerfile عند الإنشاء. آمل أن يساعد الناس:

https://github.com/shirakaba/GrafanaSimpleJsonValueMapper-docker

＋1

+1

+1

عندما تريد إجراء 1+ لهذا ، يرجى أن تضع في اعتبارك أنك ستزعج 74 شخصًا مشتركين حاليًا في هذه المشكلة ويأملون أن يتقدم أحدهم وينفذ إصلاحًا.
أضاف جيثب ردود فعل لسبب ...

+1

+1

+1

هذا سيكون أمرا رائعا! لديك قائمة من القيم الرقمية الطويلة ولكن يجب أن يكون أفضل بكثير لإظهار تسمية صديقة للإنسان لكل واحدة من القيمة نفسها
متغير: myListOfLongs {الاسم: قيمة تويوتا: 122321312332 ، الاسم: قيمة رينو: 6666666}

+1!

+1

+1
أي تحديثات حول # 11534 (السماح بالعناوين الديناميكية عند استخدام اللوحات / الصفوف المتكررة)

+1

+111111

+1

+1

+1 ، بشدة في حاجة إلى هذه الميزة.

+1

+1

+1

+1

+1

يعمل هذا مع MySql و PostgreSQL:

خيار آخر هو الاستعلام الذي يمكنه إنشاء متغير مفتاح / قيمة. يجب أن يُرجع الاستعلام عمودين يسميان __text و __value. يجب أن تكون قيمة العمود __text فريدة (إذا لم تكن فريدة ، فسيتم استخدام القيمة الأولى). سيكون للخيارات الموجودة في القائمة المنسدلة نص وقيمة تسمح لك بالحصول على اسم مألوف كنص ومعرف كقيمة. مثال على استعلام باسم المضيف كنص ومعرف كقيمة:

SELECT hostname AS __text, id AS __value FROM my_host

http://docs.grafana.org/features/datasources/mysql/#query -variable

أود أن أقترح المتغير المخصص ليكون:

[{
        "__text": "Server 1",
        "__value": 1
    },
    {
        "__text": "Server 2",
        "__value": 2
    }
]

ربما نوع جديد يسمى JSON؟

شكرا @ johnymachine! نجح ذلك بشكل جميل مع مصدر بيانات PostgreSQL.

كامتداد لهذا ، هل هناك أي طريقة لاسترداد قسم __text من المتغير؟ سيكون هذا مفيدًا حقًا لتكرار الرسوم البيانية.

مرحبًا MGinshe ، هذا يعمل بشكل جيد (يعرض النص قيمة تستخدم) بالنسبة لي:

تحرير: أسيء فهم السياق الأولي لهذا الخطأ ، وتجاهل التعليق أدناه ، فقد كان معنيًا أكثر بـ # 9292

تضمين التغريدة

يبدو أن https://github.com/grafana/grafana/pull/12609 ينفذ ما يطلبه معظم الناس هنا ، أي سبب لإغلاق ذلك وعدم دمجه مطلقًا؟

لا ، هذه القضية تتعلق بشيء مختلف تمامًا ، أو هل قمت بربطها بمسألة خاطئة؟

لا يزال لا يوجد أخبار عن هذا؟ هيا ، نحن في 2018 !! شكرا!

dmayan تم الرد عليها من قبل johnymachine . يمكنك استخدام هذا.

يعمل هذا مع MySql و PostgreSQL:

خيار آخر هو الاستعلام الذي يمكنه إنشاء متغير مفتاح / قيمة. يجب أن يُرجع الاستعلام عمودين يسميان __text و __value. يجب أن تكون قيمة العمود __text فريدة (إذا لم تكن فريدة ، فسيتم استخدام القيمة الأولى). سيكون للخيارات الموجودة في القائمة المنسدلة نص وقيمة تسمح لك بالحصول على اسم مألوف كنص ومعرف كقيمة. مثال على استعلام باسم المضيف كنص ومعرف كقيمة:

SELECT hostname AS __text, id AS __value FROM my_host

http://docs.grafana.org/features/datasources/mysql/#query -variable

أود أن أقترح المتغير المخصص ليكون:

[{
      "__text": "Server 1",
      "__value": 1
  },
  {
      "__text": "Server 2",
      "__value": 2
  }
]

ربما نوع جديد يسمى JSON؟

لا أستخدم MySQL أو PostgreSQL. يجب أن تكون هذه إحدى ميزات Grafana. لا
نوع من الاختراق.

شكرا!

El jue.، 27 de sep. دي 2018 05:52، محمد هندري [email protected]
escribió:

dmayan https://github.com/dmayan تم الرد عليه. يمكنك استخدام هذا.

يعمل هذا مع MySql و PostgreSQL:

خيار آخر هو الاستعلام الذي يمكنه إنشاء متغير مفتاح / قيمة. الاستعلام
يجب أن يُرجع عمودين يسمى __text و __value. النص
يجب أن تكون قيمة العمود فريدة (إذا لم تكن فريدة ، تكون القيمة الأولى
تستخدم). سيكون للخيارات الموجودة في القائمة المنسدلة نص وقيمة تسمحان بذلك
يجب أن يكون لديك اسم مألوف كنص ومعرف كقيمة. مثال
الاستعلام باسم المضيف كنص والمعرف كقيمة:

حدد اسم المضيف AS __text ، معرف AS __value من my_host

http://docs.grafana.org/features/datasources/mysql/#query -variable

أود أن أقترح المتغير المخصص ليكون:

[{
"__text": "Server 1"،
"__value": 1
} ،
{
"__text": "Server 2"،
"__value": 2
}
]

ربما نوع جديد يسمى JSON؟

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/grafana/grafana/issues/1032#issuecomment-425011676 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AWcYqEwxjXiXE07uM0ZG-A284TghEIR2ks5ufJG4gaJpZM4C4cjS
.

ميزة مفيدة جدًا ، إذا كانت هذه الميزة موجودة ، فقد تساعدنا كثيرًا هنا. لأن الجرافيت لا يمكنه تخزين الأحرف الصينية. لذلك علينا استخدام اللغة الإنجليزية في الجرافيت ، لكننا نرغب حقًا في إظهار اللغة الصينية في لوحة معلومات grafana ، لذلك ستكون تجربة المستخدم أفضل بكثير.

نأمل أن تتحقق هذه الميزة قريبًا.

تمكنت من إجراء تعيين المعرف> الاسم باستخدام متغيرين. يسرد المتغير الأول جميع المعرفات الممكنة (القيمة) بينما يسرد المتغير الثاني الاسم (نص العرض) الذي يطابق المعرف. إنها ليست مثالية أو جميلة ، لكنها تؤدي الغرض.

أعتقد أنها تسمى متغيرات متداخلة . وبعد ذلك يمكنك إخفاء أحد محددات المتغيرات.

+1

+1

FdeFabricio هل استخدمت InfluxDB؟ هل يتم تحديث إحدى القيم تلقائيًا عند تغيير الأخرى؟ إذا كان الأمر كذلك، كيف يمكنك أن تفعل ذلك؟

اضحك

هل استخدمت InfluxDB؟

نعم

هل يتم تحديث إحدى القيم تلقائيًا عند تغيير الأخرى؟

نعم

إذا كان الأمر كذلك، كيف يمكنك أن تفعل ذلك؟

تقوم بإنشاء متغير نوع الاستعلام الذي يحدد العنصر الذي يطابق القيمة المحددة بالفعل (على سبيل المثال SELECT "name" FROM playlists WHERE ("id" =~ /^$playlist_id$/) . لذا سيكون لديك الآن متغيرين: أحدهما بالمعرف والآخر بالاسم.

يمكنك أيضًا القيام بذلك بالعكس :

• متغير مرئي يتيح لك تحديد اسم قائمة التشغيل (مثل Girl Power)
• متغير مخفي ، يبحث عن معرف قائمة التشغيل من الاسم (شيء مثل SELECT "id" FROM playlists WHERE ("name" =~ /^$playlist_name$/) )

بهذه الطريقة ، يرى المستخدمون لديك خيارًا لتحديد قائمة التشغيل حسب اسمها ، لكن معرّف قائمة التشغيل مخفي. لا يزال بإمكانك الوصول إلى معرف قائمة التشغيل برمجيًا للبحث عن عناصر قائمة التشغيل ، إلخ.

لا يزال بناء الجملة __name و __value من مصدر بيانات PostgreSQL / MySQL مثاليًا ، لأنه يمنع أي غموض في الاسم ، ويقلل من عدد استعلامات قاعدة البيانات المطلوبة. يجب أن تكون ميزة أساسية IMO.

لقد وجدت حلاً آخر بناءً على تعليق johnymachine أعلاه. هناك دعم لهذا في بعض مصادر البيانات. إذا لم يكن مدعومًا في مصدر البيانات ، يمكنك إنشاء قاعدة بيانات MySQL وإضافة البيانات هناك وكتابة استعلام لإرجاع __value و __text. يعمل هذا إذا كانت البيانات ثابتة ، في حالتي (الحالة الجغرافية). بالنسبة لأي شخص يريد هذه الميزة للمتغيرات المحددة على أنها مخصصة ، فأنا أعتقد أن هذا حل جيد وربما حل أفضل على أي حال. يسمح بتخزين جميع القوائم المتغيرة في مكان واحد وتغييرها بسهولة أكبر. الجانب السلبي فقط هو أنه يتطلب تثبيت MySQL.

حدد SingleChar AS __value، ShortName AS __text من TSDB. State

يجب أن أضيف هذا الحل يعمل مع الرسوم البيانية المتكررة والصفوف المتكررة وأيضًا إذا كان المتغير متعدد التحديد. المثال أعلاه باستخدام متغيرين لإظهار "Girl Power" لا يعمل في هذه المواقف.

كنت أتعامل مع هذه المشكلة للتو ووجدت حلًا بديلًا إلى حد ما ...
كنت بحاجة إلى تجزئة ، يتم كتابتها في لغة Perl على النحو التالي:
Perl %units = ( 'μSv/h' => 1.0, 'mrem/h' => 0.1 );
لقد أنشأت متغير لوحة القيادة Type : Custom ، Values separated by comma : mrem/h, μSv/h ثم قمت بتعديل JSON Model على هذا النحو:
JSON { "allValue": null, "current": { "tags": [], "text": "mrem/h", "value": "0.1" }, "hide": 0, "includeAll": false, "label": null, "multi": false, "name": "units", "options": [ { "selected": true, "text": "mrem/h", "value": "0.1" }, { "selected": false, "text": "μSv/h", "value": "1.0" } ], "query": "mrem/h, μSv/h", "skipUrlSync": false, "type": "custom" }

بينما يعمل هذا (لبعض الوقت) ، فإن تحرير لوحة القيادة عبر واجهة المستخدم الرسومية يغيرها مرة أخرى إلى حالة عدم العمل: - |

خيار آخر للتغلب على هذا إذا كان لديك نظام آخر يمكنه توفير البيانات:

استخدم مكونًا إضافيًا لمصدر بيانات JSON ، أنا أستخدمه: https://grafana.com/plugins/simpod-json-datasource

نفذ فقط نقطة نهاية فحص الصحة / ونقطة النهاية /search في بعض الأنظمة التي تحتوي على البيانات المطلوبة. يجب أن تعرض نقطة النهاية /search JSON الذي يبدو مثل: [{ "text": "A Human Name", "value": "123456" }, ...] . ستكون الخاصية text هي ما يظهر في القائمة المنسدلة لتحديد المتغير وستكون الخاصية value هي ما يتم استخدامه في استعلام المقاييس.

ثم قم بإعداد متغير لوحة القيادة للاستعلام عن مصدر البيانات الجديد هذا ، إنه نوع من الاختراق ولكن يمكنك استخدام حقل target لمصدر البيانات لإخبار الواجهة الخلفية بما يجب أن تعود إذا كان لديك مجموعات بيانات متعددة تريد استخدامها معها.

+1 على هذا. أود حقًا طريقة للقيام بذلك ، ولكن طريقة لا تعتمد على الواجهة الخلفية (نستخدم الجرافيت).

+1 أي حل عملي؟

@ BlackRider97 يرجى إلقاء نظرة على التعليقات أعلاه - هناك العديد من الحلول العملية لـ PostgreSQL (وربما MySQL و MSSQL وما إلى ذلك).

الحل 1: https://github.com/grafana/grafana/issues/1032#issuecomment -409124505

الحل 2: https://github.com/grafana/grafana/issues/1032#issuecomment -453242766

سيكون تنفيذ الحل البديل من thinrope بشكل صحيح بمثابة إصلاح أنيق حقًا.
إذا تمكنا من استخدام JSON في متغير مخصص ، أو كان لدينا نوع متغير "JSON" ، فيمكننا حل هذا بدون اختراق ولا أرى أي عيوب.

+1 أي تحديث على هذا؟

+1

+1

هذا بالتأكيد يجب أن يكون ميزة.
أستخدم متغيرات لتصفية بعض المضيفين باستخدام regex على اسم المضيف. نظرًا لأن خوادمي تحتوي على أنماط في اسم المضيف ، يمكنني الحصول على regex للحصول على قائمة بجميع خوادم مجموعة معينة. بدلاً من إظهار regexp قبيح ، أود عرض اسم جميل ، مثل "خوادم المجموعة أ" كتسمية من القائمة المنسدلة.

يمكن أن تكون طريقة إدخال هذا في القيمة المخصصة بسيطة مثل:
label1:value1, value2, label3:value3, label5:value5

ستكون التسمية اختيارية. إذا كان : موجودًا في سلسلة ، فإن كل شيء قبل : هو التسمية وكل ما يليه هو القيمة.
يجب أن يكون لدينا طريقة للهروب من : إذا احتجنا إليها في اسم التصنيف أو القيمة ، كما يمكننا أن نفعل مع الحرف , .

خيار آخر للتغلب على هذا إذا كان لديك نظام آخر يمكنه توفير البيانات:

استخدم مكونًا إضافيًا لمصدر بيانات JSON ، أنا أستخدمه: https://grafana.com/plugins/simpod-json-datasource

نفذ فقط نقطة نهاية فحص الصحة / ونقطة النهاية /search في بعض الأنظمة التي تحتوي على البيانات المطلوبة. يجب أن تعرض نقطة النهاية /search JSON الذي يبدو مثل: [{ "text": "A Human Name", "value": "123456" }, ...] . ستكون الخاصية text هي ما يظهر في القائمة المنسدلة لتحديد المتغير وستكون الخاصية value هي ما يتم استخدامه في استعلام المقاييس.

ثم قم بإعداد متغير لوحة القيادة للاستعلام عن مصدر البيانات الجديد هذا ، إنه نوع من الاختراق ولكن يمكنك استخدام حقل target لمصدر البيانات لإخبار الواجهة الخلفية بما يجب أن تعود إذا كان لديك مجموعات بيانات متعددة تريد استخدامها معها.

لقد قمت بهذا التنفيذ وهو يعمل بالنسبة لي ، لكنني عالق في وضع العلامات على الاتجاه (وسيلة إيضاح) ... أحصل على معرف (رقم) أو غير محدد أو غير ذي معنى.
هل تستطيع أن تنصح؟

م

+1

أنا أستخدم الآن JSON-hack الموصوف بواسطة @ mbell697 في Grafana لشركتي. ولكن يبدو أن هناك IMHO مشكلة regex غريبة.

قمت بإعداد تطبيق python flask صغير يوفر لي المجموعات المطلوبة لاستعلامات Graphite تبدو بيانات البحث الخاصة بي

@app.route('/search', methods=['POST'])
def search():
    data = [
        {"text": "fs-servers", "value": "{FS-server-1,FS-server-2,FS-server-3}"},
        {"text": "db-a-servers", "value": "{db-server-1,}"},
        {"text": "db-b-servers", "value": "{db-server-2,db-server-3}"}
    ]
    return jsonify(data)

لذلك في لوحة القيادة ، قمت بإنشاء متغير استعلام يسمى "group" باستخدام json-source ثم حاولت التصفية لمجموعة "fs-servers" مع حقل regex باستخدام /fs-.*/ - لكن هذا لا يعمل كما هو متوقع - بعد التلاعب ، أدركت أن التعبير العادي يتم تطبيقه بطريقة ما على "القيمة" - وليس على حقل "النص". هل لدى أي شخص ربما بعض الحلول أو الفكرة؟

+1

+1

رأيي في متطلبات هذا:

في حالتنا أفكر في نوعين مختلفين من الشيء نفسه. ما نريده هو في الأساس أسماء مستعارة. في كلتا الحالتين ، يريد مالك لوحة المعلومات تزويد المستخدم بقائمة متغيرة للقالب يسهل على المستخدم النهائي فهمها. ومع ذلك ، فإن القيمة المستخدمة في الاستعلام هي القيمة الأساسية.

مثال 1 - تحويلات بسيطة من اسم واحد إلى اسم واحد. لذلك في هذه الحالة ، لدينا رموز بلد رقمية منشورة كقيم مترية. لكن اعرف واحد يحفظ الرموز الرقمية. لذلك نريد عرض "الولايات المتحدة" أو "كندا"

{"الولايات المتحدة" == "01"}
{"كندا" == "02"}

إذا تم تحديد "كندا" ، فإن قيمة متغير القالب التي تم تمريرها إلى أي استعلام هي "02"

المثال 2 - تعيين واحد إلى كثير. داخليًا ، لدينا مراحل للنشر ، على سبيل المثال s0 ، s1 ، s2 ، s3 ، s4. ومع ذلك ، يمكن للمستخدمين استخدام هذا كـ "dev، beta، prod"
لذلك يريدون تعيينهم على النحو التالي:

{"dev" == ["s1"]}
{"بيتا" == ["s2"، "s3"]}
{"prod" == ["s4"، "s5"، "s6"]} أو الأفضل من ذلك "prod" == s [456]

لذلك إذا تم تحديد "prod" يتم تمرير "s4، s5، s6" إلى الاستعلام

من منظور الاستعلام (أخذ المثال 2) حيث يكون اسم المتغير هو stageVar
واسم علامة المقياس هو المرحلة:

لا نرى الكثير من الحاجة إلى الاسم المستعار عن طريق () مثل المكالمات ولكن المزيد من الأشياء مثل:
المرحلة = ~ $ {stageVar. القيمة: regex }
الاسم المستعار (stageVar.label $)

لتصفية النتائج حسب القيم المتغيرة للقالب المحدد. من الممكن بالتأكيد أن يحاول شخص ما استخدامه في شيء مثل الاسم المستعار بواسطة () وظيفة ولكن إذا كان خطأ نحوي فلا بأس بذلك. لا أتوقع منك الإصلاح السحري لتحويل مصفوفة تم تمريرها إلى دالة تتوقع قيمة واحدة.

بالنسبة للتعيينات ، أعتقد أن تحديد المستخدم لها بشكل ثابت كافٍ.
من الناحية المثالية ، سيكون لديك استعلام إلى MT للحصول على قائمة القيم التي يجب تعيينها ، بالنسبة لك ، على سبيل المثال "01" ، "02" ، "03" ومن ثم سيكون من السهل إضافة التعيينات / الأسماء المستعارة. ستنتقل القيم غير المعينة إلى مجموعة "افتراضية".

+1

+1

أنا مندهش جدًا من عدم إدراج هذا - لقد قضيت وقتًا طويلاً في محاولة اكتشاف كيفية عمل هذا الشيء "الواضح" وفي النهاية وجدت طريقي هنا لاكتشاف عدم وجوده.

ستكون القدرة على إعادة الكتابة ديناميكيًا كما هو موضح من قبل البعض أعلاه رائعة. ومع ذلك ، سأكون سعيدًا بالاختراق قصير المدى (أو النموذج "السهل" الدائم) وهو نسخة موسعة من الحقل "مخصص" ، والتي تم تعيينها بشكل ثابت إلى نتائج اختيارات فردية أو متعددة.

مثالنا هو رموز الدول. غالبًا ما نرغب في عرض مجموعات الأنظمة بناءً على المناطق الجغرافية ، ولكن ليس حسب البلد. لكننا نقوم فقط بتخزين رموز البلدان كمفاتيح في خادم Prometheus الخاص بنا. لذا في الوقت الحالي ، إذا كنت أرغب في عرض جميع الأنظمة في أمريكا الشمالية ، فلا بد لي من تحديد US ، CA ، MX يدويًا من قائمة الخيارات المستندة إلى الاستعلام من حوالي 100 دولة. لا أستطيع حتى أن أخبرك كم من الوقت أقضيه في اختيار كل بلد في أوروبا ، أو آسيا ، أو أفريقيا لإجراء التحليل. يكاد يكون من المفيد إنشاء لوحات معلومات مختلفة تمامًا لكل منطقة ، وهو أمر سخيف ولكنه الطريقة الوحيدة لحل المشكلة بدون الرسوم البيانية ذات الترميز الثابت. يبدو أن إنشاء قاعدة بيانات جديدة تمامًا باستخدام التعيينات ثم إجراء استعلامات مخفية بعيد جدًا عن المثالية.

حلمي الحمى:
يبدو أن هذا سيكون خيار "قائمة مخصصة" كنوع جديد محتمل من المتغيرات. ستبدأ القائمة المخصصة فارغة إذا تم تحديدها ، لكنها ستبدو إلى حد كبير مثل النموذج "المخصص" الذي يبدو اليوم. سيظهر زر "إضافة". سيؤدي النقر فوق "إضافة" إلى إنشاء مصفوفة إدخال ذات حقلين مع "عرض القيمة:" و "قيمة البحث:" حيث يمكن ملء كل منهما. ستكون "قيمة العرض" هي كل ما يريد المستخدم إظهاره في قائمة الاختيار - في حالة "أمريكا الشمالية". عندئذٍ ستكون "قيمة البحث" هي ما سيتم تقديمه في طلب البحث - مرة أخرى ، في هذا المثال لأمريكا الشمالية ستكون "us، ca، mx". في أي وقت ، رمز "حذف" (سلة المهملات؟) يمكن أن يكون بعيدًا عن الخطوط الفردية. سيؤدي النقر فوق الزر "إضافة" مرة أخرى إلى إنشاء اقتران جديد ، حتى يكمل المستخدم قائمة الخيارات الخاصة به. سيظل الخياران "متعدد القيم" و "تحديد الكل" ، على غرار النموذج المخصص الحالي.

أنا مندهش جدًا من عدم إدراج هذا - لقد قضيت وقتًا طويلاً في محاولة اكتشاف كيفية عمل هذا الشيء "الواضح" وفي النهاية وجدت طريقي هنا لاكتشاف عدم وجوده.

لقد قمت بحل هذا من خلال إنشاء قاعدة بيانات MySQL ، وقمت بإنشاء جدول بالعناصر التي أريدها في القائمة المنسدلة ، مثل أوروبا وأمريكا الشمالية وما إلى ذلك. ثم أضف MySQL كمصدر بيانات واستخدمها لإنشاء المتغيرات. إنه اختراق ولكنه في الواقع يعمل بشكل جيد. أنا أستخدمه إلى حد كبير للشيء المحدد الذي تحاول القيام به.

أنا أقدر الاختراق الذكي ، لكنه ليس حلاً بالنسبة لنا حقًا. إن إنشاء قاعدة بيانات جديدة تمامًا (لا نستخدم MySQL على الإطلاق ، مما يعني أن هذا مستحيل عمليًا) لإجراء استبدال بسيط للمفتاح / القيمة وهو ثابت تمامًا يبدو وكأنه الكثير من الأطواق للقفز من خلالها.

كنت أفكر في هذا أكثر قليلاً ، وهناك طريقة أكثر أناقة لتوفير هذه الوظيفة مما وصفته أعلاه. سأسميها "ماكرو متغير". يبدو هذا مرة أخرى كقائمة مخصصة ، إلا أنه يسمح للمسؤول بتحديد أنه عند تحديد واحد (أو أكثر) من وحدات الماكرو هذه ، سيتم تعيين المتغيرات المسماة ، وسيتم إلحاق القيم المعطاة بمجموعة القيم الحالية. سيكون هذا نموذجًا يحركه UI بالكامل ، ولن يغير مفهوم المتغير الفعلي على الإطلاق - سيؤدي فقط إلى إنشاء طبقة سكر للإكمال التلقائي أعلى المتغيرات الحالية. هذا يجعلها متوافقة مع الإصدارات السابقة مع عدم الحاجة إلى متغيرات إضافية للإنشاء أو التكامل في الاستعلامات.

سيسمح الماكرو الذي يعيّن المتغيرات للمستخدم برؤية القيم أثناء تحديدها ، ثم يسمح للمستخدم بفتح كل متغير ورؤية / معالجة التحديدات أو البيانات بدلاً من إنشاء متغير منفصل كتعليقاتي السابقة لمح. سيكون هذا أكثر سهولة.

مثال:

لذا فإن ماكرو متغير يسمى "North America - Primary Cluster" سيعيّن متغيرات "Country" الخاصة بي على "us، ca، mx" وسيحدد "Cluster:" متغير إلى "أساسي". ستكون هذه الإعدادات مرئية إذا كنت سأقوم بسحب كل متغير مسمى (أو لا ، إذا كانت مخفية) حتى أتمكن من إضافة أو طرح البلدان إلى قائمة البلد: طالما أنني لم ألمس متغير ماكرو المنسدلة مرة أخرى.

من المحتمل وجود قيمة منطقية لـ "مسح المتغيرات المسماة قبل الإعداد" بحيث إذا تم إجراء تغيير في قائمة الاختيار لهذا الماكرو ، فسيتم مسح أي إعدادات أخرى للمتغيرات المحددة. قد يكون هذا مفيدًا للقوائم التي لا يكون من الواضح فيها أنك قد تتضمن شيئًا تم تعيينه مسبقًا. أفترض أنه إذا تم اختيار أكثر من خيار ماكرو متغير واحد ، فإن الخيار الأخير في القائمة التي سيتم فحصها "يفوز" إذا كانت هناك إعدادات منافسة ذات قيمة معينة ؛ بأي حال من الأحوال حول هذه المشكلة. (يمكن القول إن إجراء المقاصة هذا يجب أن يتم تحديده على أساس متغير حسب المتغير ، ولكن يبدو أن هذا يبدو مشوشًا بعض الشيء ... لكن هل هو كذلك؟)

هذا هو المثال الافتراضي الخاص بي مرة أخرى ، حيث لدي متغيرات موجودة مسبقًا من "البلد" و "الكتلة".

اسم الماكرو المتغير: المنطقة

Name1: أمريكا الشمالية - الكتلة الأولية
مسح المتغيرات المسماة قبل الإعداد: Y
المتغير 1: الدولة
القيمة 1: لنا ، كاليفورنيا ، مكس
المتغير 2: الكتلة
Value2: أساسي

Name2: دول الشمال - الكتلة الثانوية
مسح المتغيرات المسماة قبل الإعداد: Y
المتغير 1: الدولة
Value1: se، fi، no، dk، is
المتغير 2: الكتلة
Value2: ثانوي

أنا أقدر الاختراق الذكي ، لكنه ليس حلاً بالنسبة لنا حقًا. إن إنشاء قاعدة بيانات جديدة تمامًا (لا نستخدم MySQL على الإطلاق ، مما يعني أن هذا مستحيل عمليًا) لإجراء استبدال بسيط للمفتاح / القيمة وهو ثابت تمامًا يبدو وكأنه الكثير من الأطواق للقفز من خلالها.

كنت أتوقع أن تقول شيئًا كهذا. الحقيقة هي أنك طلبت اختراقًا وهذا الاختراق يحل المشكلة ، وليس من الصعب إعداده وليس من الصعب عكسه في المستقبل. أجد أنه من السهل جدًا امتلاك MySQL هناك حيث نستمر في إضافة مجموعات بيانات جديدة إليها ، إنه مكان مناسب لتتبعها وتحديثها. إذا فكرت في الأمر ، إذا كنت ستستخدم مجموعات البيانات هذه في لوحات معلومات متعددة وتريد الاحتفاظ بها مركزيًا ، فيجب تخزينها في مكان ما. إذا لم تتمكن قاعدة بيانات السلاسل الزمنية الخاصة بك من تخزينها ، فأنت بحاجة إلى إعداد شيء لتخزينها. لذلك من المنطقي تمامًا أن يكون لديك MySQL. المكافأة المضافة هي أيضًا أنه من السهل جدًا أتمتة سكان MySQL.

إذا كان لديك PostgreSQL ، فلن تحتاج إلى إنشاء جدول فعلي لرسم الخرائط ، يمكنك القيام بشيء مثل:

SELECT *
FROM
(
    VALUES
        ('London server 1', 'london_srv_1'),
        ('London server 2', 'london_srv_2'),
        ('New York server 1', 'ny_srv_1'),
        ('New York server 2', 'ny_srv_2')
) AS t (__text, __value)

لكنها لا تعمل مع القيم الرقمية:

حدد * من (VALUES ('OK'، '0')، ('ERROR'، '1')) AS t (__text، __value)

عند تحميل لوحة القيادة:

وعند اختيار معلمة أخرى

عند التحديد: موافق + خطأ

إذا كنت تريد قيمًا رقمية ، فأنت بحاجة إلى إزالة علامات الاقتباس المفردة ، وإلا فسيتم تفسيرها على أنها نص ، على سبيل المثال

SELECT * FROM ( VALUES ( 'OK', 0), ( 'ERROR', 1) ) AS t (__text, __value)

شكرًا GlennMatthys جلين على الإجابة ، لكنني وجدت بالفعل مكان حدوث المشكلة.

حدد * من (VALUES ('OK'، 0)، ('Warning'، 1)، ('Critical'، 2)) AS t (__text، __value)

تكوين القيمة المتعددة على:

يحدث ذلك

اختيار 3 ولايات

ومتعددة القيم قبالة:

جلين ماتيس - الحل المثالي ، شكرًا جزيلاً

بالنسبة لـ MySQL:
SELECT * FROM ( VALUES row('a', 1), row('b', 2) ) AS t (__text, __value)

ماذا عن مريض؟ إنه لا يعمل معي (إصدار mariaDB: 10.5.5)

SELECT * FROM ( VALUES row('a', 1), row('b', 2) ) AS t (__text, __value);
ERROR 1064 (42000)..............

أو الذي سبقه:

SELECT * FROM ( VALUES ( 'OK', 0), ( 'Warning', 1), ('Critical', 2) ) AS t (__text, __value);
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your 
MariaDB server version for the right syntax to use near '(__text, __value)' at line 1

يبدو أن بيان القيم لم يعد متاحًا ...

أم أن هناك شيئًا آخر أخطأتُ فيه؟

radoeka للأقدم MariaDB / MySQL

SELECT * FROM
(
    SELECT 'London server 1' AS '__text', 'london_srv_1' AS '__value'
    UNION ALL SELECT 'London server 2', 'london_srv_2'
    UNION ALL SELECT 'New York server 1', 'ny_srv_1'
    UNION ALL SELECT 'New York server 2', 'ny_srv_2'
) AS t;

GlennMatthys نجاح باهر نجاح باهر ، يا لها من استجابة سريعة! وهذا يعمل.
اعتقدت أنني كنت أدير إصدارًا جديدًا إلى حد ما من mariadb ، لكن هذا ليس هو الحال (باستخدام توزيعة لينكس عمرها شهرين فقط).
شكرا.

يبدو أن هذا غير مدعوم لبروميثيوس.

إعادة فتح هذه المشكلة كـ # 27829 يحل هذا فقط للبيانات الثابتة.