Foglight 5.9.1 - Federation Field Guide

Troubleshooting

This section presents a list of known federation-related issues:

Frequently asked questions

This section presents a list of the most frequently asked questions related to Foglight™ federation:

For a complete list of versions supported in this and previous versions of the Federation Master, see Requirements.

For optimal results, your Federation Master and Federated Child(ren) should be the same version.

NOTE: If a Federated Child is an earlier version than your Federation Master, performance may not be optimal.

This theory is under Quality Assurance testing and has not been validated yet. Therefore, this release imposes a strict rule that the cartridge versions need to be the same.

The Federation Master stores about 15% of what a Management Server stores.

NOTE: This value is an estimate. The data ratio may change over time.

The Federation Master receives data on demand from its clients. The data is only cached in the memory (not stored in the Federation Master’s repository), which ensures that similar retention policies are used for the Federation Master and Federated Children.

Yes, running different databases between Federated Child(ren) and a Federation Master is a supported configuration.

Mixing different platforms between Federation Master and Federated Children is allowed and supported. The only requirement is to install the same Management Server version on all servers that are part of the federated environment. The Federation Master does not store a lot of data, so having the Federation Master running with an embedded or external MySQL database is supported as well.

Yes, it is able to do so. The Federation Master synchronizes all of the models across all Federated Children. When a dashboard is deployed, it operates against the federated model. For data, the Federation Master handles sending queries to each of the Federated Children at the time the query is made. Therefore, you can use a browser on the Federation Master to display all the information. The Federation Master does not have a heavy data load because it sends queries to each of the Federated Children.

A Management Server can act as either a Federated Child or a Federation Master—the code base is the same, just the configuration is different.

A Management Server has built-in High Availability mode, and the Management Server cluster can perform a hot failover. Agents have a propagation mechanism that allows them to redirect to the hot failover server in High Availability mode.

In federation, multiple High Availability Federated Children can be added to the list of servers in federation.config. If High Availability makes one Federated Child become the primary server of a cluster, the Federation Master automatically receives data from this new primary server.

NOTE: If the Federation Master has the addresses of all Federated Children (both primary and standby) configured in federation.config, it is able to redirect requests appropriately (some data may be unavailable for short periods of time when Federated Children terminate).

Federated Children can run in High Availability mode, Federation Masters cannot.

CAUTION: Customers are advised to configure nothing on the Federation Master until it can run in High Availability mode. Failing to do so may result in data loss.

No, the Federation Master does not accept agent connections (see details on the earlier FAQ Does the Federation Master have any High Availability capabilities, to prevent it from being a single point of failure?).

[Hide the following information until we have a formula for calculating the repository sizing]

Size of the Federation Master database is based upon the size of the federated model, not the amount of collected data from Federated Children. The repository size is generally smaller for the Federation Master.

All the functionality in the Foglight browser interface is federated, with the exception of the administrative functions (for example, the agent management).

The agent property data (previously known as ASP data) is not shared between Federated Children and the Federation Master:

The status shown on the Federation Master browser interface is as up-to-date as the status shown on any other Management Server. The Federation Master pulls data from the Federated Children on request (for example, when a user clicks a dashboard), or at the refresh interval that is associated with a given dashboard/view.

WCF (Web Component Framework) lets you configure refresh intervals. The minimum refresh interval is one second.

NOTE: Alarms are subject to some delay due to caching (although they are generally pulled on demand), as described in section Understanding federation communication channels.

No, it is not. New connections are created as needed. If there is no activity for a while, older connections may be closed.

Yes, this is a concern. Ideally the time must be kept synchronized via some system service (such as NTP). If the time on the two types of servers is not synchronized, requests for data are made based on the Federation Master time, but serviced based on the Federated Child time (for example, data shown as 11:30 may in fact be 11:45, or 11:20).

IMPORTANT: Refresh time depends on the environment complexity.

IMPORTANT: No configuration changes are necessary in this case.

If you have set up token exchange security between the Federation Master and the Federated Child, the username on the Federated Child will understand to take the name from the Federation Master. For instructions on how to set up token exchange security, see Security settings.

If you have not set up token exchange security between the Federation Master and the Federated Child, the acknowledge operation fails immediately, and a security error appears on the Federation Master. Permissions are not enforced for alarm clear or acknowledge operations, just user authentication (the same as in the non-federation case).

Topology changes made on the Federated Children are visible on the Federation Master with a delay defined by the TopologyRefreshPeriod parameter in the federation.config file. Alarms are treated differently than topology changes, and their refresh frequency is defined by the MaxAlarmUpdateDelay parameter in the federation.config file.

When the link between the Federation Master and a Federated Child is interrupted, then the Federation Master has no access to data on that Federated Child. If several Federated Children are connected, and one link to one of them goes down, the Federation Master continues to receive data from the connected servers.

The Management Server reloads the federation.config periodically, and all changes take effect upon reload (by default, once a minute).

You can override any property in the server.config using the standard system properties methods that are recognized by the common code. If a property from server.config is overridden via a system property, then the override holds even if the configuration is modified at runtime.

The only thing stored on the Federation Master is the combined topology. All alarms and data are pulled on demand (that is, they are not stored). The Federation Master-side derived metrics and local alarms are stored as usual.