5b83ab354 · cryptotaxi247/netdata-1

@@ -39,18 +39,96 @@ section for details.

39

40 ## Charts

41

42 -The eBPF collector creates an **eBPF** menu in the Agent's dashboard along with three sub-menus: **File**, **VFS**, and

43 -**Process**. All the charts in this section update every second. The collector stores the actual value inside of its

44 -process, but charts only show the difference between the values collected in the previous and current seconds.

42 +The eBPF collector creates an **eBPF** menu in the Agent's dashboard along with two sub-menus: **Socket**, and

43 +**Process**. The plugin also creates charts on different menus, like System Overview, Memory, Disks, Filesystem,

44 +Mount Points and Applications. All the charts in this section update every second.

45

46 -### File

46 +The collector stores the actual value inside of its process, but charts only show the difference between the values

47 +collected in the previous and current seconds.

48

48 -This group has two charts demonstrating how software interacts with the Linux kernel to open and close file descriptors.

49 +### System overview

50 +

51 +Not all charts within the System Overview menu are enabled by default, because they add around 100ns overhead for each

52 +function call, this number is small for a human perspective, but the functions are called many times creating an impact

53 +on host. See the [configuration](#configuration) section for details about how to enable them.

54 +

55 +#### Swap

56 +

57 +Inside the swap submenu the eBPF plugin creates the chart `swapcalls`; this chart is displaying when processes are calling

58 +functions `swap_readpage` and `swap_writepage`, which are functions responsible for doing IO in swap memory.

59 +

60 +### Memory

61 +

62 +In the memory submenu the eBPF plugin creates two submenus **page cache** and **synchronization** with the following

63 +organization:

64 +

65 +* Page Cache

66 + * Page cache ratio

67 + * Dirty pages

68 + * Page cache hits

69 + * Page cache misses

70 +* Synchronization

71 + * File sync

72 + * Memory map sync

73 + * File system sync

74 + * File range sync

75 +

76 +#### Page cache ratio

77 +

78 +The chart `cachestat_ratio` shows how processes are accessing page cache. In a normal scenario, we expect values around

79 +100%, which means that the majority of the work on the machine is processed in memory. To calculate the ratio Netdata

80 +monitors calls for kernel functions `add_to_page_cache_lru`, `mark_page_accessed`, `account_page_dirtied`, and

81 +`mark_buffer_dirty`.

82 +

83 +#### Dirty pages

84 +

85 +On `cachestat_dirties` Netdata demonstrates the number of pages that were modified. This chart shows the number of calls

86 +to the function `mark_buffer_dirty`.

87 +

88 +#### Page cache hits

89 +

90 +A page cache hit is when the page cache is successfully accessed with a read operation. We do not count pages that were

91 +added relatively recently.

92 +

93 +#### Page cache misses

94 +

95 +A page cache miss means that a page was not inside memory when the process tried to access it. This chart shows the result

96 +of the difference for calls between functions `add_to_page_cache_lru` and `account_page_dirtied`.

97 +

98 +#### File sync

99 +

100 +This chart shows calls to synchronization methods, `fsync(2)` and `fdatasync(2)`, to transfer all modified page caches

101 +for the files on disk devices. These calls block until the disk reports that the transfer has been completed. They flush

102 +data for specific file descriptors.

103 +

104 +#### Memory map sync

105 +

106 +The chart shows calls to `msync(2)` syscalls. This syscall flushes changes to a file that was mapped into memory using

107 +`mmap(2)`.

108 +

109 +#### File system sync

110 +

111 +This chart monitors calls demonstrating commits from filesystem caches to disk.

112 +

113 +#### File range sync

114 +

115 +This chart shows calls to `sync_file_range(2)` which synchronizes file segments with disk. This is the most dangerous

116 +syscall to synchronize data according to its manual.

117 +

118 +### Disk

119 +

120 +The eBPF plugin also shows a chart in the Disk section when the `disk` thread is enabled. This will create the

121 +chart `disk_latency_io` for each disk on the host. These charts use [tracepoints](https://www.kernel.org/doc/html/latest/trace/tracepoints.html)

122 +`block:block_rq_issue` and `block:block_rq_complete` to measure the latency of IO events.

123 +

124 +### Filesystem

125 +

126 +This group has two charts demonstrating how applications interact with the Linux kernel to open and close file descriptors.

127

128 #### File descriptor

129

130 This chart contains two dimensions that show the number of calls to the functions `do_sys_open` and `__close_fd`. Most

53 -software do not commonly call these functions directly, but they are behind the system calls `open(2)`, `openat(2)`,

131 +software doesn't commonly call these functions directly, they are behind the system calls `open(2)`, `openat(2)`,

132 and `close(2)`.

133

134 #### File error

@@ -59,13 +137,13 @@ This chart shows the number of times some software tried and failed to open or c

137

138 ### VFS

139

62 -A [virtual file system](https://en.wikipedia.org/wiki/Virtual_file_system) (VFS) is a layer on top of regular

63 -filesystems. The functions present inside this API are used for all filesystems, so it's possible the charts in this

64 -group won't show _all_ the actions that occurred on your system.

140 +A [virtual file system](https://en.wikipedia.org/wiki/Virtual_file_system) (VFS) is a layer on top of regular filesystems.

141 +The functions presented inside this API are not used for filesystems, so it's possible that the charts in this section

142 +won't show _all_ the actions that occurred on your system.

143

144 #### Deleted objects

145

68 -This chart monitors calls for `vfs_unlink`. This function is responsible for removing objects from the file system.

146 +This chart monitors calls to `vfs_unlink`. This function is responsible for removing objects from the file system.

147

148 #### IO

149

@@ -73,8 +151,8 @@ This chart shows the number of calls to the functions `vfs_read` and `vfs_write`

151

152 #### IO bytes

153

76 -This chart also monitors `vfs_read` and `vfs_write`, but instead shows the total of bytes read and written with these

77 -functions.

154 +This chart also monitors `vfs_read` and `vfs_write` but, instead of the number of calls, it shows the total amount of

155 +bytes read and written with these functions.

156

157 The Agent displays the number of bytes written as negative because they are moving down to disk.

158

@@ -84,40 +162,62 @@ The Agent counts and shows the number of instances where a running program exper

162

163 #### Create

164

87 -This chart shows the number of calls for `vfs_create`. This function is responsible to create files.

165 +This chart shows the number of calls to `vfs_create`. This function is responsible for creating files.

166

167 #### Synchronization

168

91 -This chart shows the number of calls for `vfs_fsync`. This function is responsible to perform a fsync or fdatasync

92 -on a file.

169 +This chart shows the number of calls to `vfs_fsync`. This function is responsible for calling `fsync(2)` or

170 +`fdatasync(2)` on a file. You can see more details in the Synchronization section.

171

172 #### Open

173

96 -This chart shows the number of calls for `vfs_open`. This function is responsible to open files.

174 +This chart shows the number of calls to `vfs_open`. This function is responsible for opening files.

175

98 -### Process

99 -

100 -For this group, the eBPF collector monitors process/thread creation and process end, and then displays any errors in the

101 -following charts.

176 +### eBPF

177

178 #### Process thread

179

180 Internally, the Linux kernel treats both processes and threads as `tasks`. To create a thread, the kernel offers a few

106 -system calls: `fork(2)`, `vfork(2)` and `clone(2)`. In turn, each of these system calls use the function `_do_fork`. To

107 -generate this chart, the eBPF collector monitors `_do_fork` to populate the `process` dimension, and monitors

108 -`sys_clone` to identify threads.

181 +system calls: `fork(2)`, `vfork(2)`, and `clone(2)`. In turn, each of these system calls uses either the function

182 +`_do_fork` (kernel older than `5.10.0`) or the function `do_fork` (latest kernels). To generate this chart, the eBPF

183 +collector monitors the cited functions to populate the `process` dimension, and monitors `sys_clone` to identify threads.

184

185 #### Exit

186

187 Ending a task requires two steps. The first is a call to the internal function `do_exit`, which notifies the operating

188 system that the task is finishing its work. The second step is to release the kernel information with the internal

114 -function `release_task`. The difference between the two dimensions can help you discover [zombie

115 -processes](https://en.wikipedia.org/wiki/Zombie_process).

189 +function `release_task`. The difference between the two dimensions can help you discover

190 +[zombie processes](https://en.wikipedia.org/wiki/Zombie_process).

191

192 #### Task error

193

194 The functions responsible for ending tasks do not return values, so this chart contains information about failures on

120 -process and thread creation.

195 +process and thread creation only.

196 +

197 +#### TCP functions

198 +

199 +This chart demonstrates calls to functions `tcp_sendmsg`, `tcp_cleanup_rbuf`, and `tcp_close`; these functions are

200 +used to send & receive data and to close connections when `TCP` protocol is used.

201 +

202 +#### TCP bandwidth

203 +

204 +Like the previous chart, this one also monitors `tcp_sendmsg` and `tcp_cleanup_rbuf`, but instead of showing the

205 +number of calls, it demonstrates the number of bytes sent and received.

206 +

207 +#### TCP retransmit

208 +

209 +This chart demonstrates calls to function `tcp_retransmit` that is responsible for executing TCP retransmission when the

210 +receiver did not return the packet during the expected time.

211 +

212 +#### UDP functions

213 +

214 +This chart demonstrates calls to functions `udp_sendmsg` and `udp_recvmsg`, which are responsible for sending &

215 +receiving data for connections when the `UDP` protocol is used.

216 +

217 +#### UDP bandwidth

218 +

219 +Like the previous chart, this one also monitors `udp_sendmsg` and `udp_recvmsg`, but instead of showing the

220 +number of calls, it monitors the number of bytes sent and received.

221

222 ## Configuration

223

@@ -147,7 +247,7 @@ cd /etc/netdata/ # Replace with your Netdata configuration directory, if not /

247

248 The `[global]` section defines settings for the whole eBPF collector.

249

150 -#### ebpf load mode

250 +#### eBPF load mode

251

252 The collector has two different eBPF programs. These programs monitor the same functions inside the kernel, but they

253 monitor, process, and display different kinds of information.

Update ebpf documentation (#11440)