Managing Policies
Creating Policies
The Managing Policies section describes the properties and variables that can be configured and illustrates how to create policies.
After creating the policies, refer to the Managing added policies section to know how to enable/edit/delete added policies.
Backlog Policy
The Backlog Policies monitor the backlog request count and raise notifications based on them. Multiple backlog policies can be created and applied at different levels like the Event Process level, Component Level, or Port level. The policy applied to an Event Process will indirectly apply to all the components within that event process and will translate automatically to all monitorable ports of the components.
Monitorable ports are the destinations over which backlog depth monitoring is possible.
- Presently, monitoring is possible only in queues. Future versions of the product may extend backlog monitoring support for topics as well.
- All the property values described below appear after creating Backlog policy.
Creating a Backlog Policy
Click the Add button and choose the Type property as "Backlog" to add properties of the backlog policy.
Properties
Property Name | Description |
| Policy ID | User-defined name of the policy, which cannot be altered later. |
| Policy Levels | Monitoring to be done in one of the below levels:
|
| Applications | The event process on which the alert needs to be applied. |
| Service | The service instance name on which the policy is applied if the policy is applied at the Service Level or Port Level. |
| Port name | Select the port, for example input port or output port if the policy is applied at the Port Level. |
| Alerts | Alerts configured in the Alert Manager tab (refer to the Managing SMTP and JMS Alerts section) in the Dashboard. |
| Direction | The direction of reaching the specified depth—ANY, UP, or DOWN. If notification has to be raised when the pending requests are reduced, then DOWN will be specified otherwise UP will be specified. ANY is for both cases. |
| Backlog | Level of Backlog defined. |
| Subject | Short description of the content/subject of the message that is sent along with the alert (Applicable only for SMTP alerts). A subject can be made sensible by using variables as explained in the next section. However, if the subject is left blank, the message gets delivered with the default message. |
| Message Body | The message content to be delivered via mail. The message body can be made sensible by using variables as explained in the next section. However, if the Message Body is left blank, the message gets delivered reflecting parameters and corresponding values as configured above. |
Variables
BackLog Policy has a set of variables that can be used in the Subject and MessageBody. Variables help build a context-sensitive message/alert in contrast to a constant one. Variables are specific to types of policies. If there is a variable defined, that cannot be resolved by a particular kind of policy, it will remain unresolved in the final message. The table below lists the variables specific to backlog Policy.
Variable Name | Description |
{policy_id} | The Policy ID for which this Alert is getting executed. Every time this alert is executed, this variable will get resolved. |
{depth} | The count of pending requests for which the policy was configured. |
{port_name} | The Port Name at which the requests-pending count reached the {depth} level in Direction {direction}. The port name has the following format: EVENT_PROCESS_ID_SERVICE_INSTANCE_NAME_PORT_NAME |
{Service_instance_name} | The name of the service instance for which the requests-pending count reaches the {depth} level in Direction {direction}. The Service Instance has the following format: EVENT_PROCESS_ID__SERVICE_INSTANCE_NAME |
{application_guid} | The event process within which the pending requests for {service_instance_name} / {port_name} reached the {depth} level in Direction {direction}. |
{direction} | The direction in which the backlog depth was reached. |
{event_time} | The date and time at which the backlog depth reached the specified {depth} |
{alert_id} | This Alert ID can optionally be inserted in the message body and subject with this variable. |
Enabling backlog monitoring policy affects the performance on the concerned peer server (the peer on which destinations exist over which backlog monitoring policies are applied). As such, performance has to be empirically observed after turning on Backlog Monitoring.
Low Disk Policy
Low Disk Policies monitor the space usage of the system in which a specified server is running and raise alerts when the system space reaches the specified threshold. The alerts are raised when the space usage crosses the threshold in any direction.
Creating a Low Disk Policy
Click the Add button and choose the Type property as "Low Disk" to add properties of the low disk policy.
Properties
Property Name | Description |
| Policy ID | User-defined name of the policy, which cannot be altered later. |
| Server | Select the server on which the policy needs to be running; select from the list. |
| Threshold | The maximum value of memory usage to be used. Specify a value in the range 0.00 to 1.00. |
| Time interval | Time interval (in seconds) between two successive same-direction alerts. |
| Subject | Short description of the content/subject of the message that is sent along with the alert (Applicable only for SMTP alerts). A subject can be made sensible by using variables as explained in the next section. However, if the subject is left blank, the message gets delivered with the default message "Server Running low on disk space". |
| Message Body | The message content to be delivered via mail. The message body can be made sensible by using variables as explained in the next section. However, if the Message Body is left blank, the message gets delivered reflecting parameters and corresponding values as configured above. |
Variables
Low Disk policy type has a set of variables that can be used in the Subject and MessageBody. Variables help build a context-sensitive message/alert in contrast to a constant one. Variables are specific to types of policies. If there is a variable defined that cannot be resolved by a particular kind of policy, it will remain unresolved in the final message. The table below lists the variables specific to the Server Low Disk policy.
Variable Name | Description |
{policy_id} | The Policy ID for which this Alert is getting executed. Every time this alert is executed, this variable will get resolved. |
{max_space} | Maximum space available. |
{threshold} | Decimal value |
| {time_interval} | The minimum time interval between two successive same-direction alerts. |
| {max_allowed_space} | The Maximum space allowed for the server. |
| {consumed_space} | The space used by the server. |
{server_name} | The name of the server. |
{event_time} | The date and time at which the threshold has been reached. Specify a value in the range 0.00 to 1.00. |
{alert_id} | This Alert ID can optionally be inserted into the message body and subject with this variable. |
Server Low Memory Policy
Low Memory Policies monitor the memory usage of servers and raise alerts when the specified threshold is reached. The alerts are raised when memory usage crosses the threshold in any direction.
Creating a Server Low Memory Policy
Click the Add button and choose the Type property as "Server Low Memory" to add properties of the server low memory policy.
Properties
Property Name | Description |
| Policy ID | User-defined name of the policy, which cannot be altered later. |
| Server | Select the server on which the policy needs to be running; select from the list. |
| Alerts | Alerts configured in the Alert Manager tab (refer to the Managing SMTP and JMS Alerts section) in the Dashboard. |
| Threshold | The maximum value of memory usage to be used. Specify a value in the range 0.00 to 1.00. |
| Time interval | Time interval (in seconds) between two successive same-direction alerts. |
| Subject | Short description of the content/subject of the message that is sent along with the alert (Applicable only for SMTP alerts). A subject can be made sensible by using variables as explained in the next section. However, if the subject is left blank, the message gets delivered with the default message "Server Running low on memory". |
| Message Body | The message content to be delivered via mail. The message body can be made sensible by using variables as explained in the next section. However, if the Message Body is left blank, the message gets delivered reflecting parameters and corresponding values as configured above. |
Variables
Low Memory Policy Type has a set of variables that can be used in the Subject and MessageBody. Variables help build a context-sensitive message/alert in contrast to a constant one. Variables are specific to types of policies. If there is a variable defined that cannot be resolved by a particular kind of policy, it will remain unresolved in the final message. The table below lists the variables specific to the Server Low memory Policy.
Variable Name | Description |
{policy_id} | The Policy ID for which this Alert is getting executed. Every time this alert is executed, this variable will get resolved. |
{max_memory} | Maximum memory available. |
{threshold} | Decimal value |
{server_name} | The name of the server. |
{time_interval} | The minimum time interval between two successive same-direction alerts. |
{max_allowed_memory} | The Maximum memory allowed for the server.(max_memory*threshold) |
{consumed_memory} | The memory used by the server. |
{event_time} | The date and time at which the threshold has been reached. |
{alert_id} | This Alert ID can optionally be inserted into the message body and subject with this variable. |
Component Low Memory Policy
Low Memory Policies monitor the memory usage of servers and components and raise alerts when the specified threshold is reached. The alerts are raised when memory usage crosses the threshold in any direction.
Creating a Component Low Memory Policy
Click the Add button and choose the Type property as "Component Low Memory" to add properties of the component low memory policy.
Figure: Policy Manager screen with Low MemoryPolicy added
Properties
Property Name | Description |
| Policy ID | User-defined name of the policy, which cannot be altered later. |
| Applications | The event process on which the alert needs to be applied. |
| Service | The service instance name on which the policy is applied if the policy is applied at SERVICE_LEVEL or PORT_LEVEL. |
| Alerts | Alerts configured in the Alert Manager tab (refer to the Managing SMTP and JMS Alerts section) in the Dashboard. |
| Threshold | The maximum value of memory usage to be used. Specify a value in the range 0.00 to 1.00. |
| Time interval | Time interval (in seconds) between two successive same-direction alerts. |
| Subject | Short description of the content/subject of the message that is sent along with the alert (Applicable only for SMTP alerts). A subject can be made sensible by using variables as explained in the next section. However, if the subject is left blank, the message gets delivered with the default message "Server Running low on memory". |
| Message Body | The message content to be delivered via mail. The message body can be made sensible by using variables as explained in the next section. However, if the Message Body is left blank, the message gets delivered reflecting parameters and corresponding values as configured above. |
Variables
Low Disk policy type has a set of variables that can be used in the Subject and MessageBody. Variables help build a context-sensitive message/alert in contrast to a constant one. Variables are specific to types of policies. If there is a variable defined that cannot be resolved by a particular kind of policy, it will remain unresolved in the final message. The table below lists the variables specific to the server Low Disk policy.
The table below lists the variables specific to Component Low Memory Policy.
Variable Name | Description |
{policy_id} | The Policy ID for which this Alert is getting executed. Every time this alert is executed, this variable will get resolved. |
{max_memory} | Maximum memory available. |
{threshold} | Decimal value |
{application_guid} | The name of the Application which has the component for which the policy is applied. |
{service_instance_name} | The name of the component for which the policy is applied. |
{time_interval} | The minimum time interval between two successive same-direction alerts. |
{max_allowed_memory} | The Maximum memory allowed for the server (max_memory*threshold). |
{consumed_memory} | The memory used by the server. |
{event_time} | The date and time at which the threshold has been reached. |
Managing added Policies
Once policies are added, the Policy Alerts page lists the policies together with the type of each policy.
Activating and Suspending a Policy
To activate a policy, click the Play button under the Actions column and to deactivate the activated policy, click the Stop button. Suspending the policy execution will result in no alerts being generated and the monitoring for backlog events for this policy from different peer servers will be switched off.
The policy details will be fetched and refreshed with every activated action.
Multiple policies can be selected and activated/suspended simultaneously using the Activate/Suspend button.
Figure: Options to activate and suspend policy(ies)
- Clicking the Refresh button reloads the policies from the Policy Repository.
- Clicking the Details icon displays the details of the policy.
Fiorano Esb Classic Web Console
Once policies are added, the Policy Manager panel lists the policies together with the type and the running status of each policy at a given point of time. A policy can be in one of the two states as below:
- ACTIVE: When a policy is successfully applied, it is in an ACTIVE state.
- INACTIVE: When the user has suspended the policy execution, the policy becomes INACTIVE.
A policy could be applied to the system by clicking the Apply Policy button on the top panel. The policy turns to the Active state.
The Active policy can be suspended by clicking the Suspend Policy button. Suspending the policy execution will result in no alerts being generated and the monitoring for backlog events for this policy from different peer servers will be switched off.
The policy details will be fetched and refreshed with every activated action. Multiple policies can be selected and activated/suspended simultaneously.
The policy details displayed in the Dashboard is a paged data grid where the pages can be navigated by using the next and previous tool buttons. The Refresh button reloads the policies from the Policy Repository. Clicking the policyID displays the details of the policy.
Editing a Policy
The Policy attributes can be edited except for the Policy ID and the type of the policy. Once the policy is edited, it will be saved into the repository and will be automatically picked up from the next execution of the alert.
A policy cannot be edited while it is in the activated state. It has to be suspended from execution for editing.
Fiorano Esb Web Console
Click the Details icon of a policy to edit the properties of that policy.
Figure: Option to see the details of a policy
Removing a Policy
A policy cannot be edited while it is in the activated state. It has to be suspended from execution before it can be removed from the system.
Click the Delete icon of a policy to remove that policy.
Multiple policies can be selected and deleted simultaneously using the Delete button.
Figure: Option to see the details of a policy