立即与支持人员聊天
与支持团队交流

Foglight 5.9.3 - Upgrade Guide

Understand product versions Best practices Upgrade the Foglight Management Server Upgrade the Foglight Agent Manager Upgrade the Application Monitoring cartridges Upgrade the Database cartridges Upgrade the End User Management cartridges Upgrading the Infrastructure Management cartridges Upgrade the Integration cartridges Upgrade the cartridges in a federated or High Availability (HA) environment Appendix: Deploying an agent package using the browser interface

Upgrade installations with multiple state instances

When upgrading an Agent Manager installation that has multiple state instances running, all the state instances must be upgraded simultaneously, otherwise the upgrade process fails with errors.

You must use one of the following upgrade options:

•
Option 1: Select all hosts in the Agent Manager installation-set when initiating the upgrade.
•
Option 2: If the hosts must be upgraded individually, deactivate all of the Foglight 4 based agents running on the Agent Manager hosts that have already been upgraded in the installation-set.

Once you finish upgrading the Agent Manager hosts, restart each of the agents that were deactivated.

 
* 
NOTE: There is currently a know issue related to this type of installation. For details, see FglAM vm.config file migration fails under multi-state installations.

 

Upgrade a 32-bit FglAM installation on a 64-bit operating system

This section provides instructions for upgrading an existing 32-bit FglAM installation on a 64-bit operating system.

 
* 
NOTE: When existing installations of 32-bit FglAM instances on 64-bit operating systems are improperly updated to 64-bit installations, this causes the FglAM instances to fail when they are restarted. New 32-bit installations of FglAM 5.8.1 or later are not affected by this issue.
To upgrade an existing 32-bit FglAM installation on a 64-bit operating system:
1
Shut down the existing FglAM instance.
2
Install a “new” copy of FglAM, version 5.8.1 or later, on the same system.
3
Edit the “new” {{state/default/config/fglam.config.xml}} file, and replace the {{<config:id> ... </config:id>}} value with that obtained from the “existing” FglAM installation.
4
Edit the “new” {{state/default/config/fglam.config.xml}} file, and replace the {{<config:host-display-name> ... </config:host-display-name>}} value with that obtained from the “existing” FglAM installation.
5
Start the new FglAM installation and deploy to it all cartridges that we deployed to the old FglAM installation.

Agent Manager upgrade issues

Agent Manager upgrades for multiple state instances may fail in certain situations. A detailed description of this issue and a workaround is provided in FglAM vm.config file migration fails under multi-state installations.

Agent Manager upgrades from a 5.5.4.x legacy release require an intermediary upgrade to 5.6.7 prior to upgrading to 5.8.5 or later. To complete this intermediary upgrade, install one or more of the Agent Manager 5.6.7 platform-specific cartridges (as required), and upgrade the legacy hosts to this release before deploying the 5.9.3 Agent Manager cartridge or upgrading the Foglight Management Server to version 5.9.x.

After all of the legacy hosts are running version 5.6.7, and the Foglight Management Server is upgraded to version 5.9.x or later, you can start upgrading your hosts to version 5.9.3.

You may encounter issues in the following situation when upgrading the Agent Manager: Upgrade from an Agent Manager version earlier than 5.5.4.

 
* 
NOTE: If you have previously added certificates to the JRE manually, and are upgrading from a version earlier than 5.6.2.2, see Certificate migration from version 5.6.2.1 or earlier.

FglAM vm.config file migration fails under multi-state installations

FglAM vm.config file migration fails under multi-state installations

Description

When upgrading a multi-state Foglight Agent Managers that share “bin” directories, some of the agent managers become unresponsive as the states are running out of memory. “Out of memory” messages appear in the logs. In addition, error messages like the following appear in the agent manager log:

Foglight_Agent_Manager\state\default\config\client.config does not exist and will not be loaded.
Foglight_Agent_Manager\state\default\config\baseline.jvmargs.config does not exist and will not be loaded.

Workaround

1
Locate the client.config and baseline.jvmargs.config files.
Two new files are deployed to the state config directory during a FglAM upgrade. Locate these files (client.config and baseline.jvmargs.config) within the FglAM state instance that was upgraded.
As these file instances may already contain transferred values from the legacy vm.config, you need to review each of the settings in both of these files in order to ensure that these configuration options apply to the FglAM state instance that they are being copied into.
2
Note that the vm.config settings were migrated.
The legacy vm.config file has be replaced with two new config files. The settings in this file have been split between the new client.config and the baseline.jvmargs.config files.
3
Migrate the vmparameter.x from vm.config to baseline.jvmargs.config.
Locate the vm.config file within the config state directory instance of FglAM. At the bottom of the file there is a section for defining vmparameter.x = ""; values. Copy over the vmparameter.x settings from the legacy vm.config here into the baseline.jvmargs.config file.
4
Validate the settings in client.config with vm.config values.
Review all of the options declared in the vm.config with those of the client.config you have copied over. The client.config is a super-set of properties from the vm.config (with the exception that the vmparameter values are no longer defined here). So each property that exists in the vm.config should also exist in the client.config. Ensure that each of the common config values in the client.config file matches the values in the vm.config. If they are different, then update the client.config to match.
5
Migrate the java.vm config option.
If the java.vm config option was set in the vm.config, then update the java.vm option in the new client.config. When transferring this value over, ensure that the path value is quoted and back-slashes escaped. For example:
Windows:
java.vm = "C:\\shared_java_vms\\1.5\\jre";
Unix:
java.vm = "/opt/shared_java_vms/1.5/jre";
6
Once migration is complete, and you have validated that all config settings are in their new locations, delete the vm.config file and restart the FglAM process.
相关文档

The document was helpful.

选择评级

I easily found the information I needed.

选择评级