All Apps and Add-ons

How to prevent Splunk DB Connect 2 from disabling a database connection if the database goes offline briefly?

Communicator

Hello, all.

Does anyone know if there is a way to keep the app from disabling a given database connection if there is a network disruption or if the database is offline briefly? I've had to restart Splunk each day after in order to re-enable the connection and also re-enable each input. So far, I've changed the maxWaitMillis value indb_connection_types.conf but my custom setting does not appear to take.

Thanks,
James

0 Karma
1 Solution

Splunk Employee
Splunk Employee

Hi rmsit,

An input will be disabled automatically after a few times failures, by default, it is 6 times. If you don't want to use this feature, you can specify auto_disable to False to disable this feature.

[your_input_stanza]
...
auto_disable = False

You can find this option by searching "auto_disable" in the following web page:
http://docs.splunk.com/Documentation/DBX/2.3.0/DeployDBX/inputsspec

View solution in original post

Splunk Employee
Splunk Employee

Hi rmsit,

An input will be disabled automatically after a few times failures, by default, it is 6 times. If you don't want to use this feature, you can specify auto_disable to False to disable this feature.

[your_input_stanza]
...
auto_disable = False

You can find this option by searching "auto_disable" in the following web page:
http://docs.splunk.com/Documentation/DBX/2.3.0/DeployDBX/inputsspec

View solution in original post

Communicator

Hi Sni, just wondering how to match the documentation of 2.4.0 with what happens when either adding

[mi_input://default]
auto_disable = false
or
[default] auto_disable = false

Adding the first to the local/inputs.conf creates (Operations, DB Inputs) a 'default' named input. Seems it's not overriding the default true value but handling as an input.

Using the second one on top of that file seems to override nothing - weird enough the default 'on' mentioned in the docs is not included in the default/inputs.conf.

Hopefully we don't have to add auto_disable=false to every input?

0 Karma

Splunk Employee
Splunk Employee

I assume using the default stanza should work, your second approach (the code may handle the null value as "on" in this case):

[default]

auto_disable = false

Doesn't this work for you?

0 Karma

Contributor

Hello,

What option worked for you. We are facing the same issue where inputs gets disabled frequently.

Do we need to set it for each input or below one will work?
[default]
auto_disable = false

Thanks
Hemendra

0 Karma

Communicator

Hemendralohi, even after setting this to all inputs, and/or default, sometimes SOME (not all!) inputs have to be enabled again manually. After restarting they are not enabled again, and there's no dbx related event in splunk logging stating what went wrong. 😞
Found out DBConnect V3 has been released where perhaps this issue is fixed. (Have still some migration issues, but perhaps try that first 😉

0 Karma

Contributor

We have SHC environment and even after setting auto_disable = false for input it is getting disabled whenever SHC gets restarted? How to prevent it from disabling then? Here is my configuration:

[mi_input://Fusion_DG_Lag]
connection = Fusion_Common_DB_PRD
description = Lag between Primary and Standby DB
enable_query_wrapping = 1
index = index
input_timestamp_column_fullname = (003) NULL.TIME_COMPUTED.VARCHAR2
input_timestamp_column_name =
interval = 120
max_rows = 10000
mode = batch
output_timestamp_format = dd-MM-yyyy HH:mm:ss
query = SELECT name,\
((SUBSTR(value,2,2)*86400)+(SUBSTR(value,5,2)*3600)+(SUBSTR(value,8,2)*60)+(SUBSTR(value,11,2))) lag_time,\
time_computed\
FROM V$DATAGUARD_STATS\
WHERE name IN ('apply lag','transport lag')
source = fusion_common_db_prd
sourcetype = fusion_db
tail_rising_column_fullname = (003) NULL.TIME_COMPUTED.VARCHAR2
tail_rising_column_name = TIME_COMPUTED
ui_query_catalog = NULL
ui_query_mode = advanced
auto_disable = false

0 Karma

Contributor

Thanks for the response. I will make the changes and will monitor. If required will push for upgrade to V3 if it fixes the issue.

0 Karma

Communicator

Thank you, sni.

0 Karma