Wazuh Dashboard Aggregations Failing
Shady Mohamed
Hello,
I am facing an issue where all visualizations in the Wazuh Dashboard fail when using aggregations.
The error shown is:
null_pointer_exception
reducePhase.aggregations is null
The failing request:
POST /internal/search/opensearch → 400 Bad Request
Environment:
- Wazuh: 4.14.3
- Wazuh Dashboard: 4.14.3
- OS: Ubuntu 24.04
- Single-node deployment
Findings:
- The issue occurs with terms aggregations across multiple fields, not limited to a specific field
- Aggregations fail when using standard text fields
- The same aggregations work correctly when using corresponding .keyword fields
- Some shard failures occur during queries with errors like:
"Text fields are not optimised for aggregations" - There appears to be a mapping inconsistency across indices, where some fields are mapped differently (text vs keyword)
Could you please advise on the next steps to further troubleshoot this issue?
Please let me know if you need any additional logs or outputs.
Thank you.
Bony V John
Bony V John
Hi,
The issue you are facing might be due to a field mapping conflict. In your older index, certain fields may be mapped as keyword, while in newer indices they might be mapped as text or another data type. This mismatch can lead to issues such as shard failures or problems while creating dashboards.
Have you made any configuration changes before encountering this issue? If so, please let us know.
You can also identify the conflicting fields from the Wazuh dashboard:
- Go to the hamburger menu (top left)
- Navigate to Dashboard Management > Dashboards Management > Index Patterns > wazuh-alerts-*
- On the right side of the search bar, check if there is a “conflict” filter in the dropdown
- Select it to list all fields with mapping conflicts
Click on each conflicting field and compare the data type between the old and new indices. Based on this, you may need to update the index template to match the correct data type and reindex the affected indices to resolve the issue.
Please share screenshots of the fields showing conflicts.
Additionally, run the following command in Dev Tools to inspect the index mapping:
- Go to the hamburger menu → Indexer Management → Dev Tools
- Run:
Replace <date> with:
- An older index (working correctly)
- A newer index (showing the issue)
Share both outputs so we can compare them.
Replace <password> with your Wazuh dashboard admin credentials.
This will help us verify if any custom index templates are causing the conflict.
Shady Mohamed
Hello,
Thank you for your guidance.
Findings:
- The index pattern shows multiple fields with mapping conflicts (screenshot attached).
- When filtering by rule.id, both:
- rule.id
- rule.id.keyword
are present and aggregatable in the index pattern.
Critical observation:
There is an inconsistency in the mapping of the same field across indices:
In older indices (e.g. wazuh-alerts-4.x-2025.12.18):
rule.id → keywordIn newer indices (e.g. wazuh-alerts-4.x-2026.03.16):
rule.id → text (with keyword subfield)
This mismatch is confirmed via Dev Tools (screenshots attached).
Impact:
- Aggregations on rule.id (or any terms-based visualization) cause:
- shard failures
- illegal_argument_exception
and eventually:
reducePhase.aggregations is null null_pointer_exception
- The issue is not limited to the rule.id only — it affects multiple fields with similar mapping inconsistencies.
Notes:
- This issue started after changing the Wazuh server IP.
- TLS/certificate issues have already been resolved, but the visualization problem persists.
- Recreating index patterns and restarting services did not resolve the issue.
I am also attaching the additional requested files:
- Filebeat template: wazuh-template.json
- Index templates output from the Wazuh indexer: templates.json
Please review and advise.
Thank you.
Bony V John
Hi,
From the screenshot you shared, it appears that the issue is related to field data type conflicts. Because of this, the affected fields are causing mapping conflicts. To resolve the issue, we need to correct the field data types and then reindex the newer indices that are showing the conflict.
You can run the following command in the Wazuh dashboard Dev Tools to set the field mappings correctly.
On the Wazuh dashboard, go to: Hamburger menu > Indexer Management > Dev Tools
Then run:
{
"index_patterns": ["wazuh-alerts-4.x-*"],
"template": {
"mappings": {
"properties": {
"rule": {
"properties": {
"id": {
"type": "keyword"
}
}
},
"GeoLocation": {
"properties": {
"location": {
"type": "geo_point"
}
}
},
"data": {
"properties": {
"sca": {
"properties": {
"failed": {
"type": "integer"
},
"passed": {
"type": "integer"
},
"score": {
"type": "long"
}
}
}
}
},
"syscheck": {
"properties": {
"inode_after": {
"type": "keyword"
},
"inode_before": {
"type": "keyword"
},
"size_after": {
"type": "long"
},
"size_before": {
"type": "long"
}
}
}
}
}
}
}
If the command executes successfully, you should see a 200 OK status at the top right.
After that, you need to reindex the newer indices that are showing this issue.
First, identify the affected indices.
To list all indices, run:
GET /wazuh-alerts-4.x-2026.03.02
After identifying which indices need reindexing, reindex each one individually. Below is an example for wazuh-alerts-4.x-2026.03.02:
Take a backup of the index:
POST _reindex
{
"source": {
"index": "wazuh-alerts-4.x-2026.03.02"
},
"dest": {
"index": "wazuh-alerts-4.x-backup"
}
}
Delete the original index:
DELETE /wazuh-alerts-4.x-2026.03.02
Reindex from the backup into the original index name:
POST _reindex
{
"source": {
"index": "wazuh-alerts-4.x-backup"
},
"dest": {
"index": "wazuh-alerts-4.x-2026.03.02"
}
}
Delete the backup index:
DELETE /wazuh-alerts-4.x-backup
After that, you can verify whether the field type has changed:
GET /wazuh-alerts-4.x-2026.03.02
You can refer to the Wazuh documentation for more details about reindexing.