By default, Netdata collects anonymous usage information from the open-source monitoring agent using the open-source product analytics platform PostHog. We self-host our PostHog instance, which means your data is never sent or processed by any third parties outside of the Netdata infrastructure.
We are strongly committed to your data privacy.
We use the statistics gathered from this information for two purposes:
Quality assurance, to help us understand if Netdata behaves as expected, and to help us classify repeated issues with certain distributions or environments.
Usage statistics, to help us interpret how people use the Netdata agent in real-world environments, and to help us identify how our development/design decisions influence the community.
Netdata collects usage information via two different channels:
- Agent backend: The
netdatadaemon executes the
anonymous-statistics.shscript when Netdata starts, stops cleanly, or fails.
You can opt-out from sending anonymous statistics to Netdata through three different opt-out mechanisms.
When you kick off an Agent dashboard session by visiting
http://NODE:19999, Netdata will initialiszes a PostHog session and masks various event attributes.
Note: You can see the relevant code in the dashboard repository where the
window.posthog.register() call is made.
In the above snippet a Netdata PostHog session is initialized and the
host attributes are set to constant values for all events that may be sent during the session. This way, information like the IP or hostname of the Agent will not be sent as part of the product usage event data.
anonymous_statistics is true. The value of this
variable is controlled via the opt-out mechanism.
Every time the daemon is started or stopped and every time a fatal condition is encountered, Netdata uses the anonymous statistics script to collect system information and send it to the Netdata PostHog via an http call. The information collected for all events is:
- Netdata version
- OS name, version, id, id_like
- Kernel name, version, architecture
- Virtualization technology
- Containerization technology
Furthermore, the FATAL event sends the Netdata process & thread name, along with the source code function, source code filename and source code line number of the fatal error.
Starting with v1.21, we additionally collect information about:
- Failures to build the dependencies required to use Cloud features.
- Unavailability of Cloud features in an agent.
- Failures to connect to the Cloud in case the connection process has been completed. This includes error codes to inform the Netdata team about the reason why the connection failed.
To see exactly what and how is collected, you can review the script template
template is converted to a bash script called
anonymous-statistics.sh, installed under the Netdata
directory, which is usually
You can opt-out from sending anonymous statistics to Netdata through three different opt-out mechanisms:
Create a file called
.opt-out-from-anonymous-statistics. This empty file, stored in your Netdata configuration
/etc/netdata), immediately stops the statistics script from running, and works with any type of
installation, including manual, offline, and macOS installations. Create the file by running
.opt-out-from-anonymous-statistics from your Netdata configuration directory.
Pass the option
--disable-telemetry to any of the installer scripts in the installation
docs. You can append this option during the initial installation or a manual
update. You can also export the environment variable
DO_NOT_TRACK with a non-zero or non-empty value
When using Docker, set your
DO_NOT_TRACK environment variable to
1. You can set this variable with the following
export DO_NOT_TRACK=1. When creating a container using Netdata's Docker
image for the first time, this variable will disable
the anonymous statistics script inside of the container.
Each of these opt-out processes does the following:
- Prevents the daemon from executing the anonymous statistics script.
- Forces the anonymous statistics script to exit immediately.
Prior to v1.29.4 we used Google Analytics to capture this information. This led to discomfort with some of our users in sending any product usage data to a third party like Google. It was also not even that useful in terms of generating the insights we needed to help catch bugs early and find opportunities for product improvement as Google Analytics does not allow its users access to the raw underlying data without paying a significant amount of money which would be infeasible for a project like Netdata.
While we migrate fully away from Google Analytics to PostHog there maybe be a small period of time where we run both in parallel before we remove all Google Analytics related code. This is to ensure we can fully test and validate the Netdata PostHog implementation before fully defaulting to it.