Application monitoring tips you need to know
It's one thing to know how to use APM, but it's another thing to know how to use New Relic's application performance monitoring software well. Here are some best practices designed to help you become an pro—and a key asset to your team!
Want a step-by-step tutorial on solving performance issues? Check out our my app is slow tutorial.
To get a high-level overview of all your applications and services, use our entity explorer.
See Reliablity engineering diagnostics for a guide on how to find common performance issues using APM and other New Relic capabilities.
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, be sure to select a descriptive identifier for your apps as soon 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.
When several different applications use the same account, and each application spans multiple environments (for example, development, test, pre-production, production), it can be hard to find a specific application in your overview dashboard. That's why we recommend adding tags to your apps so that you can segment them into logical groups.
The two most common tags that mature APM customers use are application name and environment. So, for example, if you wanted to view the billing application in Test, you could simply filter by "billing app" (name tag) and "test" (environment tag).
In the APM agent configuration settings files, use the
labels field to add tags to your data. For example, see this description of the Python labels setting.
APM is designed so that apps can roll up into an unlimited number of meaningful tag categories.
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 anomalies 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, throughput are some of the static thresholds you can create alert policies on.
- Dynamic anomaly 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 anomalies 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, APM apps, browser monitoring apps, or hosts)
- 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 by leveraging New Relic's integrated alert channels, including Slack, PagerDuty, webhooks, and email. Be sure to evaluate alert policies on a regular basis to ensure that they are always valid.
See the detailed documentation:
- To set up dynamic anomaly alerts and choose an application, follow standard procedures. You will see a preview of the metric with the predicted anomaly You can select a metric for that application and see the corresponding anomaly. Then, using the threshold sliders, you can set how closely you want your threshold to follow the anomalyprediction.
- To set up static threshold alerts for your Apdex settings, follow standard procedures.
- To set up your alert notification channels, follow standard procedures.
Depending on the nature of your application, some transactions may be more important to you than others. New Relic's key transactions feature is designed to help you closely monitor what you consider to be your app's most business-critical transactions, whether that's end-user or app response time, call counts, error rates, or something else. You can also set alert threshold levels for notifications when your key transactions are performing poorly.
- Go to one.newrelic.com > All capabilities > Key transactions, and then select Add more. Then select the app and web transaction or, from the selected transaction, select Track as key transaction.
- Type a name for the key transaction, and select Track key transaction.
- Optional: If the agent for the selected app supports custom alerting, use the default values that New Relic automatically fills, or select Edit key alert transaction policy to set the Apdex and alert threshold values.
- To view the key transactions dashboard details, select View new key transaction.
When development teams are pushing new code out as frequently as possible, it can be hard to measure the impact that each deployment is having on performance. One way to stay in tune with how these changes are affecting your application is with deployment reports.
These reports list recent deployments and their impact on end-users and app servers' Apdex scores, along with response times, throughput, and errors. You can also view and drill down into the details to catch errors related to recent deployments, or file a ticket and share details with your team.
- From the New Relic menu bar, select APM & services > (select an app) > Events > Deployments.
- To view performance after a deployment, go to the selected app's Overview dashboard in the Recent events section.
A blue vertical bar on a chart indicates a deployment. To view summary information about the deployment, point to the blue bar.
From SLA, deployment, and capacity to scalability, host usage reports, and more, APM offers a variety of downloadable reporting tools surfacing historical trends—all great ways to report to senior executive teams or customers. Take a look at the full list of reports and use them to your advantage.
- From the APM menu bar, select Applications > (select an app) > Reports.
- Select the report you'd like to see.
- If you want to save or export a report to share, select Download this report as .csv, which will create a report with comma-separated values.
Use New Relic service maps, a feature included in APM, to understand how apps and services in your architecture connect and talk to each other. Service maps are visual, customizable representations of your application architecture. Maps automatically show you your app's connections and dependencies, including databases and external services. Health indicators and performance metrics show you the current operational status for every part of your architecture.
How to do it
- Go to one.newrelic.com > All capabilities > More > Service maps.
- To get started, see Introduction to service maps.
With New Relic’s SaaS platform, getting new features is as easy as updating your agent. Most likely your organization already has a set of scripts for deploying application upgrades into your environment. In a similar fashion, you can also automate your New Relic agent deployment to ensure that your systems are up to date. Ansible, Chef, and Puppet are great examples of deployment frameworks that make life easier by allowing you to automate your entire deployment and management process.
Regularly review which version of the agent you're using so that you know when an update is needed. If the latest agent release contains a needed fix or added functionality, download it.
To deploy the agent automatically (preferred as a method to avoid errors):
Use existing deployment scripts, provided they can be adapted to handle the deployment.
Create and maintain a script that specifically deploys and configures the New Relic agent. Ideally, the script would pull the agent files from a repository where the files are versioned (for rollback purposes).
Once the script has been created, shut down the application (unless script handles this).
Run the deployment script.
Start the application (unless script handles this).
If problems arise, run the script to roll back to the previous version.
To deploy the agent manually:
- Back up the current agent directory.
- Deploy the updated agent into the existing agent directory.
- Modify configuration files by comparing new files with existing files. In particular, make sure things like and custom extensions are copied over to the new configuration.
- Restart the application.
- If problems arise, restore the old agent using the backup and restart.
How you manage your users depends on which user model your users are on: