Legacy alerting reached end of life on May 15, 2018. Limited availability reporting is available from the New Relic APM UI. However, you will no longer receive alert notifications from the legacy alerting system. You must make the transition to New Relic Alerts in order to continue using alerting features.
Availability monitoring sometimes is referred to as the pinger or pinging service, and it measures your site's uptime. The primary chart in New Relic's Availability report compares throughput (calls per minute) and errors per minute for the selected time period. This information is useful to correlate with overall application performance.
The Availability report uses the availability monitor for New Relic's legacy alerting system. The report is not used with New Relic Alerts, New Relic Synthetics, or the host not reporting feature in New Relic Infrastructure.
View the Availability report
To view the Availability report for your app:
- Go to rpm.newrelic.com/apm > (select an app) > Reports > Availability.
- Use any of the available options to analyze report details.
The default report shows availability details for the past seven days for failures of at least thirty seconds. The report includes a chart and percentages of your site's downtime for the selected time period. The availability percentages represent the amount of time over a given period in which the pinger did not detect any errors. This "available" time includes periods when the ping URL was disabled or when downtime events were flagged as maintenance events.
Examine report details
Use any of New Relic's standard user interface functions to drill down into detailed information. In addition:
|If you want to...||Do this|
|View related information for the selected time period||Select the links to show the selected app's SLA report, APM Overview page, or link to the target URL.|
|View or change the availability monitoring (pinger) settings||Select the Change the ping URL link.|
|Change the time period for chart details||Select any available link for the past seven days, month to date, previous month, or past three months.|
|Change the time duration for events shown||Select an option from the Failures of at least dropdown.|
|View downtime event details||Select the Downtime duration link.|
|Flag downtime as a maintenance event||Select the Downtime duration link, and then select Flag as maintenance.|
|Show (or hide) other event details||
Select or clear the Show unverified events checkbox.
Unverified events do not trigger alerts or affect SLA reports.
Analyze your data
New Relic APM includes several reports in the user interface. To gather, analyze, and visualize data about your software in other formats, use New Relic Insights.
Use enhanced functionality with Synthetics
The limited, legacy alerting functionality has been improved upon and superseded by the enhanced functionality and alerting capabilities available with New Relic Synthetics. Synthetics provides in-depth scriptable testing, including real browser tests and testing of API endpoints. Synthetics also includes free ping monitoring, which allows you to monitor your website from geographical locations around the world. This is why New Relic Alerts does not refer to an "availability monitoring" feature.
By switching to New Relic Alerts, you can also use the host not reporting feature in New Relic Infrastructure. This allows you to take advantage of enhanced monitoring options and be notified when New Relic has stopped receiving data from your hosts.
Legacy availability monitoring
Legacy alerting reached end of life on May 15, 2018. You will no longer receive alert notifications from the legacy alerting system. You must make the transition to New Relic Alerts in order to continue using alerting features.
New Relic's legacy alerting system included a basic "availability monitoring" feature. It simply verified application availability by making regular requests to apps and recording errors. When it received an error accessing your web app, the legacy alerting system sent a notification, sometimes referred to as a "downtime alert."
This functionality no longer is available. To access information about your legacy availability monitoring settings, use the Availability report in New Relic APM's UI.
If you enabled downtime alerts in your application's legacy alert policies, New Relic will monitor your applications for ongoing availability by using an external pinger service. However, some reports that include availability data (for example, the APM SLA report) may not be available for all products.
- Monitoring only one app URL
Downtime alerting supports only one URL. If you need to monitor many URLs, use New Relic Synthetics.
User-Agent headersent with the ping request contains the value
NewRelicPinger/1.0 (your_account_id). You can specify webpage targets with HTTP and HTTPS URLs. The pinger uses HEAD requests.
If a request fails, or if you are using request substrings, the pinger will use GET requests instead. The URLs may include query strings.
- Pinger checks and response substrings
With legacy availability monitoring, New Relic checks your site approximately every twenty seconds. When New Relic detects a failure, the rate increases to once every ten seconds until the site recovers. This provides information about when your site recovered, as well as more accurate estimates for a rate of failure when there is a partial failure.
To view performance, use the Availability report in the New Relic APM UI. As of May 15, 2018, the ability to disable and enable pinging with REST API calls for legacy alerting is no longer available.
A ping is not the same as a Linux "ping" command, which checks to see if the interface to your system is live. New Relic's availability monitoring is a more extensive test; it verifies your web server is functioning correctly by accessing a webpage on your site.
If you provided substring text, New Relic checks approximately the first 57KB of data returned, including the HTTP headers. If the structure of your page varies, the size of the data preceding the substring may exceed 57KB. When this occurs, your substring will not be found, and New Relic will record an error.
If the pinger does not find the exact substring text, it responds with the error message:
Content not found.The text in parentheses next to the URL indicates the text string the pinger expected to see.
- Evaluating downtime
To check whether a downtime event is due to intermittent failure:
- Check your ISP or service provider's network status to see if there are any problems.
- Look for an increase in app server queue time or capacity (found in the Reports section available for certain platforms and product levels only).
- If you have enabled page load timing with New Relic Browser, look at the End user throughput chart for drops in end user page views during downtime. The page load timing instrumentation and availability monitoring are independent of one another. During a prolonged outage you should expect to see a noticeable drop in page load timing throughput.
- Try a secondary pinger service or a script using cURL to see if you can detect the same issue independently. Be aware that other pinging services will not be hitting your site as frequently.
- False alarms
New Relic has several pinger hosts distributed around the globe. If a downtime event does occur, you can see the region where it was reported from and the number of failed checks from each region.
You may experience frequent false alarms if your app server has a poor network connection to New Relic's pingers. If your firewall restricts access to your monitoring URL, whitelist the pinger URLs.
- Response codes and status errors
New Relic's pinger requests differ substantially from what most web browsers typically send. In nearly all cases this will not make a difference.
However, for some customers the request is rejected. This may be why you receive notification that your site is down with a status error (
404, etc.) but you are still able to open the URL. In some cases this might be from a more restricted
Acceptsheader; in other cases it might be the user agent.
From a command line, try this cURL request to see if you can reproduce the failure:
curl -v \ -H "Cache-Control: no-cache, max-age=0" \ -H "User-Agent: NewRelicPinger/1.0 (1)" \ -H "X-Newrelic-Ignore: true" \ http://www.somehost.com> /dev/null
New Relic's code emulates this request closely, but differences in setup mean that this command will sometimes succeed even if the pinger request is failing.
New Relic pingers will receive no response when there are timeouts or DNS resolution issues. The
Response Contentwill capture the next successful response in an attempt to provide useful information. This is why you may see
200response codes in downtime events.