Grafana: Permitir el mapeo personalizado del valor de la variable de la plantilla -> mostrar texto

Podría hacer esto con tableros con secuencias de comandos. Pero lo invitamos a intentar implementarlo en paneles json regulares/guardados.

+1

Yo también podría usar al menos una versión más simple de esto. Algo así como un mapeo configurado de A -> B

En mi escenario, quiero seleccionar un nombre de entidad en el menú desplegable de variables (CustomerName1, CustomerName2, etc.) pero usar una identificación numérica internamente cuando se trata del nombre de la métrica.
aplicación.solicitudes.$cliente1_ID.recuento

+1

Fusionando desde #3138

Por ejemplo, al crear una variable de plantilla personalizada con valores fooBar y baz_quuxInternal , para poder hacer que la interfaz de usuario muestre las casillas de verificación como "Foo bar" y "Baz".

Esto es especialmente común cuando se usan filas repetidas y una variable personalizada para reducir la duplicación, pero es posible que las métricas de nivel superior no sean fáciles de usar.

Potencialmente, también se podría admitir esto para los valores de plantilla consultados (por ejemplo, propiedades de grafito) mediante el uso de una expresión regular (si el reemplazo es genérico). La compatibilidad con expresiones regulares ya existe, pero se aplica tanto al valor utilizado como a la etiqueta. Tenerlo usado solo por el valor sería valioso.

Por ejemplo, si una consulta de grafito expande kafka.messagesByTopic.myservice_* para usar en plantillas, es posible que desee que la interfaz de usuario elimine el prefijo. Pero cuando se usa en los paneles reales, se debe incluir el prefijo. Esto se puede solucionar (en Grafana 2.x y versiones posteriores) ahora que las variables de plantilla se pueden incrustar en una propiedad de métrica, por lo que se podría codificar el prefijo en todas las métricas en todos los paneles y filas, pero es mejor evitarlo.

Una vez que existan estos valores de "etiqueta", sería útil poder acceder a ellos también dentro de los paneles. Tal cuando se incrusta una variable en un título de Fila y/o Panel. O podemos hacer que use la etiqueta de forma predeterminada (si está incrustada en un campo de título), o quizás con alguna sintaxis alternativa (por ejemplo $$Variable , o lo que sea)

http://play.grafana.org/dashboard/db/test?editview=templating muestra "Etiqueta de variable" como una opción. se puede cerrar esto?

EDITAR: No entendí bien el error, ¡lo siento! :) Seguir adelante.

esa es solo una opción para tener un nombre amigable para la variable, no los valores de la variable

+1

+1

+1

+1

+1

+1

¿Cuál es el estado de esto?
¿Es posible hacerlo?

¿Es esto posible para la 3.0 final?
Parece una función que mucha gente está esperando. Incluyéndome a mí :-)

+1
Normalmente uso parte de las expresiones regulares que se ven horribles para los usuarios.

+1

+1

+1
Sin esto, las expresiones regulares no se pueden utilizar en las variables de plantilla.

+1

+1

+1

+1

+1

+1

@mbell697 @torkelo

Implementé esto para un servicio interno que usa Grafana. Como usamos uuids para hosts (para que un cambio en el nombre de host no pierda el historial de métricas y otras cosas), era inaceptable mostrar esos uuids al usuario. Hice un parche específico para nuestro caso de uso en el que detectamos valores de uuid y los traducimos usando un extremo http de nuestra aplicación. Eso está funcionando bien para nosotros, pero preferiría hacer algo que sea genérico y aceptado en sentido ascendente.

¿Sería aceptable agregar una opción 'variable_translation_url' que apunte a una URL que pueda realizar el mapeo? (con un token de autorización opcional si es necesario) o una variable_translation_script que apunta a javascript src que se puede descargar y conectar a templateValuesSrv.js en los puntos donde se requiere la traducción (si esa opción está configurada)?

¿Puede compartir su código templateValuesSrv.js? quiero probarlo

@ZhuWanShan Esto es básicamente todo:

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

