Azure Monitor integration approach for Splunk

Hello SujinaSJ-1789 Approach 1 (Event Hub) is the Microsoft-recommended pattern, but you don't actually need the Azure Function in the middle. The cleaner and officially documented path is:

Diagnostic settings → Azure Event Hub → Splunk Add-on for Microsoft Cloud Services (running on your Heavy Forwarder VM)

This is exactly what Microsoft documents for Entra ID and Azure Monitor data going into Splunk:

• Stream Azure monitoring data to an event hub and external partners – Microsoft Learn [learn.microsoft.com]
• Stream Microsoft Entra logs to an event hub (Splunk section) – Microsoft Learn [learn.microsoft.com]
• Access activity logs in Microsoft Entra ID – Microsoft Learn [learn.microsoft.com]

The Microsoft Entra doc explicitly says:"To use this feature, you need the Splunk Add-on for Microsoft Cloud Services" and shows the mscs:azure:eventhub sourcetype used to query the logs in Splunk.

Note on the GitHub repo you referenced (Microsoft/AzureFunctionforSplunkVS / AzureMonitorAddonForSplunk): that project is archived and still depends on Python 2.7, and Microsoft themselves state it is "Open Source and not an officially supported Microsoft product".

It's best to avoid it for new deployments.

Steps for the recommended flow (all four log types):

1. Create the Event Hub namespace and hub in the same region as your workloads. Microsoft's guidance: start with 4 partitions, at least 7 days retention, and open outbound TCP 5671/5672 (AMQP) from the consumer.
2. Route the logs using diagnostic settings:

• Activity log → Azure Monitor → Activity log → Export Activity Logs → Stream to an event hub
• Resource logs (incl. NSG flow logs via NSG diag settings) → per-resource Diagnostic settings → Stream to an event hub
  • Entra ID (sign-in + audit + provisioning logs) → Entra ID → Monitoring & health → Diagnostic settings → Stream to an event hub.
  1. Deploy the Heavy Forwarder VM in Azure and install the Splunk Add-on for Microsoft Cloud Services.

1. Register an app in Microsoft Entra ID and grant it the Azure Event Hubs Data Receiver role on the Event Hub — this is the auth path the add-on uses.
2. Configure the Event Hub input in the add-on with the namespace FQDN, event hub name, consumer group, and the app credentials. Splunk's official guidance is one input per partition (e.g., 4 partitions → 4 inputs).
3. Verify in Splunk with:

      sourcetype="mscs:azure:eventhub"
   

   You can filter Entra data with body.records.category=AuditLogs, SignInLogs, etc., as shown in Microsoft's Entra doc.

About Approach 2 (Heavy Forwarder pulling from Storage Account)

It is technically feasible using the same Splunk Add-on for Microsoft Cloud Services, which supports Azure Storage Blob and Table inputs — no custom code needed.

Steps in short:

1. In each Diagnostic setting, additionally select Archive to a storage account for the log categories you need.
2. On the Heavy Forwarder, in the add-on, add an Azure Storage Account connection with the account name + access key (or SAS).
3. Configure a Storage Blob (and/or Storage Table) modular input pointing to the container/prefix Azure creates (e.g., insights-logs-*, insights-activity-logs).

Direct caution from Splunk's official docs for this approach:"the number of inodes available can fill up quickly, creating pointer files on your operating system for every single blob… potentially resulting in a 'no space left on device' error." This is a real concern for high-volume sources like NSG flow logs.

Recommendation: If the primary use case is SIEM / security monitoring on Activity, Resource, NSG Flow, and Entra ID logs, go with Approach 1 — Event Hub + Splunk Add-on for Microsoft Cloud Services (skip the Azure Function; the add-on pulls from the Event Hub directly). It's the pattern Microsoft explicitly documents and it's near real-time. Reserve Approach 2 only if you need cheap long-term archival and can tolerate ingestion delays.

Hope this helps!

Thanks,

Suchitra.

Hello SujinaSJ-1789,

Greetings! Thanks for raising this question in the Q&A forum.

Between the two approaches you outlined, sending logs to Event Hub is the approach recommended by Splunk for this kind of data, and the Storage Account plus heavy forwarder pull model is generally the older, less scalable pattern. Here is the reasoning and the steps for both, so you can make the call based on your own volume and cost constraints.

Understand why Event Hub is generally preferred Splunk's own guidance states that when a data source can be sent to an Event Hub in Azure, it should be sent that way in preference to other ingestion paths. Push based methods using Azure functions are the second most performant way to collect Event Hub data, and pull based ingestion can be done through the Splunk Add-on for Microsoft Cloud Services. Event Hub also gives you a single, consistent ingestion pattern across activity, resource, NSG flow, and Entra ID logs instead of managing separate polling logic against Storage.

Understand the tradeoff with Event Hub Event Hub is a streaming service, not long-term storage, so retention is short. Event Hubs have a fairly short retention time for events, typically 24 hours to 7 days, so if you ever need replay of older data, you'd rely on a separate archive (for example, Event Hub Capture to a storage account) rather than the hub itself.

Sizing Event Hub correctly for cost and performance A common design pattern is grouping similar logs into the same event hub, for example putting Entra ID sign-in and audit logs into one hub and Key Vault logs into another, with all of these hubs living in the same event hub namespace. Be aware of tier limits when planning your namespace layout, since basic and standard tiers only allow 10 hubs per namespace, and if you need more you will need an additional namespace.

If you choose the Storage Account plus heavy forwarder approach (approach 2) This is feasible and is documented by Splunk as a supported pattern, but it is generally used when a source doesn't support Event Hub output rather than as a first choice. The steps are:

• Configure the relevant Azure resource (NSG flow logs, diagnostic settings, etc.) to write to a Storage Account container.
  • Deploy the Splunk Add-on for Microsoft Cloud Services on a heavy forwarder (a single Splunk instance can host this).
    • In the add-on, configure an Azure App Account under Entra ID with an app registration, client secret, and the appropriate RBAC role (Storage Blob Data Reader at minimum for this scenario) on the storage account.
      • Create a new input of type Azure Storage Blob (or Azure Storage Table depending on data type), pointing at the container holding your logs, and set a polling interval.
        • The forwarder then pulls new blobs on that interval and indexes them, so your data latency is bound by your polling interval rather than being near-real-time as with Event Hub.
        Cost and performance comparison Event Hub plus Azure Functions (or the add-on's Event Hub input) scales better for high-volume, near-real-time data and is Splunk's stated preference. Data Manager is the recommended ingestion method for high volume data sources such as Event Hubs that support pull based ingestion, offering highly scalable, highly available, low latency ingestion. The Storage Account and heavy forwarder model tends to cost more in forwarder compute for polling at scale and introduces more latency, but avoids Event Hub throughput unit costs and can be simpler for lower-volume, less time-sensitive log types like NSG flow logs, which are Storage-only by design regardless of which path you pick for everything else. Practical recommendation For activity, resource, and Entra ID logs, route through Event Hub using either the sample Azure Functions code you linked or the Splunk Add-on for Microsoft Cloud Services Event Hub input. Reserve the Storage Account pull pattern specifically for sources that only support Storage as a destination, such as NSG flow logs, rather than standardizing on it for everything.

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,

Jerald Felix.