Setting Up the Upgrade Agent

This section explains how users should interact with the Upgrade Agent for performing upgrades and rollback operations for AP Java protectors.

AP Java Upgrade allows you to upgrade the AP Java SDK, RP Agent, and Log Forwarder without stopping your applications.

Note: For both online and offline upgrade, you should not pass the path of the extracted local .tgz build file. The Upgrade agent must extract the .tgz file to generate the signatures/ directory.

Before performing an online or offline upgrade or rollback, review the following important considerations and limitations.

Scalability and Performance Considerations

With a policy size of approximately 5MB, upgrade and rollback operations are validated safely for up to 70 concurrent processes on the tested machine configuration.

Supported Deployment

• Ensure that only one RPA and one Log Forwarder are installed on the system.
• Upgrading multiple RPAs on the same host is not supported.
• Upgrading or rolling back only one version of AP Java at a time is allowed on the same host.

Log Forwarder Upgrade Behavior and Requirements

• The Upgrade Agent does not perform fresh installations of the Log Forwarder. The Log Forwarder must already be installed for the agent to upgrade it.
• To skip the Log Forwarder upgrade when it is not required or not installed, set the isFluentBit parameter to no in the sdkupgrd.conf file.
• If isFluentBit is set to yes in sdkupgrd.conf, you must also configure the Log Forwarder endpoint in the sdkupgrd.conf file.
• When Log Forwarder mode is set to error, upgrading renames the Log Forwarder directory from logforwarder to logforwarder_<new_version>.

Port Requirements for Error Mode

• If mode=error is enabled in config.ini, ensure that ports 15780 and 15781 are open.
• The Upgrade Agent uses port 15781 to run the new Log Forwarder during upgrade.
• Although port 15780 is released after an upgrade, it is required again if an online rollback is initiated.

Backup and Rollback Limitations

• Backup is maintained only for the most recent upgrade.
• Rollback is supported only for that most recent upgrade.

Online vs Offline Upgrade and Rollback Rules

• During upgrade or rollback, multiple AP Java installations on a node must be in a consistent state. All processes must be either running or stopped. Mixed process states are not supported.
• Offline upgrade and offline rollback requires all AP Java processes to be stopped, while online upgrade and online rollback requires at least one AP Java process to be running.

DevOps Flow Limitations

• When using the DevOps flow, only offline upgrade and rollback are supported.
• Online upgrade is not supported with the DevOps flow.
• To enable the DevOps flow, set the devops parameter to yes in the sdkupgrd.conf file.

Upgrade and Hot Reload Logging

A hot upgrade or reload refers to replacing AP Java JAR and PLM files while the AP Java process is running, without restarting the service.

• Protector hot-reload logs are created by the protector and stored under /opt/protegrity/upgrader/logs/<protector_version>/. Protector upgrade logs are not sent to Protegrity Insights.
• Upgrade Agent logs are created under /opt/protegrity/upgrader/logs/Agent/. When Fluent Bit is enabled, Upgrade Agent logs are removed after being successfully pushed to Protegrity Insights.

Viewing Upgrade Agent Audit Logs

Upgrade and rollback audit logs generated by the Upgrade Agent are available in Protegrity Insights.

To locate Upgrade Agent logs:

Index:

pty_insight_analytics*troubleshooting_*

Filter:

process.name: sdkupgrd

Use this filter to view audit and troubleshooting logs related specifically to Upgrade Agent execution, including upgrade and rollback activities.

Note: Upgrade is not supported if Log Forwarder contains custom configurations for forwarding audit logs to an external SIEM.