サポートと今すぐチャット
サポートとのチャット

Foglight 7.3.0 - Administration and Configuration Guide

Administering and Configuring Foglight Extending Your Monitoring Reach with Foglight Cartridges Administering Foglight Configure Rules and Metric Calculations to Discover Bottlenecks Customizing Your Foglight Environment with Tooling

Manage Derived Metrics and Create Derived Metrics

Editing derived metric permissions

Foglight allows you to control access to derived metrics. For each derived metric you can grant or deny read, write, or control access to roles or users. For more information about security concepts in Foglight, see Managing Users and Security.

Foglight employs the following behavior when it comes to permissions of derived metrics:

•
If no one has a permission to the derived metric, everyone has a permission.
•
If one has a permission to the derived metric, others with undefined permission do not have any permission.
•
Final permission is based on a combination of the role, user, and derived metric defined on the server side.
To grant a permissions to a derived metric:
1
On the navigation panel, under Dashboards, choose Administration > Data > Manage Derived Metrics.
2
On the Manage Derived Metrics dashboard, in the row containing the rule whose permissions you want to edit, click the Edit Permissions for Derived Metric button ().
3
To add permissions to a derived metric, complete the following steps.
a
Click the role or user to which you want to assign permissions.
 
* 
TIP: The Not Assigned icons in the Permissions columns indicate that the role has no permissions assigned to it.
b
In the dialog box that appears, use the Read, Write, and Control check boxes to assign permissions as required, and click Save.
The dialog box closes and the selected entry refreshes, showing three check marks in the Permission columns, one for each of the read, write, and control permissions.
4
To edit or delete permissions for a rule, complete the following steps.
a
Click the role or user whose permissions you want to edit.
 
* 
TIP: Three check marks in the Permissions columns indicate that the role already has permissions assigned to it.
b
To edit permissions, ensure that Edit is selected and use the Read, Write, and Control check boxes as required.
or
To delete permissions, select Delete.
c
Click Save.
The dialog box closes and the selected entry refreshes, showing the newly-edited permissions.
Copying or deleting derived metrics

Copying a derived metric is useful in situations when you need to quickly create a modified version of an existing derived metric. Instead of re-creating the metric’s expressions, simply copy a similar metric and edit its calculations.

If you have any derived metrics that are no longer referenced in rule conditions or derived metric expressions, you can delete them from the list. When a derived metric is deleted, all references to that metric in rule conditions and expressions become invalid. This may cause the rule to fail to evaluate. If this occurs, you must manually modify the rule condition or expression.

To copy a derived metric:
1
On the navigation panel, under Dashboards, choose Administration > Data > Manage Derived Metrics.
2
On the Manage Derived Metrics dashboard, in the row containing the derived metric that you want to copy, click Copy Derived Metric ().
3
In the Copy Derivation dialog box, click OK.
4
Provide a unique name for the destination metric.
In the Create Derived Metric view, in the Derived Metric Name box, type the name of the derived metric.
5
If required, edit the settings of the newly-copied derived metric.
For more information, see View and edit derived metrics.
To delete a derived metric:
1
On the navigation panel, under Dashboards, choose Administration > Data > Manage Derived Metrics.
2
On the Manage Derived Metrics dashboard, select the row containing the derived metric that you want to delete.
3
Click the Delete Selected button at the bottom.
4
In the Delete Derivation dialog box, click OK.
The Delete Derivation dialog box closes.
5
Observe the Manage Derived Metrics dashboard.
The newly-deleted derived metrics no longer shows in the list.
Exploring derived metric diagnostics

The Derived Metrics Diagnostics dashboard lists all derived metrics that exist in your environment, including the derived metrics available with the server and any installed cartridges. Use this dashboard to better understand how the existing derived metrics are being calculated and to debug any derivation-related problems.

For each rule, the Derived Metrics Diagnostics dashboard shows the following information:

•
A summary view, at the top. This view shows you at-a-glance information about the amount of derived metrics that are processed in your system and their health. For example, a high ratio of erroneous derivations and their instances can indicate inaccuracies in metric calculations. The view contains the following information:
•
Derived Metrics: The number of all derived metrics defined in your system.
•
Derived Metrics with Errors: The number of erroneous derived metrics.
•
Derivation Rulettes: The number of object instances to which the derived metrics are bound.
•
Derivation Rulettes with Errors: The number of erroneous derivation instances (rulettes).
•
Derivation Metrics without Rulettes: The number of derived metrics that are not bound to any object instances.
•
Name: The derived metric name.
•
Unit: The unit in which the derived metric is expressed, one of billion, billionth, bit, byte, celsius, count, day, exabyte, gigabyte, hour, kilobyte, megabyte, microsecond, million, millionth, millisecond, minute, month, nanosecond, percent, petabyte, revolution, second, terabyte, thousand, thousandth, trillion, trillionth, or year.
•
Scope: The derived metric scope. This can give you a better idea on the effect the derived metric has on your monitored system. The scope identifies one or more topology objects that the derived metric calculates. If the scope is not defined, the derived metrics runs against the entire data set which can have a negative effect on overall performance. A derived metric can be scoped to a topology type and can optionally be scoped to specific topology objects of that type. For more information, see Setting the rule or derived metric scope.
•
Rulettes: A rulette is a derived metric instance that represent the state of the monitoring object to which the derived metric expression applies. This column contains two sub-columns:
•
Count: The number of scoped objects to which the derived metric is bound.
•
In Error: The number of erroneous derivation instances (rulettes). Clicking this column shows a list of the object instances to which the error applies.
•
Cartridge: Identifies the cartridge in which the rule is defined, if applicable. For any rules that you create, this column is blank.
•
Name: The name of the cartridge in which the rule is defined, including the cartridges included with the server, and any installed cartridges. This column is empty for those rules that you create.
•
Version: The version of the cartridge in which the rule is defined, including cartridges included with the server, and any installed cartridges. This column is empty for those rules that you create.
•
Error: If a derived metric is in error, this is usually caused by one of its derived metric calculations being in error. Inspecting individual error messages associated with different derivation instances can often help you diagnose the problem. Start this flow by drilling down on the In Error column and then, in the dwell that appears, clicking the Error column, as described above.
Click the Error column on the Derived Metrics Diagnostics dashboard to open a dwell that contains additional information about the derivation.
•
Last Modified: The most recent date and time at which the derived metric was modified.

From here, you can drill down to a derived metric to see detailed diagnostics about that metric.

Figure 7. Click the row containing a derived metric and, in the dwell that opens, under Go to, click Diagnostic Details.

 
* 
TIP: To edit rule definitions, in the dwell, click Edit Derived Metric and edit the derived metric, as required. For more information, see Get started: create derived metrics.

For more information about the Diagnostic Details view that appears, see View derived metric diagnostic details.

View derived metric diagnostic details

The Diagnostic Details view contains detailed run-time information about a selected derived metric. Use this view to determine which objects the derived metric is bound to and as a debugging tool to help you understand any derivation-related problems. Drill down to this view from the Derived Metrics Diagnostics dashboard.

Figure 8. The View Derived Metric Diagnostic Details view.

This composite view contains the following embedded views:

•
Top-Level View
•
Derived Metric Calculations View
•
Rulette Statistics View
•
Last Evaluation Result Tab
•
Observations Tab
 
 
Table 32. Top-Level View
Description

Shows the derived metric definitions.

Data displayed
•
Name. The derived metric name.
 
