Foglight 6.0.0 - Administration and Configuration Guide

Associate Service Objects with Groups and Tiers

Foglight monitors specific parts of your environment based on the concept of services. A service is a collection of monitored objects. An object group is a mechanism that assists in service creation and monitoring. It is a logical way of grouping objects that are of interest to an individual user (for example, an Oracle database administrator), or to multiple users of a system (for example, Oracle databases).

Object groups can be associated with another logical component, tiers. Each tier is a logical representation of a service component. A Foglight service can have one or more tiers. By default, Foglight organizes data into default tiers, including User, Web, Application, Database, Host, and Agent. Tiers allow you to structure services in a way that best represents your monitored environment. This type of logical structure helps you isolate performance problems associated with a specific service tier. For example, to investigate the state of the monitored hosts within the Host tier for a service, drill down on the Host tier and investigate the hosts that are related to it. For more information about services, see the Foglight User Guide.

The object groups that are needed for most service monitoring already ship with Foglight. You can create additional object groups and associate groups with tiers using the Object Groups and Tier Definitions dashboards.

To access the Object Groups dashboard, from the navigation panel, click Dashboards > Services > Object Groups.

To access the Tier Definition dashboard, from the navigation panel, click Dashboards > Services > Tier Definition.

For more information, see the following topics:

Back Up and Restore Foglight

Backup and restore processes are important aspects of database administration. The term backing up refers to making copies of data that can be used to restore your system after a data loss event. The backup process includes:

Restoring a physical backup means reconstructing it and making it available to users. You can restore a previous Foglight installation from a backed up copy of the original environment.

For more information, see the following topics:

Configure Rules and Metric Calculations to Discover Bottlenecks

The Foglight® Management Server and individual cartridges each come with a set of topology types, data retention policies, rules, and calculations, that, in most cases, work out-of-the-box. In more complex environments, your business case may require additional tuning.

Foglight uses flexible rules to apply your business logic to complex, interrelated data from multiple sources within your distributed system. A rule is a piece of business logic that links a condition with a result, for example if HTTP response time exceeds 500 ms, fire a warning alarm. A rule can includes a scope and one or more conditional expressions, alarm messages, and actions. The scope defines the set of topology objects against which it runs. The conditional expression defines the thresholds, that, if reached, cause the rule to fire. Conditional expressions can include registry variables, raw metrics, derived metrics, and topology object properties.

There are two types of rules in Foglight: simple rules and multiple-severity rules. Simple rules do not generate alarms, they fire and invoke actions when their conditions are met. Multiple-severity rules include up to five severity levels and generate alarms when the condition associated with any one of its severity levels is met.

Each severity level can have its own set of variables that you can use in alarm messages. Unlike registry variables, which are global in nature, severity-level variables are only accessible to the severity level in which they exist. For example, a Warning-level variable that contains alarm text can only be referenced by the alarm message defined for the Warning severity. Critical- or Fatal-level alarm messages, associated with the same rule, do not have access to this variable.

Severity levels can be associated with actions, causing them to occur each time a threshold is reached. Foglight comes with different types of actions, such as email, command, script, and other types of actions.

Rules have four types of triggers: data-, time-, schedule-, and event-driven triggers.

Many rules come included with Foglight and installed cartridges, such as Agent Health State, BSM All Events, Catalyst Data Service Discarding Data, and others. If the existing rules do not meet your needs, you can create a new one and add it to the rule collection.

A typical installation can include a large number of rules. You can create and manage multiple-severity rules using the Rule Management dashboard. To access this dashboard, on the navigation panel, click Dashboards > Administration > Rules & Notifications > Rules. The Rules dashboard provides access to modifying threshold variables appearing in rule conditions. For an extended set of rule management tasks, such as viewing and editing rule definitions, copying, disabling, and enabling rules, suspending or resuming rule actions, use the Manage Rules dashboard. Click Old Manage Rules to access the Manage Rules dashboard.

To obtain additional diagnostics about rule behavior and how they affect your monitoring environment, use the Rule Diagnostics dashboard. From here, drill down to a specific rule and explore the objects are affected by the rule, or find out how many times a rule was executed against a specific object. This can help you understand rule behavior and debug any problems associated with a particular rule. To access this dashboard, from the navigation panel, click Dashboards > Administration > Rules & Notifications > Rules, then click Diagnostics from the rule’s context menu.

Related topics:

For more information, see the following topics:

Working with Derived Metrics

In addition to building topology models at run-time using the data collected from monitored systems, Foglight has a unique capability to apply pre-defined calculations to the collected metrics. Metric calculations are typically scoped to specific parts of the topology and their values can change over time. They can be reused in expressions to simplify their syntax and speed up system deployment.

A metric is a specific value that is measured over time. There are two types of metrics in Foglight: raw metrics and derived metrics. Raw metrics are collected directly from your monitored environment and sent to the Foglight Management Server. Derived metrics are calculated from one or more raw or derived metrics. They are scoped to a topology type and can optionally be scoped to specific objects of that type. Many derived metrics come included with Foglight and installed cartridges. If none of the existing derived metrics meet your needs, you can create a new one and add it to the derived metric collection.

There are many reasons why it can be useful to create derived metrics. For example, creating derived metrics can make managing rules simpler by reusing metric expressions.

You can create and manage derived metrics using the Manage Derived Metrics dashboard. A typical installation can include a large number of rules. The Manage Derived Metrics dashboard lists all derived metrics that exist in your environment, and allows you to drill down to derived metric definitions. To access this dashboard, from the navigation panel, click Dashboards > Administration > Data > Derived Metrics.

To obtain additional diagnostics about derived metric behavior and how they affect your monitoring environment, use the Derived Metrics Diagnostics dashboard. From here, drill down to a specific derived metric and explore the objects that are affected by the derived metric, or find out how many times a derived metric has been calculated against a specific object. This can help you understand derived metric behavior and debug any problems associated with a particular derived metric. To access this dashboard, in the Administration dashboard, click Metrics Diagnostics in the Data column.

For more information, see the following topics: