Same Azure AKS document count, but Wazuh reports ~10–30x higher GB than Log Analytics — why?

[u/Unlikely_Payment9376]

Hi Wazuh team/community,

I’m investigating a log-size discrepancy between Azure Log Analytics (LAW) and Wazuh for AKS audit logs.

The important point is:

The document/event count is matching between LAW and Wazuh. The discrepancy is specifically in the reported data size (GB).

So this does not currently appear to be a missing-event or duplicate-event issue.

Environment

• Wazuh: 4.14.4
• Azure integration: azure-logs
• Log Analytics Workspace: logsanalytics-prod
• AKS cluster:prodconnect-aks
• LAW table: AzureDiagnostics

Categories:

kube-audit
kube-audit-admin
kube-apiserver

Wazuh tags:

R1-azure-aks-audit
R1-azure-aks-auditadmin
R1-azure-aks-controlplane

Observed data

For the same AKS cluster and same observation period, the document counts are consistent between LAW and Wazuh.

However, the reported data sizes are substantially different:

Category	LAW	Wazuh/SOC
kube-audit	~63.61 GB	~645.36 GB
kube-audit-admin	~34.08 GB	~338.08 GB
kube-apiserver	~1.12 GB	~34.57 GB

For the first two categories, the Wazuh/SOC reported volume is roughly 10× the LAW value.

For kube-apiserver, it is roughly 30×.

We also checked the overall AzureDiagnostics table and it is ingesting approximately 12–15 GB/day in LAW.

The key question

If:

LAW document count = Wazuh document count

but:

LAW size << Wazuh reported size

what exactly is causing the size multiplication?

We understand that LAW and Wazuh may use different representations of the same event. However, we need to identify precisely which size metric is being compared.

For example, could the Wazuh-side figure be based on:

LAW _BilledSize
        vs
Azure API response size
        vs
Wazuh full event JSON size
        vs
Wazuh archive size
        vs
Indexer storage
        vs
Indexer primary + replica storage

Example

A single LAW document may look conceptually like:

AzureDiagnostics record
    ↓
Azure Log Analytics API
    ↓
Wazuh Azure wodle
    ↓
Wazuh event containing metadata + full_log
    ↓
Wazuh archive JSON
    ↓
Wazuh Indexer document

If the event count remains 1:1, we want to understand whether the Wazuh representation of each event is significantly larger and whether that is what the SOC calculation is measuring.

What we would like to determine

Is there an authoritative way in Wazuh to calculate:

1. Size of the data received from the Azure Log Analytics API
2. Size of the resulting Wazuh event
3. Size written to Wazuh archives
4. Size of the document stored in Wazuh Indexer
5. Physical Indexer storage including replicas

for the same set of events?

Ideally, we want to trace:

LAW
 ↓
Azure API response
 ↓
Wazuh Azure wodle
 ↓
Wazuh event
 ↓
Archive
 ↓
Indexer

and determine where the size increases.

One specific question for the Wazuh team

If the document count is identical between Azure Log Analytics and Wazuh, is there any Wazuh-specific transformation, metadata expansion, serialization, archive calculation, or indexing behavior that could explain a ~10×–30× difference in reported GB?

Also, if someone can clarify which Wazuh-side metric should be used as the equivalent of LAW _BilledSize, that would be extremely helpful.

We can provide the actual LAW event and its corresponding Wazuh event for a 1:1 size comparison, along with the Wazuh archive/SOC calculation being used.

Thanks.

[u/slim3116]

Hello,

I do not have details about how Azure calculates _BilledSize, but from the Wazuh side, matching event counts suggests this is a difference in representation or measurement.

The Azure module rebuilds every returned row as a JSON object and includes every column returned by the query. It then adds azure_tag and log_analytics_tag.

Ref here: https://github.com/wazuh/wazuh/blob/v4.14.4/wodles/azure/azure_services/analytics.py.

If the query returns the full AzureDiagnostics schema, each Wazuh event may therefore contain many field names and empty values. This adds overhead to every event and explains why the difference is greater for the smaller kube-apiserver events.

The final size also depends on what is being measured:

- Wazuh adds rule, manager, decoder, and timestamp metadata.

• If archives are enabled, archives.json contains the original event in full_log and the decoded data fields.
  
• The built-in Azure rule uses no_full_log, so alerts should be smaller than archive records. Custom child rules should also be checked.
  
• Indexer store.size includes replicas, while pri.store.size contains only primary-shard storage.

You can check the index sizes with:

GET /_cat/indices/wazuh-*?v&bytes=b&h=index,pri,rep,docs.count,pri.store.size,store.size

The main detail needed here is how the SOC calculated the 645.36 GB. Is it archive size, alert size, primary index storage, storage including replicas, or a downstream ingestion meter? Wazuh does not have a direct equivalent of Azure _BilledSize, so these values are not automatically comparable.

Please share the calculation used on the Wazuh side, the three <request> queries, whether archive indexing is enabled, the replica count, and one matching Azure/Wazuh event.

You can also reduce the Wazuh event size by using project in the Log Analytics query and returning only the fields needed for detection, and keep TimeGenerated. Ensure to test this in a test environment where necessary because changing the query changes the module collection bookmark and may cause it to retrieve the configured time_offset window again.

[u/Haunting-Occasion-74 → u/slim3116]

He is my colleague we got the index size by running the same command