Chatta subito con l'assistenza
Chat con il supporto

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

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:

1
On the navigation panel, under Dashboards, choose Administration > Data > Manage Derived Metrics.
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.
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.
c
Click Save.

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.

1
On the navigation panel, under Dashboards, choose Administration > Data > Manage Derived Metrics.
3
In the Copy Derivation dialog box, click OK.
In the Create Derived Metric view, in the Derived Metric Name box, type the name of the derived metric.
1
On the navigation panel, under Dashboards, choose Administration > Data > Manage Derived Metrics.
3
Click the Delete Selected button at the bottom.
4
In the Delete Derivation dialog box, click OK.
The Delete Derivation dialog box closes.

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:

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.

For more information about the Diagnostic Details view that appears, see 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.

This composite view contains the following embedded views:

Table 32. Top-Level View

Shows the derived metric definitions.

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.

Shows the derived metric calculations.

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.

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.

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

Shows the property values associated with the bound object instance.

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.

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

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

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.

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.

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:

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).
For example, if you have a derivation freeMemory for the types OS and JVM, create two separate derivations to avoid coupling the definitions.

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.

On the navigation panel, under Dashboards, choose Administration > Data > Manage Derived Metrics.
On the navigation panel, under Dashboards, choose Administration > Data > Create 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.

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.

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

From here, you can proceed to 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.
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.
1
In the Expression area, under Trigger Type, select the Schedule Driven option.
Click Schedule and select a schedule from the list that appears.
Click Trigger Timing and select one of the following options from the list that appears: Enter and Exit, Enter only, or Exit only.
1
In the Expression area, under Trigger Type, select the Time Driven option.
1
In the Expression area, under Trigger Type, select the Data Driven option.

From here, you can proceed to 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.

1
In the area immediately below the Derived Metric Calculations list, click Value Type and select Metric from the list that appears.
Use one or both of the Unit boxes on the left of Unit Type as required.
For example, percent or count / second.
1
In the area immediately below the Derived Metric Calculations list, ensure that both of the Unit boxes are blank.
Click Value Type on the right and select an observation from the list that appears.
Click Add (when creating a new derived metric) or Save (when editing an existing metric).

IntelliProfile

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.

The dashboard contains two views: General and Thresholds.

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.

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.

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.

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.
4
Click Save Changes. The Save IntelliProfile dialog box opens.
5
Click Ok to close it.

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.

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.

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:

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.

IntelliProfile_Percentile1

1

IntelliProfile_Percentile2

3

IntelliProfile_Percentile3

5

IntelliProfile_Percentile4

95

IntelliProfile_Percentile5

97

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.

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.
3
Click Save Changes. The Save IntelliProfile dialog box opens.
4
Click OK to close it.

Manage Thresholds

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:

1
On the navigation panel, under Dashboards, click Administration > Data > Manage Thresholds.
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.
b
To edit permissions, ensure that Edit is selected and use the Read, Write, and Control check boxes as required.
c
Click Save.

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.

1
On the navigation panel, under Dashboards, choose Administration > Data > Manage Thresholds.
3
Click Delete Selected.
4
In the Delete Threshold dialog box, click OK.
The Delete Threshold dialog box closes.

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.

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.
To edit the threshold bounds, use the Threshold Bounds table. For complete instructions, see Add bounds to threshold levels.

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.

On the navigation panel, under Dashboards, choose Administration > Data > Manage Thresholds.
On the navigation panel, under Dashboards, choose Administration > Data > Create Threshold.
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.
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.
Click Next.

From here, you can proceed to 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.

OK

Running Unexpectedly

Broken

Agent Info Not Present

Unknown

Stopped

Starting

Stopping

Running

Collecting data

Running but not collecting data

Fire

Clear

Acknowledge

UserDefined Data

Undefined

Normal

Fire

Warning

Critical

Fatal

Stopped

Stopping

Starting

Started

Failed

Destroyed

Created

Unregistered

Registered

Active

Inactive

Create

Close

Acknowledge

Modify

Delete

Normal

Critical

Fatal

Warning

smalestValue

Locale

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

Another metric

A registry variable

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

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.

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.

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.
In the Number of Standard Deviation box, type the standard deviation.
7
Click Add.
To bind a threshold level to a registry variable:
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.
6
Click Add.
The newly-created registry variable threshold bound appears in the Threshold Bounds table.
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.
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.
6
Click Add.
To bind a threshold level to a constant value:
Click Level and select a severity level from the list that appears.
2
Select the Constant Threshold Bound option.
In the Value box, type that value. This can be a positive or a negative value, depending on the metric range.
6
Click Add.
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.
New thresholds. Click Add.

Manage Registry Variables and Check Registry Value

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.

For more information about these flows, see View and edit registry variable settings and 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.

1
On the navigation panel, under Dashboards, click Administration > Rules & Notifications > Manage Registry Variables.
The Copy dialog box opens, prompting you to specify the name of the destination variable.
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.

1
On the navigation panel, under Dashboards, click Administration > Rules & Notifications > Manage Registry Variables.
3
Click Delete.
4
In the Registry Variable Confirmation dialog box, click Delete.
The Registry Variable Confirmation dialog box closes.

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.

1
On the navigation panel, under Dashboards, click Administration > Rules & Notifications > Manage Registry Variables.
The Edit Registry Variable view appears in the display area.
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.
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.

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.

1
On the navigation panel, under Dashboards, click Administration > Rules & Notifications > Manage Registry Variables.
The New Registry Variable Wizard dialog box opens.

A boolean value: true or false.

true

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

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

6825

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

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

A text string.

This message was generated by Foglight.

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.
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.
To specify the Global Default value, click Next. The New Registry Variable Wizard dialog box refreshes.
The New Registry Variable Wizard dialog box closes.
The Edit Registry Variable view appears in the display area.
To specify a new, static value as the global default, select Static Value, and then enter the desired value.
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.
The New Registry Variable Wizard dialog box closes.
The Edit Registry Variable view appears in the display area.
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.
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.

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.

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.
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.
The Performance Calendar Wizard dialog box refreshes.
To specify a new, static value, select Static Value, and then enter the desired value.
To reference another registry variable, select Registry Reference, and then select the desired registry variable from the list that appears below.
The Performance Calendar Wizard dialog box closes and the Performance Calendar List refreshes, showing the newly created calendar entry.
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.

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.

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.
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.
The Registry Value Wizard dialog box refreshes.
To specify a new, static value, select Static Value, and then enter the desired value.
To reference another registry variable, select Registry Reference, and then select the desired registry variable from the list that appears below.
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.

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.

1
On the navigation panel, under Dashboards, choose Administration > Rules & Notifications > Check Registry Value.
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.
For example, look at the SYSADMIN variable that is scoped to two topology object instances and two different performance calendars.
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.
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.
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.
a
In the View Registry Variable view, click All Objects.
b
In the Topology Object list, select an object instance.
When you change the zonar, the Registry Value table refreshes, showing different registry values.
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.
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.
The Registry Value table refreshes, showing the values scoped to the selected object instance and date and time range.

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.

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.

Related Documents

The document was helpful.

Seleziona valutazione

I easily found the information I needed.

Seleziona valutazione