Kapacitor: Is it possible to include a variable in the deadman message?

[sslupsky]

I have reviewed issue #259

I have followed the advice and defined a variable as follows:

var db = "database"
var rp = "default"
var measurement = "P100"

Then, I used the variable in a batch node:

var location = batch
|query('SELECT mean(value) FROM db.rp.measurement')

What I would like to do in the deadman node is output the measurement name ("P100"):

|deadman(1.0,1d)
.id(measurement)

However, it seems to me that this does not follow the TICK language specification. That is, the measurement variable is a reference but the .id process requires a string literal. Is there a way to output the variable name ("P100")?

I have a work around, that involves assigning a string literal to a variable:

var name = 'P100'

Then using that variable in the .id process:

.id(name)

But this seems unnecessary if I could somehow cast the measurement variable to a string.

[nathanielc]

@sslupsky

What you are trying to do does not work ATM, but #259 is next on my list of issues to tackle and I'll take this use case into account. Thanks.

[sslupsky]

Hi @nathanielc

Thanks for getting back to me, that is what I thought was the case. In part, the purpose of my machinations is to workaround the limitations regarding grouping the fields and measurements. It would be very helpful if the fields and measurements could be grouped.

[nathanielc]

As of #577 it is possible to use string concatenation to do this:

var db = 'database'
var rp = 'default'
var measurement = 'P100'
batch
     |query('SELECT mean(value) FROM "' + db + '"."' + rp '"."' + measurement + '"')

Note, the use of single quotes for the vars and the use of double quotes in the query string to protect against keyword conflicts.

This does present a small security issue where the user supplied vars could try and SQL inject, but the arg passed to query is parsed inside Kapacitor and reformatted before sending to InfluxDB and its required to be a single SELECT statement. Otherwise Kapacitor will throw an error. So the worst a user could do is make the select statement unparseable.