Tenga en cuenta que verá 2 enfoques allí. El primero pretendía ser más general, introduciendo un nuevo tipo de variable de plantilla 'http', con una propiedad de 'consulta' que apunta a una URL HTTP para realizar el mapeo (ver _getHttpVariableOptions). Más tarde, implementé un segundo método que detecta si un texto de opción (valor de visualización) coincide con una expresión regular de UUID, y fuerza el mapeo de cualquier variable que use una llamada HTTP codificada a /api/v1/nodes/grafana-hosts/ que devuelve el mapeo de todas las opciones. Eso ha funcionado bien hasta ahora, solo necesita tener instrucciones sobre cómo convertir esto en un método genérico.

+1

+1

Para cualquiera que esté interesado, pude resolver mi caso de uso particular usando el complemento Simple JSON Datasource .

Dicho esto, el complemento actualmente no admitía consultas de variables de plantilla, pero mi solicitud de extracción que soluciona el problema se ha fusionado con el maestro. Una versión actualizada de Grafana.net del complemento debería seguir en algún momento.

Con él, puede usar puntos finales HTTP personalizados como fuentes de datos en Grafana. Solo tienen que implementar 4 métodos . Cuando se usa con variables de plantilla basadas en consultas, el extremo HTTP recibirá una solicitud de API /search y el cuerpo será un objeto JSON con el formato: { "target": "{template query content here}" } . Puede analizar el contenido de la consulta como desee.

Devolver una matriz de valores desde su punto final creará una lista subyacente de valores de variables de plantilla ["custom value 1", "custom value 2"] en forma de: [{ "text": "custom value 1", value: 0 }] donde la propiedad text es el valor devuelto por elemento de la matriz y la propiedad value es el índice de la variable en la matriz de retorno.

Alternativamente, puede devolver una matriz de objetos de texto/valor [{ "text": "label", "value": 123 }] y Grafana usará la propiedad text como la etiqueta de la variable de plantilla, y la propiedad value como el valor bruto de la variable de la plantilla.

Es posible inyectar dinámicamente otras variables de plantilla en la consulta en forma de expresión regular y enviarlas dinámicamente al punto final para su procesamiento.

Esto no resolverá todos los escenarios de creación de alias, pero tener una fuente de datos HTTP arbitraria que se pueda usar para variables de plantilla, incluida la inyección dinámica de otras variables de plantilla en la consulta de plantilla, es una buena herramienta.

Soy humano.

+1

+1

+1

+1

+1

+1

+1000

+1

+2

Sería inmensamente útil tener esto. En efecto, tengo un montón de objetos que tienen un nombre y un uuid. Me gustaría mostrar el nombre, pero almacenar el uuid en la variable.

Sería genial si pudiéramos hacer algo como tener:

Consulta (existente): MOSTRAR VALORES DE ETIQUETA DE "vcd_vm" CON CLAVE = "uuid" donde "OrgVdc" =~ /^$vDC$/)

Etiqueta (nueva): MOSTRAR VALORES DE ETIQUETA DE "vcd_vm" CON CLAVE = "nombre" donde "uuid" =~ /^$etiqueta$/)

+1

+1

+1

+1

+1

+1

+1

Sería genial si la variable de plantilla 'Personalizada' tomara como entrada una lista de 'valores' y una lista de 'etiquetas' (esencialmente, un hash/dict personalizado)

+1

+1

Esto sería útil para los datos de AWS CloudFront, tal como los exporta el exportador oficial de CloudWatch. Los datos de CloudFront se muestran mediante ID, que no utiliza ninguna persona. Mucho más fácil para los humanos que miran gráficos para ver "foo.example.com; bar.example.com" en lugar de "EAUUWLGUQEPFWV; EVWWU9PGWIB"...

+1

En primer lugar, ¡gracias por desarrollar un producto increíble y compartirlo con el mundo!

¿Alguna indicación sobre la probabilidad de que esto se implemente en los próximos meses? Solo estoy tratando de sopesar hasta qué punto tiene sentido seguir adelante e implementar la solución alternativa sugerida por @meverett o esperar esto.

Implementar esto a través de un punto final HTTP es una buena solución para una versión muy generalizada de este problema, pero parece una exageración para muchos de los casos de uso descritos aquí (incluido el mío) donde todo lo que se necesita es un mapeo estático básico en un número modesto de "amigables". pares de nombre para mostrar" -> "nombre de base de datos no descriptivo".

