Starlink Monitoring with NodePing

2025/07/15 by Leave a comment

With a Starlink antenna on hand, we thought it would be a fun experiment to see what the results would be of monitoring a Starlink connection from a residential connection with our AGENT check type. The AGENT check can be used to monitor any outbound connectivity from your location on any network. Starlink was an interesting case study for us to try our AGENT monitoring from. Some information we wanted to see was:

  1. ICMP reliability
  2. Packet loss out to the internet
  3. HTTP connections
  4. DNS queries

We targeted a handful of popular services, including our own blog page as well as a website that is hosted in Seattle. We targeted these DNS providers:

  • Google DNS
  • Quad9
  • Cloudflare
  • OpenDNS

For popular websites, we targeted:

  • Facebook
  • google.com
  • Our blog (WordPress)
  • An employee blog site in Seattle

These were all tested over IPv4 and IPv6, each website had its DNS record monitored over the different DNS providers, as well as HTTP monitoring directly to an IP address for that site to rule out DNS issues.

Hardware

To connect to Starlink’s network, the standard antenna was used. The computer was a Raspberry Pi 4 running Raspberry Pi OS.

ICMP Monitoring

The route that was taken from my current location was through Starlink’s network and then back down through Seattle and then out to the rest of the Internet. Below is an MTR from the home network to blog.nodeping.com on WordPress:

Start: 2025-06-05T17:10:24+0100
HOST: raspberrypi     Loss%   Snt Drop   Rcv   Last  Best   Avg  Wrst  Jttr Javg Jmax Jint
  1.|-- 192.168.1.1     90.0%    10    9     1    1.0   1.0   1.0   1.0   0.0  0.0  0.0  0.0
  2.|-- 100.64.0.1      30.0%    10    3     7   17.6  17.6  65.5 298.4   5.0 81.7 275. 516.6
  3.|-- 172.16.252.130  40.0%    10    4     6   19.1  19.1  49.6 154.4   5.3 44.0 130. 239.1
  4.|-- 206.224.65.146  40.0%    10    4     6  1192. 654.2 1011. 1192.  55.2 106. 405. 537.7
  5.|-- 206.224.64.37   30.0%    10    3     7   20.5  20.5  30.4  43.6   9.9 10.1 17.5 59.4
  6.|-- 206.81.81.70    40.0%    10    4     6   26.2  19.9  30.2  39.6  13.4  6.0 18.1 32.3
  7.|-- 192.0.78.12     50.0%    10    5     5   27.2  25.0  27.1  29.9   0.6  1.6  4.9  7.2

Each hop is as follows:

  1. Router
  2. SpaceX CGNAT
  3. SpaceX internal IP
  4. SpaceX public IP
  5. SpaceX public IP
  6. Seattle Internet Exchange
  7. automattic

We assigned both PING and MTR checks to our NodePing AGENT. One to have a simple ping to check uptime, and the MTR to monitor packet loss and other networking statistics.

PING Monitors

After a month of monitoring, the results showed that my average ping uptime was roughly around 99.6% for IPv6 and 99.8% for IPv4

The majority of incidents were 1 minute timeouts. Only a few longer outages occurred. A few outages are noteworthy:

  1. A 10 minute outage while the antenna was moved out of the way and obstructed
  2. A 36 minute outage that was consistent with full network downtime shown by the other results
  3. A 7 minute outage that also consistently happened with other checks

The average day showed about 10-20 events when there was typically a 1 minute timeout. This is roughly a 7-day sample of pinging Google’s site:

Generally, response times were very good and in the 20-30ms range with some blips up to about 100ms.

MTR Monitors

Our MTR monitoring paints a somewhat similar picture. The average uptime was about 99.7% to 99.9%. This is running an MTR count of 10 and expecting packet loss to be below 5%. Some observations:

  1. A time when Google IPv6 had high packet loss for 9 minutes, at the same time OpenDNS was unreachable for 7 minutes
  2. Moving the antenna was detected just like with the PING checks. This resulted in roughly 10% to 50% packet loss incidents
  3. Like PING, there were quite a few times running an MTR would show packet loss or an unreachable target for a minute
  4. I noticed most of my checks had packet loss more often in the evenings
  5. At one point Google and Facebook had high packet loss or were unreachable for about 40 minutes

