TL;DR InfluxDB Tech Tips - Kapacitor TICKscript, Series Cardinality & Slow Queries

Navigate to:

In this post we recap the week’s most interesting InfluxDB and TICK-stack related issues such as Kapacitor TICKscript, workarounds, how-tos and Q&A from GitHub, IRC and the InfluxDB Google Group that you might have missed.

Query for series cardinality

Q: Is there a way to query the database for my series cardinality?

A: Yes!

Find the series cardinality for each database:

SELECT numSeries FROM "_internal".."database" GROUP BY "database" ORDER BY desc LIMIT 1

Find the total series cardinality*:

SELECT sum(numSeries) AS "total_series" FROM "_internal".."database" WHERE time > now() - 10s
  • This query assumes that you haven’t made any changes to the <a href="https://docs.influxdata.com/influxdb/latest/administration/config/#monitor">[monitor]</a> section of the configuration file.

Using multiple level filters in a Kapacitor TICKscript

Q: My TICKscript has both a WARN level and a CRITICAL level. I receive a WARN alert as expected, but I receive an OK alert even when my data meet the criteria for the CRITICAL filter. I’ve included my TICKscript below. What am I doing wrong?

stream
   |from()
       .measurement('sparkle_forest')
   |alert()
       .warn(lambda: ("temperature" > 100 AND "temperature" <= 120))
       .crit(lambda: ("temperature" > 80 AND "temperature" <= 100))
       .log('/tmp/alerts.log')

A: Kapacitor assumes that each level is a subset of the previous level. As a result, Kapacitor only applies the filter if the data point passes the previous filter. It makes this assumption so that it can break out early and not evaluate every condition.

For example, if your data point equals 90 it doesn’t pass your first filter (.warn(lambda: ("temperature" &gt; 100 AND "temperature" &lt;= 120))). Because it doesn’t pass your first filter, Kapacitor doesn’t evaluate the second filter (.crit(lambda: ("temperature" &gt; 80 AND "temperature" &lt;= 100))) even though the value 90 technically passes that second filter. That’s why you’re seeing an OK alert instead of a CRITICAL alert.

We recommend changing your filter criteria such that the WARN level includes the values for the CRITICAL level:

stream
   |from()
       .measurement('sparkle_forest')
   |alert()
       .warn(lambda: ("temperature" <= 120))
       .crit(lambda: ("temperature" > 80 AND "temperature" <= 100))
       .log('/tmp/alerts.log')

Using that TICKscript, if your data point equals 90 it passes the first filter (.warn(lambda: ("temperature" &lt;= 120))). Because it passes the first filter, Kapacitor goes on to evaluate the second filter (.crit(lambda: ("temperature" &gt; 80 AND "temperature" &lt;= 100))), and you’ll receive the expected CRITICAL alert.

Log slow queries

Q: Is there a way to log slow queries?

A: Yes. Starting with InfluxDB version 0.13, the log-queries-after setting in the <a href="https://docs.influxdata.com/influxdb/latest/administration/config/#cluster">[cluster]</a> section of the configuration file determines the maximum time a query can run after which InfluxDB logs the query with a Detected slow query message.

See our Query Management documentation for more information.

For more InfluxDB tips, check out our Frequently Encountered Issues page and feel free to post your questions in the InfluxDB users group.

What's next?