This section collects common installation or usage problems on the Wazuh app, and some basic steps to solve them.
The Wazuh app has a file named package.json, it includes dependencies along more information. One of them is the Kibana version:
Your app must match the installed Kibana version. If the version field in the package.json file is
6.7.2 then your installed Kibana version must be
You can check our compatibility matrix to learn more about product compatibility between Wazuh and the Elastic Stack.
Elasticsearch needs a specific template to store Wazuh alerts, otherwise visualizations won't load properly. You can insert the correct template using the following command:
# curl https://raw.githubusercontent.com/wazuh/wazuh/v3.11.4/extensions/elasticsearch/7.x/wazuh-template.json | curl -X PUT "http://localhost:9200/_template/wazuh" -H 'Content-Type: application/json' -d @-
Indices with the wrong template will need to be reindexed. You can follow our reindexation guide.
It means your Wazuh API could be unavailable. Since the Wazuh app needs data from the Wazuh API, it must be available for the Wazuh app.
If you are using
systemd, please check the status as follow:
# systemctl status wazuh-api
If you are using
SysV Init, please check the status as follow:
# service wazuh-api status
If the Wazuh API is running, try to fetch data using the CLI from the Kibana server:
# curl api_user:api_pass@api_url:55000/version
If the curl command fails but the Wazuh API is running properly, it means you have a connectivity problem between servers.
The first step is to check if there are alerts in Elasticsearch.
# curl <ELASTICSEARCH_IP>:9200/_cat/indices/wazuh-alerts-3.x-*
If you don't see any Wazuh related index, it means you have no alerts stored in Elasticsearch.
Check if Filebeat is reading the
# lsof /var/ossec/logs/alerts/alerts.json
There should be two processes reading the
The Wazuh app uses the Wazuh API to fetch information, being compatible between patch versions. For example, you can use an app designed for Wazuh 3.7.2 with a Wazuh API 3.7.1.
You can't use the 3.7.2 version of Wazuh API with a Wazuh app designed for Wazuh 3.11.4.
This error usually means that you're using Wazuh v2.x with Elastic Stack v6.x, or Wazuh v3.x with Elastic Stack v5.x.
You have to use the correct versions of Wazuh and the Elastic Stack to work properly. We always recommend upgrading to the latest version following this guide.
This error message appears when clicking on the View surrounding documents or View single document buttons from an alert on the Discover tab. This is due to a breaking change introduced on Wazuh 3.7.0.
In previous versions of Wazuh, the Elasticsearch template had these properties for the
As of Elastic Stack 6.4.x, the date format causes an error when viewing the surrounding documents, and to fix this, the Elasticsearch templated was updated:
This change is not critical and won't cause any data loss on Elasticsearch. For now, the only case where this issue appears is on the View surrounding documents option. After updating Wazuh and the Elastic Stack following our upgrading guide, the new template will be in use, and the next daily indices will be created using the new date format.
However, if you want to fix this problem for the affected indices, there are different options that you can try in order to correct them:
The following methods require stopping the Filebeat service before proceeding. After finishing, you can restart it again.
Reindex indices: The most basic form of reindexation consists of copying the documents from one index to another. In this case, we use this procedure to create a new index using the updated template, so we can then remove the old one, and finally, reindex the new index into the previous one.
On the Elasticsearch documentation you can find more info about the Reindex API.
Close indices: Closing an index will be blocked for read/write operations, so it won't be used when visualizing alerts on Kibana, although the data will be still available for archiving purposes.
On the Elasticsearch documentation you can find more info about the Open/Close index API.
Delete indices: This method is not suitable for production environments where all the data must be stored or archived. It's more convenient for testing environments, since it's the fastest method to fix the issue.
On the Elasticsearch documentation you can find more info about the Delete index API.
This breaking change could lead into a X of Y shards failed message because of the presence of old and new Elasticsearch indices using different templates, but it's not critical or harmful.
All the technologies we are using have their own logs files, you can check them and look for error and warning messages.
Check the Elastic Stack log files:
# cat /var/log/elasticsearch/elasticsearch.log | grep -i -E "error|warn" # cat /var/log/filebeat/filebeat | grep -i -E "error|warn"
By default, Kibana doesn't store logs on a file. It can be configured with the
logging.destsetting in the
kibana.ymlconfiguration file. Check the Kibana documentation for more details.
Check the Wazuh app log file:
# cat /usr/share/kibana/optimize/wazuh-logs/wazuhapp.log | grep -i -E "error|warn"
Check the Wazuh manager log file:
# cat /var/ossec/logs/ossec.log | grep -i -E "error|warn"