How the Remote Upgrader for Linux Universal Forwarders works
Here is an example workflow for the Remote Upgrader for Linux Universal Forwarders:
- The Remote Upgrader for Linux Universal Forwarders monitors the trigger file start_uf_upgrade under the directory /tmp/SPLUNK_UPGRADER_MONITORED_DIR. The start_uf_upgrade and /tmp/SPLUNK_UPGRADER_MONITORED_DIR files are default values that can be modified as needed.
- When the Remote Upgrader for Linux Universal Forwarders observes trigger file activity indicating a new package, it attempts to retrieve the universal forwarder package.
- If you have configured signature validation, the Remote Upgrader for Linux Universal Forwarders validates the Splunk signature for the package.
- The Remote Upgrader for Linux Universal Forwarders validates the universal forwarder migration path from the current version to the destination version. For more about valid migration paths, see Supported universal forwarders versions.
- The Remote Upgrader for Linux Universal Forwarders starts the upgrade. By default, three attempts are made, which timeout at 300 seconds each. You can also manually configure the number of retry attempts and timeouts.
- If the upgrade fails for any reason, the Remote Upgrader for Linux Universal Forwarders rolls back the upgrade and restores the current version.
- Upon successful upgrade and once the universal forwarder is running, the Remote Upgrader for Linux Universal Forwarders ingests the upgrade logs to the indexers.
- If the universal forwarder and deployment server are running on 9.2 or higher, the Remote Upgrader for Linux Universal Forwarders reports the new upgrade status to the deployment server.
Command options | Performance benchmarks |
This documentation applies to the following versions of Splunk® Universal Forwarder: 1.0.0, 8.2.11, 8.2.12, 9.0.5, 9.0.6, 9.0.7, 9.0.8, 9.0.9, 9.0.10, 9.1.0, 9.1.1, 9.1.2, 9.1.3, 9.1.4, 9.1.5, 9.1.6, 9.1.7, 9.2.0, 9.2.1, 9.2.2, 9.2.3, 9.2.4, 9.3.0, 9.3.1, 9.3.2, 9.4.0
Feedback submitted, thanks!