Private probes

sartar checks your sites from public probes on the internet. A private probe is the same probe, installed by you on a machine of your own network. It checks what the public probes cannot reach: internal services, staging environments, anything behind your firewall.

How it works

The probe connects out to sartar over TLS, on port 443. It listens on no port, so you open nothing inbound.

A private region belongs to your account alone. A private probe only ever receives the checks of monitors that name its region.

Requirements

System Linux with systemd
Architecture amd64 or arm64
Network outbound HTTPS to sartar.app, port 443
Rights root, for the installation only

Verified platforms

Distribution Architectures Package
Ubuntu 24.04 LTS amd64, arm64 .deb

The probe is a single static binary, so the packages work on most other Debian-family and RHEL-family systems too. On a system that is not in the table, the installer says so and continues with the .deb or the .rpm that the machine can install.

1. Create a private region

An administrator of the account does this once for each place.

  1. Sign in at sartar.app.
  2. Open the account menu, then Private probes…
  3. Under New private region, enter a short name and choose Create. A name holds letters, digits, - and _, up to 40 characters.

The page now shows the region, with:

2. Install the probe

Run the command shown on the page, as root, on the machine that will host the probe. It has this shape:

curl -fsSL https://sartar.app/install-probe.sh | sudo sh -s -- \
  --region .42.datacenter

The installer asks for the token. Paste it and press Enter. Nothing is shown while you type, and the token stays out of your shell history.

The installer then:

  1. downloads the package for your system and verifies its checksum;
  2. installs it;
  3. writes the configuration;
  4. starts the probe, and tells you whether it stayed up.
Installing sartar-probe 2.2.2 (deb, amd64)
Checksum OK.
Package installed.

Token for region .42.datacenter — it will not be shown as you type.
Token:

sartar-probe is running as region .42.datacenter (id office-1).

Within a few seconds the probe appears on the Private probes page, under Connected probes.

Installer options

Option Meaning
--region <name> the full name of the region, leading dot included
--key-file <path> read the token from a file instead of asking
--key <token> give the token on the command line. Avoid it: the token ends up in the shell history
--id <name> a name for this probe. The default is the host name of the machine
--version <x.y.z> install this version instead of the latest
--no-start install and configure, but do not start the probe

Each option also exists as an environment variable: SARTAR_PROBE_REGION, SARTAR_PROBE_KEY, SARTAR_PROBE_ID, SARTAR_PROBE_VERSION.

Give each probe a name that says where it runs, such as office-1 or datacenter-b. That name is shown next to each result.

Unattended installation

Where nobody can answer a question, such as a provisioning script, put the token in a file that only root can read and pass its path:

curl -fsSL https://sartar.app/install-probe.sh | sudo sh -s -- \
  --region .42.datacenter --key-file /root/sartar-token

Without a terminal and without a token, the installer does not wait. It installs the package, leaves the probe stopped, and says what is missing.

3. Point monitors at the region

In the web dashboard, choose the private region in the region list of a monitor or of a scenario. It appears under its short name, marked as private.

With the sartar CLI, use the full name:

sartar region list
sartar monitor create --name "/internal/wiki" \
  --url https://wiki.corp.example.com/health \
  --period 60 --region .42.datacenter

With the Terraform provider:

resource "sartar_monitor" "wiki" {
  name    = "wiki"
  url     = "https://wiki.corp.example.com/health"
  period  = 60
  regions = [".42.datacenter"]
}

Two rules apply:

Several probes in one region

Install the probe on a second machine with the same region and the same token.

Each probe of a region needs a name of its own. The default name is the host name of the machine, so two machines with different host names need nothing more. Otherwise, choose the name with --id.

Two probes with the same name in one region take each other's place: each connection closes the other, and neither runs checks reliably.

Each monitor runs on one probe of the region. When that probe stops, its monitors move to another probe of the region. Two probes therefore keep your checks running while one machine restarts.

Day-to-day operation

The probe is a systemd service named sartar-probe.

systemctl status sartar-probe
journalctl -u sartar-probe -f
sudo systemctl restart sartar-probe

What is installed

Path Content
/usr/bin/sartar-probe the probe
/usr/lib/systemd/system/sartar-probe.service the service
/etc/sartar-probe/probe.env the configuration, readable by root only

The probe stores nothing on the machine. It runs without a user account of its own and without write access to the system.

Configuration

Variable Meaning
PROBE_ID the name of this probe
PROBE_REGION the full name of the region
PROBE_API_KEY the token of the region
SCHEDULER_URL where the probe connects. Leave it as installed

After you edit the file, restart the service.

Upgrade

Run the installer again. It installs the latest version and keeps your configuration. It does not ask for the token again.

curl -fsSL https://sartar.app/install-probe.sh | sudo sh -s --

The probe does not upgrade itself. You decide when a new version enters your network.

Remove

sudo apt remove sartar-probe      # Debian family
sudo rpm -e sartar-probe          # RHEL family

Removing the package keeps the configuration, which holds the token. A Debian-family system leaves the file in place, and sudo apt purge sartar-probe deletes it as well. An RHEL-family system renames it to probe.env.rpmsave.

The token

Whoever holds the token of a region can connect a probe to it and receive its checks. Those checks name your internal addresses. Treat the token as a credential.

If a token leaks, an administrator chooses Rotate token on the Private probes page. Probes that still use the old token are refused at their next connection. Update each probe of the region, either by running the installer again with --key-file, or by editing PROBE_API_KEY in the configuration and restarting the service.

Delete a region

An administrator chooses Delete region on the Private probes page. The probes of the region are disconnected.

A region that a monitor or a scenario still targets cannot be deleted. Move those monitors and scenarios to another region first.

Troubleshooting

The probe does not stay up

The installer prints the last lines the probe logged. The usual causes are a wrong region name, or a token that belongs to another region. Check that the region name starts with a dot and carries the number of your account.

Correct /etc/sartar-probe/probe.env, then:

sudo systemctl restart sartar-probe

The probe runs but does not appear on the page

The probe cannot reach sartar. Check that the machine can open an outbound HTTPS connection:

curl -sI https://sartar.app

If a firewall filters outbound traffic, allow sartar.app on port 443, WebSocket connections included.

A probe keeps disconnecting

Two probes of the region probably carry the same name. Check PROBE_ID in the configuration of each machine, give each probe a name of its own, and restart the service.

A state other than "active"

State Meaning
active the probe runs checks
paused the probe is connected and receives no checks
draining the probe finishes its current checks before it stops
on probation the probe has just connected and is being verified
quarantined the probe fails to reach most targets, so its checks were moved away

A quarantined probe usually has a network problem of its own. It returns to service by itself once it reaches its targets again.

Verify a download

Each release publishes a checksum file and its signature:

https://sartar.app/dl/sartar-probe/<version>/sartar-probe_<version>_SHA256SUMS
https://sartar.app/dl/sartar-probe/<version>/sartar-probe_<version>_SHA256SUMS.sig

The installer checks the package against the checksum file. To also check where the release comes from, verify the signature with GPG. The signing key has this fingerprint:

598F C4D4 D2CB 22E0 A197  7BD3 FDC7 EE9C 5F90 3C58

A system without a package manager

Each release also ships the probe as an archive, with the service file and the configuration template:

https://sartar.app/dl/sartar-probe/<version>/sartar-probe_<version>_linux_amd64.tar.gz
https://sartar.app/dl/sartar-probe/<version>/sartar-probe_<version>_linux_arm64.tar.gz

The current version number is at sartar.app/dl/sartar-probe/latest.txt.