Adapt Monitor class to allow child processes monitoring

[vicferpoy]

Since we added multiprocessing to the Wazuh cluster and API, we need to improve the Monitor class used for monitoring tasks to allow child processes monitoring:

wazuh-qa/deps/wazuh_testing/wazuh_testing/tools/performance/binary.py

Lines 25 to 45 in cc712b0

	class Monitor:
	"""Class to monitor a binary process and extract data referring to the CPU usage, memory consumption, etc.
	Args:
	process_name (str): name of the process to monitor.
	value_unit (str, optional): unit to store the bytes values. Defaults to KB.
	time_step (int, optional): time between each scan in seconds. Defaults to 1 second.
	version (str, optional): version of the binary. Defaults to None.
	dst_dir (str, optional): directory to store the CSVs. Defaults to temp directory.
	Attributes:
	process_name (str): name of the process to monitor.
	value_unit (str): unit to store the bytes values. Defaults to KB.
	time_step (int): time between each scan in seconds. Defaults to 1 second.
	version (str): version of the binary. Defaults to None.
	dst_dir (str): directory to store the CSVs. Defaults to temp directory.
	pid (int): PID of the process.
	event (thread.Event): thread Event used to control the scans.
	thread (thread): thread to scan the data.
	csv_file (str): path to the CSV file.
	"""

The design is yet to be decided and will be discussed on further issue comments.

[vicferpoy]

Issue update

We have decided to monitor each child process on its own, adding custom suffixes. For instance, running the following command:

wazuh-metrics -p wazuh-apid wazuh-clusterd

root@wazuh-master:/# ll /tmp

total 20
drwxrwxrwt. 1 root root  266 Nov 24 11:29 ./
drwxr-xr-x. 1 root root  362 Nov 24 11:13 ../
drwxr-xr-x. 1 root root   54 Nov 24 11:17 process_metrics/
-rw-r--r--. 1 root root 1045 Nov 24 11:17 wazuh-apid.csv
-rw-r--r--. 1 root root 1133 Nov 24 11:17 wazuh-apid_child_1.csv
-rw-r--r--. 1 root root 1133 Nov 24 11:17 wazuh-apid_child_2.csv
-rw-r--r--. 1 root root 1172 Nov 24 11:17 wazuh-clusterd.csv
-rw-r--r--. 1 root root 1268 Nov 24 11:17 wazuh-clusterd_child_1.csv

As for parent processes, the name will remain the same.

[vicferpoy]

Issue update

After some manual testing, I can confirm that the new implementation works as intended:

• Running processes

  3 API processes and 2 cluster processes.

root@wazuh-master:/# ps -edf ww | egrep "clusterd|apid"

wazuh         70       1  0 09:47 ?        Sl     0:10 /var/ossec/framework/python/bin/python3 /var/ossec/api/scripts/wazuh-apid.py
wazuh        575       1  0 09:47 ?        Sl     0:07 /var/ossec/framework/python/bin/python3 /var/ossec/framework/scripts/wazuh-clusterd.py
wazuh        963     575  0 09:47 ?        S      0:01 /var/ossec/framework/python/bin/python3 /var/ossec/framework/scripts/wazuh-clusterd.py
wazuh       1695      70  0 09:57 ?        S      0:00 /var/ossec/framework/python/bin/python3 /var/ossec/api/scripts/wazuh-apid.py
wazuh       1698      70  0 09:57 ?        S      0:00 /var/ossec/framework/python/bin/python3 /var/ossec/api/scripts/wazuh-apid.py

• After running wazuh-metrics

root@wazuh-master:/tmp# ll
total 20
drwxrwxrwt. 1 root root  234 Nov 25 09:57 ./
drwxr-xr-x. 1 root root  300 Nov 25 09:47 ../
drwxr-xr-x. 1 root root   54 Nov 25 09:57 process_metrics/
-rw-r--r--. 1 root root 3333 Nov 25 09:58 wazuh-apid.csv
-rw-r--r--. 1 root root 3743 Nov 25 09:58 wazuh-apid_child_1.csv
-rw-r--r--. 1 root root 3830 Nov 25 09:58 wazuh-apid_child_2.csv
-rw-r--r--. 1 root root 3620 Nov 25 09:58 wazuh-clusterd.csv
-rw-r--r--. 1 root root 4046 Nov 25 09:58 wazuh-clusterd_child_1.csv

However, the data-visualization CLI does not. It cannot plot all the CSV files:

root@wazuh-master:/tmp# data-visualizer -s /tmp/wazuh-apid.csv /tmp/wazuh-apid_child_1.csv /tmp/wazuh-apid_child_2.csv wazuh-clusterd.csv wazuh-clusterd_child_1.csv -t binary

[vicferpoy]

Issue update

A bug in the data-visualizer CLI was detected and fixed. Now, all CSV files are taken into account and plotted:

However, the wazuh-clusterd and wazuh-apid child processes are spawned on demand. This means that they will not be monitored in our automated tests as the monitoring tasks begins in a very early stage where these processes are not present yet. As this is a different issue, it will be solved in another one.