New Relic
New Relic has championed the idea of a SaaS based APM and is one of the industry leaders in application performance management. New Relic also provides APM for mobile apps, advanced browser performance monitoring and most recently added infrastructure monitoring.
- Languages: .NET, Java, Ruby, Phython, Nodejs, Go, PHP
- SaaS only
- Application Monitoring provides performance trends at-a-glance
- Browser Monitoring gives insights from the user perspective
- Track performance of individual SQL statements
- Low-impact production thread profiler
- Code-level diagnostics
- Cross-Application Tracing
- Monitor critical business transactions independent of application
Cost: $75-600 per month per server, cheaper annually
Monitoring Guide
Application Overview
Distributed tracing
When you can see software requests end-to-end, troubleshooting is easier and faster. Distributed tracing does this by showing you the path a request follows as it travels through a distributed system.
As requests travel between services, each segment is recorded as a span, which represents time spent in services or resources of those services. All the spans of a request are combined into a single distributed trace to give you a picture of an entire request.
Once your traces are captured in New Relic, you can use our powerful tools to analyze them:
- Filter results: You can filter charts using many data points, so you can analyze trace data in different ways.
- Detect anomalous spans: Spans that are slow in comparison to typical behavior are marked as anomalous, with charts comparing them to typical instances.
- Customize queries and dashboards: You can create custom queries of your trace data and create custom data dashboards.
- See data across accounts: In New Relic One, see a global view of traces from across all your accounts and applications.
- Query traces programmatically: Query distributed trace data by using GraphQL in our NerdGraph API explorer.
Wall-clock time
Wall-clock time is the amount of time recorded by the clock. New Relic uses wall-clock time for all the transactions and then sums that value across all of the transactions.
The host can execute requests in parallel, so you may see percentages over 100. For example, 100% would indicate that the execution time across all selected transactions is equal to the time expended when recording wall-clock time.
View transactions
To view information about your app’s transaction requests:
To quickly see the details of one of your app’s top five transactions: Go to apm > (select an app) > Monitoring > Overview, then select a Transaction link from the APM Overview page.
If a chart’s background is light red, this indicates a time period when an alert condition’s Critical threshold has been violated. To view the incident details in New Relic Alerts, click the chart.
apm > (select an app) > Monitoring > Transactions: Use the Transactions page to examine the top transactions that may indicate areas to fine-tune performance, or drill down deeper into individual transactions and trace details. Here is an example of an app with an alert violation in progress.
Use drill-down functions
Use any of New Relic’s standard user interface functions to drill down into detailed information. The Transactions page has additional drill-down functions.
If the Type dropdown appears above list of transactions, you can select your choice of transaction type. The available types depend on what transactions your application uses
The Sort dropdown above the transaction list allows you to review transactions according to different measurements. This helps you identify good candidates for performance tuning or fixing errors.
You can sort by:
| Sort option | Comments |
|---|---|
| Most time consuming (default) | Highest percentage of the app’s total time used.This measures which transactions consumed the most time in total. This is calculated by multiplying the number of times the transaction is called by the time the transaction took to complete. A transaction could be short, but if it is frequently called, it would appear at the top of this ranking. |
| Slowest average response time | Slowest individual transactions for the time period as averaged.This measures the slowest types of transaction. A transaction could be called only a few times, but if it is one of the longest transactions to finish, it would appear at the top of this ranking. |
| Apdex most dissatisfying | Transactions with the highest percentages of user dissatisfaction levels for the response time of your web apps and services (Apdex).The dissatisfaction level is the difference between a perfect Apdex score (1.0) and your app’s apdex_t (“tolerating”) score, based on your Apdex settings. Transactions that have the highest (worst) percentages appear at the top of this ranking. |
| Highest throughput | This measures the amount of throughput, in operation requests per minute or rpm. (For web throughput, requests per minute is sometimes called pages per minute or ppm.) Transactions that have the highest number of requests per minute appear at the top of this ranking. |
Depending on the transaction type you choose, different sort options may be available.
To quickly view key pieces of information about the transaction, mouse over its name on the list.
To view detailed information, select a transaction from the list, then select App performance or Historical performance. You can also view transaction traces.
The Transaction page’s Top 5 transactions chart and a selected transaction’s App performance window include options to view data as a:
- Chart
- Histogram
- Percentile
Show all transactions
To view all available transactions as a table, select the Show all transactions table link. From here, use any of the available options:
- To change the sort order, select any column header.
- To export the data to a file with comma-separated values, select Export as CSV.
- To return to the previous chart view, select Back to top transactions.
CSV tables for ending now time periods are calculated at run time. They may show slightly higher values than what appears in the APM table.
For each transaction, the Show all transactions table includes these measurements:
| Measurement | Definition |
|---|---|
| Apdex | The average Apdex score for all transactions that occurred in the selected time range.Apdex scores marked with an * asterisk indicate the agent collected fewer than 100 samples for that transaction name. Data for these transactions may be less accurate than data for transactions with higher throughput. |
| Count | The total number of all transactions that occurred in the selected time range. |
| Avg (ms) | The average time taken by all transactions in the selected time range. |
| SD (ms) | The standard deviation of all timing measurements for all transactions in the selected time range. |
| Min (ms) | The time taken by the fastest transaction in the selected time range. |
| Max (ms) | The time taken by the slowest transaction in the selected time range. |
| Total (ms) | The total amount of time taken by all transactions that occurred in the selected time range. |
| Total (% time) | The total amount of time for all transactions of that type, expressed as a percentage of the total amount of time taken by all transactions. |
| Dissat (%) | The percentage of the transactions that did not have satisfied Apdex scores.If you view transactions as a table, the All transactions row always contributes 100% of the app’s total dissatisfaction, even if no responses are dissatisfying (100% of zero is zero). In this situation, 100% does not mean that all of your transactions are dissatisfying. The sum of all the other values in the Dissat (%) column is 100%. |
New Relic: Database
apm > (select an app) > Monitoring > Databases: Use this page to view and sort detailed information about database performance and slow queries (if applicable).
The All databases overview shows:
- Top five database operations by wall-clock time
- Database response time
- Database throughput (operation requests per minute or rpm)
The details for individual operations show:
- Query time
- Throughput
- Time consumption by caller
Pages: 1 2