Alerts overview

NOTE
Since alerts are supported in both production and development sandboxes, you can subscribe to them in any sandbox. When a sandbox is reset, all subscription alerts will also be reset, and when a sandbox is deleted, all subscription alerts will be deleted.

Adobe Experience Platform allows you to subscribe to event-based alerts regarding Adobe Experience Platform activities. Alerts reduce or eliminate the need to poll the Observability Insights API in order to check if a job has completed, if a certain milestone within a workflow has been reached, or if any errors have occurred.

When a certain set of conditions in your Experience Platform operations is reached (such as a potential problem when the system breaches a threshold), Experience Platform can deliver alert messages to any users in your organization who have subscribed to them. These messages can repeat over a pre-defined time interval until the alert has been resolved.

This document provides an overview of alerts in Adobe Experience Platform, including the structure of how alert rules are defined.

One-time alerts vs. repeating alerts

Experience Platform alerts can be sent one time, or they can repeat over a pre-defined interval until they are resolved. The use cases of each of these options are intended to differ in the following ways:

One-time alert
Repeating alert
Does not necessarily indicate a problem.
Indicates a potentially undesirable state.
Does not repeat.
Can repeat if the anomalous condition persists.

Examples include:

  • Data ingestion has successfully completed.
  • A query execution has finished.
  • Data has been deleted.

Examples include:

  • Ingestion duration is exceeding the service-level agreement (SLA).
  • Daily ingestion did not happen over the past 24 hours.
  • The stream processor’s rate of error is above the configured threshold.

Anatomy of an alert

An alert can be broken down into the following components:

Component
Description
Metric
An Observability metric whose value triggers the alert, such as the number of failed batch ingestion events (timeseries.ingestion.dataset.batchfailed.count).
Condition
A condition related to the metric which triggers the alert if it resolves to true, such as a count metric exceeding a certain number. This condition may be associated with a pre-defined time window.
Window
(Optional) The condition for an alert may be constrained to a pre-defined time window. For example, an alert may trigger depending on the number of failed batches in the past five minutes.
Action
When an alert is triggered, an action is performed. Specifically, messages are sent to applicable recipients through a delivery channel, such as a pre-configured webhook or the Experience Platform UI.
Frequency
(Optional) An alert can be configured to repeat its action at a defined interval if its condition remains true or is otherwise unresolved.

Receiving and managing alerts

Alerts can be received and managed through two channels:

I/O Events events

Alerts can be sent to a configured webhook to facilitate efficient automation of activity monitoring. In order to receive alerts via webhook, you must register your webhook for Experience Platform alerts in Adobe Developer Console. See the guide on subscribing to Adobe I/O Event notifications for specific steps.

Experience Platform UI ui

The Experience Platform UI allows you to view received alerts and manage alert rules. The following video provides an introduction to these capabilities.

Transcript

In this video, I’m going to show you how to use the alerts feature in Adobe Experience Platform. Alerts allow you to subscribe to event-based messages related to various processes. Once your organization has implemented and started using Platform, you can use alerts to make sure things are running smoothly. For example, a data engineer can use alerts to monitor data ingestion processes, while a marketer could use them to make sure that their segment jobs are running smoothly. The alerts screen is under administration in the left navigation. On the browse tab, you can see all of the out-of-the-box alerts provided by Adobe. You can use the search box or a filters at the top to locate a particular alert or type of alert.

The alerts are provided out-of-the-box by various Adobe teams. Expect this list to grow in future releases. You can see the name of the alert, which service it’s related to, whether or not it’s enabled, and the last time the alert was triggered. Clicking on an alert opens the sidebar, which exposes additional details. Now, some alerts we call life cycle alerts. These are generated from an important event in the life cycle of a process, such as it completed or failed. Other alerts we refer to as metric alerts and these indicate things like a process that hasn’t completed in an expected timeframe. For example, this alert triggers when a segment job takes longer to process than a defined threshold. It’ll keep evaluating at the frequency specified and automatically change the alert status when the process completes.

Now, even though this alert evaluates every 30 seconds, it’s only going to notify you when the alert first triggers. An important distinction between the life cycle alerts and the metric alerts is that only the metric alerts will list a last triggered timestamp and display in the history tab. For each enabled alert, a user can decide whether or not they’d like to subscribe to it. Depending on your user permissions, you might also be able to enable or disable the alert for other users. Alerts will be emailed to the address associated with your Adobe ID. They’re also visible up here in the notifications area of the interface. Here’s an alert related to a source’s flow run failing. To find out more information, I can click on the notification and I’ll be taken directly to the details of the flow run where I can see that there is an error with my data. To see the alerts in the notifications area, you have to enable platform notifications, which you can do by clicking here in the gear icon, scrolling and using the toggle.

The ability to view and manage alerts is controlled in the Adobe AdminConsole where administrators can decide granular permissions related to platform features. For example, a user with a view alerts permission item can subscribe or unsubscribe to alerts, while someone with managed alerts can disable or enable an alert for other users.

Like with everything in platform, you can also interact with alerts via the API. You can subscribe to these events in the developer console and configure your own custom alert mechanisms using web hooks. I hope you enjoyed this overview of alerts. Stay alert. -

To work with alerts in the Experience Platform UI, you must have the following access control permissions enabled through Adobe Admin Console:

