Private Location Monitoring brings the all-in-one monitoring, alerting, and reporting suite of the Uptime.com platform to a containerized Docker and as part of a larger Kubernetes deployment, which can be safely and securely deployed to monitor internal network resources that are otherwise blocked from external access.
Private Location probe servers work just like a normal Location, and communicate encrypted data from internal checks to the Uptime.com central check servers so that it can be viewed, reported on, and managed in line with other external checks in the same Uptime.com account.
This tutorial will walk through the entire Private Location process, from requesting the probe servers themselves to troubleshooting techniques and use cases. For more technical information, such as hardware requirements and Command Line Interface (CLI) usage, check out our Github.
Please note: These instructions are specific to the Private Location image version 4.X. For information on using the old depreciated 3.2 image, please click here.
- Private Location Monitoring At A Glance
- Prerequisites
- Private Location Self Service
- General Overview of Container Setup
- Adding a Private Location to a Check
- Private Location Status
- Special Configurations
- Use Cases
- General Settings
- Tips and Tricks
- Final Thoughts
Private Location Monitoring At A Glance
Monitor services on internal networks without sacrificing security measures.
Manage internal and external metrics, reports, and alerts from one account.
Protect against internal monitoring gaps to guarantee full stack availability.
Prerequisites
Account Prerequisites
Private Location Monitoring is available to Essential and Premium subscribers. However, we also offer a limited Free Trial to accounts of all subscription levels.
Technical Prerequisites
Private Locations deployed to a Docker container require a registered Docker account as well as a Linux system of Ubuntu 20.04 (or higher) using kernel 4.x or 5.x.
While Private Location Monitoring is not officially supported on Windows, it is possible to run Private Locations through Windows Subsystem for Linux (WSL2) on Windows Server 2022. You will need a dedicated server or a Windows VM server that supports nested virtualization to enable WSL 2 or Hyper-V. For more information about running private locations through Windows, please see the appropriate Github documentation.
Inbound and outbound communications use ports 80 and 443.
For internal communication and support for privileged Kubernetes, Uptime.com uses ports 8080 and 8443.
For a full list of technical and hardware requirements, please see our Github.
Private Location Self Service
Adding a Private Location
Private Locations are added through the Manage Add-Ons tool. Only Account Owners and Administrators with purchase permissions are able to add Private Locations.
To add Private Locations to your account as a user who has relevant permissions:
Navigate to Billing > Manage Add-Ons:
On the Private Monitoring Locations line, click the Plus button to add Private Locations to your account:
Deploying a Private Location
To create and deploy a Private Location once it has been purchased:
- Navigate to Probe Servers > Private Locations
- Click on the Private Location Deployments tab
- Select Deploy Location
Once the private location is created, it will appear under the Private Location Deployments tab:
You are now ready to deploy your Private Location! To get your API token and deployment options:
Click View API Token:
Your API token will appear along with a Copy to Clipboard icon.
You will also receive an email with your API Token and download instructions once you have clicked to deploy a location:
To download the private location container, select your desired platform by clicking the Select Platform dropdown under Download. Choose your preferred platform from the available options:
-
- Ubuntu
- Kubernetes
- PhotonOS
- Universal Docker Deployment
Once a platform is selected, follow the on-screen instructions for that specific deployment.
For example, when deploying to Ubuntu, the following instructions are displayed:
Ubuntu Deployment Example:
- Download the Ubuntu installation script
- Make the script executable:
chmod +x docker_install_ubuntu.sh
- Run the script:
./docker_install_ubuntu.sh
- Follow the on-screen instructions to complete the installation.
Once the script has finished running and the deployment is successful, your private location will be fully set up. You can now monitor this location through Uptime.com's 'Private Locations' tab and start running checks on your location.
Deleting Private Locations
To remove a Private Location, click the Trash icon which can be found on the Private Location page next to any existing probes.
When a Private Location is deleted, a list of checks running from the location will be shown. Click a check name to open a new window where you can replace the location.
Clicking confirm will remove the private location from the list and remove all connected checks if the checks have not been reassigned to a new location.
General Overview of Container Setup
Full instructions for Container Setup, including Docker commands for “login” and “pull image”, and "Starting the Container", are found on our Github under Installation Instructions.
For Kubernetes deployments, a sample yaml file k8s-sample.yaml is available from our Github here.
Please note: Private Location probe servers (and their containers) require write permissions to the machine’s hard drive.
Upgrading from Private Location image v2.X or 3.x (depreciated versions)
There are substantial differences and upgrades made in the v4.x image, so it is a must to upgrade as soon as possible.
Please Note: When upgrading your private location version, you will need to await a new configuration packet to be prepared and sent to the account, for config format changes to support the new features shipped with the new version. The new configuration should be sent and received within 5 minutes, at which point the private location container will continue it's start-up process and then run normally.
For full information regarding these changes, please refer to our Github, specifically the section on "Upgrading from 2.X and 3.X".
Automatic Restart of the Private Location Container
In order to restart your container automatically after a reboot/restart, add the parameter --restart always to your run command.
There is also Docker Documentation found here, that can be of assistance.
Adding a Private Location to a Check
Once the container is started and running, it’s time to add a new (or edit an existing) check to use this Private Location.
From the Edit Check window, Click the “Locations” drop down to select the configured Private Location probe server(s). If adding checks programmatically via our REST API, GET /api/v1/checks/locations/ will provide the list of available locations in the account.
Before finalizing your check, use the Run Test button to verify your settings are configured properly and returning the expected results.
Select the appropriate Private Location from the “Run Test” drop down, then click Run Test.
For help with setting up an Uptime.com check generally, see our article Overview of Checks.
Private Location Status
The Private Location Status displays your private location deployments across various environments.
This dedicated page ensures that you have a comprehensive overview of your private locations, enabling you to track their health, availability, and any potential issues.
Within the Uptime.com UI, navigate to Probe Servers > Private Locations.
Use the edit button to rename the current private location’s display name.
Please note: You must be the Account Owner or an administrator to rename the private location.
Please note: Private location servers may show warnings or errors during the first hour of operation following a restart. The Version column is only available on Private Location images v3.0 and above.
Viewing Checks Running on a Private Location
When it is necessary to deactivate or perform maintenance on a Private Location, it’s helpful to know what checks are connected to it. Click the number of Checks that are shown on the specific Private location to be provided with the full list of checks:
Once the slide out list is shown (also mentioned in “Deleting Private Locations”), click on a check name to view its Check Analysis.
Special Configurations
Private Locations can utilize the full range of Uptime.com check types and features, just like a normal Location. Generally, the only difference is that the checks in question need to have the correct Private Location probe server selected from the “Locations” menu (see above).
However, there are a few specific instances that may require additional configuration:
Kubernetes (k8s)
Private Location containers can be added to and managed via a wider Kubernetes (k8s) deployment as needed.
Please see our Github for instructions and a sample config file k8s-sample.yaml for reference or go to Probe Servers > Private Locations > Private Locations Deployments > Download > Select Platform > Kubernetes.
Monitoring via Proxy
Private Locations support monitoring resources via proxy connections on the host machine, assuming that the proxy is configured in accordance with the official Docker Proxy Server guide.
Once-per-day Checks
Certain Check types, such as SSL Certificate Expiry, WHOIS/Domain Expiry, Domain Blacklist, and Malware/Virus checks, run on a 24 hour interval. To utilize a Private Location to monitor one of these sources, select the appropriate Private Location probe server from the “Locations” drop down menu (the default is Auto).
Traceroute
Traceroute (if enabled with a Premium subscription) can also utilize a Private Location probe server as the starting address. To do so, go to the Real-Time Analysis page for a given check (click Monitoring > Checks, then Actions > Analysis), and then scroll to the bottom. Select the appropriate Private Location from the “Location” drop down, and hit Submit.
Support for Private Location image v3.2
Users running the older version 3.2 image of the Private Location, will have different troubleshooting steps, as there are new commands and syntax added in the 4.X version image
For more troubleshooting information specific to v.3.2, please see the appropriate branch of our GitHub documentation here.
Use Cases
In a general sense, Private Locations allow monitoring checks to access services or URLs that aren’t normally publicly accessible. There are any number of reasons and types of services that are protected from external access that still require monitoring to confirm that everything is up and running as expected. Below are two examples of use cases where Private Locations allow for monitoring without a lapse in security.
Firewalls
Under normal circumstances, protected services or URLs behind a firewall or WAF require IP address whitelisting to allow our Uptime.com Locations access to run the specific check. Depending on the context, service, or organizational security standards, IP whitelisting may not be allowed. In this scenario, Private Locations on an internal Docker instance can exist entirely within the protected system, with only the encrypted check and synchronization data sent to our external Uptime.com check servers.
Intranet Endpoints
Any organization — such as a school, business, or government organization — may use an Intranet server to host resources that don’t need to be accessible to the wider public. Private Locations would allow these private tools, such as a bulletin board, internally hosted metrics, or other employee-only resources, to be monitored just the same as any other external URL or resource. This way, such internal systems can still be monitored by an external party to ensure they’re up and running, without the hassle of exposing those internal endpoints.
General Settings
Private Location monitoring does not change or adjust the following network settings:
- SSH
- Firewall (or Firewall rules)
- Timezones
- Hostname
- DNS
- Hostname
- DHCP
Please confirm these settings during any troubleshooting efforts.
Tips and Tricks
Private Locations need monitoring of their own to make sure they’re up and running too. Uptime.com advises using heartbeat check as well as an HTTPS check to monitor the Docker container itself.
To do this, create a heartbeat check and take note of the URL provided in its setup.
Next, create an HTTPS check that points to the URL from your heartbeat check and specify your Private Location as the location for this check.
Finally, for your HTTPS check to successfully transmit data to your heartbeat check, you will need to utilize the optional “String to Post” field since HTTPS uses GET by default. For example, adding “{"response_time": 0.8}” to this field.
By doing this, your HTTPS check will ping your heartbeat check, letting it know that the HTTPS check is operational, and in turn, your Private Location is working as expected.
Final Thoughts
Private Locations allow for internal resources, endpoints, and URLs to be securely and safely monitored without external exposure.
Troubleshooting
For information about troubleshooting Private Locations, please see our thorough guide here.
To get started, go to Private Locations and start setting up your Private Monitoring. You can also contact support@uptime.com, or request a Private Location directly!
Comments
0 comments