Define the format of the logs and add the missing logs to the new logger

[TomasTurina]

Description

The new agent has a logger that is responsible for writing the various program outputs to the wazuh.log file (among other options). The format of the logs is still to be defined, so that they are the same regardless of the OS and logging system used. In addition, some logs are already being written through this logger, but many more are missing.

As part of this issue, the following tasks must be performed:

• Define a common format for logs.
• Identify the hardcoded logs and the ones that are currently missing.
• Categorize them according to the correct type (Error, Warning, Info, Debug).
• Move or add them to the logger.
• Have the different components/modules that write outputs do so through the new logger.
• Add .clang-format and .clang-tidy files to enable checks in this module.
• Check the behavior of the diferents sinks working on a docker container.

Some considerations:

• Error and warning messages should be consistent and generic, they should be the same in all components.
  • They are recoverable problems, they should not carry additional information.
  • There should be an option to enable debug mode to see more information about the specific error (including the format).
• For fatal errors, i.e. errors that cannot be recovered, the context should always be reported without the need to activate debug mode.
  • Evaluate the possibility of displaying the stack trace.
• Centralize the location of the logs and organize them with error codes, differentiating between generic errors and errors specific to certain modules.

[sdvendramini]

As proposed in this issue:

• Investigate and implement a logger in the new agent #92

we believe that the proper log format should contain this information:

• Date
• Process name and PID
• Level
• Filename and line
• Function name
• Message

But according to the possible implementations for each OS there may be some differences. These differences can make it more difficult to parse the logs when they are processed by the manager, so we believe that a common criteria should be defined for all platforms.

In linux we have the possibility of using systemd or syslog. the first one gives the possibility to represent these data as follows:

Sep 09 11:16:12 jellyfish wazuh-agent[64015]: [INFO] [main.cpp:15] [main] Starting Wazuh Agent.

In this case we cannot duplicate the date, name and PID data since systemd handles them on its own.

And the second one, syslog, does give the possibility to send to journalctl a complete log with the data as it comes out of wazuh-agent.

Sep 09 11:16:12 jellyfish wazuh-agent[64015]: [2024-09-09 11:16:12.752] [wazuh-agent] [64015] [INFO] [main.cpp:15] [main] Starting Wazuh Agent.

in this case the data is duplicated, but for example the date format would not depend on the local journald configuration.

In the case of windows, it is possible to add all the necessary data in the message body, but it is a complete event, totally different from Unix-based logs.
We can generate something like this in the body of the event:

16-09-2024 15:25:23.935 [3296] [wazuh-agent] [INFO] [main.cpp:59] [main] Starting Wazuh Agent.

In the case of macOS, the backend used by the library is also syslog, so we could define in the message body all the data needed to parse the message.

2024-09-10 11:45:09.832125+0200 0x66f1 Default 0x0 3488 0 Wazuh-agent: 10-09-2024 11:45:09.827 [3488] [wazuh-agent] [ERROR] [main.cpp:38] [myMethod] This is an error message.

in this case also the data is duplicated, because the first part also contains data added by log show.