Wazuh version Component Install type Install method Platform

4.x Remoted/Analysisd/WazuhDB Manager Packages/Sources Linux

Wazuh version	Component	Install type	Install method	Platform
4.x	Remoted/Analysisd/WazuhDB	Manager	Packages/Sources	Linux

Description

Real-time statistics are very important to identify if the product is working as expected or if there is something wrong with it.

Wazuh manager already includes some statistics for the wazuh-remoted and wazuh-analysisd daemons, but many things could be improved:

Some counters need to be broken down into categories.
It is necessary to include some counters on the operations that are not being tracked.
It is necessary to add statistics for the wazuh-db daemon.
The statistics must be able to be consulted from the API in real-time.
The statistics could be more specific, such as applied to time intervals or to different agents.
Wazuh should be able to keep the counters after restarting the process.

Apr 11 '22 17:04 TomasTurina

I know this isn’t really a community thread, but for the benefit of unifying things, could the same functionality be applied to provide granular agent-side stats too?

Wazuh-Agent: agent_core: performance stats Log collector: counters/stats of monitored files Remoted: stats of logs sent per location (count, size etc)

Wazuh Manager: Logcollector: stats/counters per logsource/location Remoted: same as above (current stats/metrics aren’t granular enough to identify issues with specific logsources and reset between manager restarts). Modulesd: Wodle stats aren’t really monitored very well, these aren’t ingested via Remoted but modulesd needs a consistent method to report metrics.

But anyway, that’s just my input based on my experience as a member of the Wazuh community. :)

Jun 14 '22 19:06 hitman28594

Hi @hitman28594,

Thanks for your interest and input on this topic.

Wazuh currently has statistics that count events in daemons like wazuh-remoted, wazuh-analysisd, and wazuh-agentd. These statistics give an overview of the activity between the manager and the agents, but we identified that they could be improved to report more detailed information, such as identifying which are the modules or which are the agents that report more events.

As part of this development, we will do a more detailed breakdown of events, allowing us to identify very noisy modules or agents. This breakdown will be on the manager side, which has the control and the necessary information to identify the type and origin of the events.

In future iterations, we will consider adding even more granularity to event classification than was already introduced with these changes (for example, having statistics for each file monitored by wazuh-logcollector separately), as well as incorporating performance metrics.

Best regards.

Jun 21 '22 14:06 TomasTurina