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.
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. |
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 7.1.0 Agent Manager cartridge or upgrading the Foglight Management Server to version 7.1.0.
After all of the legacy hosts are running version 5.6.7, and the Foglight Management Server is upgraded to version 7.1.0 or later, you can start upgrading your hosts to version 7.1.0.
You may encounter issues in the following situation when upgrading the Agent Manager: .
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:
Workaround:
1 |
Locate the client.config and baseline.jvmargs.config files. |
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.
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.
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:
Upgrade the Database cartridges
This section explains how to upgrade an earlier version of a database monitoring cartridge to the latest version. For details, refer to the following topics: