vania-janet/multiturn-rag-retrieval-data huggingface dataset:
[Configure the IBM Cloud Event Notifications instance](https://cloud.ibm.com/docs/monitoring?topic=monitoring-eventnotif_smseventnotif_sms_step3).









 Send an SMS notification by using the PagerDuty On Call Service 

When the Activity Tracker service sends a notification (event) to PagerDuty, an alert incident is created in PagerDuty and an SMS is sent if the escalation policy and on-call responder details include the rule to send to an SMS number.



* An incident is the issue that needs to be resolved. It can have 3 states: triggered, acknowledged, and resolved
* An incident triggers a PagerDuty service that generates 1 or more notifications to go out to on-call responders according to the service's escalation policy. SMS is a type of notification. You must configure a service so that it includes the escalation policy that indicates how to connect a service to individual users and schedules.

A service includes information about the Activity Tracker service as an inbound integration that sends notifications to PagerDuty.

A service profile provides information such as collaboration across teams, who owns the service, who’s on-call, how to contact the Team responsible for the service and more.
* A User Profile includes information about on-call responders such as the phone number, SMS number, and email address. The information is used to contact the user when an incident is assigned to the user. You must configure the user profiles and check that the SMS details are correct.
* An SMS provides basic information about the alert. The alert can include 1 or more incidents. When multiple incidents are triggered and assigned to a user, the SMS notification bundles all notifications for the user into 1 SMS. You can click on an incident link to see more details. You can acknowledge or resolve the incident with a text reply.

The maximum number of characters in a text message is 160. Any text message that has more than 160 characters is truncated.
* PagerDuty publishes the SMS number list so a user can easily validate the sender of the SMS.
Slack: Specify your Webhook URL and the desired Message color.

Email: Specify the Recipients of the email and a Timezone. The timezone defines the timestamp value of each event that is included in the email. To see UTC timestamps, you can select (GMT +00:00) UTC.

PagerDuty: Specify the Service. If required, you will be prompted to connect to PagerDuty.

Webhook: Specify the Method & URL, and the Headers and Body of the JSON used to interact with your webhook. You can use Validate JSON to make sure your JSON is correct before creating the alert.
7. You can click Test to test that your alert configuration is correct.

![Test option](https://cloud.ibm.com/docs-content/v1/content/6f3c07c34058f637b1c86044ca4f9b24214330a7/activity-tracker/alerts/images/alert_test.png)
8. Click Save Alert.
9. If you want to create an additional alert channel, click + and follow the prior steps to create additional channels. You can create different channel types, for example, an email and a Slack channel. Or, you can create multiple channels of the same type with different alert criteria.



Alerts will be generated based on your configuration.
* Review the alerts sent - are the alerts required?
* Review the alerts that weren't sent - do you need to know about them?
* Review the metrics - are the metrics correct? For example, confirm that CPU usage must be set to 75% rather than 90% now that you understand your baseline.
* Do you need to configure your own alarms?
* Do you need to include virtual machines?









 Typical alarm workflow 

After set-up, review the following example of an alarm workflow, typically adopted by system administrators, when an alarm is triggered.



1. A host has an alarm set to monitor CPU usage and the alarm has an alarm action to send an email to the administrators when the alarm is triggered, as described in the previous section.
2. The host CPU usage spikes, triggering the alarm, which sends an email to the administrators.
3. One of the administrators logs in to vCenter and acknowledges the triggered alarm to allow the other administrators know the problem is being addressed, and to prevent the alarm from sending more email messages. However, the alarm is still visible in the system.
4. The administrator finds the cause of the CPU spike and rectifies.
5. The alarm is reset automatically.







 Preconfigured alarms - standard 



* Alarm name - The name of the alarm visible in vCenter.
* Guidance - IBM Cloud for VMware Solutions guidance on the use of this alarm.
* More Information - Additional information available from IBM or VMware to help with the resolution of these alarms when they are triggered.



The following table describes the standard preconfigured alarms.



Table 1. Preconfigured alarms

 Alarm name Guidance Details 

 Host connection and power state Configure to send email one time when set to Not Responding or Standby. [Alarms about the host connection state changing from green to red frequently occur (1020210)](https://kb.vmware.com/s/article/1020210) 
 Host CPU usage Configure to send email one time when host CPU usage > 90% for 5 mins.
--region <REGION> | -r <REGION>
: Name of the region, for example, us-south or eu-gb. If not specified, the region logged into or targeted will be used.

--severity <SEVERITY> | -s <SEVERITY>
: A comma-separated list of severity values enclosed in double-quotes ("). If only a single severity is specified, the double-quotes can be omitted.

--output <FORMAT>
: A comma-separated list of output preferences enclosed in double-quotes ("). If only a single preference is specified, the double-quotes can be omitted. Supported options are WIDE and JSON.

If JSON is specified, output will be returned in JSON format. If JSON is not specified, output will be returned in a tabular format.

WIDE returns additional details in the output.

--enabled <TRUE | FALSE> | -e <TRUE | FALSE>
: Boolean that indicates the alerts to be listed based on the alert notification settings. If specified, --enabled true will list alerts for instances where notifications, for example, email or Slack, are enabled. Specifying --enabled false will return a list of alerts for instances where notifications are not enabled.

--team <TEAM_NAME>
: The name of the IBM Cloud Monitoring team to be used for authorization. If no team is specified, the default team will be used.

--help | -h
: List options available for the command.





 Examples 

The following are examples using the ibmcloud monitoring alert list command.

List all alerts for the IBM Cloud Monitoring abc instance.

ibmcloud monitoring alert list --name "IBM Cloud Monitoring abc"

List all alerts for the IBM Cloud Monitoring abc instance in the us-south region.

ibmcloud monitoring alert list --name "IBM Cloud Monitoring abc" --region us-south

List all alerts for the IBM Cloud Monitoring abc instance with low and medium severity where notifications are not enabled.

ibmcloud monitoring alert list --name "IBM Cloud Monitoring abc" --enabled false --severity low,medium







 ibmcloud monitoring alert get
List all alerts for the IBM Cloud Monitoring abc instance in the us-south region.

ibmcloud monitoring alert list --name "IBM Cloud Monitoring abc" --region us-south

List all alerts for the IBM Cloud Monitoring abc instance with low and medium severity where notifications are not enabled.

ibmcloud monitoring alert list --name "IBM Cloud Monitoring abc" --enabled false --severity low,medium







 ibmcloud monitoring alert get 

Use this command to get details on an alert by using the alert ID.

ibmcloud monitoring alert get --name NAME --id ALERT_ID [--region REGION] [--output FORMAT] [--team TEAM_NAME]



 Command options 

--name <NAME> | --n <NAME>
: Name of the instance.

--id <ALERT_ID>
: ID of the alert.

--region <REGIO> | -r <REGION>
: Name of the region, for example, us-south or eu-gb. If not specified, the region logged into or targeted will be used.

--output <FORMAT>
: A comma-separated list of output preferences enclosed in double-quotes ("). If only a single preference is specified, the double-quotes can be omitted. Supported options are WIDE and JSON.

If JSON is specified, output will be returned in JSON format. If JSON is not specified, output will be returned in a tabular format.

WIDE returns additional details in the output.

--team <TEAM_NAME>
: The name of the IBM Cloud Monitoring team to be used for authorization. If no team is specified, the default team will be used.

--help | -h
: List options available for the command.





 Examples 

The following are examples using the ibmcloud monitoring alert get command.

Get details for an alert with ID 1234567 for the IBM Cloud Monitoring abc instance.

ibmcloud monitoring alert get --name "IBM Cloud Monitoring abc" --id 1234567

Get details for an alert with ID 1234567 for the IBM Cloud Monitoring abc instance in the us-south region.
You can still manage alerts by using the legacy editor. However, notice that new features are only available through the new editor.
* New configuration settings to help you troubleshoot issues. You can configure a dashboard and a runbook with an alert.



Deprecated features:



* Deprecation of the Anomaly Detection and Group Outlier alert types. You can view and manage existing alerts but you cannot define new ones.



For more information, see [Configure alerts](https://docs.sysdig.com/en/docs/sysdig-monitor/alerts/configure-alerts/).





 15 June 2022 

IBM Cloud® Monitoring has made available a proprietary time series database that is designed for storing and serving metrics at scale. [Learn more](https://docs.sysdig.com/en/docs/release-notes/enhanced-metric-store/)
: The following changes have been made:



* [Metrics and labels are stored and displayed in a Prometheus compatible naming convention](https://docs.sysdig.com/en/docs/release-notes/enhanced-metric-store/prometheus-compatible-naming-conventions-for-metrics--labels).
* Some metrics and labels have been deprecated. Deprecated metrics and labels will no longer be available 30 days after this release. See [Discontinued Metrics and Labels](https://docs.sysdig.com/en/docs/release-notes/enhanced-metric-store/discontinued-metrics-and-labels).
* Classic metrics have been replaced with context-explicit metrics. See [Mapping Classic Metrics with Context-Specific PromQL Metrics](https://docs.sysdig.com/en/docs/sysdig-monitor/metrics-dictionary/metrics-and-label-mapping/mapping-classic-metrics-with-context-specific-promql-metrics/mapping-classic-metrics-with-context-specific-promql-metrics).
[Configure the IBM Cloud Event Notifications instance](https://cloud.ibm.com/docs/monitoring?topic=monitoring-eventnotif_smseventnotif_sms_step3).









 Send an SMS notification by using the PagerDuty On Call Service 

When the Log Analysis service sends a notification (event) to PagerDuty, an alert incident is created in PagerDuty and an SMS is sent if the escalation policy and on-call responder details include the rule to send to an SMS number.



* An incident is the issue that needs to be resolved. It can have 3 states: triggered, acknowledged, and resolved
* An incident triggers a PagerDuty service that generates 1 or more notifications to go out to on-call responders according to the service's escalation policy. SMS is a type of notification. You must configure a service so that it includes the escalation policy that indicates how to connect a service to individual users and schedules.

A service includes information about the Log Analysis service as an inbound integration that sends notifications to PagerDuty.

A service profile provides information such as collaboration across teams, who owns the service, who’s on-call, how to contact the Team responsible for the service and more.
* A User Profile includes information about on-call responders such as the phone number, SMS number, and email address. The information is used to contact the user when an incident is assigned to the user. You must configure the user profiles and check that the SMS details are correct.
* An SMS provides basic information about the alert. The alert can include 1 or more incidents. When multiple incidents are triggered and assigned to a user, the SMS notification bundles all notifications for the user into 1 SMS. You can click on an incident link to see more details. You can acknowledge or resolve the incident with a text reply.

The maximum number of characters in a text message is 160. Any text message that has more than 160 characters is truncated.
* PagerDuty publishes the SMS number list so a user can easily validate the sender of the SMS.
Alarms 

The /whisk.system/alarms package, available through IBM Cloud® Functions, can be used to fire a trigger or feed at a specified frequency. Alarms are useful for setting up recurring jobs or tasks, such as invoking a system back up every hour.

The package includes the following feeds.



Table 1. Components that are included with the alarms package

 Entity Type Parameters Description 

 /whisk.system/alarms Package <br><br> * <br><br><br> Alarms and periodic utility. 
 /whisk.system/alarms/once Feed date, trigger_payload, deleteAfterFire Fire trigger event one time on a specific date. 
 /whisk.system/alarms/interval Feed minutes, trigger_payload, startDate, stopDate Fire trigger event on an interval-based schedule. 
 /whisk.system/alarms/alarm Feed cron, timezone, trigger_payload, startDate, stopDate Fire trigger event on a time-based schedule by using cron. 





 Firing a trigger event one time 

The /whisk.system/alarms/once feed configures the Alarm service to fire a trigger event one time on a specified date. To create a fire-once alarm, run the following command.

ibmcloud fn trigger create fireOnce --feed /whisk.system/alarms/once --param date "<date>" --param trigger_payload "{<key>:<value>,<key>:<value>}" --param deleteAfterFire "<delete_option>"



Table 2. Understanding the trigger create fireOnce command components

 Parameter Description 

 fireOnce The type of alarm trigger you are creating. 
 --feed /whisk.system/alarms/once The alarm package file path for the fireOnce feed. 
 --param date Replace <date> with the date when you plan to fire the trigger. The trigger fires once at the specified time. The date parameter supports an integer or string value.
A graph will help you determine the number of log entries for the timezone and time range.



6. Specify 1 or more email addresses.
7. Optional: You can click Test to test that your alert configuration is correct.
8. Click Save Alert.







 Muting an alert 

This section only applies to email alerts.

After you configure an alert on a view and receive a notification email, complete the following steps to mute the alert a period of time:



1. Go to the email account where you receive email notifications.
2. Open a notification email for a view that you want to mute.

Look for emails that are sent by IBM Cloud Activity Tracker. The subject includes the name of the view.

In the email, there is a section that includes the following text:

Mute these alerts for [1 Hour] [6 Hours] [12 Hours] [1 Day]
3. Choose a period of time.

A window opens. The information provided indicates the view, the notification that is muted, and the time period that is muted for.

For example, you can get a message that indicates the following:

Email alerting for MyView has been muted for an hour.

Unmute

Alerting is scheduled to resume at Jun 14, 11:59am.

Manage Alerts

From this page, you can select Unmute to enable notifications on the view. You can also select Manage to go to the ALERTS dashboard in the web UI.







 Unmuting a muted alert 

You can manage alerts through the ALERTS dashboard.



1. In the web UI, select the Settings icon ![Settings icon](https://cloud.ibm.com/docs-content/v1/content/f61dbc5d84bf0c89e477a05cab04c72f429e1b7a/log-analysis/alerts/images/admin.png).
2. Select ALERTS.

You can see the list of alerts that are muted.
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.



5. Depending on the type of alert you will also need to configure additional settings:

Slack: Specify your Webhook URL and the desired Message color.

Email: Specify the Recipients of the email and a Timezone. The timezone defines the timestamp value of each event that is included in the email. To see UTC timestamps, you can select (GMT +00:00) UTC.

PagerDuty: Specify the Service. If required, you will be prompted to connect to PagerDuty.

Webhook: Specify the Method & URL, and the Headers and Body of the JSON used to interact with your webhook. You can use Validate JSON to make sure your JSON is correct before creating the alert.
6. You can click Test to test that your alert configuration is correct.

![Test option](https://cloud.ibm.com/docs-content/v1/content/f61dbc5d84bf0c89e477a05cab04c72f429e1b7a/log-analysis/alerts/images/alert_test.png)
7. Click Save Alert
8. If you want to create an additional alert channel, click + and follow the prior steps to create additional channels. You can create different channel types, for example, an email and a Slack channel. Or, you can create multiple channels of the same type with different alert criteria.





Your preset can now be used by others to setup alerts.





 Deleting a preset
In the web UI, select the Settings icon ![Settings icon](https://cloud.ibm.com/docs-content/v1/content/6f3c07c34058f637b1c86044ca4f9b24214330a7/activity-tracker/alerts/images/admin.png).

Select ALERTS.

You can see the list of alerts that are muted. Each entry informs about the view where notifications are muted, the user who requested the action, and the UTC time when notifications will be enabled.
2. Select an alert that you want to unmute.
3. Click Unmute.
Sending SMS alerts using Cloud Functions 

In the IBM Cloud Monitoring service, you can configure single alerts and multi-condition alerts to notify support staff about problems that might require attention. Using IBM Cloud® Functions, these alerts can trigger SMS (short message service) messages.

This example shows how to use [Twilio Programmable SMS Messaging support](https://www.twilio.com/docs/sms) and IBM Cloud® Functions to send SMS alerts to support staff members. This example uses the Twilio Python package. [Other language support is available through Twilio.](https://www.twilio.com/docs/libraries)



1. [Create a Twilio account.](https://www.twilio.com/docs/usage/tutorials/how-to-use-your-free-trial-account)
2. [Create a Twilio phone number that will be used to send your SMS messages.](https://www.twilio.com/docs/usage/tutorials/how-to-use-your-free-trial-accountget-your-first-twilio-phone-number)

After you click Get a trial phone number make note of the phone number you are assigned. You will need this phone number in later steps.
3. [Install the IBM Cloud® Functions CLI and plug-in.](https://cloud.ibm.com/docs/openwhisk?topic=openwhisk-cli_install)
4. [Create an IBM Cloud® Functions namespace.](https://cloud.ibm.com/docs/openwhisk?topic=openwhisk-namespacescreate_iam_namespace)
5. On your local computer, create a Python virtual environment to install the requirements.

If you are running a Windows system, run the following commands:

pip install virtualenv
mkdir twilio
virtualenv twilio
cd twilio/scripts
pip install twilio
deactivate
alert(response)
})

// with this

enPush.retrieveSubscriptions(function (response) {
alert(response)
})
* Changes to the tag unsubscribe

// Replace this
bmsPush.unSubscribe("your tag", function (response) {
alert(response)
})

// with this
enPush.unSubscribe("your tag", function (response) {
alert(response)
})





Your web app is ready to work with your new instance of IBM Cloud® Event Notifications.







 Step 5: Modify the back end 

This section contains the steps that you perform in the back end. The send notification API is changed and therefore all the SDKs change also.



 If you are using the Node.js SDK 

Migrate the existing Node SDK to the new IBM Cloud® Event Notifications SDK. Follow this link for the new Node Admin SDK documentation.



1. Changes to importing the SDK



// Replace the below section

var PushNotifications = require('ibm-push-notifications').PushNotifications;
var Notification = require('ibm-push-notifications').Notification;
var PushMessageBuilder = require('ibm-push-notifications').PushMessageBuilder;
var PushNotificationsApiKey = require('ibm-push-notifications').PushNotificationsWithApiKey;

// with this

var IamAuthenticator = require('@ibm-cloud/event-notifications-node-admin-sdk/auth').IamAuthenticator
var EventNotificationsV1 = require('@ibm-cloud/event-notifications-node-admin-sdk/event-notifications/v1')



1. Changes to initializing the SDK



// Replace the below section
Muting 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 Mutable 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.

For more information on how to mute an email alert, see [Muting an alert](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-emailemail_mute).

For more information on how to ummute an email alert, see [Unmuting a muted alert](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-emailemail_unmute).
* Efficiency alerts - information to improve performance or reclaim resources.



VMware Aria Operations Alerts are events that occur on the monitored objects when data analysis indicates deviations from normal metric values, or when an issue occurs with one of the monitored components. VMware Aria Operations alerts are assigned one of these categories:



* Critical - must be acted upon immediately.
* Immediate - must be acted on as soon as possible.
* Warning - must be checked when time allows.



* Logging - VMware Aria Operations™ for Logs provides real-time log management and log analysis with machine learning-based intelligent grouping, high performance searching, and troubleshooting across the physical and virtual objects in the IBM Cloud for VMware Solutions architecture. VMware Aria Operations for Logs collects data from vSphere hosts by using the syslog protocol. It also collects events, tasks, and alarm data for other VMware products, like vCenter Server. It integrates with VMware Aria Operations to send notification events and enable launch-in-context. Other objects in the IBM Cloud for VMware Solutions architecture that can send syslog data are pointed to VMware Aria Operations for Logs. Optionally, the client can configure any system that can send syslog data to forward this data to VMware Aria Operations for Logs.
* Network Health - VMware Aria Operations™ for Networks is an analytics tool that is focused on proactively enabling:



* Network health and performance monitoring.
* End-to-end troubleshooting.
* 360° visibility and analytics.
* Micro-segmentation-based compliance management.



* Patching and Upgrading - vSphere Update Manager (VUM) provides centralized, automated patch and version management for VMware vSphere hosts and virtual machines (VMs) (not OS and apps).







 Operation management networking 

The following diagram shows the network overview.

Zoom

![Network diagram](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/vmwaresolutions/images/opsmgmt-network.svg)