@svet-b fwiw, nos movimos para usar la sugerencia de @meverett y fue indoloro y limpio. Solo unas pocas horas para construir el complemento de fuente de datos.

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

La solución alternativa de @meverett funciona bastante bien, pero se queda corta cuando se usa con variables de valores múltiples porque la serie solo se puede etiquetar con etiquetas de (en mi caso) influxdb. ¿Alguna sugerencia para soluciones allí? :)

+1

+1

+1

+1

+1

Hola a todos, dado que este problema se soluciona con bastante frecuencia, decidí crear una aplicación web Node.js de ejemplo que usa mi solución anterior .

Es bastante básico, pero implementa completamente el patrón que menciono en mi comentario original. Y si puede arreglárselas colocando sus datos de búsqueda en un solo archivo JSON que no se actualizaría muy a menudo, podría funcionar de manera inmediata para usted.

De lo contrario, puede usarlo como punto de partida y extenderlo para acceder a sus datos de alias desde cualquier fuente que desee (programado por usted, por supuesto) y servirlo a través de la aplicación de tal manera que el complemento de fuente de datos SimpleJson pueda consumirlo y se puede usar para controlar el mapeo/aliasing de variables de plantilla.

El repositorio de la aplicación web de ejemplo está aquí .

Espero eso ayude. He recibido algunas solicitudes de vez en cuando pidiendo más ayuda/explicaciones para configurar la solución.

Salud

+1

+1

Gracias por su solución improvisada, @meverett . Creé un repositorio con Dockerfile para crear un contenedor Docker para ejecutar su solución. Está configurado para tomar un data.json personalizado junto con el Dockerfile en el momento de la compilación. Espero que ayude a la gente:

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

+1

+1

+1

Cuando desee hacer +1 en esto, tenga en cuenta que molestará a las 74 personas que actualmente están suscritas a este problema y esperan que alguien dé un paso adelante e implemente una solución.
GitHub agregó reacciones por una razón...

+1

+1

+1

¡esto sería genial! a tiene una lista de valores numéricos largos, pero debería ser mucho mejor mostrar una etiqueta amigable para los humanos para cada uno que el valor en sí
variable: myListOfLongs {nombre: valor toyota: 122321312332, nombre: valor renault: 6666666}

+1!

+1

+1
Cualquier actualización sobre #11534 (Permitir títulos dinámicos al usar paneles/filas repetidos)

+1

+111111

+1

+1

+1, necesita mucho esta característica.

+1

+1

+1

+1

+1

Esto funciona para MySql y PostgreSQL:

Otra opción es una consulta que puede crear una variable clave/valor. La consulta debe devolver dos columnas denominadas __texto y __valor. El valor de la columna __text debe ser único (si no es único, se usa el primer valor). Las opciones en el menú desplegable tendrán un texto y un valor que le permite tener un nombre descriptivo como texto y una identificación como valor. Una consulta de ejemplo con nombre de host como texto e id como valor:

SELECT hostname AS __text, id AS __value FROM my_host

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

Sugeriría que la variable personalizada sea:

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

¿Quizás un nuevo tipo llamado JSON?

Gracias @johnymachine! Eso funcionó maravillosamente con la fuente de datos PostgreSQL.

Como extensión de esto, ¿hay alguna forma de recuperar la sección __text de la variable? Esto sería realmente útil para repetir gráficos.

Hola @MGinshe , esto funciona bien (muestra el valor de los usos del texto) para mí:

EDITAR: malinterpretó el contexto inicial de este error, ignore el comentario a continuación, estaba más destinado a # 9292

@torkelo @nmaniwa

https://github.com/grafana/grafana/pull/12609 parece implementar lo que la mayoría de la gente pide aquí, ¿algún motivo por el que esté cerrado y nunca se haya fusionado?

No, ese problema se trata de algo totalmente diferente, ¿o se vinculó a un problema incorrecto?

¿Todavía no hay noticias sobre esto? ¡¡Vamos, estamos en 2018!! ¡Gracias!

@dmayan fue respondido por @johnymachine . Puedes usar esto.

Esto funciona para MySql y PostgreSQL:

Otra opción es una consulta que puede crear una variable clave/valor. La consulta debe devolver dos columnas denominadas __texto y __valor. El valor de la columna __text debe ser único (si no es único, se usa el primer valor). Las opciones en el menú desplegable tendrán un texto y un valor que le permite tener un nombre descriptivo como texto y una identificación como valor. Una consulta de ejemplo con nombre de host como texto e id como valor:

SELECT hostname AS __text, id AS __value FROM my_host

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

Sugeriría que la variable personalizada sea:

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

¿Quizás un nuevo tipo llamado JSON?

No uso MySQL ni PostgreSQL. Esta debería ser una característica de Grafana. No
algún tipo de truco.

¡Gracias!

El ju., 27 de sep. de 2018 05:52, Muhammad Hendri [email protected]
escribió:

@dmayan https://github.com/dmayan fue respondido. Puedes usar esto.

Esto funciona para MySql y PostgreSQL:

Otra opción es una consulta que puede crear una variable clave/valor. La consulta
debe devolver dos columnas que se denominan __texto y __valor. El texto
el valor de la columna debe ser único (si no es único, el primer valor es
usado). Las opciones en el menú desplegable tendrán un texto y un valor que permita
debe tener un nombre descriptivo como texto y una identificación como valor. Un ejemplo
consulta con nombre de host como texto e id como valor:

SELECCIONE el nombre de host COMO __texto, id COMO __valor DE my_host

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

Sugeriría que la variable personalizada sea:

[{
"__texto": "Servidor 1",
"__valor": 1
},
{
"__texto": "Servidor 2",
"__valor": 2
}
]

¿Quizás un nuevo tipo llamado JSON?

—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/grafana/grafana/issues/1032#issuecomment-425011676 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AWcYqEwxjXiXE07uM0ZG-A284TghEIR2ks5ufJG4gaJpZM4C4cjS
.

característica bastante útil, si esta característica está disponible, podría ayudarnos mucho aquí. Porque el grafito no puede almacenar caracteres chinos. Así que tenemos que usar inglés en Graphite, pero realmente nos gustaría mostrar el chino en el tablero de grafana, para que la experiencia del usuario sea mucho mejor.

Espero que esta función se haga realidad en breve.

Me las arreglé para hacer el mapeo de ID->nombre usando dos variables. La primera variable enumera todos los ID posibles (valor) mientras que la segunda variable enumera el nombre (texto de visualización) que coincide con el ID. No es el ideal o bonito, pero hace el truco.

Creo que se llama variables anidadas . Y luego puede ocultar uno de los selectores de variables.

+1

+1

@FdeFabricio Usaste InfluxDB? ¿Actualiza automáticamente un valor al cambiar el otro? Si es así, ¿cómo haces eso?

@bassie1995

¿Usaste InfluxDB?

sí

¿Actualiza automáticamente un valor al cambiar el otro?

sí

Si es así, ¿cómo haces eso?

