Splunk® Enterprise

Admin Manual

rolling_upgrade.conf

The following are the spec and example files for rolling_upgrade.conf.

rolling_upgrade.conf.spec

#   Version 9.3.0
#

# This file contains descriptions of the settings you can use to configure the
# splunk-rolling-upgrade app.

[logging]

log_level = [DEBUG|INFO|WARN|ERROR]
* The severity level at which the splunk-rolling-upgrade app writes log file
  entries.
* splunk-rolling-upgrade writes logs at the level you set in 'log_level' and
  any higher levels. For example, if you set 'log_level = WARN',
  the app writes logs at both WARN and ERROR severity levels.
* Logging levels increase in order of severity, as follows (lower levels provide more
  information, but increase log file size):
  * DEBUG - Detailed information for diagnosing problems.
  * INFO  - Confirmation that things are working as expected.
  * WARN  - A warning of a recoverable fault or a problem that might
            occur in the future.
  * ERROR - A problem that is causing the software to not run as expected.
* Default: INFO

[requests]

# These settings control the client interface that connects to Splunk software
# via REST API.
retries = <positive integer>
* The maximum number of times the splunk-rolling-upgrade app retries a connection
  attempt before terminating the REST API request.
* Default: 2

delay = <non-negative integer>
* The initial amount of time, in seconds, splunk-rolling-upgrade app waits before
  retrying a REST call.
* Default: 1

timeout = <positive integer>
* The amount of time, in seconds, the splunk-rolling-upgrade app waits for a
  response from a REST API request before terminating the request.
* Default: 30

[process_runner]

# These settings manage internal sub-processes that the splunk-rolling-upgrade app creates.
timeout = <positive integer>
* The maximum about of time, in seconds, the splunk-rolling-upgrade app waits for a process to terminate.
  If the elapsed time exceeds the timeout value, the entire rolling upgrade fails.
* Default: 600

[kvstore_retry]

# Kvstore requires some time to be fully initialised. These settings are used to define
# how long an upgrade has to wait for kvstore initialisation.
max_tries = <positive integer>
* The maximum number of times the splunk-rolling-upgrade app checks for
  kvstore readiness.
* Default: 10

initial_delay_after_each_retry = <non-negative integer>
* The amount of time, in seconds, the splunk-rolling-upgrade app waits before
  checking again if the kvstore is properly initialized.
* Default: 20

[cluster_retry]

# When dealing with a Search Head Cluster there are few things that must happen in order to have
# a fully initialised cluster. Each peer must be ready (and their corresponding kvstore must be
# properly replicated), and a captain must be elected. This requires some time, depending on the
# cluster size.
max_tries = <positive integer>
* The maximum number of times the splunk-rolling-upgrade app checks for search
  head cluster readiness.
* Default: 10

initial_delay_after_each_retry = <non-negative integer>
* The amount of time, in seconds, the splunk-rolling-upgrade apps waits before
  rechecking search head cluster readiness.
* Default: 20

[shcluster_members_retry]

# Settings to control interaction with search head cluster members.
max_tries = <positive integer>
* The maximum number of times the splunk-rolling-upgrade app checks whether
  all historical searches are complete.
* Default: 20

initial_delay_after_each_retry = <non-negative integer>
* The amount of time, in seconds, the splunk-rolling-upgrade app waits before
  rechecking whether all searches are complete.
* Default: 20

[downloader]

# These settings control Splunk package source.
package_path = <string>
* Specifies the URI path to a new Splunk Enterprise installation pacakge. 
  Authentication is not supported.
* Supported package file formats are .tgz, .rpm, and .deb.
* Supported URI schemas are file://, http:// and https:// only. All other schemas (such as
  ftp://) result in an error.
* Default: none

md5_checksum = <string>
* Specifies the md5 checksum of the installation package pointed to by
  'package_path' in a hexadecimal format.
* If the calculated checksum of the package is different than the checksum
  specified in this setting or if the 'md5_checksum' value is missing, the 
  splunk-rolling-upgrade app won't install the package, and the upgrade
  will be stopped. 
* Example: md5_checksum = 1234567890abcdef1234567890abcdef
* Default: none

[hook]

# These settings specify a hook script that installs Splunk Enterprise on
# Linux machines during automated rolling upgrade. To install from a .tgz
# archive, use the default 'install.tgz.sh' script, which unpacks the archive
# under $SPLUNK_HOME and restarts Splunk. To install from .rpm or .deb
# packages, you must write a custom hook script. For instructions on how to
# write your own hook script, see Splunk Enterprise documentation.
install_script_path = <string>
* Specifies the path to the hook script that installs Splunk Enterprise.
* Default: $SPLUNK_HOME/etc/apps/splunk-rolling-upgrade/hooks/install_tgz.sh

[orchestrator]

# Settings to control the indexer cluster upgrade orchestrator.
upgrade_check_max_tries = <positive integer>
* Specifies the maximum number of times the orchestrator checks the status of
  a peer node while waiting for it to come back online during an upgrade.
* If the peer node does not come back online before the orchestrator performs
  the maximum number of status checks, the orchestrator registers a peer node
  upgrade failure and stops further cluster upgrade.
* Default: 30

delay_after_each_upgrade_check = <positive integer>
* The amount of time, in seconds, the orchestrator waits before doing the
  next status check of a peer node, while waiting for it to come back online
  during an upgrade.
* Default: 20

concurrency = <positive integer>
* Specifies the number of peer nodes to upgrade simultaneously.
* This value cannot be greater than (search factor - 1). For
  example, if the search factor is 3, this value cannot be greater than 2.
* Setting this value to a number greater than search factor minus one will
  result in a failure during upgrade initiation.
* Default: min((search factor - 1), (cluster_size - 1)/2)), where cluster_size 
  is the total number of peers. For example, if (search factor - 1) is 2, and 
  (cluster_size - 1)/2 is 4, then the default value is 2. 

enable_midpoint_status_check = <boolean>
* Determines whether the splunk-rolling-upgrade app splits a single site 
  indexer cluster upgrade into two halves and performs an additional health check
  on the entire cluster.
* A value of "true" means that the splunk-rolling-upgrade app first upgrades  
  50% of the peer nodes, then performs a health check on the entire cluster,
  and finally upgrades the remaining 50% of the peers.
* The additional health check verifies that all peer nodes are up and that
  the indexer cluster meets searchability requirements.
* Default: true

midpoint_check_max_tries = <positive integer>
* The maximum number of times the splunk-rolling-upgrade app waits for a
  successful indexer cluster health check status after upgrading 50% of the
  peers of a given site.
* Default: 3

midpoint_check_retry_delay = <positive integer>
* The amount of time, in seconds, the splunk-rolling-upgrade app waits before
  retrying the midpoint indexer cluster health check
* Default: 20


rolling_upgrade.conf.example

No example
Last modified on 12 September, 2024
restmap.conf   savedsearches.conf

This documentation applies to the following versions of Splunk® Enterprise: 9.3.1


Was this topic useful?







You must be logged into splunk.com in order to post comments. Log in now.

Please try to keep this discussion focused on the content covered in this documentation topic. If you have a more general question about Splunk functionality or are experiencing a difficulty with Splunk, consider posting a question to Splunkbase Answers.

0 out of 1000 Characters