Defect ID

Known Issue

Cannot deploy multiple HA-aware gars to a standby host at one time.
Workaround:

1. Log in to http://<foglight_home>:8080/jmx-console, and then click name = HAManager.
2. In the page that opens, click Invoke for the diagnosticSnapshotAsString() API.
3. Find the appropriate primary HA host (mState = PRIMARY).
4. Log in to http://<foglight_home>:8080/, and then go to Dashboards > Administration > Agents > Agent Managers.
5. Select the primary HA host found in step 3, and click Deploy Agent Package.
6. In the dialog box that appears, select multiple agent packages to deploy.
7. Click Next, and then click Finish to start the deploy task.
   When the deploy task completes, the agent packages deployed to the primary host will be automatically deployed to the standby host in a few minutes.

1. Go to the monitored host, and then execute the following commands:
   su root
   rm -f /etc/machine-id
   systemd-machine-id-setup
2. Restart the FglAM. Restart the operating system if this issue still exists after restarting the FglAM.

1. Set system.id.enabled = false for all FglAM instances in the <fglam_home>/state/<state_name>/config/client.config file.
2. Change the display name in the <fglam_home>/state/<state_name>/config/fglam.config.xml file, and then restart the FglAM.

Workaround 3: If you have cloned the servers, do not start up the FglAM. Set system.id.enabled = false for all FglAM instances in the <fglam_home>/state/<state_name>/config/client.config file, and then start the FglAM for the first time.

Agent is not listed under "agents" property of FglAMClientInstance or Host object after moved.

The Agent Manager fails to connect to the Management Server while using the default HTTPS SSL certificate.

Workaround: Install a newer certificate on the Management Server.

Upgrades from 5.7.4 to 5.8.1 or 5.8.2 may result in an error during the upgrade process.

Workaround: If you are currently running a 5.7.4 install and you want to upgrade, then you must upgrade to version 5.8.5 or later.

Foglight Log Monitor does not support UNC (Universal Naming Convention) paths.

Workaround: The following workaround applies when monitoring local log files. Monitoring remote log files is not supported.

1. Map the UNC path to a drive letter on the local machine running the Agent Manager.

2. If any monitored log files are residing in the UNC path, point the Log Monitor Agent to this location using the mapped drive letter, not its UNC path.

Installing and configuring multiple Foglight Agent Manager instances on a single physical host can cause some topology churn in the Host model representing the Agent Manager.

Workaround: By default, the Agent Manager submits performance metrics about itself. If multiple Agent Manager instances are running on the same physical host, disable the performance monitoring self-metric submission for each Agent Manager Instance by completing the following steps:

1.  Open the $FGLAM_STATE/config/baseline.jvmargs.config file for editing.

2. Add the following entry to the vmparameter. properties section of the file:
   
   vmparameter.<X> = "-Dquest.glue.disable.performancemonitor=true";
   
   Important. You must replace <X> with the next numeric sequence number.
   
   

3.  Save the file.

4.  Restart the Agent Manager

Additionally, an Agent that submits a Host object representing the monitoring host (for example, an Agent Manager instance that is running and hosting an agent instance) as part of its monitored collection causes a Host topology churn when these agent types are deployed to additional Agent Manager instances running on the same physical host.
If the monitoring agent's type supports it, its configuration should be adjusted to prevent the submission of monitoring host system ID. For example, this configuration is available for the Foglight for Infrastructure Agents and can be disabled by setting the agent instances' Collect System ID property to false.

The Agent Manager vm.config file migration fails under multi-state installs.

Workaround:  The legacy vm.config file is replaced with two new configuration files: client.config and baseline.jvmargs.config. Locate these files within the upgraded Agent Manager state instance. As these file instances may already contain transferred values from the legacy vm.config, review each of the settings in both of these files in order to ensure that these configuration options apply to the Agent Manager state instance that they are being copied into.

1. Locate the vm.config file within the configuration state directory instance of the Agent Manager. The bottom of the file contains a section for defining vmparameter.x = ""; values. Copy over these settings from vm.config here into the baseline.jvmargs.config file.

2. Review all of the options declared in vm.config with those of client.config that you have copied over. The client.config file is a super-set of properties from vm.config (with the exception of vmparameter values that are no longer defined here). So each property that exists in vm.config should also exist in client.config. Ensure that each of the common configuration values in the client.config file matches the values in the vm.config, and make any updates, if required.

3. If the java.vm configuration parameter was set in vm.config, then you should update this option in the new client.config file. When transferring this value over, ensure that the path value is quoted and backslashes escaped. For example:
   
   Windows: java.vm = "C:\\shared_java_vms\\1.5\\jre";
   Unix: java.vm = "/opt/shared_java_vms/1.5/jre";
   

4. After validating that all of the configuration settings are in their new locations, delete the vm.config file and restart the Agent Manager process.

OutOfMemoryError: The Agent Manager cannot create new native thread. It shuts down when the open file descriptor limit is too low.
Workaround: When creating a large number of agents on a single Agent Manager instance, you must ensure that the maximum number of open file descriptors (displayed by the ulimit -n command) is set high enough. 256 is the minimum suggested for an Agent Manager installation and 512 or more is recommended for an Agent Manager hosting up to 15 agents. 1024 is recommended for an Agent Manager hosting more than 15 agents. This value may need to be adjusted even higher if more agents are created on a single Agent Manager install.

The Agent Manager running on Solaris may fail to run local or external commands during startup or through the SSHLocalConnectionImpl class.

Parentheses can cause a command execution to fail while using a LocalWindowsCommandShell connection.

Workaround: If parentheses are used for grouping commands (and not in an echo context), use spaces to separate them from the other tokens in the command. For example, instead of this command:

if 3 gtr 2 (echo "3>2") else (echo "3 leq 2")

Use the following:

if 3 gtr 2 ( echo "3>2" ) else ( echo "3 leq 2" )

Slave processes exist for all installed out-of-process (OOP) agent packages, even if no agent instances are running.

Workaround: OOP packages which are not running any agent instances may be un-deployed from the Agent Manager. Currently, this is only possible using a manual procedure.

The deployed agent scratch directory created for JFogbank-type agents is not deleted during an upgrade.

Workaround: The orphaned directory is benign, and can be manually deleted after the upgrade is complete.