Problem with office365 after server update

[Serhii Zahuba]

On Friday, I updated the server to 4.14.1 - the data from the agents was preserved, but after the update I don't have any new data from office365 in the default dashboard. I don't see any errors in the logs.

In alarm.json I see new logs from office365 but I don't see this on the web.

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

Hi Serhii,

By default, ruleset matches from the analysis engine write logs to /var/ossec/logs/alerts/alerts.json, not alarm.json. Could you please explain what alarm.json means alerts.json file?

It would be great to let me know all logs not showing in the dashboard, or office 365 logs only not showing in the dashboard.

If Office 365 logs are not showing in the dashboard, please verify again that logs are written to the alerts.json file and share the output.
cat /var/ossec/logs/alerts/alerts.json | grep -i -E "office365"

If the logs are written to the alerts.json file and not showing, check the rule level is 3 or higher. By default below 3 rule levels are not showing in the dashboard.
If the rule level is 3 or higher and still not seen in the dashboard, then check the filebeat and share the output.
filebeat test output
cat /var/log/filbeat/filebeat | grep -i -E "error|warn"
If filebeat looks fine, then try restarting: systemctl restart filebeat

If the issue still persists, then share the cluster health and the logs to check further.
Navigate to Index Management> Dev Tools
Use this command:
GET _cluster/health

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

Let me know the update on this.

Ref: 
https://documentation.wazuh.com/current/user-manual/manager/alert-management.html#alert-threshold

[Serhii Zahuba]

Hello

Sorry. Not alarm.json - i mean /var/ossec/logs/alerts/alerts.json

The main problem is that new events from Office365 are not visible in the dashboard.

Log example in alert.json

{"timestamp":"2025-11-19T11:55:30.210+0200","rule":{"level":3,"description":"Office 365: Events from Microsoft Teams.","id":"91555","firedtimes":21,"mail":false,"groups":["office365","MicrosoftTeams"],"hipaa":["164.312.b"],"pci_dss":["10.6.2"]},"agent":{"id":"000","name":"templates"},"manager":{"name":"templates"},"id":"1763546130.600115992","cluster":{"name":"wazuh","node":"master-node"},"decoder":{"name":"json"},"data":{"integration":"office365","office365":{"AppAccessContext":{"AADSessionId":"006f4479-e689-3239-7138-3b49527b4114","IssuedAtTime":"2025-11-19T09:00:50","UniqueTokenId":"Cxs4bMxCvXs8eAA"},"CreationTime":"2025-11-19T09:08:50","Id":"f4a9fcc9-5180-53ec-a897-c24241e76b05","Operation":"ReactedToMessage","OrganizationId":"df91ddb0-c807-4b5e-8","RecordType":"25","UserKey":"993440f3-f6db-4ca7-aae1c","UserType":"0","Version":"1","Workload":"MicrosoftTeams","ClientIP":"91.202.73.115","UserId":"us...@domain.ua","ChatThreadId":"19:79a9a9a2cf394bd0...@thread.v2","CommunicationType":"GroupChat","DeviceId":"41002e2d-dfc3-45a2-93ab-eb8f8bdb03f3","ExtraProperties":[{"Key":"TimeZone","Value":"Europe/Kiev"},{"Key":"OsName","Value":"windows"},{"Key":"OsVersion","Value":"NT 10.0"},{"Key":"Country","Value":"ua"},{"Key":"ClientName","Value":"skypeteams"},{"Key":"ClientVersion","Value":"49/25110202312"},{"Key":"ClientUtcOffsetSeconds","Value":"7200"}],"IsBilateral":"false","IsCopilotMentioned":"false","MessageId":"1763541239599","MessageReactionType":"laugh","MessageVersion":"1763543330740","ParticipantInfo":{"HasForeignTenantUsers":"false","HasGuestUsers":"false","HasOtherGuestUsers":"false","HasUnauthenticatedUsers":"false","ParticipatingDomains":[],"ParticipatingSIPDomains":[],"ParticipatingTenantIds":["df991f47c4"]},"ResourceTenantId":"df915e91791f47c4","ChatName":"77","Subscription":"Audit.General"}},"location":"office365"}

filebeat test output
elasticsearch: https://10.26.12.28:9200...
  parse url... OK
  connection...
    parse host... OK
    dns lookup... OK
    addresses: 10.26.12.28
    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"  no error




