vania-janet/multiturn-rag-retrieval-data huggingface dataset:
When you define a Slack channel, replace <SLACK_CHANNEL_NAME> with the name of your channel. You must include the symbol with the name of the channel, for example, my_monitoring_alert_channel.



When you configure the alert, complete the following sections:



* [name and description]: You must define a unique name for the alert name by replacing <ALERT_NAME>, and optionally, add a description by replacing <ALERT_DESCRIPTION>.
* [severity]: You must define the severity of the alert by replacing <SEVERITY> with a number. Valid values are 0, 1, 2, 3, 4, 5, 6, and 7.
* [for_atleast_s]: You must define the number of consecutive seconds that the condition is met before the alert is triggered. Replace <FOR_ATLEAST_S> with the number of seconds.
* [condition]: You must define the condition that defines when the alert is triggered. For example, you can set this parameter to ['host.mac', 'proc.name'] to check a CPU alert for every process on every machine.

For more information, see [Multi-Condition Alerts](https://cloud.ibm.com/docs/monitoring?topic=monitoring-alerts).
* [segmentby]: You can define the scope of an alert by configuring the segmentedby section. The default value is ANY.
* [segment_condition]: When the parameter segmentby is specified, set this field to determine when the alert will be triggered. Valid values are ANY and ALL.
* [user_filter]: You can define a filter that indicates when a notification is sent. For example, you could define this entry if you want to receive a notification only if the name of the process meets the condition.
* [notify]: You can define the type of notifications that you want the alert to generate. Set this entry to the notification IDs of the channels that you have defined.
* [enabled]: You can configure the status of the alert when it is created. By default, alerts are enabled and the entry is set to true.
<-- <section "id="section-opt-certificate-alert" "> --> Command options --type: The type of the certificate.--name: The name of the alert policy.--description: The description for the alert policy.--emails: The email addresses for dispatching an alert notification. For example: --emails test1@cn.ibm.com,test2@cn.ibm.com--webhooks: The webhook ID that for dispatching an alert notification. For example: --webhook webhookID1,webhookID2--enabled: Whether or not the alert policy is enabled.-i, --instance: Instance name or ID. If not set, the context instance specified by ibmcloud cis instance-set INSTANCE is used.--output: Specify output format, only JSON is supported.<-- </section "id="section-opt-certificate-alert" "> --><-- <section "id="section-certificate-alert-examples" "> --> Examples Create a certificate alert for instance cis-demo. ibmcloud cis alert-policy certificate-alert-create --type universal --name test1 --emails test1@cn.ibm.com --enabled true -i "cis-demo"
<-- </section "id="section-certificate-alert-examples" "> --><-- </section "id="section-certificate-alert" "> --><-- <section "id="section-create-glb-healthcheck-alert" "> --> ibmcloud cis alert-policy glb-healthcheck-alert-create Create an alert policy for changes in health status for global load balancer, pools, and origins.
Click the + to add the address to the alert. Repeat for all email addresses.
* Click Add webhook and select an available webhook. If no webhooks are present, this option is unavailable.



5. Click Create



By default, alert policies are enabled when created. You can disable alerts that you created by switching the toggle in the Enabled column.





 Creating an advanced security alert policy by using the console 

To create an advanced security alert by using the console, take the following steps:



1. Click Create.
2. Select Advanced security events alert.
3. Enter a name for your alerting policy, and optionally enter a description.
4. Choose an alerting method. You can either select a webhook, or enter an email address to send alerts to, or both. Only one notification is required to complete configuration.



* Enter an email address to which Cloud Internet Services (CIS) sends alerts. Click the + to add the address to the alert. Repeat for all email addresses.
* Click Add webhook and select an available webhook. If no webhooks are present, this option is unavailable.



5. Click Next.
6. Select which domains the alert policy monitors.
7. Select which services the alert policy monitors.
8. Click Create.







 Editing an alert policy by using the console 

To edit an alert policy:



1. Click the overflow menu of the alert in the Alerts section and select Edit.
2. Make the changes that you want to the name and description, add or delete email addresses, and add, remove, or edit webhooks.
3. Click Edit to save your changes.







 Deleting an alert policy by using the console 

To delete an alert policy:



1. Click the overflow menu of the alert in the Alerts section and select Delete.
2. Click Delete in the confirmation message.



You can delete only alerts that you created.







 Configuring alert policies by using the CLI
Integrating with webhooks 

You can send alerts by using webhooks.



 Configuring webhooks 

When you [configure an alert](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-create_alert_ui) you can have that alert sent to a webhook for use in another application.



1. When configuring your alert, click ![Webhook icon](https://cloud.ibm.com/docs-content/v1/content/6f3c07c34058f637b1c86044ca4f9b24214330a7/activity-tracker/images/webhook.png).
2. Select if you want the alert to be sent when the condition exists (Presence) or does not exist (Absence).
3. Indicate the criteria when an alert should be sent. For example, when 100 lines matching in the view are logged in an hour. A graph will help you determine the number of log lines matching your specified criteria.
4. Select if the alert should be sent at the end of the selected period or immediately when the number of lines are logged.
5. Optionally you can specify a Custom schedule with alerting limited to a specified timezone, days of the week, or timeframe. To configure a Custom schedule:



1. Select on for Custom schedule.
2. Select the Timezone for the log entries.
3. Select the days of the week when alerts should be generated.
4. Optionally specify a time range for the selected days. A graph will help you determine the number of log entries for the timezone and time range.



6. Specify the Method & URL for the webhook.
7. If your webhook requires specific header information, specify that in Headers. Multiple headers can be added by clicking Add.

Headers must be specified in all lower-case characters.
8.
Managing alerts by using the Python client 

You can manage alerts in a IBM Cloud Monitoring instance by using the Monitoring Python client.

To learn how to use the Python client, see [Using the Python client](https://cloud.ibm.com/docs/monitoring?topic=monitoring-python-client).



 Create an alert (POST) 

The following code shows the structure of a Python script that you can use to create an alert:

 Reference the Python client
from sdcclient import IbmAuthHelper, SdMonitorClient

 Add the monitoring instance information that is required for authentication
URL = <MONITORING-ENDPOINT>
APIKEY = <IAM_APIKEY>
GUID = <GUID>
ibm_headers = IbmAuthHelper.get_headers(URL, APIKEY, GUID)

 Instantiate the Python client
sdclient = SdMonitorClient(sdc_url=URL, custom_headers=ibm_headers)

 Add the notification channels to send an alert when the alert is triggered
notify_channels = [
{
'type': 'SLACK',
'channel': '<SLACK_CHANNEL_NAME>'
},
{
'type': 'EMAIL',
'emailRecipients':
'user1@ibm.com', 'user2@ibm.com'
]
}
]

 Get the IDs of the notification channels that you have configured
res = sdclient.get_notification_ids(notify_channels)
if not res[0]:
print("Failed to fetch notification channel ID's")

notification_channel_ids = res

 Create and define the alert details
res = sdclient.create_alert(
name=<ALERT_NAME>,
description=<ALERT_DESCRIPTION>,
severity=<SEVERITY>,
for_atleast_s=<FOR_ATLEAST_S>,
condition=<CONDITION>,
segmentby=<SEGMENTBY>,
segment_condition=<SEGMENT_CONDITION>,
[Learn more](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-alerts).

You can choose to be notified by using an absence alert that is triggered when no data is available.

Define an absence alert to be notified when inactivity in an application or service is identified. Notice that absence alerts require data in the view within the past 24 hours for the alert to be active.

You can choose to be notified by using a presence alert that is triggered when more log lines than expected are present.

Define a presence alert to be notified of exceptional situations in your applications and services that require immediate attention.

You can configure multiple notification channels. Valid channels are: email, Slack, PagerDuty, Webhook



Table 4. Guidance for notification channel

 Channel Guidance 

 email Email is a traditional communication method that you can use to notify 1 or more users. This notification channel requires users to be monitoring proactively their emails to detect an alert. Define an email alert to verify that the alert on a view is working, and to inform users of situations they may have requested information. 
 Slack Slack is a collaborative tool that you can use to communicate and share information across 1 or more teams. Define a Slack alert to inform about routine scenarios that you might want to monitor. 
 PagerDuty PagerDuty is an incident management tool that you can use to automate incident resolution and escalation, define on-call schedules and more. Define a PagerDuty alert to be notified immediately so that you can take action promptly. 
 Webhook A webhook is another method that you can configure to provide other applications information. Define a webhook alert if you have a third party tool that you can configure with an auditing instance using a webhook, and where you plan to manage notifications. 



Configure PagerDuty alerts to be notified immediately so that you can take action promptly on problems and automate their resolution. In addition, configure Slack alerts to share alerts and information.

You can also define a preset. A preset is an alert template that you can attach to any number of views.
* alert_type is the type of the alert (one of dos_attack_l7, load_balancing_pool_enablement_alert, clickhouse_alert_fw_anomaly, clickhouse_alert_fw_ent_anomaly, dedicated_ssl_certificate_event_type, universal_ssl_event_type, or load_balancing_health_alert).
* mechanisms is at least one of email, webhooks.
* description (optional) is the description of the alert.
* filter is the list of all enablement statuses and pool IDs for the pool toggle alert.









 WAF alert command 

To configure a WAF alert, use the following command:

curl -X POST https://api.cis.cloud.ibm.com/v1/:crn/alerting/policies -H 'Content-Type: application/json' -H 'X-Auth-User-Token: Bearer xxxxxx' -d '{
"name": "WAF Alerter",
"description": "Send an email on spike in firewall events for any service",
"enabled": true,
"alert_type": "clickhouse_alert_fw_anomaly",
"mechanisms": {
"email": [
{
"id": "sreteam@techcompany.com"
}
]
},
"filters": {
"zones": [
"123456ab7d8e9f0g12h2j34l5mn6op78"
]
}
}'

Where:



* -d is the array of attributes required to create the alert.



* name is the name of the alert.
* description (optional) is the description of the alert.
* enabled is the state of the alert (one of true, false).
<-- </section "id="section-create-glb-healthcheck-alert-examples" "> --><-- </section "id="section-create-glb-healthcheck-alert" "> --><-- <section "id="section-update-ddos-attack-l7-alert" "> --> ibmcloud cis alert-policy ddos-attack-l7-alert-update Update an alert policy for DDos attack l7. ibmcloud cis alert-policy ddos-attack-l7-alert-update POLICY_ID --name NAME (--emails EMAILS | --webhooks WEBHOOKS) --enabled (true | false) --description DESCRIPTION] -i, --instance INSTANCE] --output FORMAT] ! ! ! ! ! !
<-- <section "id="section-opt-update-ddos-attack-l7-alert" "> --> Command options POLICY_ID: The ID of alert policy. Required.--name: The name of the alert policy.--description: The description for the alert policy.--emails: The email addresses for dispatching an alert notification. For example: --emails test1@cn.ibm.com,test2@cn.ibm.com--webhooks: The webhook ID that for dispatching an alert notification. For example: --webhook webhookID1,webhookID2--enabled: Whether or not the alert policy is enabled.-i, --instance: Instance name or ID. If not set, the context instance specified by ibmcloud cis instance-set INSTANCE is used.--output: Specify output format, only JSON is supported.<-- </section "id="section-opt-update-ddos-attack-l7-alert" "> --><-- <section "id="section-update-ddos-attack-l7-alert-examples" "> --> Examples Update a ddos attack alert policy a2633e68-1a64-2512-a321-b64a17c7db7a.
Define a webhook alert if you have a third party tool that you can configure with an auditing instance using a webhook, and where you plan to manage notifications. 



Configure PagerDuty alerts to be notified immediately so that you can take action promptly on problems and automate their resolution. In addition, configure Slack alerts to share alerts and information.

You can also define a preset. A preset is an alert template that you can attach to any number of views.

To reuse an alert configuration with different views and enforce notification channels across users that analyze data through that instance, configure alert presets.

When you send a notification, you can include log data as part of the notification.

Customize the data that is included in a notification for situations where the receiver of the notification does not have access to the log data.





 Define the archive strategy 

You might have different requirements that require archiving your data:



* Backup requirements to keep data for a period of time
* Data access requirements so that you can query the data after it is not available for search through the web UI
* Disaster recovery requirements
* Compliance requirements



IBM Cloud Activity Tracker does not backup your data.

There are 2 types of data that you should consider archiving:



* Log data

By default, archiving of log data is not enabled for any auditing instance.

When you enable archiving of your log data, you are responsible for checking that your archived files are not corrupted, and for the maintenance of your archived files.
* Web UI resource definitions such as parsing templates, exclusion rules, views, screens, and dashboards.



Archive your resource definitions and your log data.



 Backup the resource configurations of your auditing instance 

In the UI, you can define custom views, dashboards, parsing templates, screens, and exclusion rules that you can use to view and analyze data.

To reuse resource definitions that you define in your auditing instance, you can export these resources from an IBM Cloud Activity Tracker instance as a JSON file. Then, you can import the definitions into other auditing instances. For example, you can reuse your resources across different environments for your stage, pre-production, and production instances.
Because the view is not active, the absence alert is muted and you do not get notifications. To make the view active and get notifications for the absence condition, logs need to start flowing into the view.





 Alert conditions 

