Foglight 5.9.1 - Administration and Configuration Guide

Working with Foglight Registry Variables

The Foglight registry is a collection of variables. Their values can be used for evaluation or comparison in monitoring entities and thus often determine evaluation outcome and triggered actions. The Foglight registry is not related to the host’s OS registry (for example, the Windows registry).

Rule conditions, for example, and their expressions can reference registry variables. A registry variable can have a global value that is available to all topology types and objects. It can also have one or more values associated with specific topology types or objects, or calendar dates. For example, your organization can have different administrators looking after different hosts. To configure Foglight to send host-related emails to appropriate recipients, scope the SYSADMIN variable to the monitored host instances and associate an email address with each host.

Many registry variables come included with Foglight and installed cartridges, including AvailabilityCritical, AvailabilityFatal, AvailabilityTarget, and many others. If the existing registry variables do not meet your needs, you can create a new one and add it to the registry variable collection.

You can create and manage registry variables using the Manage Registry Variables dashboard. To access this dashboard, from the navigation panel, click Dashboards > Administration > Rules & Notifications > Manage Registry Variables.

To find out the value of a registry variable for a particular topology type or object during a specific time period, use the Check Registry Value dashboard. To access this dashboard, from the navigation panel, click Dashboards > Administration > Rules & Notifications > Check Registry Value.

For more information, see the following topics:

Associate Metric Calculations with Schedules

A schedule consists of one or more schedule items. Each schedule item includes a start date, an end date or a time range during which it runs, a recurrence pattern, and the range of recurrence. A default Foglight installation includes a number of schedules, including Always, Business hours, Business week, and many others.

Rules, registry variables, derived metrics, and other Foglight components use schedules to initiate calendar-driven actions. For example, a registry variable can have multiple values, each associated with a specific schedule. If none of the existing schedules meet your needs, add a new schedule to the existing collection and associate it with the registry value.

You can create and manage schedules using the Manage Schedules dashboard. To access this dashboard, from the navigation panel, click Dashboards > Administration > Schedules > Manage Schedules.

NOTE: If you accidentially delete the Daily Database Maintenance schedule, the server will recreate it within 24 hours.

For more information, see the following topics:

Manage Data Retention

Retention policies allow you to define how monitoring data is aggregated and for long it is kept before being purged from Foglight. All topology objects in Foglight form a hierarchy whose root is the super-type TopologyObject. Retention policies are inherited from the object’s type. These policies may be overwritten, in which case the modification applies to all child types in the hierarchy.

In addition to retention policies, the collected data has additional life-cycle properties that are defined in storage-config.xml. The life cycle involves several iterations of data collection, aggregation, and storage in database generations. Database generations are database structures that store aggregated data for a specific period of time.

For example, the default retention policy associated with TopologyObject causes the collected data to be rolled up to 15-minute periods after the age of 15 minutes, and stored in Generation 1 for three days. From there, four-hour interval data is rolled up to one-hour periods, and then stored in Generation 2. After 14 days, 5-day interval data from Generation 2 is rolled up to four-hour periods and stored in Generation 3 indefinitely, or until it is purged.

If there is no existing retention policy for a topology type, that type inherits the retention policy from its parent type. If no policies exist within the entire hierarchy, the type inherits the policy from the TopologyObject type. Conversely, setting a retention policy for a topology type completely overrides any policy it inherits from a super-type, and is applied to all sub-types of that topology type.

You create and manage data retention policies using the Retention Policies dashboard. To access this dashboard, from the navigation panel, click Dashboards > Administration > Data > Manage Retention Policies.

Another way to control the retention policies is through the Retention Policies dashboard. This dashboard allows you to control system-wide retention policies and to delete unwanted data from the database as a performance-tuning measure. For more information, see Manage Foglight Database Performance.

For more information, see the following topics:

Expand Your Collection of Topology Types

The set of topology types that exist in your environment depends on your monitoring needs, reflected in the type and nature of cartridges that you use for data collection. If you need additional topology types, you can add them to Foglight.

The following example shows the syntax for defining a topology type:

The Add Topology Types dashboard allows you to add new topology types to your topology model and to validate them. To access this dashboard, from the navigation panel, click Dashboards > Administration > Data > Add Topology Type.

You can explore your database schema using the Schema Browser. You can access the Schema Browser using the Dashboard Development page. For additional details, see the Dashboard Support Guide.

For more information, see Adding topology types.