Alerts release notes

Alerts release notes

Thursday, November 12, 2020 - 10:00

Improved: Infrastructure Cloud Alerts Migrated to New Relic One Streaming Alerts platform.

We are upgrading our Infrastructure Cloud Alerting to use the New Relic One Streaming Alerts back end. While you will not see any changes to the front end UI or API, the back-end implementation is moving to our new streaming alerts pipeline, with streaming algorithms that are specifically tuned for polling based cloud integrations.

As a result, your Infrastructure Cloud Alerts should have a significantly improved time-to-detect (they will be faster), with increased reliability and accuracy. The latency between when your data is retrieved from the cloud provider, and when it is evaluated by the alerts engine should be less than 1 minute. However, we can not improve the time it takes for the cloud provider to return the data to us.

This rollout begins on 11/12/2020, and is targeted to complete by 11/24/2020. There will not be any visual indication when your individual accounts have been migrated. They will just start to perform better. If you experience any issues, please contact customer support or your account team.

Thursday, November 5, 2020 - 10:00

Fix:

  • NRQL Alert Condition's Offset Evaluation By is not always being applied correctly.
  • Infrastructure Condition's filters changes are not being applied when updating an existing condition.
Monday, September 28, 2020 - 08:00

Component: NRQL Conditions (Review Required)

Announcing : New Relic One Streaming Alerts

New Relic is rolling out a new, unified streaming alerts platform for New Relic One. This new streaming alerts platform will power NRQL Alert Conditions, and over the next year, all alert condition types will be consolidated into NRQL conditions.

New Relic One Streaming Alerts delivers:

  • More reliable alerting that is far less susceptible to data latency and processing lag.
  • Increased accuracy of the data points that are being evaluated
  • Reduced time-to-detect through improvements in the streaming algorithm, and configurable aggregation duration.
  • Greater control over the signals being monitored. You can specify how to evaluate signal gaps, when to consider a signal as lost, and what actions should be taken.
  • Consistent behavior and configuration of Alert conditions regardless of the telemetry type, source of the signal being monitored, or specifics of your NRQL query.
  • Increased scalability in the number of time series that an Alert Condition can monitor and in the total number of conditions that can be configured

** Action Required : Opt-in Migration **
When we roll out this new streaming platform, there is a change in behavior related to how we process aggregation time windows that do not have data. If you are monitoring for when a signal goes to “0” in order to determine if an entity stops reporting, this approach will no longer work after moving to the new platform. To maintain this functionality you must enable Loss of Signal detection on these conditions in advance of moving your account in order to prevent false negatives. You may opt-in to this new platform now. Read more about the rollout plan in the FAQ section below.

Please read the full announcement and FAQ here , and follow the links to enroll.

When is this available?

  • You can opt-in to enable New Relic Streaming Alerts on NRQL conditions right now.
  • We plan to enable the majority of accounts the week of October 5th.
  • Accounts that have NRQL Conditions that may be monitoring for loss of signal will not be enabled automatically until October 28th. These are NRQL Conditions that either use the “Less Than” operator, or have an operator and threshold of “Equals 0”.
  • During the initial roll out the week of October 5th, you will see a banner on the top of the policy page and the NRQL Conditions create/edit page that will indicate whether your account has been enabled or whether you must update your configurations and opt-in.
Friday, September 25, 2020 - 08:00

Component: Violation Tags

Update:


We are now adding entity tag data to the violations from cloud integrations.
We are now enriching violations with entity tags for the following alert conditions and entity types

  • NRQL Conditions - ONLY when adding "facet entity.guid" to your NRQL query
  • APM Conditions
  • Synthetic Conditions
  • Infrastructure : Cloud Integrations
  • Infrastructure On-Host Integrations: only for the following types:
    • HOST
    • KafkaBroker
    • KafkaTopic
    • OracleDbInstance
    • MssqlInstance
    • ElasticsearchNode
    • RabbitMqCluster
    • RabbitMqExchange
    • RabbitMqQueue
    • RabbitMqNode
    • KubernetesCluster
    • AwsEcsCluster
    • VarnishInstance
    • MemcachedInstance
    • CouchbaseBucket
    • CouchbaseNode
    • CouchbaseCluster
    • CouchbaseQueryEngine
    • PostgreSQLInstance
    • F5System
    • F5VirtualServer
    • F5PoolMember
    • F5Pool
    • F5Node
    • ConsulAgent
    • CassandraNode
    • RedisInstance
    • ApacheServer
    • NGINXServer
    • MySQLNode
    • VSphereHost
    • VSphereVm
    • VSphereResourcePool
    • VSphereDatastore
    • VSphereCluster
    • VSphereDatacenter
    • WindowsService
Friday, September 25, 2020 - 03:30

API Limit Change

We have added a pagination limit to the Violation Search REST API(v2/alerts_violations.json). These requests will return HTTP error code “HTTP-416” along with Max Limit information in the HTTP header when the the request for the page exceed the max page limit of 1,000.

With each page containing 25 violations, you can retrieve 25k violations via the API. There is a parameter to only retrieve open violations that should be used if you need to retrieve currently open violations. If for some reason, you need a stream of all violations, please talk with your account team about how to enable event export for Violation Events.

Tuesday, August 18, 2020 - 01:30

Fix:

  • We fixed a defect that was preventing Synthetics labels and tags from appearing on alert violations and in alert notifications. All tags and labels should be appearing on new violations and tags, but the violations that were already opened, and did not receive tags will be be updated.
Thursday, July 30, 2020 - 16:00

Component: Muting Rules

New

We added the ability to schedule the start date/time and the end date/time for Muting Rules. Details can be found in the documents here: http://docs.newrelic.com/docs/muting-rules

Muting Rules can have one of the following statuses:

  • Active: Muting is enabled and actively being applied.
  • Scheduled: Muting is enabled but not currently active (there's a future schedule).
  • Ended: Muting is enabled, but no longer active (there's no future schedule).
  • Inactive: Muting is disabled.

The status is indicated in the Muting Rules list. In this list, you will also see

manage_muting_rules.png

This feature can be managed by both GraphQL API for Muting Rules and in the Muting Rules UI.

In the Edit Muting Rules Screen, you will see the following at the bottom of the form:

scheduler1.png

Reminder : While a muting rule is active, the violations that are opened during that period will remain muted after the muting rule period is over.

What's next? Later in the year, we will be releasing support for recurring schedules. Watch this space.

Thursday, June 4, 2020 - 10:00

Fix:

  • Fixed issue where slow web hook test notifications returned 500 timeout error message instead of actual web hook response message
Monday, June 1, 2020 - 11:00

Component : Muting Rules

New

  • The muting rules capability was released in March, 2020 with the ability to manage rules using the NerdGraph API.
  • The UI for muting rules was released to the platform on June 1, 2020. It is accessible on New Relic One, at https://one.newrelic.com, under the "Applied Intelligence" tile.

During times of planned system disruptions, a steady stream of noisy, unnecessary alerts can be a major distraction. You need to find a balance that allows you to filter out the noise yet still maintain observability and alerting on the rest of your system. With muting rules in New Relic Alerts, you can silence notifications during planned disruptions like maintenance windows, deployments, and testing.

Muting rules are available to all New Relic customers. Read more about muting rules in our documentation, at https://docs.newrelic.com/docs/muting-rules.

Friday, November 2, 2018 - 13:45

Changes

  • Notification channels created through the API now have better validation and error messaging, preventing certain types of invalid channels from making it into customer accounts.

Pages