You can configure any of the following conditions for an alert:



* Time frequency: You set this condition to specify how often to trigger an alert. Valid values are: 30 seconds, 1 minute, 5 minutes, 15 minutes, 30 minutes, 1 hour, 6 hours, 12 hours, 24 hours
* Event lines counter: You set this condition to specify the number of event lines that match the view's filtering and search criteria. When the number of event lines is reached, an alert is triggered.



You can decide whether both conditions are checked or only one. If both conditions are set, an alert is triggered when any of the thresholds is reached.

If you set the Event lines counter to be the only condition that triggers an alert, notice that the time frequency that is set when you configure the condition determines the time that it takes for the alert condition to be reset after the alert is triggered.

For example, you can configure an alert that is triggered after 30 seconds, or when a 100 event lines that match the view's filtering and search criteria are collected.





 Mute alert notifications 

By default, the feature that controls the ability of a user to mute notifications is enabled when you configure an alert on a custom view. The Muteable feature applies to email notifications only.

When the mutable feature is enabled on an alert, a user can pause notifications for a period of time. A user can choose to mute an alert for a period of 1 hour, 6 hours, 12 hours, or 1 day.







 Exporting logs 

You might need access to a set of logs outside the web UI to investigate an issue in more detail.

You can export data in JSONL format from an IBM Log Analysis instance into a local file.

