improve apps.plugin readme (#18705)
Ilya Mashchenko committed
Oct 7, 2024 at 12:05 UTC
baeb70090a65820b1dda94406010d34e64f5ead6
1 file changed
+85
-398
src/collectors/apps.plugin/README.md
+85
-398
@@ -4,134 +4,61 @@
4
5
## Process Aggregation and Grouping
6
7
-`apps.plugin` aggregates processes in three distinct ways to provide a more
8
-insightful breakdown of resource utilization:
7
+`apps.plugin` aggregates processes in three distinct ways to provide a more insightful breakdown of resource utilization:
8
10
-- **Tree** or **Category**: Grouped by their position in the process tree.
11
-<<<<<<< HEAD
12
- This is customizable and allows aggregation by process managers and
13
- individual processes of interest. Allows also renaming the processes for
14
- presentation purposes.
15
-
16
-- **User**: Grouped by the effective user (UID) under which the processes run.
17
-
18
-- **Group**: Grouped by the effective group (GID) under which the processes
19
- run.
9
+| Grouping | Description |
10
+|------------|----------------------------------------------------------------------------------------------------------------------------------------------------|
11
+| App | Grouped by the position in the process tree. This is customizable and allows aggregation by process managers and individual processes of interest. |
12
+| User | Grouped by the effective user (UID) under which the processes run. |
13
+| User Group | Grouped by the effective group (GID) under which the processes run. |
14
15
## Short-Lived Process Handling
16
23
-`apps.plugin` accounts for resource utilization of both running and exited
24
-processes, capturing the impact of processes that spawn short-lived
25
-subprocesses, such as shell scripts that fork hundreds or thousands of times
26
-per second. So, although processes may spawn short-lived sub-processes,
27
-`apps.plugin` will aggregate their resources utilization providing a holistic
28
-view of how resources are shared among the processes.
29
-=======
30
- This is customizable and allows aggregation by process managers and individual
31
- processes of interest. Allows also renaming the processes for presentation purposes.
32
-
33
-- **User**: Grouped by the effective user (UID) under which the processes run.
34
-
35
-- **Group**: Grouped by the effective group (GID) under which the processes run.
36
-
37
-## Short-Lived Process Handling
38
-
39
-`apps.plugin` accounts for resource utilization of both running and exited processes,
40
-capturing the impact of processes that spawn short-lived subprocesses, such as shell
41
-scripts that fork hundreds or thousands of times per second. So, although processes
42
-may spawn short lived sub-processes, `apps.plugin` will aggregate their resources
43
-utilization providing a holistic view of how resources are shared among the processes.
44
->>>>>>> fedac6cde (apps plugin docs pass)
45
-
46
-## Charts sections
47
-
48
-To provide more valuable insights, apps.plugin aggregates individual processes
49
-in several ways. Each type of aggregation is presented as a different section
50
-on the dashboard.
51
-
52
-### Custom Process Groups (Apps)
53
-
54
-<<<<<<< HEAD
55
-In this section, apps.plugin summarizes the resources consumed by all
56
-processes, grouped based on their position in the process tree and the groups
57
-provided in `/etc/netdata/apps_groups.conf`. You can edit this file using our
58
-[`edit-config`](/docs/netdata-agent/configuration/README.md#edit-a-configuration-file-using-edit-config) script.
59
-=======
60
-In this section, apps.plugin summarizes the resources consumed by all processes, grouped based
61
-on the groups provided in `/etc/netdata/apps_groups.conf`. You can edit this file using our [`edit-config`](/docs/netdata-agent/configuration/README.md#edit-a-configuration-file-using-edit-config) script.
62
->>>>>>> fedac6cde (apps plugin docs pass)
63
-
64
-For this section, `apps.plugin` builds a process tree (much like `ps fax` does
65
-in Linux), and groups processes together (evaluating both child and parent
66
-processes).
67
-
68
-### By User (Users)
69
-
70
-In this section, apps.plugin summarizes the resources consumed by all
71
-processes, grouped by the effective user under which each process runs.
72
-
73
-### By User Group (Groups)
74
-
75
-In this section, apps.plugin summarizes the resources consumed by all
76
-processes, grouped by the effective user group under which each process runs.
17
+`apps.plugin` accurately captures resource utilization for both running and exited processes, ensuring that the impact of short-lived subprocesses is fully accounted for.
18
+This is particularly valuable for scenarios where processes spawn numerous short-lived subprocesses, such as shell scripts that fork hundreds or thousands of times per second.
19
+Even though these subprocesses may have a brief lifespan, `apps.plugin` effectively aggregates their resource utilization, providing a comprehensive overview of how resources are shared among all processes within the system.
20
21
## Charts
22
80
-`apps.plugin` provides charts for 3 sections:
81
-
82
-1. Per application charts as **Applications** at Netdata dashboards
83
-2. Per user charts as **Users** at Netdata dashboards
84
-3. Per user group charts as **User Groups** at Netdata dashboards
23
+`apps.plugin` offers a set of charts for three groups within the **System->Processes** section of the Netdata dashboard: **Apps**, **Users**, and **Groups**.
24
86
-Each of these sections provides the same number of charts:
25
+Each of these sections presents the same number of charts:
26
88
-- CPU utilization (`apps.cpu`)
89
- - Total CPU usage
90
- - User/system CPU usage (`apps.cpu_user`/`apps.cpu_system`)
91
-- Disk I/O
92
- - Physical reads/writes (`apps.preads`/`apps.pwrites`)
93
- - Logical reads/writes (`apps.lreads`/`apps.lwrites`)
94
- - Open unique files (if a file is found open multiple times, it is counted just once, `apps.files`)
27
+- CPU utilization
28
+ - Total CPU usage
29
+ - User/system CPU usage
30
- Memory
96
- - Real Memory Used (non-shared, `apps.mem`)
97
- - Virtual Memory Allocated (`apps.vmem`)
98
- - Minor page faults (i.e. memory activity, `apps.minor_faults`)
99
-- Processes
100
- - Threads running (`apps.threads`)
101
- - Processes running (`apps.processes`)
102
- - Carried over uptime (since the last Netdata Agent restart, `apps.uptime`)
103
- - Minimum uptime (`apps.uptime_min`)
104
- - Average uptime (`apps.uptime_average`)
105
- - Maximum uptime (`apps.uptime_max`)
106
- - Pipes open (`apps.pipes`)
31
+ - Real Memory Used (non-shared)
32
+ - Virtual Memory Allocated
33
+ - Minor page faults (i.e. memory activity)
34
- Swap memory
108
- - Swap memory used (`apps.swap`)
109
- - Major page faults (i.e. swap activity, `apps.major_faults`)
110
-- Network
111
- - Sockets open (`apps.sockets`)
35
+ - Swap memory used
36
+ - Major page faults (i.e. swap activity)
37
+- Disk
38
+ - Physical reads/writes
39
+ - Logical reads/writes
40
+- Tasks
41
+ - Threads
42
+ - Processes
43
+- FDs
44
+ - Open file descriptors limit %
45
+ - Open file descriptors
46
+- Uptime
47
+ - Carried over uptime (since the last Netdata Agent restart)
48
49
In addition, if the [eBPF collector](/src/collectors/ebpf.plugin/README.md) is running, your dashboard will also show an
50
additional [list of charts](/src/collectors/ebpf.plugin/README.md#integration-with-appsplugin) using low-level Linux
51
metrics.
52
117
-The above are reported:
118
-
119
-- For **Applications** per target configured.
120
-- For **Users** per username or UID (when the username is not available).
121
-- For **User Groups** per group name or GID (when group name is not available).
122
-
53
## Performance
54
125
-We are proud that `apps.plugin` is a lot faster compared to any other similar
126
-tools, while collecting a lot more information for the processes, however the
127
-fact is that this plugin needs to traverse the entire process tree on every
128
-iteration, so its resources usage may be noticable.
55
+`apps.plugin` is designed to be highly efficient, collecting significantly more process information than other similar tools while maintaining exceptional speed.
56
+However, due to its comprehensive approach of traversing the entire process tree on each iteration, its resource usage may become noticeable, especially on systems with a large number of processes.
57
130
-Under Linux, for each process running, `apps.plugin` reads several `/proc`
131
-files per process. Doing this work per-second, especially on hosts with several
132
-thousands of processes, may increase the CPU resources consumed by the plugin.
58
+Under Linux, `apps.plugin` reads multiple `/proc` files for each running process, performing this operation on a per-second basis.
59
+This can lead to increased CPU consumption on hosts with several thousands of processes.
60
134
-In such cases, you many need to lower its data collection frequency.
61
+In such cases, you may need to adjust the data collection frequency to reduce the plugin's resource usage.
62
63
To do this, edit `/etc/netdata/netdata.conf` and find this section:
64
@@ -141,111 +68,87 @@ To do this, edit `/etc/netdata/netdata.conf` and find this section:
68
# command options =
69
```
70
144
-Uncomment the line `update every` and set it to a higher number. If you just
145
-set it to `2`, its CPU resources will be cut in half, and data collection will
146
-be once every 2 seconds.
71
+Uncomment the `update every` line and set it to a higher value.
72
+For example, setting it to 2 will halve the plugin's CPU usage and collect data once every 2 seconds.
73
74
## Configuration
75
150
-<<<<<<< HEAD
76
The configuration file is `/etc/netdata/apps_groups.conf`. You can edit this
77
file using our [`edit-config`](/docs/netdata-agent/configuration/README.md#edit-a-configuration-file-using-edit-config) script.
153
-=======
154
-The configuration file is `/etc/netdata/apps_groups.conf`. You can edit this file using our [`edit-config`](/docs/netdata-agent/configuration/README.md#edit-a-configuration-file-using-edit-config) script.
155
->>>>>>> fedac6cde (apps plugin docs pass)
78
79
### Configuring process managers
80
159
-`apps.plugin` needs to know the common process managers, the names of the processes
160
-which spawn other processes. Process managers help `apps.plugin` automatically
161
-consider all their sub-processes, important to monitor.
81
+`apps.plugin` needs to know the common process managers, which are the processes that spawn other processes.
82
+These process managers allow `apps.plugin` to automatically include their subprocesses in the monitoring process, ensuring that important processes are not overlooked.
83
163
-Process managers are configured in `apps_groups.conf` with the prefix
164
-`managers:`, like this:
84
+- Process managers are configured in the `apps_groups.conf` file using the `managers:` prefix, as follows:
85
166
-```text
167
-managers: process1 process2 process3
168
-```
86
+ ```text
87
+ managers: process1 process2 process3
88
+ ```
89
170
-Multiple lines may exist, all starting with `managers:`.
90
+- Multiple lines can be used to define additional process managers, all starting with `managers:`.
91
172
-A line `managers: clear` will clear all managers, so that a new list can be
173
-provided.
92
+- If you want to clear all existing process managers, you can use the line `managers: clear`. This will remove all previously configured managers, allowing you to provide a new list.
93
94
### Configuring interpreters
95
177
-Interpreted languages like `python`, `bash`, `sh`, `node` and more, may hide
178
-the actual name of a process.
96
+Interpreted languages like `python`, `bash`, `sh`, `node`, and others may obfuscate the actual name of a process.
97
180
-For such programs, `apps.plugin` can be instructed to check for the actual
181
-process name in one of the command line parameters of the program. When a
182
-process matches an interpreter, apps.plugin will go through all the parameters
183
-of the interpreter and find the first parameter that is an absolute filename
184
-existing on disk. When found, `apps.plugin` will name the process using
185
-the name of that filename.
98
+To address this, `apps.plugin` allows you to configure interpreters and specify that the actual process name can be found in one of the command-line parameters of the interpreter.
99
+When a process matches a configured interpreter, `apps.plugin` will examine all the parameters of the interpreter and locate the first parameter that is an absolute filename existing on disk. If such a filename is found, `apps.plugin` will name the process using the name of that filename.
100
187
-Interpreters are configured in `apps_groups.conf` with the prefix
188
-`interpreters:`, like this:
101
+- Interpreters are configured in the `apps_groups.conf` file using the `interpreters:` prefix, as follows:
102
103
```text
104
interpreters: process1 process2 process3
105
```
106
194
-Multiple lines may exist, all starting with `interpreters:`.
107
+- Multiple lines can be used to define additional process managers, all starting with `interpreters:`.
108
196
-A line `interpreters: clear` will clear all interpreters, so that a new list
197
-can be provided.
109
+- If you want to clear all existing process interpreters, you can use the line `interpreters: clear`. This will remove all previously configured interpreters, allowing you to provide a new list.
110
111
### Configuring process groups and renaming processes
112
201
-The configuration file works accepts multiple lines, each having this format:
113
+- The configuration file supports multiple lines, each following this format:
114
203
-```text
204
-group: process1 process2 ...
205
-```
115
+ ```text
116
+ group: process1 process2 ...
117
+ ```
118
207
-Each group can be given multiple times, to add more processes to it.
119
+- You can define a group multiple times to include additional processes within it.
120
209
-For each process given, all of its sub-processes will be grouped, not just the
210
-matched process.
121
+- For each process specified, all of its subprocesses will be automatically grouped, not just the matched process itself.
122
123
### Matching processes
124
214
-The process names are the ones returned by:
215
-
216
-- **comm**: `ps -e` or `cat /proc/{PID}/stat`
217
-- **cmdline**: in case of substring mode (see below): `/proc/{PID}/cmdline`
218
-
219
-On Linux **comm** is limited to 15 characters. `apps.plugin` attempts to find
220
-the entire **comm** name by looking for it at the **cmdline**. When this is
221
-successful, the entire process name is available, otherwise the shortened one
222
-is used.
125
+The following methods are used for matching against the specified patterns:
126
224
-To add process names with spaces, enclose them in quotes (single or double)
225
-example: `'Plex Media Serv'` or `"my other process"`.
127
+| Method | Description |
128
+|---------|----------------------------------------------------------------------|
129
+| comm | Process name as reported by `ps -e` or `cat /proc/{PID}/comm` |
130
+| cmdline | The complete command line (`cat /proc/{PID}/cmdline \| tr '\0' ' '`) |
131
227
-You can add asterisks (`*`) to provide a pattern:
132
+> On Linux, the **comm** field is limited to 15 characters.
133
+> `apps.plugin` attempts to obtain the full process name by searching for it in the **cmdline**.
134
+> If successful, the entire process name is used; otherwise, the shortened version is used.
135
229
-- `*name` _suffix_ mode: will match a **comm** ending with `name`.
230
-- `name*` _prefix_ mode: will match a **comm** beginning with `name`.
231
-- `*name*` _substring_ mode: will search for `name` in **cmdline**.
136
+You can use asterisks (`*`) to create patterns:
137
233
-Asterisks may appear in the middle of `name` (like `na*me`), without affecting
234
-what is being matched (**comm** or **cmdline**).
138
+| Mode | Pattern | Description |
139
+|-----------|----------|------------------------------------------|
140
+| prefix | `*name` | Matches a **comm** that begins with name |
141
+| suffix | `name*` | Matches a **comm** that ends with name |
142
+| substring | `*name*` | Searches for name within the **cmdline** |
143
236
-To add processes with single quotes, enclose them in double quotes:
237
-`"process with this ' single quote"`.
144
+- Asterisks can be placed anywhere within name (e.g., `na*me`) without affecting the matching criteria (**comm** or **cmdline**).
145
+- To include process names with spaces, enclose them in quotes (single or double), like this: `'Plex Media Serv'` or `"my other process"`.
146
+- To include processes with single quotes, enclose them in double quotes: `"process with this ' single quote"`.
147
+- To include processes with double quotes, enclose them in single quotes: `'process with this " double quote'`.
148
+- The order of the entries in the configuration list is crucial. The first matching entry will be used, so it's important to follow a top-down hierarchy. Processes that don't match any entry will inherit the group from their parent processes.
149
239
-To add processes with double quotes, enclose them in single quotes:
240
-`'process with this " double quote'`.
241
-
242
-The order of the entries in this list is important: the first one that matches
243
-a process is used, so follow a top-down hierarchy. Processes not matched by any
244
-row, will inherit it from their parents.
245
-
246
-There are a few command line options you can pass to `apps.plugin`. The list of
247
-available options can be acquired with the `--help` flag. The options can be
248
-set in the `netdata.conf` using the [`edit-config` script](/docs/netdata-agent/configuration/README.md).
150
+There are a few command line options you can pass to `apps.plugin`. The list of available options can be acquired with the `--help` flag.
151
+The options can be set in the `netdata.conf` using the [`edit-config` script](/docs/netdata-agent/configuration/README.md).
152
153
For example, to disable user and user group charts you would set:
154
@@ -259,235 +162,19 @@ For example, to disable user and user group charts you would set:
162
If you don't see charts under the **eBPF syscall** or **eBPF net** sections, you should edit your
163
[`ebpf.d.conf`](/src/collectors/ebpf.plugin/README.md#configure-the-ebpf-collector) file to ensure the eBPF program is enabled.
164
262
-Also see our [guide on troubleshooting apps with eBPF
263
-metrics](/docs/developer-and-contributor-corner/monitor-debug-applications-ebpf.md) for ideas on how to interpret these charts in a
264
-few scenarios.
165
+Also see our [guide on troubleshooting apps with eBPF metrics](/docs/developer-and-contributor-corner/monitor-debug-applications-ebpf.md) for ideas on how to interpret these charts in a few scenarios.
166
167
## Permissions
168
268
-`apps.plugin` requires additional privileges to collect all the information it needs.
269
-The problem is described in issue #157.
270
-
271
-When Netdata is installed, `apps.plugin` is given the capabilities `cap_dac_read_search,cap_sys_ptrace+ep`.
272
-If this fails (i.e. `setcap` fails), `apps.plugin` is setuid to `root`.
273
-
274
-### linux capabilities in containers
275
-
276
-There are a few cases, like `docker` and `virtuozzo` containers, where `setcap` succeeds, but the capabilities
277
-are silently ignored (in `lxc` containers `setcap` fails).
278
-
279
-In this case, you will have to setuid to root `apps.plugin` by running these commands:
280
-
281
-```sh
282
-chown root:netdata /usr/libexec/netdata/plugins.d/apps.plugin
283
-chmod 4750 /usr/libexec/netdata/plugins.d/apps.plugin
284
-```
169
+`apps.plugin` requires additional privileges to collect all the necessary information.
170
286
-You will have to run these, every time you update Netdata.
171
+During Netdata installation, `apps.plugin` is granted the `cap_dac_read_search` and `cap_sys_ptrace+ep` capabilities.
172
+If this fails (i.e., `setcap` fails), `apps.plugin` is setuid to `root`.
173
174
## Security
175
290
-`apps.plugin` performs a hard-coded function of building the process tree in memory,
291
-iterating forever, collecting metrics for each running process and sending them to Netdata.
292
-This is a one-way communication, from `apps.plugin` to Netdata.
293
-
294
-So, since `apps.plugin` cannot be instructed by Netdata for the actions it performs,
295
-we think it is pretty safe to allow it to have these increased privileges.
296
-
297
-Keep in mind that `apps.plugin` will still run without escalated permissions,
298
-but it will not be able to collect all the information.
299
-
300
-## Application Badges
301
-
302
-You can create badges that you can embed anywhere you like, with URLs like this:
303
-
304
-```text
305
-https://your.netdata.ip:19999/api/v1/badge.svg?chart=apps.processes&dimensions=myapp&value_color=green%3E0%7Cred
306
-```
307
-
308
-The color expression unescaped is this: `value_color=green>0|red`.
309
-
310
-Here is an example for the process group `sql` at `https://registry.my-netdata.io`:
311
-
312
-
313
-
314
-Netdata is able to give you a lot more badges for your app.
315
-Examples below for process group `sql`:
316
-
317
-- CPU usage: 
318
-- Disk Physical Reads 
319
-- Disk Physical Writes 
320
-- Disk Logical Reads 
321
-- Disk Logical Writes 
322
-- Open Files 
323
-- Real Memory 
324
-- Virtual Memory 
325
-- Swap Memory 
326
-- Minor Page Faults 
327
-- Processes 
328
-- Threads 
329
-- Major Faults (swap activity) 
330
-- Open Pipes 
331
-- Open Sockets 
332
-
333
-<!-- For more information about badges check [Generating Badges](/src/web/api/v2/api_v3_badge/README.md) -->
334
-
335
-## Comparison with console tools
336
-
337
-SSH to a server running Netdata and execute this:
338
-
339
-```sh
340
-while true; do ls -l /var/run >/dev/null; done
341
-```
342
-
343
-In most systems `/var/run` is a `tmpfs` device, so there is nothing that can stop this command
344
-from consuming entirely one of the CPU cores of the machine.
345
-
346
-As we will see below, **none** of the console performance monitoring tools can report that this
347
-command is using 100% CPU. They do report of course that the CPU is busy, but **they fail to
348
-identify the process that consumes so much CPU**.
349
-
350
-Here is what common Linux console monitoring tools report:
351
-
352
-### top
353
-
354
-`top` reports that `bash` is using just 14%.
355
-
356
-If you check the total system CPU utilization, it says there is no idle CPU at all, but `top`
357
-fails to provide a breakdown of the CPU consumption in the system. The sum of the CPU utilization
358
-of all processes reported by `top`, is 15.6%.
359
-
360
-```text
361
-top - 18:46:28 up 3 days, 20:14, 2 users, load average: 0.22, 0.05, 0.02
362
-Tasks: 76 total, 2 running, 74 sleeping, 0 stopped, 0 zombie
363
-%Cpu(s): 32.8 us, 65.6 sy, 0.0 ni, 0.0 id, 0.0 wa, 1.3 hi, 0.3 si, 0.0 st
364
-KiB Mem : 1016576 total, 244112 free, 52012 used, 720452 buff/cache
365
-KiB Swap: 0 total, 0 free, 0 used. 753712 avail Mem
366
-
367
- PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
368
-12789 root 20 0 14980 4180 3020 S 14.0 0.4 0:02.82 bash
369
- 9 root 20 0 0 0 0 S 1.0 0.0 0:22.36 rcuos/0
370
- 642 netdata 20 0 132024 20112 2660 S 0.3 2.0 14:26.29 netdata
371
-12522 netdata 20 0 9508 2476 1828 S 0.3 0.2 0:02.26 apps.plugin
372
- 1 root 20 0 67196 10216 7500 S 0.0 1.0 0:04.83 systemd
373
- 2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
374
-```
375
-
376
-### htop
377
-
378
-Exactly like `top`, `htop` is providing an incomplete breakdown of the system CPU utilization.
379
-
380
-```bash
381
- CPU[||||||||||||||||||||||||100.0%] Tasks: 27, 11 thr; 2 running
382
- Mem[||||||||||||||||||||85.4M/993M] Load average: 1.16 0.88 0.90
383
- Swp[ 0K/0K] Uptime: 3 days, 21:37:03
384
-
385
- PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
386
-12789 root 20 0 15104 4484 3208 S 14.0 0.4 10:57.15 -bash
387
- 7024 netdata 20 0 9544 2480 1744 S 0.7 0.2 0:00.88 /usr/libexec/netd
388
- 7009 netdata 20 0 138M 21016 2712 S 0.7 2.1 0:00.89 /usr/sbin/netdata
389
- 7012 netdata 20 0 138M 21016 2712 S 0.0 2.1 0:00.31 /usr/sbin/netdata
390
- 563 root 20 0 308M 202M 202M S 0.0 20.4 1:00.81 /usr/lib/systemd/
391
- 7019 netdata 20 0 138M 21016 2712 S 0.0 2.1 0:00.14 /usr/sbin/netdata
392
-```
393
-
394
-### atop
395
-
396
-`atop` also fails to break down CPU usage.
397
-
398
-```bash
399
-ATOP - localhost 2016/12/10 20:11:27 ----------- 10s elapsed
400
-PRC | sys 1.13s | user 0.43s | #proc 75 | #zombie 0 | #exit 5383 |
401
-CPU | sys 67% | user 31% | irq 2% | idle 0% | wait 0% |
402
-CPL | avg1 1.34 | avg5 1.05 | avg15 0.96 | csw 51346 | intr 10508 |
403
-MEM | tot 992.8M | free 211.5M | cache 470.0M | buff 87.2M | slab 164.7M |
404
-SWP | tot 0.0M | free 0.0M | | vmcom 207.6M | vmlim 496.4M |
405
-DSK | vda | busy 0% | read 0 | write 4 | avio 1.50 ms |
406
-NET | transport | tcpi 16 | tcpo 15 | udpi 0 | udpo 0 |
407
-NET | network | ipi 16 | ipo 15 | ipfrw 0 | deliv 16 |
408
-NET | eth0 ---- | pcki 16 | pcko 15 | si 1 Kbps | so 4 Kbps |
409
-
410
- PID SYSCPU USRCPU VGROW RGROW RDDSK WRDSK ST EXC S CPU CMD 1/600
411
-12789 0.98s 0.40s 0K 0K 0K 336K -- - S 14% bash
412
- 9 0.08s 0.00s 0K 0K 0K 0K -- - S 1% rcuos/0
413
- 7024 0.03s 0.00s 0K 0K 0K 0K -- - S 0% apps.plugin
414
- 7009 0.01s 0.01s 0K 0K 0K 4K -- - S 0% netdata
415
-```
416
-
417
-### glances
418
-
419
-And the same is true for `glances`. The system runs at 100%, but `glances` reports only 17%
420
-per process utilization.
421
-
422
-Note also, that being a `python` program, `glances` uses 1.6% CPU while it runs.
423
-
424
-```bash
425
-localhost Uptime: 3 days, 21:42:00
426
-
427
-CPU [100.0%] CPU 100.0% MEM 23.7% SWAP 0.0% LOAD 1-core
428
-MEM [ 23.7%] user: 30.9% total: 993M total: 0 1 min: 1.18
429
-SWAP [ 0.0%] system: 67.8% used: 236M used: 0 5 min: 1.08
430
- idle: 0.0% free: 757M free: 0 15 min: 1.00
431
-
432
-NETWORK Rx/s Tx/s TASKS 75 (90 thr), 1 run, 74 slp, 0 oth
433
-eth0 168b 2Kb
434
-eth1 0b 0b CPU% MEM% PID USER NI S Command
435
-lo 0b 0b 13.5 0.4 12789 root 0 S -bash
436
- 1.6 2.2 7025 root 0 R /usr/bin/python /u
437
-DISK I/O R/s W/s 1.0 0.0 9 root 0 S rcuos/0
438
-vda1 0 4K 0.3 0.2 7024 netdata 0 S /usr/libexec/netda
439
- 0.3 0.0 7 root 0 S rcu_sched
440
-FILE SYS Used Total 0.3 2.1 7009 netdata 0 S /usr/sbin/netdata
441
-/ (vda1) 1.56G 29.5G 0.0 0.0 17 root 0 S oom_reaper
442
-```
443
-
444
-### why does this happen?
445
-
446
-All the console tools report usage based on the processes found running _at the moment they
447
-examine the process tree_. So, they see just one `ls` command, which is actually very quick
448
-with minor CPU utilization. But the shell, is spawning hundreds of them, one after another
449
-(much like shell scripts do).
450
-
451
-### What does Netdata report?
452
-
453
-The total CPU utilization of the system:
454
-
455
-
456
-<br/>_**Figure 1**: The system overview section at Netdata, just a few seconds after the command was run_
457
-
458
-And at the applications `apps.plugin` breaks down CPU usage per application:
459
-
460
-
461
-<br/>_**Figure 2**: The Applications section at Netdata, just a few seconds after the command was run_
462
-
463
-So, the `ssh` session is using 95% CPU time.
464
-
465
-Why `ssh`?
466
-
467
-`apps.plugin` groups all processes based on its configuration file.
468
-The default configuration has nothing for `bash`, but it has for `sshd`, so Netdata accumulates
469
-all ssh sessions to a dimension on the charts, called `ssh`. This includes all the processes in
470
-the process tree of `sshd`, **including the exited children**.
471
-
472
-> Distributions based on `systemd`, provide another way to get cpu utilization per user session
473
-> or service running: control groups, or cgroups, commonly used as part of containers
474
-> `apps.plugin` does not use these mechanisms. The process grouping made by `apps.plugin` works
475
-> on any Linux, `systemd` based or not.
476
-
477
-#### a more technical description of how apps.plugin works
478
-
479
-Apps.plugin reads `/proc/<pid>/stat` for all processes, once per second and extracts `utime` and
480
-`stime` (user and system cpu utilization), much like all the console tools do.
481
-
482
-But it also extracts `cutime` and `cstime` that account the user and system time of the exit
483
-children of each process. By keeping a map in memory of the whole process tree, it is capable of
484
-assigning the right time to every process, taking into account all its exited children.
176
+`apps.plugin` operates on a one-way communication model, sending metrics to Netdata without receiving instructions. This design minimizes potential security risks.
177
486
-It is tricky, since a process may be running for 1 hour and once it exits, its parent should not
487
-receive the whole 1 hour of cpu time in just 1 second - you have to subtract the cpu time that has
488
-been reported for it prior to this iteration.
178
+Although `apps.plugin` can function without escalated privileges, it may not be able to collect all the necessary information. To ensure comprehensive data collection, it's recommended to grant the required privileges.
179
490
-It is even trickier, because walking through the entire process tree takes some time itself. So,
491
-if you sum the CPU utilization of all processes, you might have more CPU time than the reported
492
-total cpu time of the system. Netdata solves this, by adapting the per process cpu utilization to
493
-the total of the system. [Apps.plugin adds charts that document this normalization](https://london.my-netdata.io/default.html#menu_netdata_submenu_apps_plugin).
180
+The increased privileges are primarily used for building the process tree in memory, iterating over running processes, collecting metrics, and sending them to Netdata. This process does not involve any external communication or user interaction, further reducing security concerns.