DB Connect 3.1.4 Data Duplication & Rising Col Issue

[paulbannister]

Our current setup has a Heavy Forwarder running Enterprise 6.5 and DB Connect 3.1.3 that handles all our database connections and a few other miscellaneous connections to send to both our Cloud and Enterprise instances, for obvious reasons we are looking to upgrade our HF and have a newly configured one ready to go sitting on Enterprise 7.0.3 and DB Connect 3.1.3

We have one database connection that throws up an issue anytime we try to enable it, as it would appear that it can't keep up the rising column, and after ingesting an amount of data drops the rising column value back by a 1000 and starts duplicating events in the index and becomes stuck in a loop of this activity until we manually change the rising column.... and then shortly after it will repeat the issue, basic connection details as below:

Rising Column
Max Rows to Retrieve = 15000
Fetch Size = 300
Execution Frequency = 30

The db itself can contain some quite large column values, in excess of 20k in some cases, but the old 6.5 HF has been handling it happily for some time, to make matters worse the old 6.5 HF is almost completely undocumented so tracking down any specific conf changes can be fun (some have even been made in default files)

We have tried all the obvious changes we can think of and are now running a blank as to what this issue might be, so any help would be very much appreciated

[paulbannister · Accepted solution]

UPDATE

Currently we are exploring the fact that in might be a limit issue on the size of messages that HEC can handle, to resolve this we've updated our HF to 7.0.6 so that we are able to set the maxEventSize in the inputs.conf for [HTTP]

So far all feeds concerned seem stable and are continuing to ingest data, but we have had periods of stability like this before so we're going to let it sit for a week or so to confirm

FIXED

So doing the above seemed to have fixed the issue, updating to 7.0.6 which allowed us to use the maxEventSize config setting, an obscure issue but hopefully this will prove helpful to someone down the line.

Under $SPLUNK_HOME$/etc/apps/splunk_httpinput/local/inputs.conf we merely added the stansa:

[http]
maxEventSize=15728640