You need to understand how your websites and applications are operating, right now, across the globe. Synthetics is a suite of automated, scriptable tools to monitor your websites, critical business transactions, and API endpoints. Ping monitors check that your site is up, while scripted browsers simulate real end-user activity. API tests let you ensure your backend is up too.
To help you be as successful as possible with Synthetics, we’ve put together a list of best practices that will keep you organized and help you take action.
When you have reviewed these best practices, show off your new found skills. Take the Synthetics Best Practices Quiz to earn your badge .
Set up a naming convention
You could easily have a number of monitors potentially targeting the same service, like a ping check running every minute to act as an availability monitor, or a less frequent Scripted Browser monitor to test a full user workflow. So being able to find the right monitor is important. Setting up a naming convention will help to identify the right monitors at a glance. A good naming convention could look something like this:
Type - Service - Env, for example,
Ping - Webstore - Production
Set Appropriate Permissions
New Relics base & add on roles help to restrict edit rights to a lot of features. That said, Synthetics Scripts are likely to hold personal or private information, such as login credentials. Synthetics Permissions allows you to add more fine grained permissions to what each user can see. Applying a set of rules to groups allows you to separate access to only those who should have access.
Monitor Management via the API
If you are managing a large number of monitors, it may make more sense to add, remove, or update those monitors programmatically. The API can be used for adding/editing all types of monitors, including ping, simple browser, scripted browser, and API test monitors. You can also use the API to update your scripts and see available locations.
Add Secure Credentials to your scripts
Scripted Browser monitors are used to simulate user workflows on your sites, this often involves logging in. Synthetics Secure Credentials offer you a secure way to include username/password combinations in your script, heavily encrypted rather than stored in plain text.
Understanding your Data
Interpret your Synthetics failures
Synthetics monitors can fail for a number of reasons, and will return a different error code for each type of failure. These error code are essential to understanding why your monitor failed, so familiarity with them makes diagnosing the problem much faster.
Interpreting your scripts
Scripts can go anywhere from 10 - 1000 lines, and beyond. Troubleshooting scripted monitor failures may involve having a good understanding of your scripts. We recommend adding comments throughout your script, so that when you read it back you have a good idea of what each function may be doing. In addition, adding log messages is hugely helpful when inspecting failures. Looking at the script log will show you how far your script got before failing, helping you to identify the problem areas.
Taking action on your data
Insights Queries for Synthetics
There are 3 event types sent to Insights from Synthetics.
SyntheticPrivateMinion. Each comes with a number of helpful attributes. Try out the queries below to get a deeper understanding of your Synthetics Requests.
Non 200 requests, faceted by domain.
SELECT count(*) FROM SyntheticRequest SINCE yesterday where responseCode !=200 FACET domain limit 100
Synthetics Failures faceted by location.
SELECT count(*) FROM SyntheticCheck WHERE result != 'SUCCESS' SINCE THIS WEEK FACET locationLabel LIMIT 100
Synthetics Failures faceted by individual monitor
SELECT count(*) FROM SyntheticCheck WHERE result != 'SUCCESS' SINCE this week FACET monitorName LIMIT 100 timeseries auto
Average durations per network type (DNS/Connect/SSL/etc…) faceted by location
SELECT average(durationDNS) as 'DNS', average(durationSSL) as 'SSL', average(durationConnect) as 'Connect' , average(durationSend) as 'Send', average(durationWait) as 'Wait', average(durationBlocked) as 'Blocked', average(durationReceive) as 'Receive', average(duration) as 'Duration' from SyntheticRequest since yesterday facet locationLabel
By default, Synthetics Alerts will notify you of a monitor failure, and again when that monitor recovers. If you’d like alternate alert configurations, such as getting alerts for the number of failing locations over time. Or getting alerts only when multiple monitors fail in a set period of time, you can use the power of NRQL alerts.
NRQL will allow you to set up alerts on any returned numeric value. The level-up post below will help you get the best from NRQL alerts.
Ready to learn more?
Looking for more Synthetics best practices and tips? Check out the Synthetics Level Up space.