•
Unit. The unit in which the derived metric is expressed, such as billion, billionth, bit, byte, celsius, count, day, exabyte, gigabyte, hour, kilobyte, megabyte, microsecond, million, millionth, millisecond, minute, month, nanosecond, percent, petabyte, revolution, second, terabyte, thousand, thousandth, trillion, trillionth, or year.
 
•
Value Type. A derived metric take over the form of the Foglight metric or an observation type. The range of available observations depends on the number of installed cartridges.
 
•
Cartridge. The name of the cartridge in which the derived metric is defined, including the cartridges included with the server, and any installed cartridges. This column is empty for those derived metrics that you create.
 
•
Cartridge Version. The version of the cartridge in which the derived metric is defined, including cartridges included with the server, and any installed cartridges. This column is empty for those derived metrics that you create.
 
•
Description. Contains the Derived Metric Calculations View.
 
Table 33. Derived Metric Calculations View
Description

Shows the derived metric calculations.

Data displayed
•
Scope. The derived metric scope. This can give you a better idea on the effect the derived metric has on your monitored system. The scope identifies one or more topology objects that the derived metric calculates. If the scope is not defined, the derived metrics runs against the entire data set which can have a negative effect on overall performance. A derived metric can be scoped to a topology type and can optionally be scoped to specific topology objects of that type. For more information, see Setting the rule or derived metric scope.
 
•
Expression. Contains the derived metric expression.
 
•
Trigger Type. The trigger type. This value affects the frequency at which Foglight processes the metric’s calculations. The trigger gives you a general idea of the metric’s activity. For example, a default data-driven trigger causes Foglight to process the metric’s calculations every time the data associated with the derived metric is collected. For more information, see Trigger derived metrics.
 
•
Error. If the derived metric has any errors associated with it, this column contains the error indicator.
 
 
Table 34. Rulette Statistics View
Description

Lists one or more object instances to which the derived metric is bound, and shows information about the derived metric activity, as it relates to each object instance. Selecting a table row shows additional details about the derived metric on the Last Evaluation Result Tab and Observations Tab.

Data displayed
•
Object. The name of the object instance used in the derived metric expression and its data type.
 
•
Enabled. Indicates if the object is enabled.
 
•
Error. If a derived metric instance has any errors associated with it, this column contains the error indicator.
 
•
Evaluations. The number of times the object instance was used in the derived metric calculation.
 
•
Reset Time. The date and time of the object’s most recent reset.
 
•
Last Evaluation. The date and time the most recent derived metric calculation took place.
Where to go next
•
Drill down on an entry in the Object column. Displays a dwell that shows the health of the object instance, identifies any agents or hosts related to this instance, and lists links to views that reference the object instance, including the Property Viewer and Metric Analyzer. From here, clicking a link under Related drills down to the selected view.
•
If a derived metric instance has any errors associated with it, the Error column contains the error indicator. Drill down on an error indicator. Displays a message that can help you diagnose the problem.
 
Table 35. Last Evaluation Result Tab
Description

Shows the property values associated with the bound object instance.

Data displayed
•
Last Eval Result. Shows the most recent values of following object properties:
Sum of Squares: Sum of the squares of all metric values collected in the most recent sampling interval.
Standard Deviation: Standard deviation of all metric values collected in the most recent sampling interval.
Maximum: Maximum value of all metric values collected in the most recent sampling interval.
Count: Count of all metric values collected in the most recent sampling interval.
 
Table 36. Observations Tab
Description

Shows information about the object to which the derived metric is bound.

Data displayed
•
Name. The name of the metric evaluated by the derived metric expression.
 
•
Object Name. The name of the object instance to which the derived metric is bound.
 
•
Object Type. The type of the object instance to which the derived metric is bound.
Where to go next
•
Drill down on an entry in the Observations table. Displays a dwell that shows the health of the object instance the metric is associated with, identifies any agents or hosts related to this instance, and lists links to views that reference the object instance, including the Property Viewer and Metric Analyzer. From here, clicking a link under Related drills down to the selected view.
4
View and edit derived metrics

The Manage Derived Metrics dashboard shows all of the derived metrics that exist in your monitoring environment. This includes the derived metrics that come with the Foglight Management Server and installed cartridges, and also any derived metrics that you create. From here, you can drill down to view the settings for a derived metric, and edit them, as required.

To view or edit derived metric:
1
On the navigation panel, under Dashboards, choose Administration > Data > Manage Derived Metrics.
2
On the Manage Derived Metrics dashboard, click the Derived Metric Name column of the row containing the derived metrics whose definitions you want to view.
The Edit Derived Metric view shows the derived metric settings, such as the derived metric name, cartridge name and version (if applicable), modification date, and the derived metric calculations.
 
* 
TIP: If a derived metric comes with the Foglight Management Server or any installed cartridge, the Cartridge Name and Cartridge Version values indicate the cartridge name and its version. Otherwise, if a derived metric is created using the Create Derived Metric dashboard, this value is blank.
3
Observe the metric definitions.
4
Edit the derived metric as required.
•
To edit the name of derived metric, type the desired value into the Derived Metric Name box
•
To make additional modifications, such as adding calculations, see Add calculations to derived metrics for complete instructions.
Get started: create derived metrics

A metric is a specific value that is measured over time. Many derived metrics come included with Foglight and installed cartridges, including activeAgentCount, availability, avg_inserts_per5min, and many others. 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 for using derived metrics in your setup. First, derived metrics make the process of managing rules simpler. For example, using the same expression in multiple rules requires editing each expression when your requirements change. Instead, define a derived metric and edit its expression, instead of editing multiple conditions.

Derivation definitions also allow multiple scoping query/expression pairs under a single definition. For each topology object, the expression paired with the first scoping query which matches the object will be calculated. This allows you to override a derivation definition based on the scoping query where multiple derivations definitions exist.

Use the following guidelines to decide when to use one derivation with multiple scopes, or when to use multiple derivation definitions:

•
Choose a single derivation definition when you need the overriding behavior. If you have a subset of a topology object type that requires a derivation to be calculated differently, use a single derivation definition with additional scope/expression pairs.
For example, you have a derivation freeMemory for topology type OS, with a subtype Unix that requires a different freeMemory calculation. Define a single derivation freeMemory create two scope/expression pairs (one for OS and the other for Unix).
•
Choose a multiple derivation definition when you are using the same observation name for unrelated scoping queries.
For example, if you have a derivation freeMemory for the types OS and JVM, create two separate derivations to avoid coupling the definitions.
•
Choose multiple derivation definitions when you have alternate ways of calculating the same observation for the same topology objects. If you keep the calculations in the same derivation definition, only the first calculation in the list will take effect.

Derived metrics can also help you optimize performance by reducing the number of calculations that need to be performed at run-time. For example, if there are multiple rules that need to use the same complex metric expression in their conditions, creating a derived metric with this expression and using it in these rules’ conditions would have a positive impact on performance: the calculation specified in the metric expression would only need to be performed each time an instance of the derived metric is created instead of each time the rule is evaluated.

To get started with creating a derived metric:
1
Open the Create Derived Metric dashboard by completing one of the following steps:
•
On the navigation panel, under Dashboards, choose Administration > Data > Manage Derived Metrics.
In the Manage Derived Metrics dashboard that appears in the display area, click the Add Derived Metric button in the lower-left corner.
or
•
On the navigation panel, under Dashboards, choose Administration > Data > Create Derived Metric.
2
Provide a descriptive name for the derived metric.
On the Create Derived Metric dashboard, in the Derived Metric Name box, type the name that you want to assign to the derived metric.

