Template Variable in opentsdb metric

I’m trying to use template variables to overlay multiple variables in the same graph panel in opentsdb. Am I doing something wrong? I basically need a new row to be created for each variable rather than it trying to pass in the whole list of variables to opentsdb ‘|’ separated.

I use the variable like this:

and am getting this error:

So the issue is it is trying to put all of the variables in one metric query. It needs to repeat the row for each query so that each variable shows up on the same graph panel but is queried separately.

Anyone know if this is possible?

There are some dashboards for opentsdb that can help get started using the datasource:

This one is using template variables with opentsdb (which may help with your scenario)

I’ll setup an opentsdb server and see if I can help out.

How are you sending data/metrics to opentsdb?



They’re being sent via a json string to a link associated with our server. Essentially the json is something like:

          "aggregator": "sum",
          "alias": "##ALIAS##",
          "currentTagKey": "",
          "currentTagValue": "",
          "disableDownsampling": true,
          "downsampleAggregator": "avg",
          "downsampleFillPolicy": "none",
          "downsampleInterval": "",
          "hide": false,
          "metric": "##Tag in DB##",
          "refId": "A",
          "tags": {
            "OPCQuality": "192"

But I’m using SQL to retrieve the list of tags we have from our SQL server so with that my code is:

Select [TAGNAME] from [Table]

The thing is when I try to use the variable (in this case $fqn) in the OpenTSDB metric box, it is passing in every single one of those tags that is retrieved from the database, and it appears from that screenshot that they are ‘|’ separated. I need my metric to pull each of the tagnames returned from my sql query and repeat the query for each of these. Essentially creating a new metric for each tag so I have a graph at the end that has all of the tagname metrics on one graph panel.

I think I may just be misunderstanding how to pass my variable into the metric properly. Or perhaps this isn’t possible? The issue is I have so many tagnames being returned I can’t have it repeat the gaph panel and make an individual graph panel for each tagname returned from the SQL query because there would be tens if not hundreds returned, which isn’t very useful to look at.

In the template variable setup, does the preview show one long list, or are they “boxed” as separate entries?

If it’s one long result, you can add a regex pattern to the template variable:

to split pipe separated tag names, something like this should work in the query options regex field:


They’re the individual metric query type

Sorry to resurrect an old post, but did you ever resolve this?

I have a similar issue where we are sending network utilisation metrics - each metric name starts with Network_Utilisation_$interfaceName_in and Network_Utilisation_$interfaceName_out.

One host may have multiple interfaces, so using a query variable (metrics(Network_Utilisation) I am able to get a list all of all metrics starting with that and I am using regex to filter the _in and _out (/_in$/) which does return the correct metrics:


But I am unsure of how to correctly use this in a graph as the metric names are all piped together with | in the OpenTSDB query:

message:"No such name for 'metrics': Network_Utilisation.ASIX_AX88179_USB_3_0_to_Gigabit_Ethernet_Adapter_in|Network_Utilisation.Broadcom_NetXtreme_E-Series_Advanced_Dual-port_10GBASE-T_Ethernet_LOM__2_in|

Selecting a single metric works correctly, and using the repeating option inside of Grafana works too, although this creates empty graphs because one host may only have one interface - I’d rather have all metrics on the one graph and hide series with null values, but in a single query.

Disregard my post - we’re rewriting the OpenTSDB writer we use to change the interface names to key/pair tags and keep the metric name generic as per the best practices.

We were never able to figure out how to configure the panels correctly to alleviate this issue. We built an in house data update program to update the json code of each panel and we’re exploring provisioning to reach a halfway point for these dashboards.