Create event rules 编辑

You can configure rules to monitor specific events. Rules make it easier to monitor a large number of events generated across your infrastructure.

You can filter a set of events by configuring rules with specific conditions and assigning actions to the rules. When the events generated meet the filter criteria in the rule, the action associated with the rule is run. The conditions for which you can create filters are: severity, Citrix Application Delivery Controller (Citrix ADC) instances, category, failure objects, configuration commands, and messages.

You can assign the following actions to the events:

  • Send e-mail Action: Send an email for the events that match the filter criteria.

  • Send Trap Action: Send or forward SNMP traps to an external trap destination

  • Run Command Action: Run a command when an incoming event meets the configured rule.

  • Execute Job Action: Run a job is for events that match the filter criteria that you’ve specified.

  • Suppress Action: Suppresses drop an event for a specific time period.

  • Send Slack Notifications: Send notifications on the configured Slack channel for the events that match the filter criteria.

  • Send PagerDuty Notifications: Send event notifications based on the PagerDuty configurations for the events that match the filter criteria.

  • Send ServiceNow Notifications: Auto-generate ServiceNow incidents for an event that match the filter criteria.

For more information, see Add event rule actions

You can also have notifications resent at a specified interval until an event is cleared. And you can customize the email with a specific subject line, user message, and attachment.

Monitor events with rules

For example, as an administrator you might want to monitor “high CPU usage” events for specific Citrix ADC instances if those events can lead to an outage of your Citrix ADC instances. You can:

  • Create a rule to monitor the instances and specify an action that sends you an email notification when an event in the “high CPU usage” category occurs.

  • Schedule the rule to run at a specific time, such as between 11 AM to 11 PM, so that you are not notified every time there is an event generated.

Configuring an event rule involves the following tasks:

  1. Define the rule

  2. Choose the severity of the event that the rule detects

  3. Specify the category of the event

  4. Specify Citrix ADC instances to which the rule applies

  5. Select failure objects

  6. Specify advanced filters

  7. Specify actions to be taken when the rule detects an event

Step 1 - Define an event rule

Navigate to Infrastructure > Events > Rules, and click Add. If you want to enable your rule, select the Enable Rule check box.

You can set the Event Age option to specify the time interval (in seconds) after which Citrix ADM refreshes an event rule.

Note:

The minimum value for the event age is 60 seconds. If you keep the Event Age field blank, the event rule is applied immediately after the event is occurred.

Based on the example above, you may want to be notified by email every time your Citrix ADC instance has a “high CPU usage” event for 60 seconds or longer. You can set the event age as 60 seconds, so that every time your Citrix ADC instance has a “high CPU usage” event for 60 seconds or more, you receive an email notification with details of the event.

Create event rule

You can also filter event rules by Instance Family to track the Citrix ADC instance from which Citrix ADM receives an event.

If you want to include a regular expression other than asterisk (*) pattern matching, select Enable Advanced Filter with Regex Matching.

Step 2 - Choose the severity of the event

You can create event rules that use the default severity settings. Severity specifies the current severity of the events you which you want to add the event rule.

You can define the following levels of severity: Critical, Major, Minor, Warning, Clear, and Information.

Define severity levels

Note

You can configure severity for both generic and Advanced-specific events. To modify event severity for Citrix ADC instances managed on Citrix ADM, navigate to Infrastructure > Events > Event Settings. Choose the Category for which you want to configure event severity and click Configure Severity. Assign a new severity level and click OK.

Step 3 - Specify the event category

You can specify the category or categories of the events generated by your Citrix ADC instances. All categories are created on Citrix ADC instances. These categories are then mapped with Citrix ADM that can be used to define event rules. Select the category you want to consider and move it from the Available table to the Configured table.

In the example above, you will need to choose “cpuUsageHigh” as the event category from the table displayed.

Define event category

Step 4 - Specify Citrix ADC instances

Select the IP addresses of the Citrix ADC instances for which you want to define the event rule. In the Instances section, click Select Instances. In the Select Instances page, choose your instances, and click Select.

Specify instances

Step 5 - Select failure objects

You can either select a failure object from the list provided or add a failure object for which an event has been generated. You can also specify a regular expression to add failure objects. Depending on the specified regular expression, the failure objects are automatically added to the list. Failure objects are entity instances or counters for which an event has been generated.

Important

To list failure objects using regular expression, select Enable Advanced Filter with Regex Matching in Step 1.

The failure object affects the way an event is processed and ensures it reflects the exact problem as notified. With this filter, you can track issues on the failure objects quickly and identify the cause for an issue. For example, if a user has login issues, then the failure object here is the user name or password, such as nsroot.

