Private Location Monitoring | Setup and Troubleshooting

These instructions will provide a walkthrough of creating and running an Uptime.com Private Location Monitoring Server with Docker. Monitor internal applications and services using an instance of Uptime.com run from a private location. 

Uptime.com private location probe servers are used to communicate securely with Uptime.com. Private location monitoring is a solution designed to test and monitor services on your company’s internal network, which may not be visible to the outside world.

Table of Contents

Prerequisites

Before you begin, please ensure you have the following:

  1. Docker v. 18+
  2. Be a registered user of Docker Hub

Our recommended specs for a machine running private location monitoring are: two CPUs and 2 GB of RAM. The image size is around 3 GB, and Uptime.com stores all reporting metrics on our own servers. 

Please note: Private location monitoring was tested on Linux kernel 4.x (e.g. Ubuntu 18.04 or similar, including an updated 16.04 version that uses a 4.x kernel), and it may or may not work on kernel v. 5.x. Kernel versions 3.x are not supported. Private location monitoring requires a system running a Linux kernel, 4.x. Windows is not supported, neither as the Docker host nor via any Linux virtual machine running on a Windows host (e.g. WSL or VirtualBox).

If you meet the above prerequisites, and wish to run private location monitoring, contact support@uptime.com. We will provide you access to our private Docker Hub repository, and an API key.

In your working directory, create a file named `seccomp-config.json`with the following contents (download file)

Setup Instructions

Log into Docker Hub with the command docker login, and then use the command docker pull uptimecom/uptime-private-location:latest to pull the latest image. 

The private location application will use the host's network settings (including DNS settings of the host machine); if you want to monitor external resources from a private location (e.g. from the insides of your intranet) you might want to set your host machine's DNS to Google's 8.8.8.8

Running Your Monitoring Server

You will find instructions to run and utilize your server here. 

Starting the Container

To start a container, use the command:

docker run -it \

    --env UPTIME_API_TOKEN="YOUR_UPTIME_API_TOKEN" \

   --mount type=volume,dst=/usr/local/nagios/etc/hosts,src=uptime-nagios-hosts \

    --mount type=volume,dst=/usr/local/nagios/var/,src=uptime-nagios-var \

    --mount type=volume,dst=/home/webapps/uptime/logs/,src=uptime-logs \

    --mount type=volume,dst=/home/webapps/uptime/data/,src=uptime-data \

    --security-opt seccomp=./seccomp-config.json \

    --hostname localhost \

    uptimecom/uptime-private-location

Stopping the Container

To stop the container, you must first retrieve the PID of your running container. Use the command docker ps. Once you’ve retrieved the contained PID, use the command docker kill PID_OF_THE_RUNNING_CONTAINER to stop the container. 

Adding Checks

When you add a new check, via the Uptime.com UI or REST API, the private location probe servers you have configured will be visible in the Locations field. Ensure that only these probe servers are monitoring the check you’ve configured for Private Location Monitoring purposes. 

assign-check-to-private-location.png

Please Note: Private Location Probe Servers will need permissions to write to the server’s drive.

Use Cases

Private location monitoring will generally allow you to monitor services and URLs that are not publicly accessible, such as websites behind a firewall or intranet applications to be sure all is up and working. 

A school or a government organization might use this kind of tool to monitor its internal bulletin board system during a temporary outage or maintenance period. Doing so ensures that connectivity remains open to the bulletin board system and that communications remain alive while the external services are maintained. 

In a corporate setting, the use cases are more varied. Intranet might be the first place employees check in during their morning, or where IT keeps its internal metrics. Private Location monitoring allows continuous assurance these services are alive and well.

Status and Troubleshooting

Private Location monitoring depends on a number of processes that must be monitored to ensure the probe is working properly. We highly recommend using the methods below to monitor for errors. 

Using Uptime.com Custom Checks

Uptime.com advises users with Private Location monitoring utilize our custom checks in one of two ways.

The first method is to use the URL provided by webhook or heartbeat monitoring as part of an external script on the host. Run this script periodically to check either that your Docker is running, or the Private Location container is running. This is the most robust method, and is our primary recommendation.  

Alternatively, you can create a custom check and then create an HTTP(S) check with Uptime.com that utilizes your Private Location probe servers. If this check ever fails, you will receive an alert to your contact of choice. 

Check Status of a Container Using CLI

It is possible to check the status of a running container, either by exposing a port and making a HTTP(S) call or by running a CLI command.

Retrieve the PID of a running container with the command docker ps. Once you have retrieved the PID, use the command docker exec -it PID_OF_THE_RUNNING_CONTAINER /status.sh 

Check Status of a Container Using a Network Call

Stop the container if it is running. Modify the run script for the container and add an option to expose a port. The command below will expose a container's HTTP(S) port on local `8003` port:

     docker run -it \

         --env UPTIME_API_TOKEN="YOUR_UPTIME_API_TOKEN" \

         --mount type=bind,source=/sys/fs/cgroup,target=/sys/fs/cgroup \

         --mount type=volume,dst=/usr/local/nagios/etc/hosts,src=uptime-nagios-hosts \

         --mount type=volume,dst=/usr/local/nagios/var/,src=uptime-nagios-var \

         --mount type=volume,dst=/home/webapps/uptime/logs/,src=uptime-logs \

         --mount type=volume,dst=/home/webapps/uptime/data/,src=uptime-data \

         --security-opt seccomp=./seccomp-config.json \

         --hostname localhost \

         -p 8003:443 \

         uptimecom/uptime-private-location

Next, use the following cURL command to make a HTTP(S) call to https://localhost:8003/status:

     curl -k https://127.0.0.1:8003/status

The JSON Payload

Both the CLI and Network Call methods will return a JSON payload, an example is below:

{

   "details": {

      "check_load": {

         "status": "OK",

         "description": "OK - load average: 0.16, 0.09, 0.03"

      },

      "check_total_procs": {

         "status": "OK",

         "description": "PROCS OK: 37 processes | procs=37;500;750;0;\n"

      },

      "check_nag": {

         "status": "OK",

         "description": "PROCS OK: 6 processes"

      },

      "check_mem": {

         "status": "OK",

         "description": "OK - 77.5% (1586788 kB) free."

      },

      "check_txn_manager": {

         "status": "OK",

         "description": "OK - 0 checks executed, 0 waiting, 0 declined"

      },

      "check_alert_queue": {

         "status": "OK",

         "description": "OK - 1 files in dir\n"

      },

      "check_send_alert_errors": {

         "status": "OK",

         "description": "OK - No errors found\n"

      },

      "check_perfdata_log": {

         "status": "ERROR",

         "description": "WARNING - Unable to match pattern: ### WEB API CALL COMPLETE"

      },

      "check_reconfig_log": {

         "status": "ERROR",

         "description": "WARNING - Unable to match pattern: ### CHECK FOR CONFIG UPDATE"

      },

      "check_stalled_check_detection_log": {

         "status": "ERROR",

         "description": "WARNING - Unable to match pattern: ### STALLED CHECK"

      },

      "last_check_times": {

         "status": "OK",

         "description": "OK: Last check ran 0:00:07 secs ago at 2020-01-15 16:15:56 UTC"

      }

   },

   "status": "ERROR",

   "description": "One or more checks have returned errors."

}

Private Location monitoring allows for an array of possibilities where errors may not necessarily signal action is necessary. One example is an image that has no checks assigned to it providing an error for last_check_times. 

Uptime.com Private Location Monitoring does not change or adjust the following settings:

  • SSH
  • Firewall (or Firewall rules)
  • Timezones
  • Hostname
  • DNS
  • Hostname
  • DHCP

Users are advised to check these settings as part of any troubleshooting efforts. 

Troubleshooting will involve considering the process that is down, and making a determination of when to reboot it. Please contact support@uptime.com if you encounter continued errors. 

Please note: once a container starts, some tasks may take time to settle (For example, reconfigurations or stalled check detections). As a result, some checks may fail. Please allow approximately one hour after a container is started for all checks to return to OK status. If you experience down checks after one hour, you should investigate further. 

Was this article helpful?
0 out of 1 found this helpful