Comment on page
Release Notes: 2014-10-29
October, October. The leaves are turning color across the country, Halloween is approaching, and the Fall Classic is winding up, hopefully with our hometown Giants on top for the third time in just five years. It's a good month. Here at ThousandEyes, we've been hard at work and have some exciting updates to announce, particularly in the area of alerting. Check the release notes below for details.
HTTP Server tests now support setting a Desired Response code. Useful for service-targeted monitoring that doesn't return an HTTP/200 response (for example, targeting a site that requires client-side certificates), Administrators can change the desired response code from the default (2xx or 3xx responses) to a specific response code. This expected response code is used to determine the availability of an agent.
To set the desired response code, uncheck the Default (2xx or 3xx) option and set the response code, using Test Settings > Advanced Settings > HTTP Response section of the test settings interface. The desired response code must be a single response code; neither ranges nor wildcards are supported.
Note: this setting is independent of the Alert Settings option for specific response. The default alerting condition for HTTP Server tests "ERROR is ANY" will respect the Desired Status Code entered here.
This is the first of two releases covering significant changes in our alerting. Based on feedback from our customers (remember, you can make use of the "Make a Wish" at the bottom of each page in the platform to request), we have added the following new features:
Our alerting has long supported the concept of consecutive alerts before notification. In this release we've changed the behavior of this option, and moved it from the notification rule logic into the alert triggering logic. This change was made to reduce alerting noise in the system, and make alert notifications.
Now, you can set the number of locations, and the number of times they must meet this criteria before the alert is triggered in the alert settings page.
For accounts who were using the Consecutive Violations before Notification setting (which has been removed in light of this new option), we have moved the value used in notification into the alert rule triggering criteria.
We've introduced the ability to use PagerDuty to handle notification and escalation of your alerts generated by ThousandEyes. From PagerDuty's website: "PagerDuty is an alerting system for IT professionals. PagerDuty connects with a variety of systems (including monitoring tools and ticketing systems) and dispatches alerts via automated phone call, SMS and email."
Based on the reverse DNS name of layer 3 devices found in the path between agents and test targets, we now show the Interface type and Vendor (if available) of devices transited during Path Trace attempts. This is shown when hovering over a node in the Path Visualization view, for a device matching patterns determined by our development efforts.
We've added the roundsBeforeTrigger field (introduced in today's release) to the alert-rules endpoint for APIv4 and higher, as well as corrected an issue with retrieval of Saved Event data for Page Load Tests. Check our Developer Reference site for more information.
As always, send us a note if you have a question, a comment, or just want to say hi.