Dashborads not updating post update

[Paul]

Hi,

I have updated Wazuh to Ver 4.14 running on Ubuntu 24.04.3 LTS.

I have multiple Office 365 logs being ingested and i can see they are being received into Wazuh when I view through Explore-Discover.

I have multiple Dashboards setup, they were all working fine until 20:20 24/10/25 they are now no longer showing the updated events being received by Wazuh.

Indexer, Manager, Dashboard and Filebeat all running.

Any advise to help resolve appreciated.

Thanks Paul

[hasitha.u...@wazuh.com]

Hi Paul

In most cases (around 90%), missing alerts on the dashboard occur due to one of the following reasons:

• Indexer shard limit has been reached.

• Filebeat is not forwarding alerts from alerts.json to the indexer.

First, we need to confirm that all components have been properly upgraded.

Could you please clarify the issue further? Are you saying that no events are appearing in the Wazuh dashboard at all, or are only certain logs missing?

You can check the current versions of your Wazuh Manager, Indexer, and Dashboard using the following command:

For example:
apt list --installed wazuh-indexer
apt list --installed wazuh-manager
apt list --installed wazuh-dashboard
or
yum list installed wazuh-indexer
yum list installed wazuh-manager
yum list installed wazuh-dashboard

If some logs are missing, start by verifying whether new logs are being written to the alerts.json file using the following command:

tail /var/ossec/logs/alerts/alerts.json

If new alerts are appearing in alerts.json, it means the Manager is generating alerts, and the issue is likely between Filebeat and the Indexer.

Next, please share the output of this command to test the Filebeat connection:

filebeat test output

Then, restart both the Wazuh Indexer and Filebeat services to check if the issue gets resolved:

systemctl restart wazuh-indexer
systemctl restart filebeat

Also, please provide the relevant logs for further analysis:

Filebeat logs: 
cat /var/log/filebeat/filebeat | grep -i -E "error|warn"

Wazuh Indexer logs:
Check the log file name in /var/log/wazuh-indexer/, then run:
cat /var/log/wazuh-indexer/wazuh-cluster.log | grep -i -E "error|warn"

Finally, check the cluster health from either the Wazuh Web UI or CLI.

Web UI:
Navigate to Index Management → Dev Tools, then run:
GET _cluster/health

CLI:
curl -XGET -k -u <user>:<password> "https://<localhost or indexer_ip>:9200/_cluster/health"

(Use the same admin credentials you use to log in to the Wazuh Web UI.)

Please share the results of these commands so we can investigate the issue further.

[Paul]

Hi Hasitha,

wazuh-indexer/stable,now 4.14.0-1 amd64 [installed]

wazuh-manager/stable,now 4.14.0-1 amd64 [installed]
wazuh-dashboard/stable,now 4.14.0-1 amd64 [installed]

When i run: tail /var/ossec/logs/alerts/alerts.json: I can see alerts with current timestamp

filebeat test output:

elasticsearch: https://127.0.0.1:9200...
  parse url... OK
  connection...
    parse host... OK
    dns lookup... OK
    addresses: 127.0.0.1
    dial up... OK
  TLS...
    security: server's certificate chain verification is enabled
    handshake... OK
    TLS version: TLSv1.2
    dial up... OK
  talk to server... OK
  version: 7.10.2

cat /var/log/filebeat/filebeat | grep -i -E "error|warn":

nothing returned

cat /var/log/wazuh-indexer/wazuh-cluster.log | grep -i -E "error|warn":

I have attached the output in attached wazuh-cluster.txt

GET _cluster/health:

{
  "cluster_name": "wazuh-cluster",
  "status": "yellow",
  "timed_out": false,
  "number_of_nodes": 1,
  "number_of_data_nodes": 1,
  "discovered_master": true,
  "discovered_cluster_manager": true,
  "active_primary_shards": 355,
  "active_shards": 355,
  "relocating_shards": 0,
  "initializing_shards": 0,
  "unassigned_shards": 29,
  "delayed_unassigned_shards": 0,
  "number_of_pending_tasks": 0,
  "number_of_in_flight_fetch": 0,
  "task_max_waiting_in_queue_millis": 0,
  "active_shards_percent_as_number": 92.44791666666666
}

Many Thanks 

Paul 

[hasitha.u...@wazuh.com]

Hi Paul,

If the latest alerts are being received by the manager, it means there’s no issue on the manager's side.

Then, we need to make sure Filebeat is reading the alert files and sending them to the indexer. To do so, you may use the lsof command to verify Filebeat is reading the file and check the Filebeat connection. Please, share the output of the following commands:
lsof /var/ossec/logs/alerts/alerts.json

Also, share the full filebeat log file to check further.

This one indicates that [ca-wazuh-indexer-1] has not been initialized.

[2025-10-26T11:55:12,045][ERROR][o.o.s.a.BackendRegistry  ] [node-1] Not yet initialized (you may need to run securityadmin)

To address this, you could try running the following command:
/usr/share/wazuh-indexer/bin/indexer-security-init.sh

Additionally, I see you have 29 unassigned shards left. Could you share the following information?
Shards explain:
curl -k -u admin:<password> \
  -X GET "https://indexer-IP:9200/_cluster/allocation/explain?pretty"

Then, details about the unassigned shards:
curl -k -u admin:<password> \
  -X GET "https://indexer-IP:9200/_cat/shards?v" | grep UNASSIGNED

If you found any system indices that are unassigned (for example, indices starting with opendistro-* that are system indices of the Wazuh indexer.) Then you need to follow the steps below to remove them.

Please comment out the line
 plugins.security.system_indices.indices: [".opendistro-alerting-config", ...]
 by adding a # at the beginning:
#plugins.security.system_indices.indices: [".opendistro-alerting-config", ...]

Then, restart the indexer using:
systemctl restart wazuh-indexer

Alternatively, you can remove the unassigned index names from the
 plugins.security.system_indices.indices: [ ... ] line and restart the indexer service:
systemctl restart wazuh-indexer

After following one of the options then remove the unassigned shards.
curl --key /etc/wazuh-indexer/certs/admin-key.pem --cert /etc/wazuh-indexer/certs/admin.pem --insecure -XGET https://127.0.0.1:9200/_cat/shards?h=index,shard,prirep,state,unassigned.reason | grep UNASSIGNED | awk '{print $1}' | xargs -i curl --key /etc/wazuh-indexer/certs/admin-key.pem --cert /etc/wazuh-indexer/certs/admin.pem --insecure -XDELETE "https://127.0.0.1:9200/{}"

Also, try the above steps again after commenting or removing indices from the opensearch.yml file.
Replace 127.0.0.1 with the indexer’s IP address, or keep 127.0.0.1 if you are using an all-in-one setup.
Check the certificates' names for any name or path issues.
ls /etc/wazuh-indexer/certs/

Then, check again the cluster health and share the result, and share the output.

Let me know the update on this.

[Paul]

Hi Hasitha,

As this is in my lab and not business crital yet i have wiped the VM and done a fresh all-in-one setup which is now working.

Many Thanks

[hasitha.u...@wazuh.com]

Hi Paul,

Glad to hear the fresh setup got everything running smoothly.