From here, you can proceed to Add calculations to derived metrics.

Add calculations to derived metrics

The scope of a derived metric defines the set of topology objects against which Foglight calculates it. A derived metric is scoped to a topology type and can optionally be scoped to specific topology objects of that type. If a derived metric is not scoped to specific objects, it applies to all instances of that type. You specify the derived metric scope using the query language. You can change the scope of a derived metric (the topology type or one or more specific topology objects of that type to which it applies) after its creation.

A derived metric can contain one or more calculations. Foglight processes derived metric calculations in the order they are listed, starting with the first one. Changing their order affects the behavior of the actions that are associated with the derived metric.

For example, if there are two calculations whose conditions evaluate to True, the first calculation takes precedence, causing one or more actions that are associated with that metric to be generated before the next one.

For detail information on how to scope a rule or derived metric to one or more topology objects, see Setting the rule or derived metric scope.

To add calculations to a derived metric:
 
* 
NOTE: This procedure continues from View and edit derived metrics or Get started: create derived metrics.
1
New derived metrics only. In the Derived Metric Calculations area, click Add Calculation.
2
Use the Derived Metric Scope and Expression areas to specify the scope of the derived metric.
 
* 
IMPORTANT: If you change the topology type or one or more objects to which the derived metric is scoped, you may need to reconfigure the derived metric expression: the metrics specified in the existing expression may not be available for the new topology type or object.

Likewise, if you change the metrics that are specified in the Expression field, ensure that the new metrics are available for the topology type or one or more objects to which the derived metric is scoped.
3
When you finish adding calculations to derived metrics, ensure that the order in which they appear is valid.
Foglight evaluates derived metric calculations in the order they are listed, starting with the first one. Changing their order affects the output of actions that are associated with those calculations.
To change the order of calculations, use the Move up () or Move down () buttons.
4
Specify the unit of the derived metric.
Use one or a combination of the two Unit boxes under the Derived Metric Calculations list to specify the unit. Each box contains the following choices: billion, billionth, bit, byte, celsius, count, day, exabyte, gigabyte, hour, kilobyte, megabyte, microsecond, million, millionth, millisecond, minute, month, nanosecond, percent, petabyte, revolution, second, terabyte, thousand, thousandth, trillion, trillionth, and year.
For example, to set the unit o the derived metric to a number of days per month, click the left Unit box, and select day from the list that appears, then click the right Unit box and select month, as illustrated bellow.
5
Optional — Add comments about the newly-created derived metric.

From here, you can proceed to Trigger derived metrics.

Trigger derived metrics

An instance of a derived metric is created when its definition is triggered. A derived metric is configured to have one of the following triggers:

•
Schedule-Driven Derived Metric. A schedule-driven derived metric is evaluated based on an existing schedule. For more information about schedules, see Associate Metric Calculations with Schedules.
There are three trigger timing options for schedule-driven derived metrics:
•
Enter and Exit. Causes the derived metric to be evaluated when the period defined by the schedule begins and ends.
•
Enter only. Causes the derived metric to be evaluated when the period defined by the schedule begins.
•
Exit only. Causes the derived metric to be evaluated when the period defined by the schedule ends.
•
Time-Driven Derived Metrics. A time-driven trigger causes the derived metric to be evaluated once per pre-defined interval.
•
Data-Driven Derived Metrics. If a derived metric has a data-driven trigger, it will be evaluated every time that data that is used in the expression for the derived metric is sent to the Foglight Management Server.
To assign a schedule-driven trigger to a derived metric:
 
* 
NOTE: This procedure continues from Add calculations to derived metrics.
1
In the Expression area, under Trigger Type, select the Schedule Driven option.
2
Choose the schedule during which you want the derived metric to be triggered.
Click Schedule and select a schedule from the list that appears.
 
* 
NOTE: The list shows all schedules that exist in Foglight. For more information about schedules, see Associate Metric Calculations with Schedules.
3
Select the trigger timing option to specify the point in time in which Foglight evaluates the derived metric in relation with the newly-specified schedule.
Click Trigger Timing and select one of the following options from the list that appears: Enter and Exit, Enter only, or Exit only.
4
To evaluate the derived metric expression in each collection interval, regardless of the existence of data, select Enable Trigger without Data.
5
Save your changes.
To assign a time-driven trigger to a derived metric:
 
* 
NOTE: This procedure continues from Add calculations to derived metrics.
1
In the Expression area, under Trigger Type, select the Time Driven option.
2
Specify the recurrence interval for the trigger in the hh:mm:ss format.
3
To evaluate the derived metric expression in each collection interval, regardless of the existence of data, select Enable Trigger without Data.
4
Save your changes.
To assign a data-driven trigger to a derived metric:
 
* 
NOTE: This procedure continues from Add calculations to derived metrics.
1
In the Expression area, under Trigger Type, select the Data Driven option.
2
Save your changes.

From here, you can proceed to Setting the derived metric type.

Setting the derived metric type

When you define the scope and trigger of the derived metric, you can specify the value type for the derived metric. The value type for a derived metric affects its appearance in dashboards. You can set the derived type to a metric, and specify its unit of measurement, or to an observation.

To set the value type for a derived metric:
 
* 
NOTE: This procedure continues from Trigger derived metrics.
1
In the area immediately below the Derived Metric Calculations list, click Value Type and select Metric from the list that appears.
2
Select the units of measurement.
Use one or both of the Unit boxes on the left of Unit Type as required.
For example, percent or count / second.
 
* 
NOTE: You cannot change the value type of a derived metric unless you also change the name of the derived metric.

You can change the unit of measurement for a derived metric, but only to a compatible unit. For example, you could change the unit from megabyte to kilobyte, but you could not change it from megabyte to percent without also changing the name of the derived metric.
To set the value type to an observation:
 
* 
NOTE: This procedure continues from Trigger derived metrics.
1
In the area immediately below the Derived Metric Calculations list, ensure that both of the Unit boxes are blank.
2
Specify the observation that you want to use as the value type for the derived metric.
Click Value Type on the right and select an observation from the list that appears.
3
Optional — Add comments about the value type.
Type your comments in the Comments box.
4
Save your changes.
Click Add (when creating a new derived metric) or Save (when editing an existing metric).

IntelliProfile

Explore the IntelliProfile dashboard

IntelliProfile evaluates collected data against the baseline, and compares incoming data for those metrics that have IntelliProfile threshold levels configured. Metric threshold states reflect the degree of deviation from the baseline, and can indicate potential performance bottlenecks. If there are any rule conditions that evaluate threshold states for such metrics, Foglight can generate alarms when a metric enters a certain threshold state.

 
* 
NOTE: You can only use this feature after installing a baseline cartridge that contains definitions for a selected metric property. Agent developers can write baseline cartridges. For more information about metric thresholds, see Working with Metric Thresholds.

The dashboard contains two views: General and Thresholds.

General

This view indicates the minimal number of hours allocated to IntelliProfile to process data, before generating the initial baseline. By default, this period is 24 hours. It also determines the length of time during which IntelliProfile retains collected data for its learning cycles. By default, this period is 90 days. Increasing this value results in larger storage requirements. Click to edit these values, as required. For more information, see Configuring the baseline.

Thresholds

