InfluxDB 2.0 and future of the fritzcollectd -> influxdb -> grafana stack

[wfjm]

The README.me of the current Beta of InfluxDB V2.0 has the statement

- What is NOT planned? 
  - Direct support by InfluxDB for CollectD, StatsD, Graphite, or UDP.

So I wonder what the long term perspectives of the somehow popular "fritzcollectd -> influxdb -> grafana" stack is. Without build-in collectd support in influxdb one could continue with

   fritzconnection <- fritzcollectd
      -> collectd
      -> telegraf  (via socket_listener: data_format = "collectd")
      -> influxdb

Doesn't look too attractive to me, there are shorter ways, like with a new fritztelegraf

  fritzconnection <- fritztelegraf (to be written)
      -> telegraf  (via execd: data_format = "influx"; signal = "STDIN")
      -> influxdb

which should also emit a schema better suited for influxdb, with one series per device and multiple fields.

Are there plans from the community behind fritzcollectd to embark on such a solution ?

[volschin]

The question is, is the intent of the program to support collectd, independent from InfluxDB as one target. Otherwise a program should be something like fritzinflux. As I know there is a good python client for Influxdb 2.0 https://www.influxdata.com/blog/getting-started-with-python-and-influxdb-v2-0/

You don't need telegraf.

[Apollon77]

exactly, this question is more for collectd and not for this collectd plugin! This here is "Only" a greeat plugin for collectd. The question so is for collectd how they want to handle this

[fetzerch]

When I wrote fritzcollectd, collectd still was quite popular for server monitoring and it made sense to base the Fritzbox monitoring on it because it provided a scheduler, a configuration framework and a database abstraction. Back then, I wasn't even using InfluxDB but Graphite.

Nowadays most of the users don't care about collectd and run it just for fritzcollectd. And because setting up collectd is not trivial, people execute the whole stack using Docker containers.

In my opinion the way forward would be to rewrite frizcollectd to a script that uses https://github.com/influxdata/influxdb-python to directly send the measurements to InfluxDB. I'd probably just use systemd timers to periodically execute it. The configuration could be read from a Json/Yaml/Toml file in /etc.

Unfortunately I have no spare time at the moment to work on this.

[wfjm]

@volschin: I'm aware of fritzinfluxdb, and BoxMatrix - OSS-News lists even more. But the fritzinfluxdb project lacks support of AVM home automation devices. It offers on the other side data points essential for real trouble shooting which are missing on fritzcollectd (see #40). So I haven't found the perfect one yet :(

[Agrigor]

I already use a python script to read the sensor data from the FRITZ!DECT 210 and 301 devices, store them in influxdb and visualize in Grafana. This script uses the libraries for influxdb and a self-written class to communicate over the AVM http-api with ssl and authentication. In addition it has also some code to read the data which fritzcollectd collects, but I commented it out to prevent doubled data. It is not that big (about 200 lines) and I planned to put that as repo on github some time, maybe it could help or I can help to rewrite this entire thing. :)

[UweBeckert]

I would prefer to go via a telegraf plugin either the above mentioned socket_listener or the exec plugin. Telegraf has the advantage to buffer measurements if the connection to influxdb is down.

[teeberg]

@Agrigor That sounds interesting! Would be willing to upload it as a Github Gist? Or just put it in its own repository? Then people could already contribute to it. :)

[Agrigor]

@teeberg I guess, I will! But I definitely need some time beforehand to spiff it up, maybe the Christmas holidays will bring some time :)