Netdata panel not working after install

[yunohost-apps]

Netdata panel not working after install

[JimboJoe]

Hi, thanks for reporting!
I've created PR #15 to fix it, could you please test it?

[lapineige]

It works :)

But now I have "no data points" everywhere.
Maybe it's unrelated, I had this on a KVM VPS before. But now I have it too on a Raspberry PI.

[JimboJoe]

I had this issue in a virtualized environment as well: the default dashboard points to /dev/sd* disks whereas my virtual disks were named /dev/vd*. So I just edited the panels to point to the right location.
What about yours?

[lapineige]

It's /dev/dm-*. But I don't understand why this would leave for instance CPU utilisation empty.
And changing "sda" to "dm-0" (for instance) in Disk space usage doesn't change anything.

(can't Netdata detect the correct CPU, and share that with Grafana ?)

[JimboJoe]

How is the connection from Grafana to Influxdb (Configuration/Data Sources/InfluxDB/Save and Test)?
What is the status of netdata and influxdb (systemctl status netdata (or influxdb)?
You can also search in netdata logs if there is a connection problem to the backend (influxdb): /opt/netdata/var/log/netdata/error.log.

[lapineige]

How is the connection from Grafana to Influxdb (Configuration/Data Sources/InfluxDB/Save and Test)?

"Data source is working"

What is the status of netdata and influxdb (systemctl status netdata (or influxdb)?

Netdata is fine.
Same for influxdb.
I tried to restart both, same issue.

netdata INFO : PLUGINSD[python.d] : File /opt/netdata/var/cache/netdata/web_log_my_domain_tld.http_method/PUT.db is too old (last collected 766397 seconds ago, but the database is 4000 seconds). Clearing it.
netdata ERROR : BACKENDS : Failed to connect to '::1', port '4242' (errno 111, Connection refused)
netdata ERROR : BACKENDS : Failed to connect to '127.0.0.1', port '4242' (errno 111, Connection refused)
netdata ERROR : BACKENDS : BACKEND: failed to update database backend 'localhost:4242'

[JimboJoe]

Can you do a netstat -lapute and check if influxdb is listening to TCP port 4242?
If not, can you check /etc/influxdb/influxdb.conf and see if enabled = true is present in ``[[opentsdb]]` section?

[lapineige]

It does not.

The whole opentsdb part is commented (so enabled = True is commented)

[JimboJoe]

OK, then could you please:

• share your influxdb.conf file
• try to enable opentsdb in it and reload influxdb service to check everything is working?

[lapineige]

I de-commented everything in that file. The no data points disappeared, but now on the corner of each graph I have a warning "502 bad gateway"

It looks like that

[[opentsdb]]
   enabled = true
   bind-address = ":4242"
   database = "opentsdb"
   retention-policy = ""
   consistency-level = "one"
   tls-enabled = true
   certificate= "/etc/ssl/influxdb.pem"

  # Log an error for every malformed point.
   log-point-errors = true

  # These next lines control how batching works. You should have this enabled
  # otherwise you could get dropped metrics or poor performance. Only points
  # metrics received over the telnet protocol undergo batching.

  # Flush if this many points get buffered
   batch-size = 1000

  # Number of batches that may be pending in memory
   batch-pending = 5

  # Flush at least this often even if we haven't hit buffer limit
   batch-timeout = "1s"

[JimboJoe]

You only have to uncomment the "enabled" line (see here)...
Furthermore, could you please share the original file, so that I can see what's to fix?

[lapineige]

Ok with only this line uncommented, it works.
Thanks ! :)

Furthermore, could you please share the original file, so that I can see what's to fix?

You mean before de-commenting ?

[JimboJoe]

Yes, the PR was supposed to uncomment this line (it worked for me), but curiously it didn't work on your server...