This list can contain counter names for all threshold‐related events, entity names for all entity‐related events, certificate names for certificate‐related events, and so on.

Object list

Step 6 - Specify advanced filters

You can further filter an event rule by:

  • Configuration Commands - You can specify the complete configuration command, or specify a regular expression to filter events.

    You can further filter the event rule by the command’s authentication status and/ or its execution status. For example, for a NetscalerConfigChange event, type [.]*bind system global policy_name[.]*.

    Advance configuration commands filter

  • Messages - You can specify the complete message description, or specify a regular expression to filter the events.
    For example, for a NetscalerConfigChange event, type [.]*ns_client_ipaddress :10.122.132.142[.]* or ns_client_ipaddress :^([.]*10.122.132.142[.]*).

    Advance message filters

Step 7 - Add event rule actions

You can add event rule actions to assign notification actions for an event. These notifications are sent or performed when an event meets the defined filter criteria that you’ve set above. You can add the following event actions:

  • Send email Action

  • Send Trap Action

  • Run Command Action

  • Run Job Action

  • Suppress Action

  • Send Slack Notifications

  • Send PagerDuty Notifications

  • Send ServiceNow Notifications

To set email Event Rule Action

When you choose the Send email Action event action type, an email is triggered when the events meet the defined filter criteria. You will need to either create an email distribution list by providing mail server or mail profile details or you can select an email distribution list that you’ve previously created.

Due to a high number of virtual servers being configured in Citrix ADM, you might receive a high number of emails every day. The emails have a default subject line that provides information about the severity of the event, the category of the event and the failure object. But the subject line does not carry any information about the name of the virtual server where these events originate from. You now have an option to include some additional information like the name of the affected entity, that is the name of the failure object.

You can also add a customized subject line and a user message, and upload an attachment to your email when an incoming event matches the configured rule.

While sending emails for event notifications, you might want to send a test email to test the configured settings. The “Test” button now allows you to send a test email after configuring an email server, associated distributed lists, and other settings. This feature ensures that settings are working fine.

You can also ensure that all critical events are addressed and no important email notifications are missed, by selecting the Repeat Email Notification until the event is cleared check box to send repeated email notifications for event rules that meet the criteria you’ve selected. For example, if you’ve created an event rule for instances that involve disk failures, and you want to be notified until the issue is resolved, you can opt to receive repeated email notifications about those events.

Set email event rule action

To set Trap Event Rule Action

When you choose the Send Trap Action event action type, SNMP traps are sent or forwarded to an external trap destination. By defining a trap distribution list (or a trap destination and trap profile details), trap messages are sent to specific trap listeners when events meet the defined filter criteria.

To set the Run Command Action

When you choose the Run Command Action event action, you can create a command or a script that can be run on Citrix ADM for events matching a particular filter criterion.

You can also set the following parameters for the Run Command Action script:

  
ParameterDescription
$sourceThis parameter corresponds to the source IP address of the received event.
$categoryThis parameter corresponds to the type of traps defined under category of the filter
$entityThis parameter corresponds to the entity instances or counters for which an event has been generated. It can include the counter names for all threshold-related events, entity names for all entity-related events, and certificate names for all certificate-related events.
$severityThis parameter corresponds to the severity of the event.
$failureobjThe failure object affects the way an event is processed and ensures that the failure object reflects the exact problem as notified. This can be used to track down problems quickly and to identify the reason for failure, instead of simply reporting raw events.

Note

During command execution, these parameters are replaced with actual values.

For example, consider that you want to set a run command action when a load balancing virtual server status is Down. As an administrator, you might want to consider providing a quick workaround by adding another virtual server. In Citrix ADM, you can:

  • Write a script (.sh) file.

    The following is a sample script (.sh) file:

     #!/bin/sh
     source=$1
     failureobj=$2
     payload='{"params":{"warning":"YES"},"lbvserver":{"name":"'$failureobj'","servicetype":"HTTP","ipv46":"x.x.x.x","port":"80","td":"","m":"IP","state":"ENABLED","rhistate":"PASSIVE","appflowlog":"ENABLED","
     bypassaaaa":"NO","retainconnectionsoncluster":"NO","comment":""}}'
     url="http://$source/nitro/v1/config/lbvserver"
     curl --insecure -basic -u nsroot:nsroot -H "Content-type: application/json" -X POST -d $payload $url
    
     <!--NeedCopy-->
    

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。
列表为空,暂无数据

词条统计

浏览:21 次

字数:16302

最后编辑:7 年前

编辑次数:0 次

    我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
    原文