is there any equivalence of kapacitor’s sideload() in influxdb2?
for example, if i have a cpu alert, how can i set up different thresholds per server in a simple way like sideload() does?
I wonder how people creates “exceptions” with InfluxDB2 to disable alerts on host under maintenance or set specific thresholds. I can’t find anything on the official documentation. I think it’s better to stay with InfluxDB1.x + Kapacitor as it still has many functionalities which don’t exist in InfluxDB2 
Hello @vvilaplana,
you can add tags and fields to data with the
map()
set()
and to() functions but not from a file like you can with the sideload node in kapaciotr.
There isn’t a clever way to automate task creation in influxDB v2 like there is in kapacitor unfortunately. However you could use invokable scripts in your task with parameters and create a new task and pass in the new threshold values. You could invoke these in a task with a http post function.
Let me know if you need help with an example of that.
so, it looks it’s just another influxdb 1.x functionality that influxdb 2.x can’t do without hacks and workarounds. quite frustrating
my team is very happy with influxdb 1.x because to put a host in maintenance all they have to do is to create the [host].yaml file with the line “maintenance: true” and restart kapacitor. if some host usually has a very busy CPU, all they have to do is “cpu_warn: 99” to change the threshold for that host and restart. it takes less than one minute and even the CTO can do that. unless you provide me a clear example, i don’t see a quick way of doing the same with influxdb2.
the truth is i’ve been trying to migrate to influxdb 2.x for last two years. we’re in 2.3.0 and it still lacks some functionalities present in influxdb 1.x like dynamic tag/field exclusion (like ‘sideload’), avoiding repeated alerts (without messing around with _monitoring bucket), avoiding hysteresis, no flux visual query builder for grafana, etcetera. all these issues are forcing us to stay with influxdb 1.x, and i’m sure there are thousands of people in the same situation. all the proposed workarounds are very scenario-dependant and time-costly. i can’t afford having developers wasting their time learning a new “language” like flux.
1 Like
Wow, only just seen this, we use InfluxDB 1.x Enterprise, we have automated every aspect from the platform build to telegraf deployment, config, tasks, platform component config, sideloads - everything controlled via git. We have a small team, with more stacks to maintain than team members, we need to automate or we can’t function.
We cannot use InfluxDB 2 if it doesn’t have a similar capability. At a previous Influx Event, I spoke to the CEO who promised that it would be a limousine class upgrade going from 1.x to 2.x. This alone means we’ll ditch influx at the earliest opportunity, there is no future in it for us.
