For Part 1 of this blog series, which contains overview material, please click here.
There are several scenarios that must be addressed when thinking about getting telemetry from Azure resources to Splunk. What if Splunk is on premises? What if you’re using Splunk Cloud? You could be using a private network connection to Azure, or not. The Splunk add-on approach isn’t suited to all of these. In this blog and others in this series, I’ll introduce some new architectural elements and go into detail on each.
In this article, “the add-on” refers to this.
These specific scenarios will be dealt with:
- Cloud-based Splunk, using the add-on (Part 2)
- Cloud-based Splunk, using the HTTP Event Collector (Part 3)
- Premises-based Splunk, using private network (this article)
- Premises-based Splunk, via the internet (Part 5)
In this, Part 4, I’ll go into Premises-based Splunk using a private network. There are a couple of variations.
This is the only configuration that supports the use of an on prem proxy server.
In the first variation, the Splunk Forwarder VM is just Splunk Enterprise with some features switched off. It receives and indexes the incoming events then passes them along to the centralized indexer (VM or cluster). With ExpressRoute (or a site-to-site VPN) configured to encapsulate the VNET where the Splunk VM resides, there is a clear channel to the Splunk Enterprise box on prem. So this configuration is really exactly the same as the one in Part 2 of this series, with the added Splunk instance on prem.
The Express Route isn’t an absolute requirement in this variation since the Splunk Forwarder VM could be a single instance with a static IP. The proxy server could be programmed to allow the Splunk server on prem to talk to it directly.
In the second variation, the on prem Splunk server can see the Azure Function via the private network. In this case, the Azure Function must exist in the context of an App Service Environment in order to have control over its network configuration.