1. Standardize application-naming conventions
Most New Relic agents provide a default application name, such as "My Application" or "PHP Application," if you don't specify one in your New Relic configuration file. You don't want to end up with 20 identically named applications, so always be sure to select a descriptive identifier for your apps as soon as you deploy them.
To keep things consistent and easy to navigate, New Relic recommends standardizing your application naming (for example, all apps in Staging append [Staging] or the like at the end of their names). Ideally, you want your new Java applications to be named automatically to reduce the chances of typographical errors and misnaming.
For Java applications, automatic application naming can come from the following sources:
- Request attribute
- Servlet init parameter
- Filter init parameter
- Web app context parameter
- Web app context name (display name)
- Web app context path
Choose the method that fits best your needs and follow these steps.
For non-Java applications, there are no automatic naming methods, so refer to the documentation for your APM agent.
2. Create alerts
When key performance indicators spike or drop, individuals and teams in your organization need to be notified. Alerting in New Relic provides a set of tools, including dynamic baselines that allow you to detect problems before they impact your end users.
Alert policies can be set up in two primary ways:
Static threshold alerts are great when you already know the nature of an application and its normal behaviors aren't likely to change anytime soon. Apdex score, response time, error rate, and throughput are some of the static thresholds on which you can create alert policies.
Dynamic baseline alerts make it easy to determine and set dynamic alert thresholds for applications with varying seasonal patterns and growth trends (which make it difficult to set thresholds that define normal behavior). These alerts use baselines modeled from your application’s historical metric data.
Each alert policy can contain as many conditions as you need, and each alert condition includes three components:
Type of condition (metric, external service, and so on)
Entities that the policy targets (for example, apps monitored by New Relic APM or New Relic Browser, hosts monitored by New Relic Infrastructure, and so on)
Thresholds that escalate into alerting situations with increasing severity
Once you have your alerting set up, you then want to make sure you're taking advantage of all viable notification channels. After all, what good are alerts if no one knows about them?
You can manage alerts by creating specific user groups and leveraging New Relic's integrated alert channels, including Slack, PagerDuty, webhooks, and email. Be sure to evaluate alert policies regularly to ensure that they are always valid.
3. Track deployments
When development teams push new code out as frequently as possible, it can be hard to measure each deployment’s impact on performance. You can use deployment reports to stay in tune with how these changes affect your application.
These reports list recent deployments and their impact on end users and app servers' Apdex scores, response times, throughput, and errors. You can also view and drill down into the details to catch errors related to recent deployments, or file tickets to share details with your team.
To access deployment reports:
From the New Relic menu bar, select APM > (selected app) > Events > Deployments.
To view performance after a deployment, select the timestamp for the requested deployment.