Creas una variable de tipo de consulta que selecciona el elemento que coincide con el valor ya seleccionado (por ejemplo SELECT "name" FROM playlists WHERE ("id" =~ /^$playlist_id$/) . Así que ahora tendrás dos variables: una con el ID y otra con el nombre.

@bassie1995 @FdeFabricio También podrías hacer esto al revés:

• Una variable visible, que le permite seleccionar el nombre de la lista de reproducción (es decir, Girl Power)
• Una variable oculta, que encuentra el ID de la lista de reproducción a partir del nombre (algo así como SELECT "id" FROM playlists WHERE ("name" =~ /^$playlist_name$/) )

De esta forma, sus usuarios verán una opción para seleccionar la lista de reproducción por su nombre, pero la identificación de la lista de reproducción estará oculta. Todavía puede acceder a la ID de la lista de reproducción mediante programación, para buscar elementos de la lista de reproducción, etc.

Sin embargo, la sintaxis __name y __value de la fuente de datos PostgreSQL/MySQL sigue siendo ideal, ya que evita cualquier ambigüedad de id->nombre y reduce la cantidad de consultas de base de datos requeridas. Debería ser una característica básica de la OMI.

Encontré otra solución basada en el comentario anterior de @johnymachine . Hay soporte para esto en algunas fuentes de datos. Si no es compatible con su fuente de datos, puede crear una base de datos MySQL, agregar los datos allí y escribir una consulta para devolver __value y __text. Esto funciona si los datos son estáticos, en mi caso estado (estado geográfico). Para cualquiera que quiera esta función para las variables definidas como personalizadas, creo que esta es una buena solución y posiblemente una mejor solución de todos modos. Permite que todas las listas de variables se almacenen en 1 ubicación y se cambien más fácilmente. El único inconveniente es que requiere instalar MySQL.

SELECCIONE SingleChar COMO __value, ShortName COMO __text FROM TSDB. State

Debería agregar que esta solución funciona para gráficos repetidos, filas repetidas y también si la variable tiene selección múltiple. El ejemplo anterior que usa 2 variables para mostrar "Girl Power" no funciona en estas situaciones.

Estaba jugando con ese problema y encontré una solución un tanto hackinsh ...
Necesitaba un hash, que en notación Perl se escribe como:
Perl %units = ( 'μSv/h' => 1.0, 'mrem/h' => 0.1 );
Creé una variable de tablero Type : Custom , Values separated by comma : mrem/h, μSv/h y luego edité JSON Model así:
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" }

Si bien esto funciona (por un tiempo), editar el tablero a través de la GUI lo vuelve a cambiar a un estado que no funciona :-|

Otra opción para evitar esto si tiene otro sistema que pueda proporcionar los datos:

Use un complemento de fuente de datos JSON, estoy usando: https://grafana.com/plugins/simpod-json-datasource

Implemente solo el punto final de verificación de estado / y el punto final /search en algún sistema que tenga los datos necesarios. El punto final /search debería devolver un JSON similar a: [{ "text": "A Human Name", "value": "123456" }, ...] . La propiedad text será lo que aparece en el menú desplegable de selección de variables y value será lo que se use en la consulta de métricas.

Luego, configure la variable de su tablero para consultar en esta nueva fuente de datos, es un poco complicado, pero puede usar el campo target para la fuente de datos para decirle al backend qué debe devolver si tiene varios conjuntos de datos con los que desea usar esto.

+1 en esto. Realmente me gustaría una forma de hacer esto, pero una que no dependiera del backend (usamos grafito).

+1 alguna solución de trabajo?

@ BlackRider97 Eche un vistazo a los comentarios anteriores: hay varias soluciones que funcionan para PostgreSQL (y probablemente MySQL, MSSQL, etc.).

Solución 1: https://github.com/grafana/grafana/issues/1032#issuecomment -409124505

Solución 2: https://github.com/grafana/grafana/issues/1032#issuecomment -453242766

Implementar la solución alternativa de @thinrope correctamente sería una solución realmente elegante en mi humilde opinión.
Si pudiéramos usar JSON en una variable personalizada, o tener un tipo de variable "JSON", podríamos resolver esto sin trucos y no veo ningún inconveniente.

+1 alguna actualización sobre esto?

+1

+1

Esta es definitivamente una característica imprescindible.
Uso variables para filtrar algunos hosts usando expresiones regulares en el nombre de host. Como mis servidores contienen patrones en el nombre de host, puedo tener una expresión regular para obtener la lista de todos los servidores de un grupo determinado. En lugar de mostrar una expresión regular fea, me gustaría mostrar un nombre bonito, como "Servidores del grupo A" como etiqueta del menú desplegable.

La forma de ingresar esto en valor personalizado podría ser tan simple como:
label1:value1, value2, label3:value3, label5:value5

La etiqueta sería opcional. Si un : está presente en la cadena, entonces todo lo anterior a : es la etiqueta y todo lo que sigue es el valor.
Deberíamos tener una forma de escapar : si lo necesitamos en el nombre o valor de la etiqueta, como podemos hacer para el carácter , .

Otra opción para evitar esto si tiene otro sistema que pueda proporcionar los datos:

Use un complemento de fuente de datos JSON, estoy usando: https://grafana.com/plugins/simpod-json-datasource

Implemente solo el punto final de verificación de estado / y el punto final /search en algún sistema que tenga los datos necesarios. El punto final /search debería devolver un JSON similar a: [{ "text": "A Human Name", "value": "123456" }, ...] . La propiedad text será lo que aparece en el menú desplegable de selección de variables y value será lo que se use en la consulta de métricas.

Luego, configure la variable de su tablero para consultar en esta nueva fuente de datos, es un poco complicado, pero puede usar el campo target para la fuente de datos para decirle al backend qué debe devolver si tiene varios conjuntos de datos con los que desea usar esto.

Hice esta implementación y funciona para mí, pero estoy atascado en el etiquetado de la tendencia (leyenda) ... Obtengo una identificación (número) o no definida o alguna otra tontería.
¿Puedes aconsejarme?

METRO

+1

También estoy usando ahora el JSON-hack descrito por @ mbell697 en Grafana de mi empresa. Pero parece que hay un extraño problema de expresiones regulares en mi humilde opinión.

Configuré una pequeña aplicación de matraz de python que me proporciona los grupos necesarios para las consultas de Graphite, como se ven mis datos de búsqueda

@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)

Entonces, en el tablero, creé una variable de consulta llamada "grupo" usando json-source y luego traté de filtrar el grupo "fs-servers" con el campo regex usando /fs-.*/ , pero esto no funciona como se esperaba, después de jugar, reconocí que la expresión regular se aplica de alguna manera al "valor", y no al campo de "texto". ¿Alguien tiene tal vez alguna solución o una idea?

+1

+1

Mi opinión sobre los requisitos para esto:

En nuestro caso pienso en dos variantes de lo mismo. Lo que querríamos es esencialmente alias'es. En ambos casos, el propietario del tablero quiere proporcionar al usuario una lista de variables de plantilla que sea fácil de entender para el usuario final. Sin embargo, el valor utilizado en la consulta es el valor subyacente.

Ejemplo 1: conversiones de nombre sencillas de uno a uno. Entonces, en este caso, tenemos códigos numéricos de países publicados como valores métricos. Pero sepa que uno memoriza los códigos numéricos. Entonces queremos mostrar "EE. UU." o "Canadá"

{ "EE. UU." == "01" }
{ "Canadá" == "02" }

Si se selecciona "Canadá", el valor de la variable de plantilla que se pasa a cualquier consulta es "02".

Ejemplo 2 - es un mapeo de uno a muchos. Internamente tenemos etapas para el despliegue, por ejemplo, s0, s1, s2, s3, s4. Sin embargo, los usuarios finales pueden usar esto como "dev, beta, prod"
Entonces quieren mapearlos como:

{ "desarrollo" == ["s1"] }
{ "beta" == ["s2", "s3"] }
{ "prod" == ["s4", "s5", "s6"] } o mejor aún "prod" == s[456]

Entonces, si se selecciona "prod", "s4, s5, s6" se pasa a la consulta

Desde una perspectiva de consulta (tomando el Ejemplo 2) donde el nombre de la variable es stageVar
y el nombre de la etiqueta de la métrica es etapa:

No vemos tanto la necesidad de aliasBy() como llamadas pero más cosas como:
etapa=~${etapaVar. valor: expresión regular }
alias($etapaVar.etiqueta)

Para filtrar los resultados por los valores de las variables de la plantilla seleccionada. Ciertamente, es posible que alguien intente usarlo en algo como una función aliasBy(), pero si es un error de sintaxis, está bien. No esperaría que arreglaras mágicamente una conversión de una matriz pasada a una función que espera un solo valor.

En cuanto a las asignaciones, creo que es suficiente que el usuario las defina estáticamente.
Idealmente, tendría una consulta a MT para obtener la lista de valores que deben asignarse, por ejemplo, "01", "02", "03" y luego sería fácil agregar las asignaciones / alias. Los valores no asignados irían a un depósito "predeterminado".

+1

+1

Estoy muy sorprendido de que esto no se haya incluido: pasé bastante tiempo tratando de descubrir cómo hacer esto "obvio" y finalmente encontré mi camino aquí para descubrir que no existe.

La capacidad de reescribir dinámicamente como se describe anteriormente sería fantástica. Sin embargo, incluso estaría feliz con un truco a corto plazo (o un modelo "fácil" permanente) que es una versión extendida del campo "Personalizado", que mapea estáticamente las opciones a resultados de una o varias opciones.

