Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

10 Ways to Find Your Alerting Sweet Spot with New Relic

DZone's Guide to

10 Ways to Find Your Alerting Sweet Spot with New Relic

· Performance Zone
Free Resource

Download our Introduction to API Performance Testing and learn why testing your API is just as important as testing your website, and how to start today.

[This article was written by Asami Novak]

Last week New Relic announced a number of exciting updates to our Software Analytics Platform, including a new streamlined alerting system designed to help users focus on fixing problems and eliminate “alert fatigue” with incident rollups.

As part of our reimagined alerting, New Relic now groups related alerts from multiple products into an incident dashboard, allowing the people responsible to better understand the history of a performance outage and more quickly determine how to fix it. Whether you’re focused on servers, databases, Web applications, or mobile apps, you can find the information you need all in one centralized location.

To help new and existing users get up to speed with our new alerting system, we put together a handy checklist of 10 Ways to Get the Most Out of New Relic Alerts. Here are a few suggestions to get you started, but be sure to check out all 10 tips to really find your alerting sweet spot:

1. Define alert policies. Your alert policies define the conditions for when you or your team get notified of an event exceeding the thresholds you select. An alert policy can apply to one or more New Relic products. It can also contain one or more alert conditions and one or more notification channels. When designing your alert policies, consider:

  • The parts of your infrastructure that need personnel to be responsible for them
  • The individuals who are responsible for one or more parts of your infrastructure

2. Create alert conditions. Define one or more conditions to identify what triggers an alert for your selected policy. Each condition applies to a specific New Relic product. For example, you can create a single alert policy with a condition for error rate thresholds for all apps monitored by New Relic APM, a second condition with a custom metric for selected apps monitored by New Relic APM, and a third condition with a CPU percentage threshold for servers monitored by New Relic Servers.

New Relic Alerts chart

[click to enlarge]

3. Use meaningful names. Make sure each alert policy and alert condition has a concise and meaningful name. Doing so means that you can see useful information in notification messages that have limited characters, such as email subject lines, chat, etc. It can also help make it easier to skim the index in the New Relic alerting user interface.

Here are a couple alert policy naming recommendations:

  • Your group or team’s name
  • The set of resources or services the alert policy is targeting

And here are a couple alert condition recommendations:

For additional New Relic alerting tips, take a look at the free checklist, 10 Ways to Get the Most Out of New Relic Alerting.

Want more user tips on New Relic Alerts?

Find scaling and performance issues before your customers do with our Introduction to High-Capacity Load Testing guide.

Topics:
database ,open source ,performance ,monitoring ,new relic

Published at DZone with permission of Fredric Paul, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}