Foglight 5.9.2 - Federation Field Guide

지금 지원 담당자와 채팅

Model union rules

Metric pull on demand Alarm service communication channel

Planning for federation

Communication ports HA considerations

Configuring a federated environment

Setting up a federated environment Federation configuration changes Security settings Query limitations Custom script queries Upgrading cartridges on a federated system Selectively disabling federation services Deploying cartridge components

Troubleshooting Frequently asked questions

Federation overview

Federation is a Foglight™ feature that addresses the needs of customers who monitor large-scale environments that are naturally partitioned into logical units. Each partition is traditionally served by one Foglight Management Server instance and its distributed clients/agents.

This document presents an overview of the federation feature and provides guidelines for configuring Federation Masters and Federated Children.

The intended audience for this document is the Quest SC/PSO (System Consultant/Professional Services Organization) personnel working in the field.

This section describes a number of cases where the Foglight federation feature is used. In addition, a list of federation capabilities, known issues, and requirements are provided.

•

•

•

•

•

Scalability expectations

Use cases

Federation enables the use of one Foglight™ Management Server to operate, while using other Management Servers as the data source. As illustrated in the following figure, a Foglight user can visualize the data from one or more stand-alone Management Servers (the Federated Children) from a single, central Management Server (the Federation Master). This allows users to meet both local and central monitoring requirements.


	NOTE: It is not possible to perform administration of Federated Children from the Federation Master.

Figure 1. Federation use cases

Federation should be used to address the following customer environment issues:

•

In large environments, where customers need to manage reports, view alarms, and track service levels of items which run on more than one Management Server.

For example:

•

A customer has an environment consisting of 3000 Oracle databases, and a requirement to create a single report that summarizes activity across all 3000 instances. In this case, a Federation Master can be used to pull the data from two or more Management Servers (Federated Children).

•

A customer has a large environment (hundreds of JVMs and hundreds of databases) with one common message bus, which is a key component of every application. In this case, the Federation Master can be used to create application/service models based on topology objects from more than one Federated Child. Service levels, in this case, are calculated on the Federation Master.

•

In an environment where initially a single Management Server is set up, but where customers must see technology views that cross several Management Servers.

For example:

•

Due to purchasing constraints, the business divisions purchase Management Servers for their applications only. As a result, the technical management structure does not align with the business organization. The database administrators and system administrators need to have a unified view of the technology (for example, databases and hosts), across business divisions. To address this problem, the existing servers must be federated.

•

In an environment where customers require scalability improvements on a single Management Server.

For example:

•

If a customer is nearing the scalability limit, or is experiencing slow performance, a Federation Master can be added to remove the UI (user interface) processing burden on the primary Management Server. As a result, this increases the ability of the primary server to process the rules, derived metrics, and calculations.

Capabilities

Federation Masters have the following capabilities:

•

Unifying and periodically synchronizing the model between more than one Foglight™ Management Server.


	IMPORTANT: If an object is deleted from a Federated Child but still exists on another Federated Child, the object is not deleted from the Federation Master. However, if an object is deleted from a Federated Child and does not exist on any other Federated Child, the object and all references to it are deleted from the Federation Master.

•

Serving as the UI, by pulling data on request, from one or more other Management Servers.


	IMPORTANT: The Federation Master does not store data. It queries data, on demand, from the Federated Children.

•

Building new applications/services that use elements crossing more than one Management Server.

•

Processing and storing time-driven derived metrics by gathering the required data at run time from one or more Management Servers.

•

Processing and performing actions on time-driven rules by gathering the required data at run time from one or more Management Servers.

The federation feature allows users to:

•

See a complete view of all topologies combined in the Foglight browser interface. Once the information is centralized, this information is available regardless of whether the Federated Children are running or not.

•

See data in charts as if it were present on the Federation Master (pulled on demand).


	IMPORTANT: If one or more of the Federated Children are not available, the affected data charts will be empty (“No data” may be displayed). Metrics and complex observations (pulled data) are not stored or cached on the Federation Master.

•

Go to the Alarms Viewer and see all current alarms that are reported by any Federated Child.


	IMPORTANT: In Foglight 5.7.x, users can control the alarms’ refresh period by setting the MaxAlarmUpdateDelay parameter in the federation.config file. For more information, see Alarm service communication channel.

•

Define services and add services, categories, and objects from Federated Children.


	IMPORTANT: If an object is deleted from a Federated Child but still exists on another Federated Child, the object is not deleted from the Federation Master. However, if an object is deleted from a Federated Child and does not exist on any other Federated Child, the object and all references to it are deleted from the Federation Master.

•

Write time-driven rules and derived metrics that operate on data across Federated Children.

•

Acknowledge and clear all alarms originating from any of the Federated Children.