Verify repository mode configuration

After you change the repository mode or saved-search configuration, verify your configuration and runtime behavior to confirm that agent management operates as expected.

After you change the repository mode or saved-search configuration, verify your configuration and runtime behavior to confirm that agent management operates as expected.

  1. Run btool or an equivalent configuration inspection method to confirm the value of repository_type in agent_management.conf.
    CODE
    $SPLUNK_HOME/bin/splunk btool agent_management list general --debug
  2. Confirm saved-search state in savedsearches.conf.
    CODE
    $SPLUNK_HOME/bin/splunk btool savedsearches list AgentManagerAppEventData --debug
    $SPLUNK_HOME/bin/splunk btool savedsearches list AgentManagerPhonehomeData --debug
    $SPLUNK_HOME/bin/splunk btool savedsearches list AgentManagerClientData --debug
    $SPLUNK_HOME/bin/splunk btool savedsearches list AgentManagerEventSummary --debug
  3. Restart Splunk if you changed the configuration and have not restarted yet.
  4. For database mode, confirm that your agent management server can search the relevant _internal data.
  5. For database mode, confirm that the saved-search pipeline begins producing CSV batches.
  6. Review agent management UI or API behavior and confirm that supported data loads as you expect.
  7. Review Splunk logs and status information for warnings that indicate ingestion delay, matching refresh lag, search-tier pressure, or database pressure.

For database mode, healthy operation looks like this:

  • You can search relevant agent management _internal data from your agent management server.
  • Agent management generated events such as source=AgentManagerClientData and source=AgentManagerPhonehomeData are searchable locally when you have forwarding enabled.
  • New data continues to appear in agent management without sustained lag.
  • Matching refresh completes on its expected interval.
  • CSV backlog does not continue to grow over time.
  • Search jobs and Postgres-backed ingestion don't produce persistent warnings.