{
  "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": 46,
  "active_shards": 46,
  "relocating_shards": 0,
  "initializing_shards": 0,
  "unassigned_shards": 3,
  "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": 93.87755102040816

}


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

no error


Periodically I see one or two events appear on the dashboard, but this is rare, it feels like something is missing from the system.



Also i see 

tail -f /var/ossec/logs/ossec.log 

2025/11/19 11:51:50 wazuh-integratord: WARNING: Overlong JSON alert read from 'logs/alerts/alerts.json'

2025/11/19 11:52:15 wazuh-logcollector: WARNING: Target 'agent' message queue is full (1024). Log lines may be lost.
2025/11/19 11:53:29 rootcheck: INFO: Ending rootcheck scan.
2025/11/19 11:57:54 wazuh-integratord: WARNING: Overlong JSON alert read from 'logs/alerts/alerts.json'
2025/11/19 12:03:03 wazuh-modulesd:ms-graph: WARNING: Interval overtaken.
2025/11/19 12:03:03 wazuh-modulesd:ms-graph: INFO: Scanning tenant 'df91ddb0-c807-4b5e-89ac-5e91791f47c4'
2025/11/19 12:03:51 wazuh-integratord: WARNING: Overlong JSON alert read from 'logs/alerts/alerts.json'

вівторок, 18 листопада 2025 р. о 09:01:15 UTC+2 hasitha.u...@wazuh.com пише:

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

Hi Serhii

2025/11/19 12:03:51 wazuh-integratord: WARNING: Overlong JSON alert read from 'logs/alerts/alerts.json'

This warning message from the wazuh-integratord daemon indicates that the Wazuh Integrator module encountered an alert entry in /var/ossec/logs/alerts/alerts.json (or the equivalent path in your setup) that exceeds the maximum allowable size for processing. Specifically, more than 64 KB. As a result, the integrator skips that alert to avoid potential issues like memory exhaustion or parsing failures, but it continues processing subsequent alerts normally. This is a protective mechanism rather than a critical error, and your Wazuh setup should remain functional overall.

Regarding this error, I suggest you increase the queue size to avoid facing agent queue full issue.

2025/11/19 11:52:15 wazuh-logcollector: WARNING: Target 'agent' message queue is full (1024). Log lines may be lost.

By default, a single Wazuh agent can handle up to 1000 EPS, so distributing the load across seven collectors will help maintain performance and stability. 
The leaky bucket can be configured to adapt to any environment with the use of the following configuration options:
Throughput configuration
Threshold configuration

1. <client_buffer>
2.   <!-- Agent buffer options -->
3.   <disabled>no</disabled>
4.   <queue_size>5000</queue_size>
5.   <events_per_second>500</events_per_second>
6. </client_buffer>

queue_size
Default value: 5000
Allowed values: Any number between 1 and 100000.
events_per_second
Default value: 500
Allowed values: Any number between 1 and 1000.

I can see that your indexer cluster is yellow due to 3 unassigned shards.
Check the unassigned shards and their unassignment reason.
curl -k -XGET -u admin:<admin_user's_PASSWORD> "https://127.0.0.1:9200/_cat/shards?v=true&h=index,shard,prirep,state,node,unassigned.reason&s=state" | grep UNASSIGNED
curl -k -XGET -u admin:<admin_user's_PASSWORD> "https://127.0.0.1:9200/_cluster/allocation/explain?pretty"

You can remove unassigned shards if they are no longer needed. Use the following command to identify and delete them:
curl -k -XGET -u user:<password> "https://127.0.0.1:9200/_cat/shards" | grep UNASSIGNED | awk '{print $1}' | xargs -I {} curl -k -XDELETE -u user:<password> "https://<indexer_ip>:9200/{}"

After removing unassigned shards, check the cluster health, which has changed to green.

Also, please check if the Office 365 alerts are being stored in the alerts.json file, and cross-verify that they are not appearing on the dashboard.

Check the wazuh-analysisd.state file to identify any events dropped.
For example:
If non-zero, events are being discarded due to queue overflows, indicating manager overload: cat /var/ossec/var/run/wazuh-analysisd.state | grep events_dropped
Check for agent message drops: cat /var/ossec/var/run/wazuh-remoted.state | grep discarded

Let me know the update on this.