Below are some results from the MTR check to Facebook over IPv6:

I noticed that inter arrival jitter was high. The average seemed to be roughly in the 30s, however, it would also frequently go up into the upper 100s. This could potentially impact RTP streams.

Other Monitoring

DNS Monitors

During my testing, DNS checks were rather boring. The overall uptime was 99.9% with minimal timeouts or other issues. One day OpenDNS, Cloudflare, and Google DNS had 3 to 5 minutes of timeouts, but at different times of the day. Some days Quad9 ended up doing worse than others, but overall all the DNS services had that 99.9% uptime. At some times some services would timeout at the same time, but not others. Average responses were around 30-60ms. There were some incidents that happened, but I will expound on those in the next section.

Earlier it was noted that the antenna was moved and obstructed for a little while. All the checks were impacted by this obstruction. However, DNS was not.

HTTP Monitors

Last of all, HTTP monitors. The average uptime was 99.8%. While monitoring HTTP, I was able to use information from my DNS checks to get additional insights into the failures. While an HTTP check will mention it cannot resolve a hostname, the DNS checks provided additional detail into DNS failures and helped me to identify the cause of failed HTTP connections. For example, one day there was about a 5 minute window of failures when some hosts were unable to resolve hostname and others were getting ENETUNREACH errors. My default DNS resolver was Google DNS. At that time, I noticed that the other DNS services were not failing, only Google DNS. With that information, I was able to determine that I was unable to reach my websites because of the DNS provider I was using.

For some of my HTTP checks, I set some of the targets to be the IP address only so DNS was not resolved. At times when failures happened, I could see if the DNS and no DNS checks were failing. If they were, the site was unreachable. If only the DNS checks were failing, then the issue was likely with DNS. There was one outage that was 36 minutes long where my DNS and no DNS checks were failing.

The TLS EACCES errors show that a secure TLS connection could not be established. This often happens when there is a networking issue, since I know that the TLS certificates on the end are correct. This is especially obvious here since the TLS connection failures are happening to multiple services.

Conclusion

After a month of monitoring, it is clear to see that there is some network instability with Starlink. The service could not quite reach three 9s outbound. This could be perfectly sufficient for some, however, mission critical services will likely have frequent reachability issues.

Using AGENTs to monitor my Starlink connection provided me with some interesting results. While using our public probes, there were no incidents with the services I monitored. Using an AGENT to monitor outbound connections to services provided useful data to determine connectivity issues to commonly used services. This is useful when you need to monitor for incidents from a Starlink or any other remote connection and respond to them.

If you have any remote POPs that you need to monitor, try out our NodePing AGENTs today. We offer a free, no-obligation 15-day trial. The best way to see if NodePing meets your needs is to try it out.

Filed under AGENT, DNS, HTTP, MTR, uptime Tagged with ,

Monitoring the Server Room with NodePing – Part 1

2023/08/08 by Leave a comment

Monitoring services inside the server room is pretty easy with NodePing. I’m going to show you how I can keep an eye on my server room and its services using NodePing PUSH and AGENT checks. In this scenario, the room only contains network devices, so I chose to stand up a Raspberry Pi. It will also let me add temperature and humidity sensors in addition to monitoring stuff inside the firewall.

NodePing offers two different check types to allow me to do on-premise system, sensor, and network monitoring: PUSH and AGENT checks.

PUSH checks allow me to send heartbeats from any server to NodePing. I can also use the metric tracking to do things like monitor load, disk space, memory usage, and more. Basically any numeric value I can read or generate on a box can be submitted, tracked, and trigger notifications.

