Indexer pattern conflic

[Varad Gunjkar]

Hi Team,

I am getting indexer pattern conflict for o365 due to which data is not visualizing in o365 dashboard. I have attached snapshot for reference. All config is proper. How to fix this?

[Bony V John]

Hi,

Could you please check whether alerts related to Office 365 are being triggered and written to the alerts.json file on the Wazuh manager?

To verify, run the following command on the Wazuh manager server:

cat /var/ossec/logs/alerts/alerts.json | grep =iE "office365"

This will search for any Office 365-related alerts in the alerts.json file. Please confirm if such alerts are present.

If no alerts are found, proceed with the following steps:  

Check for errors in the Wazuh manager log, run this command to look for any error messages in ossec.log:

cat /var/ossec/logs/ossec.log | grep -iE "error|warn|crit|fatal"

Validate your Office 365 configuration, review your Wazuh manager’s ossec.conf configuration file to ensure the Office 365 integration is set up correctly. You can refer to the Wazuh documentation for guidance.

If the alerts are present in the alerts.json file:  

Check Filebeat status, run the following command to test Filebeat output:

filebeat test output

Review Filebeat logs, check for any error messages in the Filebeat logs:

cat /var/log/filebeat/filebeat | grep -iE "error|warn|crit|fatal"

If there’s a mapping conflict or other ingestion issue, this command should reveal it.  

Check the index pattern in the Wazuh dashboard:

From the Wazuh Dashboard:

• Click the hamburger icon in the top-left corner

• Go to Stack Management > Index Patterns

• Click on the wazuh-alerts index pattern

• Look for any fields marked with a conflict warning

This helps identify mapping issues that could prevent logs from appearing in the dashboard.

Check Wazuh Indexer logs, run this command on the Wazuh Indexer server to look for critical issues:

cat /var/log/wazuh-indexer/wazuh-cluster.log | grep -iE "error|warn|crit|fatal"

For further analysis, please share the findings from the above steps along with the full output of the commands executed.  

[Varad Gunjkar]

[Varad Gunjkar]

On Monday, May 26, 2025 at 9:36:09 AM UTC+5:30 Varad Gunjkar wrote:

[Bony V John]

Hi,

Have you made any changes in the /etc/filebeat/wazuh-template.json file on the Wazuh manager server before encountering this issue?

From the shared screenshot, it appears that the field data.office365.AdditionalInfo has a mapping conflict issue with the datatype.

To resolve this issue, try reindexing all the indices that are showing this mapping conflict.

Follow the steps below to perform reindexing from the Wazuh dashboard:

In the Wazuh dashboard, click on the hamburger icon at the top left > Index Management > Dev Tools.

Run the following API command in the Dev tool console to get the names of all available indices:

GET _cat/indices

Take a backup of the index for that run the following command, replacing wazuh-alerts-4.x-2023.04.24 with index name that you want to reindex:
POST _reindex
{
  "source": {
    "index": "wazuh-alerts-4.x-2023.04.24"
  },
  "dest": {
    "index": "wazuh-alerts-4.x-backup"
  }
}

Delete the original index:
DELETE /wazuh-alerts-4.x-2023.04.24

Reindex from backup:
POST _reindex
{
  "source": {
    "index": "wazuh-alerts-4.x-backup"
  },
  "dest": {
    "index": "wazuh-alerts-4.x-2023.04.24"
  }
}

Delete the backup index:
DELETE /wazuh-alerts-4.x-backup

Repeat these steps for any other indices that are showing field conflict issues.
You can also refer to the Wazuh reindexing documentation for more details.

[Varad Gunjkar]

Hi Team,

I tried this, but each index is around 30GB, and it's taking a longer time to create a backup of each file. As you saw in the above image, there are multiple indexes on which the conflict has occurred, it will take months to fix this way.

[Bony V John]

Hi,

Apologies for the late response. In the screenshot you shared, it shows that the field office365.AdditionalInfo has two conflicting data types: keyword and object. To resolve this and prevent such conflicts in the future, I recommend disabling the office365.AdditionalInfo field in the Filebeat template and then re-indexing the data.

Please follow the steps below to disable the field:

To avoid misconfiguration issues, first, take a backup of the wazuh-template.json file by running the following command on the Wazuh Manager server:
cp /etc/filebeat/wazuh-template.json /root/copy-wazuh-template.json

Run the following command to stop filebeat:
systemctl stop filebeat

Open the wazuh-template.json file for editing:
vi /etc/filebeat/wazuh-template.json

Search for the office365 field, and within that section, add the following to disable the AdditionalInfo field:  

"AdditionalInfo": {
                "enabled": false
              },

I have attached a screenshot showing how the configuration should look.  

After making these changes, save the file and exit.

Run the following command to insert the updated template:
sudo filebeat setup -index-management

Restart the filebeat service:
systemctl restart filebeat

Now you can perform the reindexing to resolve the field mapping conflict. Please follow the reindexing steps I shared in the previous thread.  

Regarding the time required to perform reindexing, it depends on the size of each index and the available resources on your Wazuh indexer. If your Wazuh indexer has limited resources and the indices are around 30 GB in size, the reindexing process may take a considerable amount of time. Reindexing is the only way to resolve this issue.