Big News For Alerts and Applied Intelligence

Hi @vinodkumar

Let’s take a look at your questions one at a time.

Does this big news applies to both US & EU region?

Yes, it applies to all New Relic customers, regardless of region.

Are infra metrics alerts conditions are also moving to NRQL?

Yes, all non-NRQL condition types will be retired in favor of NRQL conditions.

Will these be replaced automatically in NRQL during migration by NR OR should I start writing them from scratch using NRQL conditions in Terraform and delete existing general and infra metrics monitoring AWS resources currently?

Our plan right now is to have an in-UI migration tool (for migrating conditions one-at-a-time) as well as a bulk migration tool, so that you have a couple of options to migrate these through the UI. We also have, already available, an in-UI Terraform script generator for NRQL alert conditions, so that once you have used the UI to perform a migration on a condition, you can look and see the pattern in Terraform and adjust your script.

In short, if you start switching over to using NRQL conditions right now, you will save yourself some work in the future. However, we will certainly have helper tools when the time comes.

I attempted to import Infra metrics condition in NRQL declared resource and it doesn’t allow me to import and reports resource doesn’t exist however with infra metrics resource declaration I can do this. Is there some mechanism to import Infra metrics conditions in NRQL conditions without writing fresh resources in Terraform if it has be done by customer?

It sounds like you’re trying to directly copy your Infra condition configurations into NRQL conditions, which you wouldn’t be able to do; they’re different APIs and expect different formats. Let me know if I’m reading the question wrong.

If I’m reading it right, once we have migration tools in place (I mentioned these above), you will be able to do a migration, grab the Terraform script from the NRQL condition, and then not save the change, but instead update your Terraform script.

You may want to contact your account team with this question, as they may have further suggestions based on your individual configuration.

How to get the condition ID for Infra metric conditions in NewRelic UI ? This is more of general question because I have to do API call to get the same.

That is a great question! Infrastructure conditions do not display their condition ID in the UI, so you have to do a little more to find that out.

Basically you have to load the condition with the network tab from the dev tools open, filter the network calls down to “alerts:condition”, and you’ll see it (here it’s 24983174):

I hope this helps!

1 Like

but so will a destination with Opsgenie be released?

1 Like

A webhook template will be released that will allow integration with OpsGenie.

1 Like

Since notification channels are going to go away and be replaced by workflows, are all the details that were available through the webhook payload for notification channels available in Workflows? From what I have seen, at least tags/labels seem to be missing and are a big part of how we use alerts today.

The webhooks in the notification channel let me use $TARGETS to send certain tags/labels to the endpoints but that seems to be missing in the workflows.

Ideally we should be able to completely replicate the JSON Payload that was being sent by notification channel webhooks using the workflows.

2 Likes

Hi @Fidelicatessen - Can a feature request be raised for this question - "How to get the condition ID for Infra metric conditions in NewRelic UI ? "

I know I’m just missing it, but in the Logs UI the “Create Alert Condition” option still takes you to a Policy which has Notifications and there doesn’t seem to be any way to use a workflow instead. Is the promised ui tool to migrate the notifications still not released? I would think that “Create Alert Condition” would be using the workflows already. thanks, Will

Update : 07/07/22
The content above will be changed to reflect this update.

Workflows and Destinations capabilities are fully deployed, and they are the official method for configuring and receiving notifications.

