Deployment Architecture

Deployment monitor and intermediary forwarder

echalex
Builder

Hi,

We have set up a Splunk infrastructure where all forwarders send their data to intermediary forwarders (universal forwarders), which in turn forward the data to the indexers.

This is working out nicely, except for the Deployment monitor which does not present any information about the client forwarders, which use the intermediary forwarders. In other words, the indexers, search heads and intermediary forwarders are visible, as well as all the older forwarders who send their data directly to an indexer.

Is there any way of getting ALL the information through the intermediary forwarders?

1 Solution

echalex
Builder

Aha! Found the problem!

Events for _internal are not being forwarded by default. So I decided to test adding this to etc/system/local/outputs.conf on the intermediary forwarders:

[tcpout]
forwardedindex.3.whitelist = _internal

This solved the problem. No I see all forwarders.

View solution in original post

echalex
Builder

Aha! Found the problem!

Events for _internal are not being forwarded by default. So I decided to test adding this to etc/system/local/outputs.conf on the intermediary forwarders:

[tcpout]
forwardedindex.3.whitelist = _internal

This solved the problem. No I see all forwarders.

trutch
Explorer

This just solved an issue with my Heavy Forwarder. The weird thing is that _internal is all ready whitelisted in system/default/outputs.conf

forwardedindex.2.whitelist = (_audit|_internal)

Thanks for following up and answering your own question!

0 Karma
Get Updates on the Splunk Community!

Automatic Discovery Part 1: What is Automatic Discovery in Splunk Observability Cloud ...

If you’ve ever deployed a new database cluster, spun up a caching layer, or added a load balancer, you know it ...

Real-Time Fraud Detection: How Splunk Dashboards Protect Financial Institutions

Financial fraud isn't slowing down. If anything, it's getting more sophisticated. Account takeovers, credit ...

Splunk + ThousandEyes: Correlate frontend, app, and network data to troubleshoot ...

 Are you tired of troubleshooting delays caused by siloed frontend, application, and network data? We've got a ...