NodePing AGENT checks allow me to configure NodePing probe functionality, installed and maintained by me and available only to my NodePing account. I can use my AGENTs to run other NodePing checks from anywhere, even inside my private network, without needing to open up any firewall ports.

The PUSH and AGENT checks can run on a wide variety of hardware. In this blog post, I would like to show you how I configure NodePing on-premise monitoring tools to work on a Raspberry Pi.

Setting Up

To get started with setting up the Raspberry Pi, I use the Raspberry Pi Imager to configure an appropriate version of RaspberryOS. I can use either the 32-bit or 64-bit options. Watch this quick video from Raspberry Pi on how to use their installer. The Imager can be obtained from their website. Below, I chose to use the default, and very popular, Raspberry Pi OS 32-bit. You can also select the 64-bit option as well as the Lite versions which are designed for headless installations if you don’t need a desktop environment. NodePing PUSH and AGENT checks work with all the different flavors of Raspberry Pi OS.

I intend on using this Pi in a headless configuration, without a keyboard or monitor always connected, so I go into the “Advanced Options” page in the imager and enable SSH. I’ll also need to configure a user, password, and necessary networking. It will need internet access either via wifi or ethernet to send check results to NodePing. I’m going to use one of the Lite versions in this case to reduce the amount of extra software that gets installed.

Enabling SSH, authentication settings, and setting a username and password.

Once the microSD card is imaged, I insert it into my Pi and fire it up… waiting for it to boot. I’m able to SSH in! Good start.

From here, I do some further SSH hardening and require the user I configured to have the password entered when I do any sudo commands.

Additionally, I update the packages on my Pi.

$ sudo apt update
$ sudo apt upgrade

Installing the PUSH Clients

PUSH checks can submit any numeric metrics to NodePing using an HTTP POST, and be used to trigger notifications of the PUSH check. The PUSH payload schema is discussed in the PUSH check documentation. I can also use one of the pre-defined clients available on GitHub. Currently, NodePing provides PUSH clients written in POSIX shell, Python, and Powershell. The POSIX shell scripts and Python scripts will work on the Raspberry Pi. If I want to use a different programming language to create my own client I might want to use the existing code as a reference.

I’m going to go with the POSIX client. To get the PUSH clients code, I can visit the GitHub page to download a zip file or I can use git to fetch the code directly using the following command:

$ git clone https://github.com/NodePing/PUSH_Clients.git

From here, I can either use the clients from the directory that was cloned, or make a copy of the individual client elsewhere. A convention I tend to follow is to create a folder named something like “pi_push_metrics_202306261808OGK26-JEZ6ENNW” where name is the label of the PUSH check in NodePing, and the check ID that is generated when you create that check in the NodePing web interface.

I created those folders using the command:

$ mkdir -p push-clients/pi_push_metrics_2023-06261809OGK26-JEZ6ENNW

You can call your folder whatever you want. I use this so I can easily find the right PUSH check in NodePing that corresponds to this PUSH client.

Configuring a PUSH Check

Now I’m going to copy the POSIX client from the git clone I made into the new folder I created above.

Installation instructions are available for each of the client types. For now, I will show you a quick demo of how to configure a PUSH client that will monitor free memory, and 1 and 5 minute load averages. I configured my check like so in the NodePing web interface:

This check will pass so long as the free memory is greater than 100MB and less than 3800MB, 1 min load is between 0 and 4, and 5 min load is between 0 and 2.5. This will help me keep tabs on when my system load is too high, and if my Pi is using more or less memory than expected. For the client on the Pi, I am interested in a few files:

  1. NodePingPUSH.sh
  2. moduleconfig
  3. The modules directory

I have to ensure NodePingPUSH.sh and the other .sh files are executable by this system user. For the moduleconfig file I only want to run the memfree and load module so I simply add those in the moduleconfig file.

The contents of the file are only the 2 lines “load” and “memfree”.

For the NodePingPUSH.sh file, I need to add my check ID and its checktoken. These are found in the check drawer.