Workflows and Destinations are an upgrade, and direct replacement of, the legacy alert notification channels, and the policy-to-channels relationship. We will be upgrading all accounts to use the new capabilities. We will do so in a way that will give API users time to update their automation, while trying to minimize the effort and disruption for UI-managed accounts.

  • The current APIs for Notification Channels and Channels-to-Policy will remain available through June, 2023
  • Over a number of months, we will upgrade each account by automatically creating workflows and destinations to mirror the existing policy-to-channels relationship.
  • There should be minimal disruption to alert notifications during the upgrade process
  • After the upgrade, you can review and optimize your workflow configurations. Since workflows are more flexible and efficient than the policy-to-channel relationship, you may be able to implement a more efficient model.
  • A small number of accounts have configurations that can not be automatically upgraded. Your account teams will be contacting you if are one of these accounts.
  • Accounts will be upgraded based on the notification channel types that are being used in the account.
  • We will migrate whole accounts so that the account is not left in an awkward mixed state.
  • The full schedule is being finalized now, and we will update this post with the details. We will not upgrade accounts between 10/28/22 - 1/16/23 .
  • We plan to upgrade the first cohort of accounts the week of 8/22 . This will be accounts that use ONLY the email channel type. The subsequent cohort will be accounts that ONLY use the User channel type.
  • There is not a “user” destination type in the new system. “User” channels will be upgraded to a workflow that triggers an email destination and a mobile push destination.
  • User Channels are considered to be deprecated. User Channels are a 'V1 Users" capability. After accounts are upgraded to “V2 Users” , User Channels are not be created for new users. The existing, active User Channels will continue to function, until they are upgraded to workflows that have an email destination and a mobile push destination.
2 Likes

We’ve been been seeing this appended to all our Slack notifications “Notice: We’re replacing notification channels with more powerful workflows.”.

Is it safe to assume that there are no actions required by us to avoid any disruption to our Slack alerting?

1 Like

Same question here. Also, if I may add, this warning appended to any slack alert notification is kind of annoying, if nothing really goes away soon.

@sburke1

That’s correct – we’ll be converting notification channels to destinations and workflows behind the scenes seamlessly.

this warning appended to any slack alert notification is kind of annoying, if nothing really goes away soon.

@tzafrir.kost

This is a very high priority for us, and we’ll be starting soon with accounts that only use email notification channels, and then moving on from there. Email and User channels will be first, and Slack will come after.

I hope multi location conditions going to NRQL conditions will have as simple a set up as current day multi location conditions. Perhaps NR will auto create the NRQL query and configuration that would give the equivalent of current day multi location conditions?

Will we be able to continue using webhooks for services that don’t have integrations (beyond OpsGenie, VictorOps, XMatters) if that is exactly sufficient for our needs?

Hi @kevin.laureano

You asked a couple of questions:

I hope multi location conditions going to NRQL conditions will have as simple a set up as current day multi location conditions.

We are still working on the design of this particular use-case for NRQL conditions, but our overriding goal is to make them as easy to set up as possible, ideally without even having to formulate a NRQL query.

Will we be able to continue using webhooks for services that don’t have integrations (beyond OpsGenie, VictorOps, XMatters) if that is exactly sufficient for our needs?

Generic webhook destinations are already available for … well, anything you can use a webhook for! I encourage you to try them out.

1 Like

3 posts were split to a new topic: Add tag to payload through Workflows

A post was merged into an existing topic: Plan to upgrade Alert Notification Channels to Workflows and Destinations

That’s correct – we’ll be converting notification channels to destinations and workflows behind the scenes seamlessly.

It seems there are now 2 Slack apps from New Relic. We have set up notification channels, and it is the New Relic Alerts app that posts messages in Slack if there is an incident.

But when I go to set up a destination, then I need to connect the New Relic - EU app.

Seems like it’s better to create new destinations so as to ensure the destination uses the newer Slack app, right?

@it.hq_core

Seems like it’s better to create new destinations so as to ensure the destination uses the newer Slack app, right?

Yes, that’s a great solution for your newer configurations! We recommend using the new Destinations and Workflows right away.

Please take a look at this post for more details on how we’ll be upgrading notification channels->destinations.

A post was merged into an existing topic: Plan to upgrade Alert Notification Channels to Workflows and Destinations

I updated this post today to :

  • Indicate the status of the ongoing efforts
  • Update the approach for unifying all alert conditions into a unified user experience
  • Update the EOL date for alert condition APIs for all condition types except NRQL condition types.