You can export logs through a view in the web UI, or programmatically by using a REST API.

Consider the following information when you export logs:



* You export a set of event entries.
400 The alert configuration is not valid. 
 401 Unauthorized access. 
 404 The alert ID is not recognized. 
 409 There is a version mismatch. 
 422 The alert name is not valid. The name is already used. 







 Body parameters 



 id (integer) 

ID of an alert.





 condition (string) 

Defines the threshold that is configured for the alert. This parameter is required for MANUAL alerts only.

For example, you can defines a consition as follows: avg(timeAvg(uptime)) <= 0





 createdOn (integer) 

Defines the creation time of an alert in milliseconds.

This parameter returns the Unix-timestamp when the alert was created.





 description (string) 

This parameter describes the alert.

The description is available when you view an alert in the Alerts section of the monitoring UI, and it is included in notification emails.





 enabled (boolean) 

Defines the status of an alert.

By default, this parameter is set to true and the alert is enabled when it is created.





 filter (string) 

Defines the scope of the alert by configuring segments.

When this field is empty, all the metric sources are included. The scope is set to Everything.

For example, you can define filters like the following ones:

kubernetes.namespace.name='production'

container.image='nginx'.

kubernetes.namespace.name='production' and container.image='nginx'.





 name (string) 

Name of the alert. Must be unique.

The name is used to identify the alert in the Alerts section of the monitoring UI, and it is included in notification emails.





 modifiedOn (integer) 

Defines when an alert was last modified in milliseconds.

This parameter defines the Unix-timestamp when the alert was last modified.





 notificationChannelIds (array) 

Lists the notification channels that are configured to notify when an alert is triggered.

Valid options are EMAIL, PAGER_DUTY, WEBHOOK, VICTOROPS, and SLACK.

"notificationChannelIds": [
SMS You can send an SMS to notify of an alert either through the PagerDuty channel or through the IBM Cloud Monitoring channel. For more information, see [Integrating with SMS](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-sms). 
 Slack You can configure a slack channel. 
 Webhook You can configure a web hook URL. 
 PagerDuty You can configure connection details to your PagerDuty system, and select a service. Use this channel when you require call times and escalation management processes. For more information, see [Integrating with PagerDuty](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-pagerduty). 
 IBM Cloud Monitoring You can configure a Monitoring instance. When you need alerts on log data alongside your system health metrics, configure a Monitoring notification channel. For more information, see [Integrating with IBM Cloud Monitoring](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-monitoring). 







 Creating alerts 

You can choose any of the following options to create an alert:



* Create a preset and attach the preset to the view
* Create a specific alert on a view.



You can configure alerts graphically through the Log Analysis UI, or programmatically.



* For more information on how to configure an alert, see [Creating alerts through the UI](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-create_alert_ui).
* For more information on how to create alerts programmatically, see [Managing views and alerts programmatically](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-config_api).







 Deleting alerts 

You can delete alerts graphically through the Log Analysis UI, or programmatically.
Enter the condition, for example, min(min(cpu.used.percent)) < = 50 OR max(max(cpu.used.percent)) >= 80.

Zoom

![Multi-condition alert](https://cloud.ibm.com/docs-content/v1/content/220cdcbf6f4421bd7fee83fd1028048dba3f16c8/monitoring/monitor/images/multi-condition-alerts.png)

Multi-condition alert







 Step 5. Define the scope 

Indicate the scope of the alert. By default, the scope is set to everywhere. However, you can limit the scope, for example, to a specific component of the infrastructure.





 Step 6. Define the trigger condition 

Choose any of the following options:



* Choose Single Alert when you want this alert to be triggered when the condition is met for your entire scope.
* Choose Multiple Alert and configure 1 or more segments when you want this alert to be triggered when the condition is met for any or every segment.







 Step 7. Configure the notify section 

Select 1 or more notification channels.

By default, you get a notification in the Events section.

You can enable multi-channel notifications by enabling 1 or more notification channels.

Optionally, you can customize the information that is included in a notification to provide more context for the alert.
“6e67c08e3bae7eb398101d08def8a68a”,
“df2d9d70fcb194ea60d2e58397cb35a6”
]
},
"conditions": {
}}'

Where:



* -d is the array of attributes that are required to create the alert.



* name is the name of the alert.
* enabled is the state of the alert (one of true, false).
* alert_type is the type of the alert (one of dos_attack_l7, load_balancing_pool_enablement_alert, clickhouse_alert_fw_anomaly, clickhouse_alert_fw_ent_anomaly, dedicated_ssl_certificate_event_type, universal_ssl_event_type, or load_balancing_health_alert).
* mechanisms are at least one of email, webhooks.
* description (optional) is the description of the alert.
* filter is the list of all enablement statuses and pool IDs for the pool toggle alert.
* conditions describe for all pools whether the pool is being enabled, disabled, or both. Content is generated automatically if the field is empty.









 Security (WAF) alert command 

To configure a WAF alert, use the following command:

curl -X POST https://api.cis.cloud.ibm.com/v1/:crn/alerting/policies -H 'Content-Type: application/json' -H 'X-Auth-User-Token: Bearer xxxxxx' -d '{
"name": "WAF Alerter",
"description": "Send an email on spike in firewall events for any service",
"enabled": true,
"alert_type": "clickhouse_alert_fw_anomaly",
"mechanisms": {
"email": [
{
"id": "sreteam@techcompany.com"
}
]
},
"filters": {
"zones": [