The problem is caused by an input without the attribute mode defined. This attribute is required, without it the input definition is invalid. Therefore, the migration cannot operate on it. You must either define the mode for this input (batch, rising, advanced) or remove it completely before running the migration. ... View more

Hi, 503 means that HEC queue to send to the indexers is full. The problem is to identify where is the bottleneck: 1) is it the heavy forwarder? 2) is the network between the heavy forwarder and the indexers? 3) is it the indexers? To help you diagnose, you can check following things: - CPU usage on heavy forwarder and indexers - queue size on indexers If the CPU is high (more than 90%) in one of the component, that's where you should focus to troubleshoot. If everything seems normal it might be a network issue. Finally, another test you can have to troubleshoot is to index on the heavy forwarder locally. After doing so, there is no 503 anymore, the bottleneck is clearly downstream (network or indexers). ... View more

I was able to install successfully this environment: - CentOS Linux release 7.0.1406 (Core) - JDK build 1.8.0_144-b01 - Splunk 7.0.0 build c8a78efdd40f - DB Connect 3.1.1 build 34 The only thing to mention is to open the 8000 port: firewall-cmd --zone=public --add-port=8000/tcp ... View more

If you cannot access the Monitoring Console page, it seems not to be a problem from DB Connect. I suggest you to contact our support to help you with the installation. ... View more

Can you try to visit the page mentioned earlier by accessing the following URL http://your_host:8000/en-US/app/splunk_monitoring_console/monitoringconsole_check ? Can you have a look on splunkd.log? You need to search for the string "server.sh" in this file to find relevant logs about your issue. ... View more

Hi, Can you try to run DB Connect installation's health checks, please? To run them you need to go to your monitoring console > Health Check and then select the app DB Connect. You can also use this URL http://your_host:8000/en-US/app/splunk_monitoring_console/monitoringconsole_check ... View more

Did you have relevant logs to share? You can search index=_internal sourcetype=dbx_server and probably add a condition with your input name to limit to only see the relevant events. ... View more

The number of apps truncated to 30 apps has been fixed in 3.1.0 http://docs.splunk.com/Documentation/DBX/3.1.0/ReleaseNotes/Releasenotes. Also in 3.1.0, you can move lookup to other app after creation. ... View more

You probably need to remove settings.py, settings.pyo, settings.pyc from $SPLUNK_HOME/etc/apps/splunk_app_db_connect/bin. You can check http://docs.splunk.com/Documentation/DBX/3.1.0/DeployDBX/Checklist#Upgrade_an_existing_DB_Connect_deployment for details. It is also mentioned in the release notes http://docs.splunk.com/Documentation/DBX/3.1.0/ReleaseNotes/Releasenotes. ... View more

We are sorry about the confusion. You can run dbxquery in a saved search run on Search Head Cluster for alerts or reports. What you cannot do is to ingest data read from a DB on a Search Head Cluster. ... View more

We'll try to improve the documentation, sorry for that. Let me clarify what we meant: - dbxquery, dbxlookup, dbxoutput commands should typically be run on Search Head - scheduled jobs configured in DB Connect (inputs and outputs) cannot be run on Search Head Cluster. During captain reelection running DB Connect scheduled jobs can cause some duplicates or missing data. @sarnagar to answer your questions: - Should I move the lookups to Heavy Forwarder? No, keep them on Search Head - Where do I have to declare the different entities: inputs, outputs, connections, ...? - inputs: Heavy Forwarder - outputs: Heavy Forwarder - lookups: Search Head - connections: Heavy Forwarder and/or Search Head. Connections are necessary to connect to your DB. Therefore, connections used by inputs/outputs need to be declared on Heavy Forwarder. Connections used by lookups, queries must be declared on Search Heads. ... View more