Binary packages

Updated Sep 20, 2016

Currently installing or updating netdata is quite complicated, this process should be simplified to allow users add package repository and install software from it.

Project should have some sort of package repository as well as an automatic build system of binary packages. This way it could automatically build packages after each accepted merge request and publish them as some sort of current package version. Also it should provide stable packages related to GitHub releases.

The central components of netdata are (will be):

  • the registry, that keeps track of all netdata installations we have (exists)
  • the authentication server, that allows us to login to each netdata server (does not exist yet)
  • the health monitoring server, that collects the alarm log from all netdata servers and handles notifications (does not exist yet)

All should all allow replication and sharding, so that a distributed monitoring network can be achieved.

Once all these are implemented, netdata will be the first monitoring solution that can scale to hundreds of thousands of monitored nodes. And we will provide a public central global cluster offering all the above, to everyone!

Health monitoring in netdata is missing 2 important functions:

  • Alerts for a server that has frozen/crashed or rebooted.
  • Central dispatch of all notifications, so that all roles, recipients, severity filtering etc is centrally controlled.

Both of these can be solved by propagating the alarm log from all netdata servers to a central netdata. All the netdata servers should check-in every 1 minute or 30 seconds to the central monitoring server, so that the absence of this check-in could trigger the alarm related to a frozen/crashed server. Similarly server reboots could be detected by including the server uptime to the check-in request.

The check-in request could also include a few key performance metrics (available memory, cpu usage, disk I/O, network activity, etc), so that a central dashboard can be rendered without any access to each netdata.

Authenticated Access

Updated Sep 19, 2016

Authentication in netdata should be distributed, much like the registry.

A central netdata should act as the authentication server. The only configuration of all other netdata servers should be: authentication on/off and authentication server to be consulted.

The authentication server could be related with the registry (i.e. properties of the person objects the registry already maintains).

Back-end authentication should be performed with PAM (i.e. linux username/password, supporting all Linux back-ends), or other OAuth providers (google, github, etc). The supported back-ends should be configured at the central authentication netdata server only.

Netdata should also support API keys to allow third party applications get access to certain features or charts of each netdata.

TCP Extended Statistics exposed by the Linux kernel at /proc/net/netstat, provide a lot of information regarding the internal mechanism of the TCP stack, and many metrics stating the reasons TCP connections are dropped or rejected, queues are overrun, etc.

Using this information netdata can provide alarms to let you know when your server is hitting the limits of the system, with instructions on how to tune the system for minimum latency and max performance.

No results.