master
md 115 lines 5.44 KB
Rendered Raw
1 # Manually build Netdata from source
2
3 These instructions are for advanced users and distribution package
4 maintainers. Unless this describes you, you almost certainly want
5 to follow [our guide for manually installing Netdata from a git
6 checkout](/packaging/installer/methods/manual.md) instead.
7
8 ## Required dependencies
9
10 At a bare minimum, Netdata requires the following libraries and tools
11 to build and run successfully:
12
13 - libuuid
14 - libuv version 1.0 or newer
15 - zlib
16 - CMake 3.16.0 or newer
17 - GCC or Xcode (Clang is known to have issues in certain configurations, see [Using Clang](#using-clang))
18 - Ninja or Make (Ninja is preferred as it results in significantly faster builds)
19 - Git (we use git in the build system to generate version info, you don't need a full install, just a working `git show` command)
20 - OpenSSL 1.0.2 or newer, or LibreSSL 3.0.0 or newer
21 - liblz4 r129 or newer
22 - libcurl 7.21 or newer
23
24 The following additional dependencies are also needed, but will be prepared automatically by CMake if they are not available on the build system.
25
26 - libyaml
27 - JSON-C
28
29 Additionally, the following build time features require additional dependencies:
30
31 - Netdata Cloud support:
32 - A working internet connection
33 - protobuf (Google Protocol Buffers) and protoc compiler. If protobuf is not available on the system,
34 CMake can be instructed to fetch and build a usable version for Netdata.
35 - Netdata Go collectors:
36 - Go (the minimum required version is determined by the `go` directive in `src/go/go.mod`)
37
38 ## Preparing the source tree
39
40 Netdata uses Git submodules for some of it’s components, which must be fetched prior to building Netdata. If you
41 are using a source tarball published by the Netdata project, then these are included. If you are using a checkout
42 of the Git repository, you may need to explicitly fetch and update the submodules using `git submodule update
43 --init --recursive`.
44
45 ## Building Netdata
46
47 Once the source tree has been prepared, Netdata is ready to be configured
48 and built. Netdata uses CMake for configuration, and strongly prefers
49 the use of an external build directory. To configure and build Netdata:
50
51 1. Run `cmake -S . -B build -G Ninja` in the source tree. `build` can be replaced with whatever path you want for the build directory. If you wish to use Make instead of Ninja for the build, remove the `-G Ninja` from the command.
52 2. Run `cmake --build build`, where `build` is the build directory. CMake’s `--parallel` option can be used to control the number of build jobs that are used.
53 3. Run `cmake --install build`, where `build` is the build directory.
54
55 ### Configure options
56
57 Netdata’s CMake build infrastructure intentionally does very little auto-detection, and requires most components
58 to be explicitly enabled or disabled. A full list of available configuration options for a given version of Netdata,
59 with help descriptions, can be seen by running `cmake -LH` in the source tree.
60
61 ### Using Clang
62
63 Netdata is primarily developed using GCC, but in most cases we also
64 build just fine using Clang. Under some build configurations of Clang
65 itself, you may see build failures with the linker reporting errors
66 about `nonrepresentable section on output`. We currently do not have a
67 conclusive fix for this issue (the obvious fix leads to other issues which
68 we haven't been able to fix yet), and unfortunately the only workaround
69 is to use a different build of Clang or to use GCC.
70
71 ### Linking errors relating to OpenSSL
72
73 Netdata's build system currently does not reliably support building
74 on systems which have multiple ABI incompatible versions of OpenSSL
75 installed. In such situations, you may encounter linking errors due to
76 Netdata trying to build against headers for one version but link to a
77 different version.
78
79 ## Additional components
80
81 A full featured install of Netdata requires some additional components
82 which must be built and installed separately from the main Netdata
83 agent. All of these should be handled _after_ installing Netdata itself.
84
85 ### eBPF collector
86
87 On Linux systems, Netdata has support for using the kernel's eBPF
88 interface to monitor performance-related VFS, network, and process events,
89 allowing for insights into process lifetimes and file access
90 patterns. Using this functionality requires additional code managed in
91 a separate repository from the core Netdata Agent. You can either install
92 a pre-built copy of the required code, or build it locally.
93
94 #### Installing the pre-built eBPF code
95
96 We provide pre-built copies of the eBPF code for 64-bit x86 systems
97 using glibc or musl. To use one of these:
98
99 1. Verify the release version that Netdata expects to be used by checking
100 the contents of `packaging/ebpf.version` in your Netdata sources.
101 2. Go to <https://github.com/netdata/kernel-collector/releases>, select the
102 required release, and download the `netdata-kernel-collector-*.tar.xz`
103 file for the libc variant your system uses (either rmusl or glibc).
104 3. Extract the contents of the archive to a temporary location, and then
105 copy all of the `.o` and `.so.*` files and the contents of the `library/`
106 directory to `/usr/libexec/netdata/plugins.d` or the equivalent location
107 for your build of Netdata.
108
109 #### Building the eBPF code locally
110
111 Alternatively, you may wish to build the eBPF code locally yourself. For
112 instructions, please consult [the README file for our kernel-collector
113 repository](https://github.com/netdata/kernel-collector/#readme),
114 which outlines both the required dependencies, as well as multiple
115 options for building the code.