Map dotted Wazuh label keys to nested alert fields

Bottom line: Inspect the emitted label structure before writing the consuming search or parser. Keep an XML label key, its nested JSON representation and the consumer’s supported field syntax distinct.

Source fact: documented behavior

The Agent labels guide documents periods in label keys as a way to create nested labels in JSON-formatted alerts.

Its example defines aws.instance-id in XML and shows instance-id inside the alert’s agent, labels and aws objects.

The guide also says a duplicate label set through centralized agent.conf overrides its local ossec.conf counterpart.

What the source does not establish

This article checks label representation at the consumer boundary. It does not define every search engine’s field grammar, promise retroactive enrichment of earlier alerts or approve putting secrets in labels.

Applicability questions

• What exact label key and harmless value are intended?
• What nested objects occur in an actual new alert?
• Which local and centralized values could conflict?
• How does the selected consumer address that observed structure?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

DSE recommends proving the nested alert structure with one harmless label before deploying a label-based search or parser.

1. Choose a non-sensitive label and write down its intended meaning, key and owner. Draw the proposed object hierarchy one level at a time rather than assuming a period always belongs to a flat key. Check whether the label is also defined centrally so the trial has one understood effective value. Keep metadata labeling separate from authorization to see the resulting alerts.
2. Use an approved disposable agent or controlled configuration population to emit a harmless new alert. Inspect the actual JSON object and locate the label without relying only on the dashboard’s formatted summary. Preserve a redacted structural example for the consumer owner. Do not paste the source’s example instance identifier into a real inventory or treat it as evidence about an organization’s assets.
3. Build the consuming search or parser against that observed hierarchy using the consumer’s own supported syntax. Prepare a missing-label case and a different-value control. Review what each case should do before the consumer runs. If a field is not found, investigate the emitted structure and effective configuration before changing collection scope or silently assigning a default value that conceals the missing metadata.

Verification and evidence

Proposed verification: compare the configured dotted key with the actual nested object from the harmless alert. Ask a second operator to locate the same value in the retained JSON. Then exercise the separately approved consumer against the present, missing and different-value cases, retaining the expected and actual dispositions.

If centralized and local definitions intentionally conflict in the test, record both inputs and inspect the effective emitted value as a separate case. Do not claim that existing alerts were rewritten or that a displayed value makes the label suitable for secrets. No label configuration, alert generation or parser test was performed for this article.

Official references

• Agent labels — Wazuh; official product documentation.

Source review completed October 30, 2026. Recheck the official source and deployment-specific applicability before changing production settings.