How will removing a heavy forwarder from my current environment affect indexing performance?

[some_guy]

My clustered index sizes/event counts seem to occasionally mismatch a bit from indexer-to-indexer. This might result in search weirdness.

Right now, it looks like this:
server A (syslog collector/universal forwarder) -> server B (heavy forwarder) -> Index (cluster)

I'm thinking of removing the heavy forwarder:
server A (syslog collector/universal forwarder) -> Index (cluster)

Might this help indexing performance? Am I losing much by not using a heavy forwarder?

Any advice appreciated.

[hrithiktej]

Hi there I recently inherited Splunk and saw there were too many heavy forwarders in place and i replaced them with UFs but when i take out heavy forwarder from the license master which is also our cluster master we stop seeing license usage. Is HF a mandate requirement on license/cluster master to show license usage?

[gjanders]

Rather than bump a really old post you would be better off creating a new one.

The license master must be a Splunk enterprise instnace, any indexer should be reporting the license master to record the license usage.
Heavy forwarders do not have to report to the license master unless they are indexing and forwarding.

There is no requirement to have HF's at all in an environment, although you will normally have a reason for them (for example running applications that need python or similar).

Also the blog post Heavy forwarder or Universal Forwarder might be relevant to the original question.

[hrithiktej]

oh ok, thanks from next time I will create a new post, Did you mean to say that forwarding should be enabled on the license master to record license usage. Because if I take out indexers IP from the outputs.conf of License master than the license usage is not counted.

So now I see 1 H.F. i.e. our license master in our environment when I see forwarder deployment under DMC

[esix_splunk]

It depends on what role the HF has in your environment.

From a architectural point of view, the HF is usually placed in front of indexers for the following reasons:
1) Parsing - to offset parsing/typing load from the indexers
2) Segregation - in large distributed environments, indexers are frequently in more secure zones that the UF's cannot talk to directly. HF's act as gateways, if you will, to the indexers.
3) Workflow requirements - send data streams to specific indexers, or adding index time data based on location
4) Input requirements. E.g., DBX, eStreamer, and other apps that require an HF.

If you dont have these requirements, then going from a UF directly to the Indexer is not a problem. In fact, depending on the type of input you have, this should actually be faster for indexing.

If you explain your use case a bit more, we can provide a bit more directed feedback for you.

[some_guy]

Thank you for the insight.

At present we don't have a need for any sophisticated index routing. This enterprise is large, but centralized to one campus (fairly flat network). The input parsing is being handled largely by syslogNG, but an upstream HF might be useful for parsing in the near future (thus keeping some load off the indexers).

I've read that you shouldn't use an HF unless you absolutely need it. I've also read that there is benefit in having a buffer before the indexers. While our specific immediate use-case doesn't call for anonymization, index routing or detailed parsing...I can't say it never will.