Current application

The current healthcheck is a centralized path of each application that checks and creates the minimal items to work: such as index patterns (alerts, monitoring, statistics), edits some settings, checks the connection with Wazuh API server and version compatibility.

Some of these checks (index patterns and settings), create/edit items that depend on the selected tenant of the logged user.

Some checks are done when changing the URL path and could cause a redirection to the healthcheck. The http client can capture errors related to Wazuh server API connection and redirect to the heatlhcheck too.

Migration ideas

Localized checks

Run the localized checks in the application, page, or tab level that allows to decouple the checks but could increase the time between navigation. Implementing a cache system for the checks could reduce the check frequency.

Parallel process

Run the checks in a parallel way. Display the status with bottom bar, notifications.

Job in the backend side of Wazuh dashboard

Create items on the backend side when the Wazuh dashboard starts.

New store system for saved objects

Store the saved objects (index patterns, settings, future dashboards) into a new store. This could allow the initialization of the items as a job in the backend side of the Wazuh dashboard, but creates a different way to manage similar items. To solve this problem, maybe we could customize the items that are returned when fetching items related to an specific tenant: tenant + Wazuh central items info.

Meeting

We have decided to run a backend job to initialize the minimal items to work (TBD) when the Wazuh dashboard starts in the global tenant.

The setup of other tenants could need some manual step.

We should explore the possibility to setup the items depending on the tenant. This could allow to setup other tenants on demand.

Initialization service

I created a new service to manage the initiation tasks. This provides a mechanism to register tasks that will be run when the wazuCore plugin starts (plugin lifecycle). This approach allows the tasks can be registered by other plugins. Moreover I added some execution data that could be used in the future to display the task information in the UI.

Migrate health check tasks

The checks done in the health check of the frontend side must be migrated to the backend side as initiation tasks:

• Ensure the existence of index patterns (alerts, statistics, vulnerabilities-states, etc...)
• Check external index pattern templates
• Check connection and compatibility of the Wazuh server API with the Wazuh dashboard versions

Tasks tenant-dependant

For the tasks that manage data in the tenant, these will store data in the internal repository (global tenant when multitenancy is enabled).

For other tenants:
The tasks can be executed through API endpoints.

Checks

• Check connection with the Wazuh server API
• Check compatibility with the Wazuh server API
• Check existence of alerts index pattern (create if this does not exist)
• Check existence of monitoring index pattern (create if this does not exist)
• Check existence of statistics index pattern (create if this does not exist)
• Check existence of vulnerabilities-states index pattern (create if this does not exist)
• Check existence of defined template for the alerts index pattern

Update

I am working into adding some API endpoints to retrieve data or run initialization task user-scoped that could replace the current health check done in the frontend side.