Nuestro ejemplo son los códigos de país. A menudo deseamos ver grupos de sistemas basados ​​en regiones geográficas, pero no por país. Pero solo almacenamos códigos de países como claves en nuestro servidor Prometheus. Entonces, ahora mismo, si quiero ver todos los sistemas en América del Norte, tengo que seleccionar US, CA, MX manualmente de una lista de opciones basada en consultas de casi 100 países. Ni siquiera puedo decir cuánto tiempo paso seleccionando cada país de Europa, Asia o África para hacer el análisis. Casi vale la pena configurar tableros completamente diferentes para cada región, lo cual es absurdo pero es la única forma de resolver el problema sin codificar gráficamente. Hacer una base de datos completamente nueva con asignaciones y luego hacer consultas ocultas también parece estar muy, muy lejos de ser ideal.

Mi sueño de fiebre:
Parecería que esta sería una opción de "Lista personalizada" como un posible nuevo tipo de Variable. La Lista personalizada comenzaría vacía si se selecciona, pero se parecería mucho al modelo "Personalizado" actual. Aparecería un botón "Agregar". Al hacer clic en "Agregar" se crearía una matriz de entrada de dos campos con "Valor de visualización:" y "Valor de búsqueda:" donde cada uno podría completarse. El "Valor de visualización" sería lo que el usuario quisiera mostrar en la lista de selección, en nuestro caso, "América del Norte". Luego, el "Valor de búsqueda" sería lo que se presentaría en la consulta; de nuevo, en este ejemplo para América del Norte sería "us,ca,mx". En cualquier momento, un icono de "eliminar" (¿papelera?) eliminaría líneas individuales. Al hacer clic en el botón "Agregar" nuevamente, se crearía un nuevo emparejamiento, hasta que el usuario haya completado su lista de opciones. Las opciones "Valor múltiple" y "Seleccionar todo" se mantendrían, similares al modelo personalizado existente.

Estoy muy sorprendido de que esto no se haya incluido: pasé bastante tiempo tratando de descubrir cómo hacer esto "obvio" y finalmente encontré mi camino aquí para descubrir que no existe.

Resolví esto creando una base de datos MySQL, creo una tabla con los elementos que quiero en el menú desplegable, por ejemplo, Europa, América del Norte, etc. En un segundo campo, tengo una expresión regular que coincidirá con las entradas que quiero que coincidan. Luego agregue MySQL como fuente de datos y utilícelos para crear las variables. Es un truco, pero en realidad funciona bastante bien. Lo uso para más o menos exactamente lo que estás tratando de hacer.

Agradezco el truco inteligente, pero para nosotros no es realmente una solución. Configurar una base de datos completamente nueva (no usamos MySQL en absoluto, lo que significa que esto es imposible desde el punto de vista operativo) para realizar una simple sustitución de clave/valor que es bastante estática parece ser un montón de obstáculos por los que pasar.

Estuve pensando un poco más en esto, y hay una forma aún más elegante de proporcionar esta funcionalidad que la que describí anteriormente. Yo lo llamaría una "macro variable". De nuevo, esto parece una lista personalizada, excepto que le permite al administrador especificar que cuando se selecciona una (o más) de estas macros, se establecerán las variables nombradas y los valores proporcionados se agregarán al conjunto de valores existente. Este sería completamente un modelo basado en la interfaz de usuario y no cambiaría el concepto de variable real en absoluto; simplemente crearía una capa de azúcar de autocompletado sobre las variables existentes. Esto lo hace compatible con versiones anteriores sin necesidad de variables adicionales para la creación o integración en consultas.

Una macro que establece las variables permitiría al usuario ver los valores a medida que se seleccionan y luego permitiría al usuario abrir cada variable y ver/manipular las selecciones o los datos en lugar de crear una variable separada como mis comentarios anteriores. implicar. Esto sería mucho más intuitivo.

Ejemplo:

Entonces, una macro variable llamada "Norteamérica - Clúster primario" establecería mis variables "País" en "us, ca, mx" y establecería mi variable "Clúster:" en "primario". Esas configuraciones serían visibles si desplegara cada variable nombrada (o no, si están ocultas) para poder agregar o restar países a la lista País: siempre y cuando no toque el menú desplegable Macro variable nuevamente.

Es posible que haya un valor booleano de "borrar variables nombradas antes de configurar", de modo que si se realiza un cambio en la lista de selección para esta macro, se borrará cualquier otra configuración de las variables especificadas. Esto podría ser útil para las listas en las que no es obvio que podría incluir algo que se configuró previamente. Supongo que si se eligió más de una opción de macro variable, entonces la última en la lista que se examinará "gana" si hay configuraciones en competencia de un valor particular; no hay forma de evitar ese problema. (Es discutible que esta acción de limpieza deba especificarse variable por variable, pero eso parece sonar un poco desordenado... pero ¿lo es?)

Aquí está mi ejemplo hipotético nuevamente, donde tengo variables preexistentes de "País" y "Cluster".

Nombre de macro variable: Región

Nombre 1: América del Norte - Clúster principal
Borrar variables con nombre antes de configurar: Y
Variable1: País
Valor1: nosotros, ca, mx
Variable2: Clúster
Valor2: primario

Nombre 2: Países nórdicos - Clúster secundario
Borrar variables con nombre antes de configurar: Y
Variable1: País
Valor1: sí, fi, no, dk, es
Variable2: Clúster
Valor2: secundario

Agradezco el truco inteligente, pero para nosotros no es realmente una solución. Configurar una base de datos completamente nueva (no usamos MySQL en absoluto, lo que significa que esto es imposible desde el punto de vista operativo) para realizar una simple sustitución de clave/valor que es bastante estática parece ser un montón de obstáculos por los que pasar.

Esperaba que dijeras algo como esto. La realidad es que usted pidió un truco y este truco resuelve el problema, no es difícil de configurar y no es difícil de revertir en el futuro. De hecho, me parece bastante útil tener MySQL allí, ya que seguimos agregando nuevos conjuntos de datos, es un lugar conveniente para realizar un seguimiento y actualizarlos. Si lo piensa, si va a utilizar estos conjuntos de datos en múltiples tableros y desea que se mantengan centralmente, entonces deben almacenarse en algún lugar. Si su base de datos de series de tiempo no puede almacenarlos, entonces necesita alguna configuración para almacenarlos. Entonces, en realidad tiene mucho sentido tener MySQL. La ventaja adicional es que también es muy fácil automatizar la población de MySQL.

Si tiene PostgreSQL, no necesita crear una tabla real para el mapeo, puede hacer algo como:

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)

Pero no funciona con valores numéricos:

SELECCIONE * DESDE ( VALORES ( 'OK', '0'), ( 'ERROR', '1') ) AS t (__texto, __valor)

Al cargar el tablero:

Y al seleccionar otro parámetro

Al seleccionar: OK + ERROR

Si desea valores numéricos, debe eliminar las comillas simples; de lo contrario, se interpreta como texto, es decir

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

Gracias @GlennMatthys glenn por la respuesta, pero ya encontré dónde ocurre el problema.

SELECCIONE * DESDE ( VALORES ( 'OK', 0), ( 'Advertencia', 1), ('Crítico', 2) ) AS t (__texto, __valor)

Configuración de valores múltiples en:

Sucede

Seleccionando 3 estados

Y multivalor apagado:

GlennMatthys: su solución es perfecta, muchas gracias

Para MySQL es:
SELECT * FROM ( VALUES row('a', 1), row('b', 2) ) AS t (__text, __value)

¿Qué pasa con MariaDB? No me funciona (versión mariaDB: 10.5.5)

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

O el anterior:

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

Parece que la declaración de valores ya no está disponible...

¿O hay algo más que hago mal?

@radoeka Para versiones anteriores de 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 guau guau guau, ¡qué respuesta tan rápida! Y esto funciona
Pensé que estaba ejecutando una versión bastante nueva de mariadb, pero ese no es el caso (usando una distribución de Linux que solo tiene 2 meses).
Gracias.

Esto parece no ser compatible con Prometheus.

Reabrir este problema como #27829 solo resuelve esto para datos estáticos.