The only variables needing editing are CHECK_ID, and CHECK_TOKEN.

After configuring those files I will run:

$ sh NodePingPUSH.sh -debug

This will let me see the data that would be sent to NodePing without actually sending it. This is just for testing and is a good way to make sure I edited those files correctly without impacting any uptime stats for the check in NodePing.

Lastly, I need to set up cron to run my PUSH client on a regular interval. I want this one to run every minute, so the cron line will look like the one below. To edit my cron tab, I run crontab -e and add the following entry:

* * * * * /bin/sh /home/pi/push-clients/pi_push_metrics_202306261809OGK26-JEZ6ENNW/NodePingPUSH.sh -l

The -l at the end of that line will make the script log to a NodePingPUSH.log file in that same directory. You can modify the logfilepath variable in NodePingPUSH.sh if you want to have your logs go to a different folder.

NodePing AGENT

PUSH checks are great for pushing arbitrary metrics into NodePing. However, if I want to run one of our standard check types in my network, without creating ingress holes in my firewall, NodePing AGENT checks are the way to go. Once the AGENT software is installed, I’ll be able to run checks directly on this Pi.

Installing NodeJS

To setup the AGENT, I need NodeJS and npm installed. Raspberry Pi OS makes this simple with a single command on the Pi:

$ sudo apt install nodejs npm

With those pieces of software installed, I can clone the AGENT software git repo to get that code. The instructions can always be found in the GitHub repository, but for now, here’s the short version of the commands I ran as an example:

$ git clone https://github.com/NodePing/NodePing_Agent.git
$ cd NodePing_Agent
$ npm install
$ node NodePingAgent.js install 202306261809OGK26-1QFZPD19 31PF34KZ-JQ4S-43FP-8L6J-20Q46NFRPT07

The Check ID and Checktoken in the forth command example above are used to tie this instance of the AGENT running on my Pi to the AGENT check I created in NodePing. They can be found with the check information on the NodePing site:

The node NodePingAgent.js install command will set up the AGENT to run, and at this point I can now create checks on NodePing and assigned them to run on this AGENT. To do that, when I create a check in NodePing, in the “Region” dropdown, I select the name of the AGENT I made. When that check starts to run, I should begin to see it is being run from my AGENT, not the normal NodePing probes.

Here’s an example where I’m pinging an interval server, using the private IP address, from the AGENT on my Pi.

Note that the Region is set to the label we gave to the AGENT check. Now with the AGENT running, I can monitor anything I choose from this Pi, whether the servers are internal or external.

Diagnostics

I want to take advantage of NodePing’s Automated and On-demand Diagnostics so I want to start the Diagnostics Client on my Pi as well using the following command:

node DiagnosticsClient.js >>log/DiagnosticsClient.log 2>&1 &

The Diagnostics Client will allow NodePing to get MTRs, DNS, and other diagnostics to send me when my checks assigned there fail. It makes troubleshooting so much faster and easier.

This is Only the Beginning

Now I have a Raspberry Pi all ready to have NodePing collect a wide variety of metrics with my PUSH check and run as a custom NodePing probe with my AGENT check. I can use them to do all sorts of cool things.

In Part 2, I’ll add some hardware sensors to this Pi to measure temperature and humidity of my rack so alerts can be sent if either goes outside of a safe range. Fun stuff coming.

If you don’t yet have a NodePing account, please sign up for our free, 15-day trial.

Filed under AGENT, Node.js, PUSH, SysAdmin, System Monitoring Tagged with , ,

Finding the Best Server Providers

2023/08/01 by Leave a comment

Great services need great boxes to run on. How do we know if a server or VPS host is performant and reliable?

We use dozens of different hosts for NodePing and our standards for performance and reliability are really high. There are many SaaS out there that host only on AWS. Putting all your eggs in one basket is nice for billing but would make our service fragile and vendor-dependent. We spread our boxes around to make it resilient and better represent the Internet’s disperate architecture for monitoring.

