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
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
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
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?
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?
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
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 😉
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
Hi @hemendralodhi
I have the same problem too
regards
Altin
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.
Thank you, sni.