Probe Server Changes and Addition [IT,UK,CH,JP,CA,OR,GA]

The following probe servers will be changing IP addresses on 2017/12/05:

Manchester, England (UK) – GB is changing from
(194.187.248.8 / 2001:ac8:21::b0)
to
(185.116.237.211 / 2a06:8181:a0:bfaf::1)

Tokyo, Japan (JP) – JP is changing from
(106.186.116.86 / 2400:8900::f03c:91ff:fedb:b594)
to
(180.149.230.17 / 2406:d500:9::7a91:9b75)

Los Angeles, California (CA) – USA is changing from
(184.170.243.202 / 2607:f7a0:3:8:225:90ff:fe51:d0b0)
to
(192.161.172.202 / 2607:fcd0:106:ab01::10)

Portland, Oregon (OR) – USA is changing from
(69.163.39.244 / 2605:ea00:1:1:d267:e5ff:fee7:51c)
to
(100.42.30.2 / 2604:B480:FFF6::10)

Atlanta, Georgia (GA) – USA is changing from
(66.71.251.162 / 2607:f7a0:6:a:225:90ff:fe79:4318)
to
(107.150.22.26 / 2607:fcd0:aa80:2200::10)

We’re also adding a new server to the Europe region on 2017/12/05:
Zurich, Switzerland (CH) – CH
(5.102.145.51 / 2a06:c01:1:1102::9133:51)

The following probe is being removed on 2017/12/05:
Milan, Italy (IT) – IT
(185.93.183.12 / 2001:ac8:24::40)

Please adjust your firewalls appropriately if you whitelist so your checks do not fail because of the probe IP address changes.

An always current and updated list of all the IP addresses for our probe servers can be found in the FAQ, a text file, and via DNS query, probes.nodeping.com.

[UPDATE – 2017-12-05 10:53GMT-7] – IP changes and probe addition/removal complete.

The NodePing API and PowerShell

At NodePing we interact with our own API quite a bit from the command line.  Most of that is from bash on Linux, because that’s where we live most of our lives.  But the API works well from just about any scripting environment.  Since our documentation examples all use curl with bash syntax, it seemed like it might be a good idea to also write up some examples of using other tools.  Here, as the first installment of that effort, is a handful of examples of using PowerShell with the NodePing API.

Full disclosure: PowerShell is not an environment we spend a lot of time working with.  There are likely ways to do some of this better.  We’ve tested the example calls in this post.  Hopefully it is enough to get you started if you work with PowerShell.

Basic GET Calls

Basic calls are quite simple to make using Invoke-RestMethod.  If you have the check ID, getting a check is quite easy:

Invoke-RestMethod ‘https://api.nodeping.com/api/1/checks/201205050153W2Q4C-OJ2HSIRF?token=[token]’

This returns a JSON object, which PowerShell handles easily.

_id : 201205050153W2Q4C-0J2HSIRF
description : This is the description, if the check has one.
public : False
customer_id : 201205050153W2Q4C
queue : nyI8JSL23W
interval : 1
created : 1427513104608
pro : nodeping.com
modified : 1510332098196
parameters : @{target=https://example.com/; follow=False; threshold=5; sens=2; invert=False; verify=false}
firstdown : 0
label : Keep me
runlocations : False
enable : active
uuid : bd3eha9o-z2m5-4qg2-9k8b-jqq0kiituyxz
state : 1
status : assigned
notifications : {}
type : HTTP
acctdisable : False
suspacct : False
dep : False

Note that “parameters” is another hash.  You can refer to the fields in the check as properties of the returned object, including properties that are hashes themselves.  So, for example, this will give you the check check threshold, which is part of “parameters”.

$check = Invoke-RestMethod ‘https://api.nodeping.com/api/1/checks/201205050153W2Q4C-0J2HSIRF?token=[token]’ ;
$check.parameters.threshold;

API Authentication

PowerShell doesn’t easily support basic authentication.  Since the NodePing API supports passing the token as a parameter, the easiest approach is to include it in the query string, as I did in the example above.  In most cases I prefer to pass it in the Body, as I’ll show in examples below.  If you’re working with a script its usually easiest to set a $token variable and use that throughout your script.  If you’re just sending a URL as I did in the simple GET calls above, actually putting in the query string works fine.

If you’re using the API in scripts that make several calls to the API, you might want a more reusable way to pass the token that keeps it out of your Body.  You can do this by manually building the headers.  That requires base64 encoding the credentials and then setting that using the -Headers argument. That looks something like this:

$hash = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(("{0}:{1}" -f $token,"")))

Then set the -Header argument to @{Authorization=(“Basic {0}” -f $hash)}

Or, if you are doing this several times, you will probably want to set this to a variable you can reuse.

Some sites suggest that you create a credential object using ConvertTo-SecureString and Management.Automation.PSCredential, and pass that using the -Credential argument.  However, this won’t work with the NodePing API, since the -Credential option waits for the challenge to send the authorization header.  The API is stateless, and expects the header on each request.

Put and Post Calls

We recommend that you use JSON to set fields for our API in most environments.  However, PowerShell does not automatically handle sending the body as JSON.  For POST calls, this isn’t a big deal, and you can just POST the body as it is and Invoke-RestMethod sends the data as if it were a form.  PUT and DELETE calls don’t work that way.  For those, you have to convert to JSON, or include all of your parameters in a query string.

Creating a check looks like this:

Invoke-RestMethod 'https://api.nodeping.com/api/1/checks' -Method Post -Body @{ 
    label='test label' 
    type="HTTP"
    target="http://example.com"
    token=$token 
}

This call will return an object with the new check.  You can add any of the other fields listed in our documentation.

Updating a check is almost the same.  This can all be done on one line, but we’ll split it out here to make it easier to see.

$data = @{ label='a new label'; type="HTTP"; interval=5; token=$token } | ConvertTo-Json
Invoke-RestMethod 'https://api.nodeping.com/api/1/checks/201205050153W2Q4C-0J2HSIRF' -Method Put -Body $data

Note that since we’re updating a check, we need to include the check ID.  As with the Post call, the Put call returns the updated check object.

Working with Lists of Checks

Working with a list of checks is slightly trickier.  The call returns a JSON object with a list of checks using the ID as the key.  For PowerShell, this is a hash table of hashes.  So to list checks, you would do something like this:

Invoke-RestMethod 'https://api.nodeping.com/api/1/checks' -Body @{ token=$token } | %{ $_.PSOBJECT.Properties.value }

This is actually fairly handy, because you can fairly easily list a specific field from the response.  For example, this lists all of the targets from all of the checks on this account:

Invoke-RestMethod 'https://api.nodeping.com/api/1/checks' -Body @{ token=$token } | %{ $_.PSOBJECT.Properties.value.parameters.target }

You could do all sorts of things at this point.  For example, here’s a list of all checks that include “nodeping” somewhere in the check’s target:

Invoke-RestMethod 'https://api.nodeping.com/api/1/checks' -Method Get -Body @{ token=$token } | %{ foreach($value in $_.PSOBJECT.Properties.value){ if($value.parameters.target -like "*nodeping*"){ $value } } }

This is practical as a way to find a check with a specific target up to a few thousand checks.

Getting Results

Applying the same principles should let you do just about anything with the NodePing API.  Applying the same pattern to a results call, for example:

Invoke-RestMethod 'https://api.nodeping.com/api/1/results/201205050153W2Q4C-0J2HSIRF' -Method Get -Body @{ token=$token; limit=2; clean=1 }

Note that you’ll want to always include the “clean” parameter for results.  The unclean response takes more parsing.

The options available for results calls are documented here:
https://nodeping.com/docs-api-results.html

Profit!

That’s the basics of using PowerShell to interact with the NodePing API.  With the API you can add checks, remove checks, get your results and uptime, manage contacts and notifications, and add and manage subaccounts.  Our customers use the API both for programmed integrations, and from the command line using quick scripts like the ones I demonstrated here to make quick changes to several (or lots) of checks at once.

If you’re doing interesting things with PowerShell and the NodePing API, we’d like to hear about it!  Please email support and let us know.  That’s also a great place to ask us questions.  We’re happy to help people interact with our service.

Notification Escalations on NodePing

Most systems run smoothly most of the time.  Servers keep running.  Web sites serve pages and deliver data from backend databases.  DNS servers respond to queries with hardly any delay at all.  Email flows smoothly.

Emergency_light_with_grillIt’s that tiny percent of the time that it doesn’t work that way that causes the heartburn.  A server that has been running just fine for months suddenly hiccups.  But even when that happens, it’s usually a hiccup.  The person who is the first line of responsibility for that service needs to know right away.  They jump on it, clear the problem, and things go back to humming like normal.  You need fast and reliable monitoring to help keep these interruptions to service short.  A lot of times, the service is back to normal before most people realize there was an issue.  These incidents likely go in a report, but the rest of the team doesn’t need to get involved.  Its dealt with, duly noted, and life goes on.

Then there are the times that something goes really wrong.  The first line is working on it, but the server isn’t going to be back up in a minute or two.  Or the first line person is not available.  Maybe he’s in accounting trying to sort out his paperwork for credit card expenses for last month.  Someone else needs to know that things are down.

Sometimes these situations turn into real disasters.  The website is down.  Upper management is going to be calling, wondering who’s spilling revenue out on the server room floor.  The manager getting that call wants to know about it before the phone rings with that call.

Most monitoring systems use escalating notifications to handle these situations.  If a system is down, the first line person should be notified immediately.  If it’s down for a few minutes, the people who back him up need to be brought in.  If it’s down longer than that, systems management will want to get a heads up.

NodePing uses the notification delay feature to provide notification escalations.  A delay can be set on each notification contact for each check.  The NodePing notification delay feature notes that a check set with a delayed notification has gone down.  After the delay interval has been reached, if the check is still “down” we send the notification to that contact.

Set up the first line systems with no delay, so they’ll get notified when the system goes down right away.  If the service hasn’t recovered in a few minutes, send a notification to the systems group using a contact group.  Then, if the service hasn’t recovered in 10 minutes (or whatever the tolerance for the service being down is for this service in your organization), notify the systems management.

The notification delay feature can be used for other things besides notifications.  Sometimes services have a higher tolerance for transient interruptions.  You can use the delay to mean “if this service is down shorter than 3 minutes, I don’t need to be notified.”  This is useful, for example, for services in remote locations where Internet connectivity can have brief interruptions.  But our most common request for using the delays are for notification escalations.

 

WHOIS Monitoring

Need an alert when your domain is about to expire?

Want to make sure your domain admin contact hasn’t been tampered with?

Need a notification when your configured name servers get changed?

Maybe you’re running your own TLD (you lucky dog, you) and need to verify your WHOIS servers are up and responding properly?

NodePing’s new WHOIS monitoring has got you covered. Our new check will verify the presence or absence in the WHOIS response for any text you specify, helping you ensure your domain information hasn’t been hacked or altered without you knowing.  We’ll also send alerts before the domain expires. You choose how many days ahead of expiration you want to receive the notifications and how you want to be notified (email, SMS, Voice call, Pushover, Slack, etc)

You can optionally configure a specific WHOIS server to query via IPv4 or IPv6.

WHOIS checks are available to all NodePing accounts starting today. If you don’t have an account yet, sign up for your free, 15-day trial today and let NodePing keep an eye on your WHOIS info for you.

Support for Multiple Public Status Pages

Our public status report is a critical part of keeping your customers informed of your site and service status—which after all is one of the points of monitoring. Our status pages are customizable to your company, and support a custom domain so you can display your status at status.yourdomain.com, or whatever is most applicable to your business.

We have had a public status page as one of our key features for some time.  Now, we’re adding support for multiple status pages on one account. For instance, NodePing has a status report page for our websites at status.nodeping.com, and one specifically for our probe servers at probestatus.nodeping.com.  Business and Provider accounts can optionally set up an SSL cert for their status pages (contact support for info how).

To create a new status report, just log into your account , and go to the “Account Settings” tab, then the “Reporting” subtab. Click “Add new status report” and add as many checks as you want to your new status report.  

We hope you will find this feature just as useful as we do.  We also have several more enhancements for public status pages coming soon.  Let us know what you think at support@nodeping.com, by posting comments here, or by using our Contact Page.

Probe server change [SG]

The following probe server will be changing IP addresses on 2017/10/18:

Singapore (SG) – SG is changing from (103.25.202.111 / 2400:c980:0:2:48d:a4ff:fe01:1262) to (103.16.16.30 / 2001:df0:24f:214::10)

Please adjust your firewalls appropriately if you whitelist so your checks do not fail because of the probe IP address change.

An always current and updated list of all the IP addresses for our probe servers can be found in the FAQ

[UPDATE – 2017-10-18 11:45GMT-6] – IP change complete.

Probe Server Change and Addition [FR,MX]

The following probe server will be changing IP addresses on 2017/09/19:

Paris, France (FR) – FR is changing from (37.59.86.248 / 2001:41d0:a:7a50:5:5:9ab9:a412) to (195.154.167.97 / 2001:bc8:2327:110::10)

We’re also adding a new probe to the Latin America region on 2017/09/19:
Mexico City, Mexico (MX) – MX (138.204.171.109)

Please adjust your firewalls appropriately if you whitelist so your checks do not fail because of the probe IP address changes.

An always current and updated list of all the IP addresses for our probe servers can be found in the FAQ

[Update 2017-09-18] – the new probe planned for Mexico will not be added as planned.

[UPDATE – 2017-09-19 10:41GMT-6] – IP change complete.