Permission
Description
View Alerts
Allows you to view received alert messages.
View Alerts History*
Allows you to view a history of received alerts via the Alerts tab.
Manage Alerts*
Allows you to enable and disable alert rules via the Alerts tab.
Resolve Alerts*
Allows you to resolve triggered alerts via the Alerts tab.

*In order to access the Alerts tab, you must also be granted the View Alerts permission in combination with one of the other permissions.

NOTE
For more information on how to manage permissions in Experience Platform, refer to the access control documentation.

With the View Alerts permission, can view received alerts by selecting the bell icon ( Bell Icon ) in the top-right corner.

NOTE
Select an alert to navigate to a related dashboard for more detailed information on why the alert has been triggered.

In addition, the Alerts tab in the UI allows individual users to subscribe to specific alert types, and allows admins to enable or disable alert rules altogether. See the UI guide for more information on managing alerts.

Slack integration slack-integration

You can use a webhook proxy on Adobe App Builder to receive Adobe I/O Events from Experience Platform to your Slack. The proxy handles Adobe’s verification handshake and turns event payloads into Slack messages, so you can receive customer-facing alerts directly to your workspace.

Transcript

Hello, in this guide we will integrate Slack webhooks using Adobe’s runtime deployments. Before we begin, make sure that the prerequisites for this project are completed and that your user has the Developer role enabled. If not, you can ask the administrators of your organization to provide it for you. Let’s begin. First, we will create a project from a template and we will choose the App Builder option. Give a meaningful name for the project. I will call mine Slack Webhook Integration. I will not add any other workspace, so we will use the default ones.

Save the project. Now, we will need to initialize the runtime environment on our machine. For this, open up a terminal. Log in to Adobe IEO using the aio-login command.

I am already logged in, so I will skip this command. Every command that will be run in the terminal in this guide can also be found on the written documentation guide.

Now, let’s initialize the application by running the following command. From here, choose your org and choose the project that you’ve just created. In my case, Slack Webhook Integration. From here, using your arrow keys, choose the only template supported by my org option. From here, we will simply press enter. We will skip this. We will choose the actions deploy runtime actions option.

Use your arrow keys and choose the Adobe Experience platform real-time customer profile option. Press enter.

From here, we will choose the pure HTML or JS project. We will leave the sample action with the generic template, so we will press enter.

And we will leave the name as given.

So, we will press enter again. Awesome. Our project has been initialized.

Let’s go into the directory of the project, namely Slack Webhook Proxy.

Now that we are here, let’s add an action. From here, choose the only action template supported by my org option. Press enter. And from here, press space in order to choose the template Adobe Generator Ad Publish Events.

On my machine, you can see that the circle next to the name has been filled.

This confirms the selection.

Press enter. Here, we will name our action Webhook Proxy. Make sure that this name is identical to what is in the documentation. Great. Our action has been created.

Now, we will have to navigate into a text editor or an IDE in order to do some modifications to the files.

For this project, I will choose IntelliJ IDEA. You can use any tool that you have at your disposal. In the root directory, you can see that we have an action directory. Here, you will also see that we have the action that we’ve just created, namely Webhook Proxy. Under this directory, there is an index.js file. Here is where the code for our Webhook Proxy will reside.

I will delete the content that is in it by default, and I will save the file.

And I will now copy the code that is needed. There we go.

Make sure that you save the file.

Next up, we have to configure the runtime in order to see this action and enable it as needed.

For this, we will go into the app.config.yaml file.

Here, we will also delete the existing content. Now, from the written documentation, you should copy the content that is put there for the file app.config.yaml. This is what it should look like. We have our project, Slack Webhook Proxy, with a defined action Webhook Proxy, with a function that is given in the action slash Webhook Proxy directory. Next up, make sure that in your environment file, you will add the Slack Webhook URL, as indicated in the documentation.

This part is crucial. I will not do it on video, as the credentials are sensitive. After you do that, make sure that you save the file. Cool.

Now, let’s go back to the terminal.

Now that our action has been configured as needed, we need to deploy our action.

For this, run the following command. Make sure that you are in the root of your directory. Otherwise, this one would… Our action has been deployed. Now, we will go back to our project in the Developer Console. From here, we will choose a workspace. I will choose Stage. We will add a service, Event. Choose Experience Platform and Platform Notifications. From here, choose any and all events that you want to receive on your Slack application.

For this tutorial, I will choose all the events. Leave this as default. And give a meaningful name to this event registration. Give it also a description. Cool. On the How to Receive Events page, we will go for the second option, namely Runtime Action, and we will choose the action that we’ve just deployed, the Webhook Proxy action. Save your configured events. And here we are. On the Event Delivery method, we have the Webhook Proxy action that we just created. In order to test whether the integration was successful or not, you should send a sample event.

I will send the Streaming Throughput Capacity. Looking into my Select Channel, I can see that I’ve received the event that I’ve set, namely Streaming Personalization Throughput Capacity Breached. Awesome.

The configuration worked.

Thank you for your attention on this tutorial.

For more information on how to receive Experience Platform notifications in Slack by integrating with an Adobe App Builder webhook proxy, see monitor Experience Platform events in Slack.

Next steps

By reading this document, you have been introduced to Experience Platform alerts and their role in the Experience Platform ecosystem. Refer to the process documentation linked to throughout this overview to learn how to receive and manage alerts.

recommendation-more-help
d82ad670-3501-465b-afee-a91200fdc02c