Reduce serverclass allow list and deny list count

Improve performance by optimizing serverclass allow list and deny list configuration to reduce regex matching operations.

Condition

Performance issues in agent management can cause slow responses from the deployment/server/clients endpoint. The following symptoms indicate a performance issue:
  • The response from the endpoint deployment/server/clients takes more than 30 seconds.
  • The Agent Management home page takes more than 30 seconds to load.
  • Searching by host name or app takes more than 30 seconds to complete.
  • The list of matched agents for server class takes more than 30 seconds to load.

Serverclass allow list and deny list configuration is a known bottleneck. Each list entry results in heavy regex matching operations that are repeated for each agent connected to Deployment Server. Lower the count of serverclass allow list and deny list entries to improve overall performance, especially in environments with high agent count. Importing allow lists from CSV files is generally not recommended due to performance issues.

Use regex to combine multiple entries into one

  1. Review your current serverclass configuration.

    Before optimization:

    [serverClass:splunk_app]
whitelist.0 = 192.130.*.*
whitelist.1 = 192.131.*.*
whitelist.2 = 192.132.*.*
whitelist.3 = 192.133.*.*
whitelist.4 = 193.*.*.*
  2. Combine multiple entries using regex patterns.

    After optimization:

    [serverClass:splunk_app]
whitelist.0 = 192.13[0-3].*.*|193.*.*.*

Match agents by shared attributes instead of unique GUID or host name

  1. Identify common patterns in your agent identifiers.

    Before optimization:

    [serverClass:splunk_app]
whitelist.0 = dc-sim-00001
whitelist.1 = dc-sim-00002
whitelist.2 = dc-sim-00003
whitelist.3 = dc-sim-00004
whitelist.4 = dc-sim-00005
  2. Replace individual entries with a wildcard pattern.

    After optimization:

    [serverClass:splunk_app]
whitelist.0 = dc-sim*

Remove stale and unused entries from allow list and deny list files

  1. Review your serverclass configuration for inactive agents.

    Before cleanup:

    [serverClass:splunk_app]
whitelist.0 = 96ef4a20-cbb4-47a0-a827-01b8d606c9ba
whitelist.1 = 0d52f064-e8c1-406a-8b8f-7131d7d0308a
whitelist.2 = 69237b94-fe6d-4e6b-a437-3fbc13518d1c
whitelist.3 = 496f193a-b912-4f80-beff-985d5cb60e8e
whitelist.4 = 7b3bc452-b340-4c38-b513-ab2285cfd3cf # This agent doesn't exist anymore
  2. Remove entries for agents that no longer exist.

    After cleanup:

    [serverClass:splunk_app]
whitelist.0 = 96ef4a20-cbb4-47a0-a827-01b8d606c9ba
whitelist.1 = 0d52f064-e8c1-406a-8b8f-7131d7d0308a
whitelist.2 = 69237b94-fe6d-4e6b-a437-3fbc13518d1c
whitelist.3 = 496f193a-b912-4f80-beff-985d5cb60e8e
  3. Keep your configuration files up to date by removing stale unused entries from *.conf and *.csv files on a regular basis.

Use machineTypesFilter instead of whitelist

  1. Identify agents that can be grouped by machine type.
    Note: The machineTypesFilter setting might not work correctly in deployment server releases lower than version 10.0.

    Before optimization:

    [serverClass:splunk_app]
whitelist.0 = 96ef4a20-cbb4-47a0-a827-01b8d606c9ba
whitelist.1 = 0d52f064-e8c1-406a-8b8f-7131d7d0308a
whitelist.2 = 69237b94-fe6d-4e6b-a437-3fbc13518d1c
whitelist.3 = 496f193a-b912-4f80-beff-985d5cb60e8e
whitelist.4 = 7b3bc452-b340-4c38-b513-ab2285cfd3cf
  2. Replace individual agent entries with machine type filters.

    After optimization:

    [serverClass:splunk_linux]
whitelist.0 = *
machineTypesFilter = linux-x64

[serverClass:splunk_windows]
whitelist.0 = *
machineTypesFilter = windows-x64

Combine both allow list and deny list

  1. Identify overlapping patterns in your serverclass configurations.

    Before optimization:

    [serverClass:splunk_app_1]
whitelist.0 = 96ef4a20-cbb4-47a0-a827-01b8d606c9ba
whitelist.1 = 96ef4a20-e8c1-406a-8b8f-7131d7d0308a
whitelist.2 = 96ef4a20-fe6d-4e6b-a437-3fbc13518d1c
whitelist.4 = 96ef4a20-b340-4c38-b513-ab2285cfd3cf

[serverClass:splunk_app_2]
whitelist.0 = 0d52f064-cbb4-47a0-a827-01b8d606c9ba
whitelist.1 = 0d52f064-e8c1-406a-8b8f-7131d7d0308a
whitelist.2 = 0d52f064-fe6d-4e6b-a437-3fbc13518d1c
whitelist.3 = 96ef4a20-b912-4f80-beff-985d5cb60e8e
  2. Use wildcard patterns with deny list to exclude specific agents.

    After optimization:

    [serverClass:splunk_app_1]
whitelist.0 = 96ef4a20*
blacklist.0 = 96ef4a20-b912-4f80-beff-985d5cb60e8e

[serverClass:splunk_app_2]
whitelist.0 = 0d52f064*
whitelist.1 = 96ef4a20-b912-4f80-beff-985d5cb60e8e

Distribute agents across multiple deployment servers

  1. Plan how to divide agents between deployment servers.

    Before distribution on a single deployment server:

    [serverClass:splunk_app_1]
whitelist.0 = 192.130.*.*
whitelist.1 = 192.131.*.*

[serverClass:splunk_app_2]
whitelist.0 = 192.132.*.*
whitelist.1 = 192.133.*.*
  2. Configure the first deployment server to serve only 192.13[0/1]/*.* agents.

    After distribution, deployment server 1:

    [serverClass:splunk_app_1]
whitelist.0 = 192.13*
  3. Configure the second deployment server to serve only 192.13[2/3]/*.* agents.

    After distribution, deployment server 2:

    [serverClass:splunk_app_2]
whitelist.0 = 192.13*
  4. Group agents in a way that allows for the smallest configuration on each deployment server.