* spelling: activity Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: adding Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: addresses Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: administrators Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: alarm Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: alignment Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: analyzing Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: apcupsd Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: apply Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: around Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: associated Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: automatically Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: availability Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: background Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: bandwidth Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: berkeley Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: between Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: celsius Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: centos Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: certificate Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: cockroach Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: collectors Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: concatenation Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: configuration Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: configured Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: continuous Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: correctly Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: corresponding Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: cyberpower Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: daemon Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: dashboard Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: database Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: deactivating Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: dependencies Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: deployment Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: determine Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: downloading Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: either Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: electric Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: entity Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: entrant Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: enumerating Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: environment Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: equivalent Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: etsy Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: everything Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: examining Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: expectations Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: explicit Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: explicitly Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: finally Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: flexible Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: further Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: hddtemp Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: humidity Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: identify Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: importance Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: incoming Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: individual Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: initiate Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: installation Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: integration Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: integrity Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: involuntary Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: issues Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: kernel Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: language Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: libwebsockets Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: lighttpd Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: maintained Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: meaningful Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: memory Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: metrics Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: miscellaneous Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: monitoring Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: monitors Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: monolithic Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: multi Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: multiplier Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: navigation Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: noisy Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: number Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: observing Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: omitted Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: orchestrator Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: overall Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: overridden Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: package Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: packages Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: packet Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: pages Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: parameter Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: parsable Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: percentage Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: perfect Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: phpfpm Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: platform Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: preferred Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: prioritize Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: probabilities Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: process Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: processes Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: program Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: qos Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: quick Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: raspberry Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: received Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: recvfile Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: red hat Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: relatively Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: reliability Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: repository Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: requested Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: requests Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: retrieved Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: scenarios Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: see all Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: supported Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: supports Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: temporary Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: tsdb Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: tutorial Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: updates Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: utilization Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: value Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: variables Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: visualize Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: voluntary Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: your Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>
14 KiB
Manually build Netdata from source
These instructions are for advanced users and distribution package maintainers. Unless this describes you, you almost certainly want to follow our guide for manually installing Netdata from a git checkout instead.
Required dependencies
At a bare minimum, Netdata requires the following libraries and tools to build and run successfully:
- libuuid
- libuv version 1.0 or newer
- zlib
- GNU autoconf
- GNU automake
- GCC or Xcode (Clang is known to have issues in certain configurations, see Using Clang)
- A version of
makecompatible with GNU automake - Git (we use git in the build system to generate version info, don't need a full install, just a working
git showcommand)
Additionally, the following build time features require additional dependencies:
- TLS support for the web GUI:
- OpenSSL 1.0.2 or newer or LibreSSL 3.0.0 or newer.
- dbengine metric storage:
- liblz4 r129 or newer
- OpenSSL 1.0 or newer (LibreSSL amy work, but is largely untested).
- libJudy
- Netdata Cloud support:
- A working internet connection
- A recent version of CMake
- OpenSSL 1.0.2 or newer or LibreSSL 3.0.0 or newer.
- JSON-C (may be provided by the user as shown below, or by the system)
Preparing the source tree
Certain features in Netdata require custom versions of specific libraries, which the the build system will link statically into Netdata. These libraries and their header files must be copied into specific locations in the source tree to be used.
Netdata cloud
Netdata Cloud functionality requires custom builds of libmosquitto and libwebsockets.
libmosquitto
Netdata maintains a custom fork of libmosquitto at https://github.com/netdata/mosquitto with patches to allow for proper integration with libwebsockets, which is needed for correct operation of Netdata Cloud functionality. To prepare this library for the build system:
- Verify the tag that Netdata expects to be used by checking the contents
of
packaging/mosquitto.versionin your Netdata sources. - Obtain the sources for that version by either:
- Navigating to https://github.com/netdata/mosquitto/releases and downloading and unpacking the source code archive for that release.
- Cloning the repository with
gitand checking out the required tag.
- If building on a platform other than Linux, prepare the mosquitto
sources by running
cmake -D WITH_STATIC_LIBRARIES:boolean=YES .in the mosquitto source directory. - Build mosquitto by running
make -C libin the mosquitto source directory. - In the Netdata source directory, create a directory called
externaldeps/mosquitto. - Copy
lib/mosquitto.hfrom the mosquitto source directory toexternaldeps/mosquitto/mosquitto.hin the Netdata source tree. - Copy
lib/libmosquitto.afrom the mosquitto source directory toexternaldeps/mosquitto/libmosquitto.ain the Netdata source tree. If building on a platform other than Linux, the file that needs to be copied will instead be namedlib/libmosquitto_static.a, but it still needs to be copied toexternaldeps/mosquitto/libmosquitto.a.
libwebsockets
Netdata uses the standard upstream version of libwebsockets located at https://github.com/warmcat/libwebsockets, but requires a build with SOCKS5 support, which is not enabled by most pre-built versions. Currently, we do not support using a system copy of libwebsockets. To prepare this library for the build system:
- Verify the tag that Netdata expects to be used by checking the contents
of
packaging/libwebsockets.versionin your Netdata sources. - Obtain the sources for that version by either:
- Navigating to https://github.com/warmcat/libwebsockets/releases and downloading and unpacking the source code archive for that release.
- Cloning the repository with
gitand checking out the required tag.
- Prepare the libwebsockets sources by running
cmake -D LWS_WITH_SOCKS5:bool=ON .in the libwebsockets source directory. - Build libwebsockets by running
makein the libwebsockets source directory. - In the Netdata source directory, create a directory called
externaldeps/libwebsockets. - Copy
lib/libwebsockets.afrom the libwebsockets source directory toexternaldeps/libwebsockets/libwebsockets.ain the Netdata source tree. - Copy the entire contents of
lib/includefrom the libwebsockets source directory toexternaldeps/libwebsockets/includein the Netdata source tree.
JSON-C
Netdata requires the use of JSON-C for JSON parsing when using Netdata Cloud. Netdata is able to use a system-provided copy of JSON-C, but some systems may not provide it. If your system does not provide JSON-C, you can do the following to prepare a copy for the build system:
- Verify the tag that Netdata expects to be used by checking the contents
of
packaging/jsonc.versionin your Netdata sources. - Obtain the sources for that version by either:
- Navigating to https://github.com/json-c/json-c and downloading and unpacking the source code archive for that release.
- Cloning the repository with
gitand checking out the required tag.
- Prepare the JSON-C sources by running
cmake -DBUILD_SHARED_LIBS=OFF .in the JSON-C source directory. - Build JSON-C by running
makein the JSON-C source directory. - In the Netdata source directory, create a directory called
externaldeps/jsonc. - Copy
libjson-c.afro the JSON-C source directory toexternaldeps/jsonc/libjson-c.ain the Netdata source tree. - Copy all of the header files (
*.h) from the JSON-C source directory toexternaldeps/jsonc/json-cin the Netdata source tree.
Building Netdata
Once the source tree has been prepared, Netdata is ready to be configured and built. Netdata currently uses GNU autotools as it's primary build system. To build Netdata this way:
- Run
autoreconf -ivfin the Netdata source tree. - Run
./configurein the Netdata source tree. - Run
makein the Netdata source tree.
Configure options
Netdata provides a number of build time configure options. This section lists some of the ones you are most likely to need:
--prefix: Specify the prefix under which Netdata will be installed.--with-webdir: Specify a path relative to the prefix in which to install the web UI files.--disable-cloud: Disables all Netdata Cloud functionality for this build.
Using Clang
Netdata is primarily developed using GCC, but in most cases we also
build just fine using Clang. Under some build configurations of Clang
itself, you may see build failures with the linker reporting errors
about nonrepresentable section on output. We currently do not have a
conclusive fix for this issue (the obvious fix leads to other issues which
we haven't been able to fix yet), and unfortunately the only workaround
is to use a different build of Clang or to use GCC.
Linking errors relating to OpenSSL
Netdata's build system currently does not reliably support building on systems which have multiple ABI incompatible versions of OpenSSL installed. In such situations, you may encounter linking errors due to Netdata trying to build against headers for one version but link to a different version.
Additional components
A full featured install of Netdata requires some additional components which must be built and installed separately from the main Netdata agent. All of these should be handled after installing Netdata itself.
React dashboard
The above build steps include a deprecated web UI for Netdata that lacks support for Netdata Cloud. To get a fully featured dashboard, you must install our new React dashboard.
Installing the pre-built React dashboard
We provide pre-built archives of the React dashboard for each release (these are also used during our normal install process). To use one of these:
- Verify the release version that Netdata expects to be used by checking
the contents of
packaging/dashboard.versionin your Netdata sources. - Go to https://github.com/netdata/dashboard/releases and download the
dashboard.tar.gzfile for the required release. - Unpack the downloaded archive to a temporary directory.
- Copy the contents of the
builddirectory from the extracted archive to/usr/share/netdata/webor the equivalent location for your build of Netdata. This will overwrite some files in the target location.
Building the React dashboard locally
Alternatively, you may wish to build the React dashboard locally. Doing so requires a recent version of Node.JS with a working install of NPM. Once you have the required tools, do the following:
- Verify the release version that Netdata expects to be used by checking
the contents of
packaging/dashboard.versionin your Netdata sources. - Obtain the sources for that version by either:
- Navigating to https://github.com/netdata/dashboard and downloading and unpacking the source code archive for that release.
- Cloning the repository with
gitand checking out the required tag.
- Run
npm installin the dashboard source tree. - Run
npm run buildin the dashboard source tree. - Copy the contents of the
builddirectory just like step 4 of installing the pre-built React dashboard.
Go collectors
A number of the collectors for Netdata are written in Go instead of C, and are developed in a separate repository from the mian Netdata code. An installation without these collectors is still usable, but will be unable to collect metrics for a number of network services the system may be providing. You can either install a pre-built copy of these collectors, or build them locally.
Installing the pre-built Go collectors
We provide pre-built binaries of the Go collectors for all the platforms we officially support. To use one of these:
- Verify the release version that Netdata expects to be used by checking
the contents of
packaging/go.d.versionin your Netdata sources. - Go to https://github.com/netdata/go.d.plugin/releases, select the
required release, and download the
go.d.plugin-*.tar.gzfile for your system type and CPu architecture and theconfig.tar.gzconfiguration file archive. - Extract the
go.d.plugin-*.tar.gzarchive into a temporary location, and then copy the single file in the archive to/usr/libexec/netdata/plugins.dor the equivalent location for your build of Netdata and rename it togo.d.plugin. - Extract the
config.tar.gzarchive to a temporarylocation and then copy the contents of the archive to/etc/netdataor the equivalent location for your build of Netdata.
Building the Go collectors locally
Alternatively, you may wish to build the Go collectors locally yourself. Doing so requires a working installation of Golang 1.13 or newer. Once you have the required tools, do the following:
- Verify the release version that Netdata expects to be used by checking
the contents of
packaging/go.d.versionin your Netdata sources. - Obtain the sources for that version by either:
- Navigating to https://github.com/netdata/go.d.plugin and downloading and unpacking the source code archive for that release.
- Cloning the repository with
gitand checking out the required tag.
- Run
makein the go.d.plugin source tree. - Copy
bin/godpluginto/usr/libexec/netdata/plugins.dor th equivalent location for your build of Netdata and rename it togo.d.plugin. - Copy the contents of the
configdirectory to/etc/netdataor the equivalent location for your build of Netdata.
eBPF collector
On Linux systems, Netdata has support for using the kernel's eBPF interface to monitor performance-related VFS, network, and process events, allowing for insights into process lifetimes and file access patterns. Using this functionality requires additional code managed in a separate repository from the core Netdata agent. You can either install a pre-built copy of the required code, or build it locally.
Installing the pre-built eBPF code
We provide pre-built copies of the eBPF code for 64-bit x86 systems using glibc or musl. To use one of these:
- Verify the release version that Netdata expects to be used by checking
the contents of
packaging/ebpf.versionin your Netdata sources. - Go to https://github.com/netdata/kernel-collector/releases, select the
required release, and download the
netdata-kernel-collector-*.tar.xzfile for the libc variant your system uses (either rmusl or glibc). - Extract the contents of the archive to a temporary location, and then
copy all of the
.oand.so.*files and the contents of thelibrary/directory to/usr/libexec/netdata/plugins.dor the equivalent location for your build of Netdata.
Building the eBPF code locally
Alternatively, you may wish to build the eBPF code locally yourself. For instructions, please consult the README file for our kernel-collector repository, which outlines both the required dependencies, as well as multiple options for building the code.