This view shows the data ranges for Information, Warning, and Critical thresholds. Each data range has a minimum and maximum value pair that represents the percentage of expected average value. For more information, see Edit IntelliProfile thresholds.

Configuring the baseline

The General view on the IntelliProfile dashboard shows the amounts of time allocated to IntelliProfile to process and retain data. Edit these values to suit your needs, as required.

To configure the baseline:
1
On the navigation panel, under Dashboards, choose Administration > Data > IntelliProfile.
2
On the IntelliProfile dashboard that appears in the display area, in the General view, set the IntelliProfile is ready after first value. By default, this period is set to 24 hours.
3
Set the Allow IntelliProfile to automatically calculate the optimal based on the instance activity of the past value. By default, this period is set to 90 days.
 
* 
IMPORTANT: Increasing this value results in larger storage requirements.
4
Click Save Changes. The Save IntelliProfile dialog box opens.
5
Click Ok to close it.
Edit IntelliProfile thresholds

The Thresholds view on the IntelliProfile dashboard shows the data ranges for the default threshold bounds. Each data range has a minimum and maximum value pair that represents the percentage of expected average value.

In a typical scenario, most data samples fall into the Information (baseline) data range, followed by data in the Warning and Critical ranges.

Figure 9. Typical data sample pattern for IntelliProfile baseline ranges.

However, in some cases, threshold ranges do not follow this order. You may have, for example, the Critical threshold value level immediately after Information, followed by the Warning level. When the values overlap, certain levels can take precedents over others, depending on the order in which they are defined, and any overrides. For complete information, see Add bounds to threshold levels.

Figure 10. Overlapping threshold value ranges.

Cartridge developers can write rule conditions to examine if a metric entered a particular threshold state, and generate alarms. For example, if a memory usage metric enters a Warning state, you can write a condition that triggers a Warning alarm to alert end-users of a potential bottleneck:

thresholdState(#memory_usage#)?.name == "Warning"

Threshold level bounds are stored in the Foglight registry. You can edit them using the Thresholds view. The Threshold ranges listed on this view illustrate a default scenario in which the levels are listed in the incremental order relative to the baseline. Every threshold value points to a IntelliProfile registry variable that you can edit using this view.

 
Table 37. Threshold values and their related registry variables and default values.
Threshold Value
Registry Variable
Default
Critical Above (%)

IntelliProfile_Percentile1

1

Warning Above (%)

IntelliProfile_Percentile2

3

Information Above (%)

IntelliProfile_Percentile3

5

Information Below (%)

IntelliProfile_Percentile4

95

Warning Below (%)

IntelliProfile_Percentile5

97

Critical Below (%)

IntelliProfile_Percentile6

99

Consider this list as a default mapping for those cases where threshold levels are maintained in incremental order from the baseline, which is the recommended configuration. However, the current server capabilities allow you to assign severities in a different order.

Editing these values updates the related variables, as indicated below. Edit these values to suit your needs.

 
* 
IMPORTANT: Updating these values affect all of the threshold bounds for the metrics that use them. If required, you can always revert to the default values.
To edit threshold values:
1
On the navigation panel, under Dashboards, choose Administration > Data > IntelliProfile.
2
On the IntelliProfile dashboard that appears in the display area, in the Thresholds view, click and edit the values in the table.
 
* 
TIP: You can revert to the default values by clicking Restore Default Thresholds.
3
Click Save Changes. The Save IntelliProfile dialog box opens.
4
Click OK to close it.

Manage Thresholds

Edit threshold permissions

Foglight allows you to control access to thresholds. For each threshold you can grant or deny read, write, or control access to roles or users. For more information about security concepts in Foglight, see Managing Users and Security.

Foglight employs the following behavior when it comes to threshold permissions:

•
If no one has a permission to the threshold, everyone has a permission.
•
If one has a permission to the threshold, others with undefined permission do not have any permission.
•
Final permission is based on a combination of the role, user, and threshold defined on the server side.
To grant permissions for a threshold:
1
On the navigation panel, under Dashboards, click Administration > Data > Manage Thresholds.
2
On the Manage Thresholds dashboard, in the row containing the variable whose permissions you want to edit, click Edit Permissions for Threshold ().
3
To grant permissions to a threshold, complete the following steps.
a
Click the role or user to which you want to assign permissions.
 
* 
TIP: The Not Assigned icons in the Permissions columns indicate that the role does not have permissions assigned to it.
b
In the dialog box that appears, use the Read, Write, and Control check boxes to assign permissions as required, and click Save.
4
To edit or delete permissions for a threshold, complete the following steps.
a
Click the role or user whose permissions you want to edit.
 
* 
TIP: Three check marks in the Permissions columns indicate that the role already has permissions assigned to it.
b
To edit permissions, ensure that Edit is selected and use the Read, Write, and Control check boxes as required.
or
To delete permissions, select Delete.
c
Click Save.
The dialog box closes and the selected entry refreshes, showing the newly-edited permissions.
Delete thresholds

You can delete thresholds that you no longer need. However, when a threshold is deleted, all references to that threshold in rule conditions or derived metric expressions become invalid. This may cause a rule to fail to evaluate. If this occurs, you must manually modify the rule condition or expression.

To delete a threshold:
1
On the navigation panel, under Dashboards, choose Administration > Data > Manage Thresholds.
2
On the Manage Thresholds dashboard, select the row containing the threshold that you want to delete.
3
Click Delete Selected.
4
In the Delete Threshold dialog box, click OK.
The Delete Threshold dialog box closes.
5
Observe the Manage Thresholds dashboard.
The newly-deleted threshold no longer appears in the list.
View and edit thresholds

The Manage Thresholds dashboard lists all of the thresholds that exist in your monitoring environment. This includes the thresholds that come with the Foglight Management Server, any installed cartridges, and also any thresholds that you create.

To view or edit a threshold:
1
On the navigation panel, under Dashboards, choose Administration > Data > Manage Thresholds.
2
On the Manage Thresholds dashboard, click the Metric column of the row containing the threshold whose definitions you want to view.
The Edit Threshold view shows the topology type and its metric property for which the threshold is defined, the selected threshold level, modification date, and threshold bounds. Each threshold level comes with a unique set of pre-defined bound levels. For example, the threshold level for the agent state includes the bound levels that correspond to different agent states, such as Stopped, Started, Running, and others.
3
Observe the threshold definitions.
4
Edit the threshold as required.
•
To change the topology type, metric property, or the threshold level, specify the Topology Type, Metric, or Threshold Levels values.
 
* 
IMPORTANT: Because each threshold level comes with a unique set of pre-defined bound levels, changing any of these values may invalidate the existing threshold bounds.
•
To edit the threshold bounds, use the Threshold Bounds table. For complete instructions, see Add bounds to threshold levels.
Getting started: create thresholds

Threshold levels in metrics are useful in situations when you need to reference a specific metric value multiple times, for example in derived metrics or rules.

Different types of metrics can have different types of threshold levels such as the levels that refer to agent states, alarm severity, and others. Each threshold level comes with a unique set of pre-defined bound levels. For example, the agent state threshold level for the includes the bound levels that correspond to different agent states, such as Stopped, Started, Running, and others. A bound level value can be associated with a constant value, a registry variable, or another metric of the same topology type.

Some thresholds come included with Foglight and installed cartridges, including baselineAvailability. If the existing derived metrics do not meet your needs, you can create a new one and add it to the threshold collection.

To get started with creating a threshold:
1
Open the Create Threshold dashboard by completing one of the following steps:
•
On the navigation panel, under Dashboards, choose Administration > Data > Manage Thresholds.
In the Manage Thresholds dashboard that appears in the display area, click the Add Threshold button in the lower-left corner.
or
•
On the navigation panel, under Dashboards, choose Administration > Data > Create Threshold.
2
Choose the topology type of the metric whose thresholds you want to set.
On the Create Threshold dashboard, in the Step 1: Create Threshold—Select Metric area, click Topology Type and select the topology type from the list that appears.
3
Choose the metric whose thresholds you want to set.
Click Metric and select the metric from the list that appears.
Click Next.
4
In the Step 2: Create Threshold — Select Threshold Level area, click Threshold Levels and choose one of the following predefined threshold levels from the list that appears.
For example, to use an agent state as threshold level, select AgentState.
Click Next.

From here, you can proceed to Add bounds to threshold levels.

Add bounds to threshold levels

Each threshold level comes with a unique set of bound levels. For example, the threshold level for agent state includes bound levels that correspond to different agent states, such as Stopped, Started, Running, and others. A bound level value can be associated with a constant value, a registry variable, or another metric of the same topology object.

 
Table 38. Threshold levels and their associated bound levels
Threshold Level
Threshold Bound Level
AgentHealthState

OK

Running Unexpectedly

Broken

Agent Info Not Present

AgentState

Unknown

Stopped

Starting

Stopping

Running

Collecting data

Running but not collecting data

AlarmChangeType

Fire

Clear

Acknowledge

UserDefined Data

AlarmSeverity

Undefined

Normal

Fire

Warning

Critical

Fatal

CatalystServiceState

Stopped

Stopping

Starting

Started

Failed

Destroyed

Created

Unregistered

Registered

HostDiscoveryStatus

Active

Inactive

IncidentChangeType

Create

Close

Acknowledge

Modify

Delete

ThresholdSeverity

Normal

Critical

Fatal

Warning

UnitGroupAutoScalingType

smalestValue

Locale

You can have one or more types of threshold bounds in a threshold level.

 
Table 39. There are three different types of threshold bound types:
Type
Severity level is bound to
Metric Threshold Bound

Another metric

Registry Variable Threshold Bound

A registry variable

Baseline Threshold Bound

A baseline, defined in the baseline cartridge that contain one or more baseline patterns for the selected metric

NOTE: This option is only available after installing a baseline cartridge that contains the baseline definitions for the selected metric property. A baseline illustrates the behavior of a metric over time, allowing for its categorization into repeating patterns, such as weekly, monthly, and so on, that can be charted, as required. A baseline cartridge contains the definitions of one or more baselines for a particular metric. Agent developers can write baseline cartridges followed by installing them on the Foglight Management Server. When you add or edit a threshold for a metric, if a cartridge that contains baseline definitions for that metric, the Baseline Threshold Bound option becomes available, allowing you to use one or more metric baseline definitions in the selected metric’s threshold definitions.
Constant Threshold Bound

A fixed value

Foglight evaluates threshold bounds in the order that they are listed, starting with the first one. Changing their order affects the output of actions that are associated with those threshold levels.

For example, if a threshold level includes several threshold bounds that reference standard Foglight severity levels in the ascending order such as Normal, Warning, Critical, and Fatal, and you change their order in the list to Normal, Critical, Warning, and Fatal, the Warning, the bound that is associated with the Warning level evaluates to True only after the evaluation of the Critical level.

The ranges of threshold levels are created by going over threshold bounds in the order form first to last (from top to bottom in the Threshold Bounds table) and assigning the threshold level of the bound to the range immediately above the threshold bound. In some cases, their ranges do not always follow a progression sequence. This can happen in cases where threshold bounds values are calculated during run-time. For example, a set of threshold bounds can include a mix of constant values and baseline values. As a result, the effective threshold ranges may be different at different time points. It is possible to have valid configurations when threshold ranges minimize to zero '0' or even overlap. When this happens, the default behavior causes the higher threshold level to be applied. To ensure that the appropriate threshold level is applied when their ranges overlap, you can either accept the default behavior, or define a precedence to override the level with a higher value. This can be done with the Override flag. When set for a threshold bound, this flag ensures that the threshold level associated with a particular threshold bound is applied to incoming data even though its value overlap with a higher threshold level.

 
Figure 11. Examples of the change to threshold behavior when bounds are changed.
Threshold Bounds
Applied Threshold Levels
Observed Behavior

There are no threshold level overrides set for any of the threshold bounds.

The Override flag is set for the Fatal threshold level (column four in the Threshold Bounds table on the left), causing it to take precedence over Warning.

The Override flag is set for the Normal and Fatal threshold levels, causing it to take precedence over Warning. In this case, Normal takes precedence over Critical, and Fatal takes precedence over Warning.

To bind a threshold level to a metric:
 
* 
NOTE: This procedure continues from View and edit thresholds or Getting started: create thresholds.
1
Select the severity type of the threshold level.
Click Level and select a threshold level from the list that appears.
2
Select the Metric Threshold Bound option.
3
Click Metric and select a metric from the list that appears.
4
Optional — Specify the standard deviation from the value that the selected metric contains.
In the Number of Standard Deviation box, type the standard deviation.
5
Optional — If you want Foglight to acknowledge that the threshold is reached when the threshold level exceeds the value of the binding metric, ensure that the Inclusive check box is cleared.
If you want Foglight to acknowledge that the threshold is reached when the threshold level reaches the value of the binding metric, check the Inclusive check box.
6
Optional — If your threshold levels are expected to change over time, and you want the associated threshold level to take precedence over any levels with that have a higher value, select the Override check box.
For more information see Add bounds to threshold levels.
7
Click Add.
To bind a threshold level to a registry variable:
 
* 
NOTE: This procedure continues from View and edit thresholds or Getting started: create thresholds.
1
Select the severity type of the threshold level.
Click Level and select a severity level from the list that appears.
2
Select the Registry Variable Threshold Bound option.
3
Click Registry Variable Name and select a variable from the list that appears.
4
If you want Foglight to acknowledge that the threshold is reached when the threshold level exceeds the value of the binding registry variable, ensure that the Inclusive check box is cleared.
or
If you want Foglight to acknowledge that the threshold is reached when the threshold level reaches the value of the binding registry variable, select Inclusive.
5
Optional — If your threshold levels are expected to change over time, and you want the associated threshold level to take precedence over any levels with that have a higher value, select the Override check box.
For more information about this behavior, see Add bounds to threshold levels.
6
Click Add.
The newly-created registry variable threshold bound appears in the Threshold Bounds table.
To bind a threshold level to a baseline:
 
* 
NOTE: The Baseline Threshold Bound option is only available after installing a baseline cartridge that contains baseline definitions for the selected metric property. Agent developers can write baseline cartridges. A baseline illustrates the behavior of a metric over time, allowing for its categorization into repeating patterns, such as weekly, monthly, and so on, that can be charted. A baseline cartridge contains the definitions of one or more baselines for a particular metric. When you add or edit a threshold for a metric, if a cartridge contains baseline definitions for that metric, the Baseline Threshold Bound option becomes available, allowing you to use one or more metric baseline definitions in the selected metric’s threshold definitions.
 
* 
NOTE: This procedure continues from View and edit thresholds or Getting started: create thresholds.
1
Select the severity type of the threshold level.
Click Level and select a severity level from the list that appears.
2
Select the Baseline Threshold Bound option.
The Baseline Name and Baseline Bound boxes appear below the Bound Type options, allowing you to specify the baseline value to which you want to bind the severity level.
3
Select the baseline and a bound value from that baseline to which you want to bind the selected threshold level.
The installed baseline cartridge contains one or more baseline definitions for the selected metric. Each baseline contains one or more values that can be used as threshold bounds.
a
Click Baseline Name and select a baseline from the list that appears.
b
Click Baseline Bound and select a baseline value that you want to use as a threshold.
4
Optional — If you want Foglight to acknowledge that the threshold is reached when the threshold level exceeds the value of the binding baseline value, ensure that the Inclusive check box is cleared.
If you want the Foglight to acknowledge that the threshold is reached when the threshold level reaches the value of the binding baseline value, check the Inclusive check box.
5
Optional — If your threshold levels are expected to change over time, and you want the associated threshold level to take precedence over any levels with that have a higher value, select the Override check box.
For more information about this behavior, see Add bounds to threshold levels.
6
Click Add.
To bind a threshold level to a constant value:
 
* 
NOTE: This procedure continues from View and edit thresholds or Getting started: create thresholds.
1
Select the severity type of the threshold level.
Click Level and select a severity level from the list that appears.
2
Select the Constant Threshold Bound option.
.
3
Specify the value to which you want to bind the threshold level.
In the Value box, type that value. This can be a positive or a negative value, depending on the metric range.
4
Optional — If you want Foglight to acknowledge that the threshold is reached when the threshold level exceeds the value of the binding registry variable, ensure that the Inclusive check box is cleared.
If you want the Foglight to acknowledge that the threshold is reached when the threshold level reaches the value of the binding registry variable, check the Inclusive check box.
5
Optional — If your threshold levels are expected to change over time, and you want the associated threshold level to take precedence over any levels with that have a higher value, select the Override check box.
For more information about this behavior, see Add bounds to threshold levels.
6
Click Add.
To save your changes:
* 
NOTE: his procedure continues from any of the following sections:
•
To bind a threshold level to a metric:
•
To bind a threshold level to a registry variable:
•
To bind a threshold level to a constant value:
1
Ensure that the order of the bounds in the threshold bounds is valid.
 
* 
IMPORTANT: The Foglight Management Server evaluates threshold bounds in the order that they are listed, starting with the first one. Changing their order affects the output of actions that are associated with that threshold level.
To move a threshold bound up or down, in the Threshold Bounds table, in the Info column, use the Move up this bound () or Move down this bound () buttons as required.
2
Complete one of the following steps:
•
Existing thresholds. Click Save.
or
•
New thresholds. Click Add.
Observe the Manage Thresholds dashboard.
The newly-added threshold appears in the list.

Manage Registry Variables and Check Registry Value

Explore the Manage Registry Variables dashboard

This dashboard is a starting point for any work made to the Foglight registry. It displays a list of all registry variables that exist in your environment, including the variables that come with the Management Server and any installed cartridges. It also provides an interface for creating and managing registry variables.

By default, the following columns are displayed:

•
Variable Name: The variable name.
•
Type: Shows the data type of the registry variable. Possible values include Double, Integer, Long, String, Boolean, Timestamp, and Password. For more information about these data types, see Step 3 in Getting started: create registry variables.
•
Cartridge Name: The name of the cartridge in which the registry variable is defined, if applicable. This column is blank for any registry variables that you create using this dashboard.
•
Global Default: The global default value assigned to the variable. If the global default points to another registry variable, it starts with the prefix Ref:, followed by the referenced registry variable name.
•
Scoped Default (TopologyObject): The value assigned to the variable when the variable is scoped to a particular type. To scope on a topology type, click Scope Filter and choose from the available types.
•
Scheduled: Indicates if a performance calendar is defined for the variable. For more information about performance calendars, see Using performance calendars in registry variable definitions.
•
Active Schedule: If performance calendars are defined, this column indicates the name of the current schedule, if applicable.

In addition to these columns, the following columns can also be displayed by clicking and selecting them from the Show Columns dwell that appears.

•
Cartridge Version: The cartridge version in which the registry variable is defined.
•
Last Modified: The date and time at which the registry variable was last modified.
The Add button starts the New Registry Variable Wizard flow that allows you to quickly add a variable to the existing collection.

For more information about the New Registry Variable Wizard, see Getting started: create registry variables.

Figure 12. The left-most column in the list contains check boxes that allow you to select one or more variables, and delete your selections.

Figure 13. Clicking the variable name displays a menu with a set of actions that are accessible from this column.

For more information about these flows, see View and edit registry variable settings and Copy or delete registry variables.

Copy or delete registry variables

Copying a registry variable is useful in situations when you need to quickly create a modified version of an existing variable. Instead of redefining the scope and performance calendars, simply copy a similar registry variable and edit its definitions.

If you have any registry variables that are no longer referenced in rule conditions, you can delete them from the list. When a registry variable is deleted, all references to that variable in rule conditions and expressions become invalid. This may cause the rule to fail to evaluate. If this occurs, you must manually modify the rule condition or expression. For details, see Writing conditional expressions for time-, data-, or schedule-driven rules and Write a conditional expression for an event-driven rule.

To copy a registry variable:
1
On the navigation panel, under Dashboards, click Administration > Rules & Notifications > Manage Registry Variables.
2
On the Manage Registry Variables dashboard, in the row containing the variable that you want to copy, click the variable name.
3
In the menu that opens, click Copy.
The Copy dialog box opens, prompting you to specify the name of the destination variable.
4
Type the name of the variable and click OK.
 
* 
IMPORTANT: You must use a unique name.
The dialog box closes and the Edit Registry Variable view appears in the display area.

From here, you can edit the newly copied registry variable to better suit your needs. For example, you can have its value change over time, or scope it to topology types or object instances. For further information, see Using performance calendars in registry variable definitions and Scoping registry variables to topology types or object instances.

To delete a registry variable:
1
On the navigation panel, under Dashboards, click Administration > Rules & Notifications > Manage Registry Variables.
2
On the Manage Registry Variables dashboard, select the check box in the row containing the variable that you want to delete.
3
Click Delete.
4
In the Registry Variable Confirmation dialog box, click Delete.
The Registry Variable Confirmation dialog box closes.
5
Observe the Manage Registry Variables dashboard.
The newly deleted variable no longer appears in the list.
View and edit registry variable settings

The Manage Registry Variables dashboard shows all of the registry variables that exist in your monitoring environment. This includes the variables that come with the Foglight Management Server, any installed cartridges, and any registry variables that you create.

To view or edit variable settings:
1
On the navigation panel, under Dashboards, click Administration > Rules & Notifications > Manage Registry Variables.
2
On the Manage Registry Variables dashboard, in the row containing the variable whose definitions you want to view or edit, click the variable name.
The Edit Registry Variable view appears in the display area.
3
Observe the variable definitions.
•
Name: The name of the registry variable.
•
Variable Type ClassName: The data type of the registry variable.
•
Description: A brief description of the registry variable.
•
Cartridge Name: If the registry variable is defined and included in a cartridge, this field contains the cartridge name in which the registry variable is defined. If you created this variable, this is indicated by the System Value setting that appears in this field.
•
Cartridge Version: If the registry variable is defined and included in a cartridge, this field contains the cartridge version in which the variable is defined. If you created this variable, this field is blank.
•
Global Default: The global default value. If the global default points to another registry variable, it starts with the prefix Ref:, followed by the referenced registry variable name.
A registry variable can have multiple values, each associated with a performance calendar or topology types and their instances, along with the default value you see here.
•
Performance Calendars List: Shows a list of values that are associated with specific schedules. Having one or more entries in this list causes the registry value to change over time.
•
Registry Values: Shows a list of values scoped to specific topology types and their instances (if applicable). This causes the registry value to change in rules and derived metrics.

From here, you can edit the registry variable to better suit your needs. For example, you can have its value change over time, or scope it to topology types or object instances. For further information, see Using performance calendars in registry variable definitions and Scoping registry variables to topology types or object instances.

Getting started: create registry variables

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.

Foglight registry variables can be used in rule conditions, expressions, and actions. 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.

The New Registry Variable Wizard takes you to the process of creating registry variables and setting its basic properties, such as the name, data type, and initial value.

The values that you assign to a variable in the wizard must be consistent with the data type that you specify at variable creation time. For example, if you selected the data type Integer, you need to provide a valid integer number when specifying the value.

To create a registry variable:
1
On the navigation panel, under Dashboards, click Administration > Rules & Notifications > Manage Registry Variables.
2
On the Manage Registry Variables dashboard, in the row containing the variable whose definitions you want to view or edit, click Add.
The New Registry Variable Wizard dialog box opens.
3
Specify the data type for the variable.
a
Select one of the following values.
 
* 
IMPORTANT: The registry variable type cannot be changed once the registry variable has been added.
 
Table 40. Registry value types and their descriptions, with examples.
Registry Value Type
Description
Example
Boolean

A boolean value: true or false.

true

Double

A decimal value between 2-1074 and
(2-2-52) * 21023. For example, valid values include 34.1234, 35e3 (meaning 35,000.0) or 1.2E-2 (meaning 0.012).

95.0

Integer

An integer value between -231 and 231 -1. For example, valid values include 235 and -10000.

6825

Long

An integer value that is too large to fit the Integer data type. It can be in the range between -263 and 263- 1.

1099511627776

Password

A password value. Prior to storing the value of the Password data type in the registry, Foglight encrypts it and saves the encrypted value in the database. This is useful in cases where you need to secure password values when passing it to command or remote command actions.

For example, you create a registry variable of the Password type, MyPassword, and set its value to demo123. Foglight encrypts the registry value, then stores it encrypted in the database (for example, 43-119-184-240-170-150-124-218-30-112-216-76-197-233-188-206). In a function call registry("MyPassword"), Foglight retrieves the registry value from the database in its encrypted form, which secures the password value.

demo123

String

A text string.

This message was generated by Foglight.

Timestamp

Contains a date and time. For example, valid values include 06/12/06, 2006-06-21 15:30:21.0, June 7, 2006 3:08:21 PM.

Invalid date or time formats cannot be saved to the database and any attempts to save them results in an error. If the time is not provided, or the values are invalid, Foglight treats the time as midnight.

Prior to saving the value of a variable that uses this data type, Foglight converts it to the following format and stores it in the database:

yyyy-mm-dd hh:mm:ss.ds

2008-08-10 23:15:16.0

b
Click Next. The New Registry Variable Wizard dialog box refreshes.
4
Specify the name and description of the variable using the following boxes.
•
Name: The name of the variable. This is a required value. The registry variable name cannot be longer than 255 characters and must be unique. In addition, the name cannot be changed once the registry variable has been added. This is because registry variables are referred to by their names in rule conditions and expressions and changing them would invalidate these references. However, you can copy a registry variable and give it a different name.
•
Description: Comments about the variable or its usage. This value is optional.
5
Indicate if you want to specify the Global Default value, or proceed without specifying one.
 
* 
TIP: You can edit the Global Default value at a later time.
•
To specify the Global Default value, click Next. The New Registry Variable Wizard dialog box refreshes.
•
To create the variable without specifying its Global Default value, click Finish.
The New Registry Variable Wizard dialog box closes.
The Edit Registry Variable view appears in the display area.
 
* 
TIP: Because you did not specify the Global Default, this value appears unset. You can change it by clicking Change.
From here, you can proceed to Step 7.
6
Specify the global default value, and click Finish.
•
To specify a new, static value as the global default, select Static Value, and then enter the desired value.
This value must be compatible with the variable’s data type that you set at variable creation. For example, if the data type is Double, enter a decimal value in the box.
 
* 
TIP: Failing to set this value causes a validation error. Null is not an acceptable value for the Global Default value in any case. If you do not want to set a value at this time, click Previous and then Finish without setting a global default.
•
To specify another registry variable as the global default, select Registry Reference, and then select the desired registry variable from the list that appears below.
Select a registry variable from the registry reference list.
The New Registry Variable Wizard dialog box closes.
The Edit Registry Variable view appears in the display area.
7
Observe the variable definitions.
•
Name: The name of the registry variable you specified in Step 4.
•
Variable Type ClassName: The data type of the registry variable you specified in Step 3.
•
Description: The description of the registry variable you specified in Step 4.
•
Global Default: The global default value you specified in Step 6. If the global default points to another registry variable, it starts with the prefix Ref:, followed by the referenced registry variable name.
A registry variable can have multiple values, each associated with a performance calendar or topology types and their instances, along with the default value you see here.
•
Performance Calendars List: Shows a list of values that are associated with specific schedules. Performance calendars are always associated with the global default. If the global default is not set, performance calendars cannot be added. When you first create a registry variable, this list is empty by default. Having one or more entries in this list causes the registry value to change over time.
•
Registry Values: Shows a list of values scoped to specific topology types and their instances (if applicable). When you first create a registry variable, this list is empty by default.Having multiple scoped values causes the registry value to change in rules and derived metrics.

From here, you can edit the newly created registry variable to better suit your needs. For example, you can have its value change over time, or scope it to topology types or object instances. For further information, see Using performance calendars in registry variable definitions and Scoping registry variables to topology types or object instances.

Using performance calendars in registry variable definitions

If you want the default value to change over time, add one or more schedules to the performance calendar and specify the value for each schedule.

For example, there is a simple rule that applies to the servlets in your application; an alarm fires if the request response time for a servlet exceeds a value set by the ResponseTimeTooLong registry variable that is scoped to the topology type J2EEServlet and with the default scoped value of eight seconds. However, you know that at certain times of day response times for servlet instances are expected to exceed this threshold. At these times, the acceptable response time can be as long as 15 seconds. To prevent alarms from generating as a result of false positives, leave the variable’s scoped value of eight seconds, and create a schedule that recurs daily at the times when it is acceptable for response times for the servlet instances to exceed eight seconds, and specify the alternative threshold of 15 seconds by associating this value with the schedule.

Foglight evaluates the schedules in the order they are listed in the performance calendar, starting with the first one. Changing their order affects the behavior of the actions that are associated with the variable whose value is set by the schedule-based entries in the performance calendar.

For example, if there are two schedule entries in the performance calendar that overlap in time but have two different values, the first entry listed takes precedence, causing one or more actions that are associated with that variable to make use of that entry for the duration of the schedule.

The Performance Calendar Wizard, accessible from the Performance Calendars List, allows you to associate a registry value with a schedule.

To associate a performance calendar with a registry variable:
1
In the Edit Registry Variable view, in the Performance Calendars List, click Add.
The Performance Calendar Wizard dialog box opens, showing a list of all schedules that exist in your environment.
The list shows the schedules that exist in your Foglight installation and their descriptions. This includes default schedules packaged with Foglight and any schedules that you create.
2
Select a schedule that you want to add to the performance calendar.
a
Review the list of schedules.
b
If you do not find a schedule that meets your needs, you can create a new one.
 
* 
IMPORTANT: Choosing to create or edit the existing schedules causes you to exit the wizard.
To create a new schedule, click New Schedule and follow the flow in the Simple New Schedule Wizard that appears. For more information, see Create a new schedule. When done, the Simple New Schedule Wizard closes and newly created schedule appears selected in the Performance Calendar Wizard.
c
Select the schedule that you want to assign to the topology blackout and click Next.
The Performance Calendar Wizard dialog box refreshes.
3
Specify the registry variable value that will be assigned to the variable during the newly selected schedule, and click Finish.
•
To specify a new, static value, select Static Value, and then enter the desired value.
This value must be compatible with the variable’s data type. For example, if the data type is Double, enter a decimal value in the box.
•
To reference another registry variable, select Registry Reference, and then select the desired registry variable from the list that appears below.
Select a registry variable from the registry reference list.
The Performance Calendar Wizard dialog box closes and the Performance Calendar List refreshes, showing the newly created calendar entry.
4
If required, add more schedules to the list and ensure that their order is valid.
 
* 
IMPORTANT: The Management Server evaluates schedule-based values in the order that they are listed, starting with the first one. Changing their order affects the output of actions that are associated with the value that is associated with their schedule entries.
To change the order of schedules, use the Move Up or Move Down columns.

From here, you can proceed to Scoping registry variables to topology types or object instances.

Scoping registry variables to topology types or object instances

A Foglight 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.

The way you define registry variables can help you to reduce the number of rules that need to be created and managed. For example, instead of creating multiple rules that follow the same logic to monitor different data types or object, you can create a single rule and reference a registry variable scoped to those entities.

To scope the registry value to a topology type or object:
1
In the Edit Registry Variable view, in the Registry Values view, click Add.
The Registry Value Wizard dialog box opens, showing a list of all schedules that exist in your environment.
2
In the Registry Value Wizard dialog box, select a type from the list and click Next.
The Registry Value Wizard dialog box refreshes.
The list contains instances of the selected topology type. For each object instance in the list, the Name and Domain Root columns indicate the instance name and its domain root.
 
* 
TIP: Use the Customizer to display two additional columns that are hidden by default: Long Name and Monitoring Agent.
Long Name consists of the object name followed by its type name. For example:
Broken (AgentHealthState).
Monitoring Agent contains the name of the monitoring agent. This information is important if you have monitoring agents whose definitions include objects of the same type and name, like the legacy Cartridge for Operating Systems agents.
For more information about the Customizer, see the Foglight User Help.
The Customizer allows you to select columns to display in a table.
3
Optional — narrow down your scope to a particular object. By default, All Objects is selected, meaning that the registry value is scoped to all instances of the selected type.
Select an object from the list that appears, and click Next.
The Registry Value Wizard dialog box refreshes.
4
Specify the value that you want to assigned to the variable, and click Finish.
•
To specify a new, static value, select Static Value, and then enter the desired value.
This value must be compatible with the variable’s data type. For example, if the data type is Double, enter a decimal value in the box.
•
To reference another registry variable, select Registry Reference, and then select the desired registry variable from the list that appears below.
Select a registry variable from the registry reference list.
The Registry Value Wizard dialog box closes and the Registry Values refreshes, showing the newly created registry value entry.

From here, to edit a registry value and associate it with performance calendars, click the registry value in the list.

View registry variable values

A registry variable can have a global value that is available to all topology types and objects. It can also have multiple additional values associated with specific topology types or objects, or calendar dates. To find out what is the value of a registry variable for a particular topology type or object, and, if applicable, during a specific time period, use the Check Registry Value dashboard.

To view the values of a registry variable:
1
On the navigation panel, under Dashboards, choose Administration > Rules & Notifications > Check Registry Value.
The Check Registry Value dashboard appears in the display area, showing the View Registry Variable view.
2
The dashboard shows the following information:
•
Variable Name: The name of the registry variable whose value you want to view.
•
Topology Type Name: The topology type with which the registry value is associated.
•
Topology Object: The object instance of the specified topology type with which the registry value is associated.
•
Registry Value: The value to which the variable is set during a specified date and time range. If there are multiple time ranges during which the registry value changes, the table shows the registry value for each range.
3
Specify the name of the variable whose values you want to view.
For example, look at the SYSADMIN variable that is scoped to two topology object instances and two different performance calendars.
 
* 
IMPORTANT: By default, the SYSADMIN variable has no scoped values. They are created for the purpose of this exercise.
a
In the View Registry Variable view, click Please select variable.
The Registry Variable list appears, showing the registry variables that exist in your Foglight environment. This includes any registry variables that came with the installation of the Foglight Management server, any installed cartridges, or any variables you previously created.
 
* 
NOTE: The list does not include the registry variables that contain password values.
b
In the Registry Variable list, scroll down until you find a registry variable, and select that entry. For example, to select the SYSADMIN variable, select SYSADMIN.
4
Select the topology type to which the selected registry variable is scoped.
a
In the View Registry Variable view, click Please select topology type.
The Topology Type list appears, showing all available topology types.
b
In the Topology Type list, select a type.
5
Select the object instance of the selected topology type to which the selected registry variable is scoped.
a
In the View Registry Variable view, click All Objects.
b
In the Topology Object list, select an object instance.
6
Specify the date and time range for which you want to see the registry values using the Zonar.
The Zonar is located in the upper right corner of the browser interface.
When you change the zonar, the Registry Value table refreshes, showing different registry values.
Values may change depending on the date and time selected.
For more information about the Zonar, see the Foglight User Guide.
7
Optional — Reduce the number of columns that appear in the Registry Value table by clicking and selecting the columns that yo want to appear or hide.
For example, to display only the time at which the value was set and the value, ensure that Period Begin Time and Registry Value check boxes are selected, and clear Period End Time.
Click Apply.
8
Optional — Print the list of audit logs to a file.
In the Registry Value table, click and select one of the following options
•
Export as CSV, to export the table contents to a Comma Separated Values (CSV) file.
•
Export as PDF, to export the table contents to a PDF file.
•
Export as Excel, to export the table contents to an Excel file.
•
Export as XML, to export the table contents to an XML file.
 
* 
IMPORTANT: If you had previously chosen to show or hide one or more columns in the Registry Value table, the selected layout is reflected in the exported file. For example, if you display only the time at which the value was set and the registry value, only those columns appear in the export file.
9
Change the object instance and the date and time range.
The Registry Value table refreshes, showing the values scoped to the selected object instance and date and time range.
Running the Registry Variable Report

Some Foglight dashboards have reports associated with them. This allows you to run a report based on the current dashboard. You can generate the report using the Reports menu in the top-right corner.

The Manage Registry Variables dashboard is associated with the Registry Variable Report. Run this report by choosing Registry Variable Report from the Reports menu, and specifying the input parameters in the report wizard.

Figure 14. The Manage Registry Variables dashboard, with the Reports menu selected.

The report wizard provides more information about the Registry Variable Report and instructions on how to set the input values. For more information about reports in Foglight, see the Foglight User Help.

関連ドキュメント

The document was helpful.

評価を選択

I easily found the information I needed.

評価を選択