We have to take new boxes out and put them through their paces; kick the tires and make sure they’re solid. This is how we test out a new provider before we use a dedicated server or VPS.

Blacklisted

As soon as we have our IP assignments from the provider, we check to make sure the IPs aren’t listed in any spam blacklists using NodePing RBL checks. Most of our hosts don’t send any actual email but our public probes do a lot of SMTP connections to ensure our customers’ mail servers are functioning properly. If the IPs are blacklisted, we’ll need a clean IP from the provider or cancel and look elsewhere.

We’ll leave this RBL check running once an hour to make sure it doesn’t get listed half way through our testing period.

Blacklisted IPs can be a good indicator of provider quality even if the server won’t be sending any email. A provider that can’t keep spammers out of their service is unlikely to be able to keep a reliable network.

Incoming Traffic

Solid networks can be hard to find. We test for inbound packet-loss and routing issues using NodePing PING checks. We’ll sometimes test from a few different geographical regions to ensure global routing is stable. Anything less than 100% uptime for 30 days is unacceptable for us. If the provider had announced planned maintenance well in advance, we’d use NodePing’s maintenance feature to ensure the uptime stats remained accurate despite planned outages. In our decade-plus experience, a network that sees even one episode of packet-loss or route failure is going to continue to see them and isn’t stable enough for our use.

We’ll do the same for IPv6 addresses as routing and packet-loss can be independent of the IPv4 stack. Some providers have a hard time keeping their IPv6 blocks broadcasted and we’ve seen IPv6 completely fail while IPv4 continued to function normally.

We enable automated diagnostics for all our PING checks so we can see where on the route the packet-loss or routing failure is happening. Getting immediate MTRs can show us the weak links in a network and if we see issues with some of the usual suspects, we will for sure dump it. Yes, I’m looking at you, Cogent!

Outbound Traffic

Sometimes a network issue seems to only impact outbound routing. We use the AGENT functionality to assign additional PING checks to originate from the server being tested towards some of the other servers it would be connecting to if it’s moved into production. The AGENT software will run NodePing checks just like the public probes but originating from our test host. It’s a great way to detect outbound packet-loss and routing issues from the server. Again, anything less than 100% uptime on this test and the service isn’t going to make muster.

System Load

The performance of a VPS can be greatly impacted by issues outside our control. Two of the most frequent system load issues we’ve seen on VPS are noisy neighbors and host server backups.

A good provider won’t oversell their VPS host servers and will suspend anyone who is abusing more than their fair share of resources. If we end up on a box with noisy neighbors, the system load on our VPS will likely spike, starving our processes from getting the CPU, memory, networking, or storage I/O they need to function properly.

We’ve also come across providers where we saw system load rise every Saturday around midnight (GMT) for 30 mins or so. Turned out their backup process was overwhelming the disks and causing load issues on all the VPS on the host.

These types of issues are simple to find using PUSH checks that monitor the system load. Since we aren’t using these boxes for anything yet, we have to set the thresholds pretty low to detect load issues caused by resource starvation. This is one test that we’ll give a bit of slack to a provider if it fails though. Noisy neighbors or hungry backups can happen to any provider and we’ll give them a chance to find and address the cause. If it keeps happening though, pull the plug on that provider. It’ll just be worse once you start using the machine and an ongoing headache trying to get their support to do anything about it.

If a server can keep humming along for 30 days without any of the checks above failing, there’s a pretty good chance that provider and network are going to be solid and reliable. I hope this look into our vetting process will help you with your provider search for those elusive reliable networks and servers.

If you don’t yet use NodePing, please sign up for our free, 15-day trial and see for yourself how our monitoring can increase your uptime.

Filed under AGENT, diagnostics, Monitoring, MTR, NodePing, PING, PUSH, RBL, SMTP, System Monitoring, uptime Tagged with , , , , ,

Monitoring VPN Connections with NodePing AGENTs

2023/07/06 by Leave a comment

In today’s world, VPNs have become more popular and widely used. Some common use cases have been road warrior VPNs when you are on the go, site-to-site VPNs for satellite offices, and remote connections back to the office for those who work from home (WFH). Since VPNs have become so central to many of our activities, it is important to ensure that the VPN setup you are using is both available and working as intended. This sort of monitoring is readily available with our AGENT feature.

The NodePing AGENT is designed to run NodePing monitors on your own private infrastructure. The AGENT allows you to run checks you want from any network, as long as you can stand up a Linux computer to run the AGENT. This includes locations we do not have a public probe, like your local networks, and even over VPN connections. Once you have an AGENT created and running, you can assign checks to the AGENT as the location, and the checks will run on the AGENT automatically. Most of our check types are available to use to monitor services and connectivity, which allows you to monitor your VPN resources without having to allow our public probes into your network. No firewall changes needed!

The AGENT can work with many different VPN setups. For example, configuring your AGENT computer or VM to be a WireGuard peer to monitor a WireGuard VPN. This works with other VPNs as well, such as monitoring OpenVPN connections or you can monitor IPSec or IKEv2 VPNs. With connectivity to your remote network, you can run your checks to ping internal servers, do local DNS queries, which can be useful if you have a split-DNS configuration, or HTTP connections to your local servers, and it can test outbound connectivity to the Internet.

To get started running the AGENT, you need to first create an AGENT check on NodePing. This can be done either by signing into your account on our website, or via the API. You can find this information in our documentation. The AGENT check creates the AGENT instance so you can assign checks to it. The AGENT software also sends a heartbeat so you can ensure the AGENT is running and doing its jobs. To create the AGENT check, follow these steps:

  1. Click “Add new check”
  2. Select AGENT from the Check type drop down
  3. Label the AGENT to identify it, adding a meaningful location to the label. This label is what will appear in the locations list when you assign checks to run on the AGENT
  4. Set the Check Frequency. 1 minute is recommended
  5. Optionally set “Fail when heartbeat is old” so you can know if the Agent is not submitting results
  6. Set notifications for the check
  7. Then save the check

Next, to run the AGENT software on your computer, install NodeJS on your Linux distribution of choice, then you can proceed with installing the AGENT. The instructions can always be found on our GitHub repository, but for now, here’s the short version as an example:

$ git clone https://github.com/NodePing/NodePing_Agent.git
$ cd NodePing_Agent
$ npm install
$ node NodePingAgent.js install 202306261809OGK26-N68DRNSR SW3UN1KW-5J6K-47SK-8QJH-SJPY9V7EC0IB

The Check ID and Checktoken in the example above are used to tie this instance of the AGENT running on your computer to the check running on NodePing. They can be found with the check information on the NodePing site:

The install command will set up the AGENT to run, and at this point you can now create checks to be assigned to this AGENT. To do that, create a check, and in the “Region” dropdown, select the name of the AGENT you just created. After creation, you should begin to see the checks running on your AGENT.

Additionally, if you want to take advantage of our Automated Diagnostics or our other Diagnostic Tools, you can start the Diagnostic Client on your computer as well:

node DiagnosticsClient.js >>log/DiagnosticsClient.log 2>&1 &

Now that you have the AGENT software running on your computer, and the AGENT check set up and connected, we can start assigning checks to run on this AGENT. In this scenario, let us assume we have an internal web server at 192.168.20.150, an internal DNS server we want to query at 192.168.20.100 and make sure it is returning 192.168.20.150 for our internal webserver FQDN internal.example.com, and lastly test to see that we can ping something on the Internet too so we know our clients can connect to the Internet through the VPN.

For the Web server, let’s set up an HTTP check to run on the AGENT

Note the “Region” dropdown and that I selected the AGENT I created earlier.

Next we want to make sure that we are getting the proper internal IP address for that web server:

Here, we configure the check to make a query to the internal DNS server 192.168.20.100 and expecting the answer 192.168.20.150 for internal.example.com.

Lastly, we want to ping an external server to see that clients can reach the Internet. This is useful if you do want your VPN clients going out to the Internet too. For this example, we would ping external.example.com (note these aren’t real websites):

This is all only one example of many ways you could configure your VPN monitoring. Our AGENT is capable of handling all sorts of different monitoring tasks you may want to throw at it.

The NodePing AGENT is a robust feature we provide as a part of our Premiere plan. If you don’t yet have a NodePing account, please sign up for our free, 15-day trial and try out our on-premises monitoring and see how our AGENT can help you with monitoring your VPN connections.

Filed under AGENT, Monitoring, NodePing, Using NodePing, VPN Tagged with , , , , , , , ,

On-demand Diagnostics API and from AGENT Checks

2020/05/11 by Leave a comment

It isn’t always obvious what’s going on when a check fails and additional information about what our probes are seeing can be helpful for troubleshooting. The NodePing diagnostic tools allow you to run several utilities to get information about what our probes are seeing. Now we’ve brought that functionality to our AGENT checks as well as a new API endpoint.

Diagnostics from AGENTs

You can now connect your AGENT checks to our diagnostics servers to run our most useful tools: mtr, ping, traceroute, and dig. Use the instructions in the AGENT software to run the diagnostic client on your AGENT. Your AGENTs will appear in the ‘location’ dropdown of the Diagnostic Tools in NodePing.

Diagnostics API

On-demand diagnostics can now be requested via our REST API. Your integrations can request NodePing diagnostics from any of our probes as well as from your AGENTs with a simple HTTP request. Please see the diagnostics API documentation for details.

If you don’t have a NodePing account, you can sign up for a free, 15-day trial and experience the fast and accurate service NodePing provides.

Filed under AGENT, Announcement, api, diagnostics, NodePing Updates Tagged with , ,

Monitoring Private Networks with NodePing

2020/03/12 by Leave a comment

NodePing has been providing distributed Internet availability monitoring since 2011.  During that time we’ve made billions of HTTP requests, connected to a huge number of SSH servers, and sent boat loads of PINGs.  Our systems have been listening for dropped volume levels on audio feeds, verifying SSL certificates, testing the response from email servers, checking DNS servers, and monitoring a whole slew of Internet services on every continent (except for Antarctica, yet).

undefinedThe missing component, until recently, was monitoring for private networks.  All of the monitoring mentioned above was availability monitoring from the Internet and required access through periphery firewalls to services.  That works well for public facing services, but it leaves out a lot of services and systems that are not (and should not be) publicly accessible. We’ve been working for a few years to find just the right approach to safely and reliably provide private network monitoring, and we think we’ve found it in our new AGENT check type.

Our AGENT check allows you to install a small agent on a machine in your local network and run most of our standard check types just about anywhere you have a Linux box available.  The software is small and very efficient, and is a really easy install. Once it is running, you can assign checks to your private location using our normal UI, or through our API.

The agent runs on node.js, and the code is available on github for you to review and audit.  The software can run under a regular user, and does not need any elevated privileges. Only your account has access to run checks on your agent instances.

So now you can easily assign PING, HTTP, SSH, DNS, PORT, and most of our other check types to a machine on your private network, to monitor services that should not be accessible from the Internet.  Monitor your private Intranet, make sure your private database servers are accepting connections on your network, and verify internal DNS responses. This solution scales well, is easy to start, simple to maintain, and like the rest of NodePing’s monitoring services, it just works.

Since our AGENT check runs our standard check types, it is a great compliment to our PUSH check type, which remains available and actively supported as well.  The PUSH check type is designed for you to customize and monitor basically anything on your local machine that is quantifiable by a local script. Together, these check types allow you to fully monitor your private networks and resources, safely and reliably.

The AGENT check is available now on all Provider accounts. If you don’t have a NodePing account yet, we offer a 15 day free trial.  Give it a try!

Filed under AGENT, Announcement, Monitoring