Troubleshooting
This section collects common installation or usage problems on the Wazuh app, and some basic steps to solve them.
"Incorrect Kibana version in plugin [wazuh]" when installing the app
The Wazuh app has a file named package.json, it includes dependencies along more information. One of them is the Kibana version:
"kibana": {
"version": "6.7.2"
},
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 6.7.2
.
You can check our compatibility matrix to learn more about product compatibility between Wazuh and the Elastic Stack.
No template found for the selected index pattern
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.9.5/extensions/elasticsearch/7.x/wazuh-template.json | curl -X PUT "http://localhost:9200/_template/wazuh" -H 'Content-Type: application/json' -d @-
{"acknowledged":true}
Warning
Indices with the wrong template will need to be reindexed. You can follow our reindexation guide.
Wazuh API seems to be down
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.
I don't see alerts in the Wazuh app
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 alerts.json
file:
# lsof /var/ossec/logs/alerts/alerts.json
There should be two processes reading the alerts.json
file: ossec-analysisd
and filebeat
.
API version mismatch. Expected vX.Y.Z
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.9.5.
Routes. Error. Cannot read property 'manager' of undefined
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.
Failed to parse date field with format dateOptionalTime
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 @timestamp
field:
"@timestamp": {
"type": "date",
"format": "dateOptionalTime"
},
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:
"@timestamp": {
"type": "date"
},
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:
Warning
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.
None of the above solutions are fixing my problem
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"
Note
The Elastic Stack uses the
/var/log
folder to store logs by default. This setting can be customized following the documentation for Elasticsearch or Filebeat.Warning
By default, Kibana doesn't store logs on a file. It can be configured with the
logging.dest
setting in thekibana.yml
configuration 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"
You can also open a new thread in our Google mailing list, or a new issue in our GitHub repository.