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
- You create a private region in your account. A region is a name for a place: an office, a data centre, a cluster.
- You install the probe on a machine of that place, with the token of the region.
- You point monitors and scenarios at the region. They run from your probe, and their results appear in the dashboard like any others.
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.
- Sign in at sartar.app.
- Open the account menu, then Private probes…
- 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:
- its full name, such as
.42.datacenter. The leading dot and the number of your account are part of the name; - its token, hidden until you choose Reveal;
- the install command for this region.
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.datacenterThe 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:
- downloads the package for your system and verifies its checksum;
- installs it;
- writes the configuration;
- 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-tokenWithout 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.datacenterWith the Terraform provider:
resource "sartar_monitor" "wiki" {
name = "wiki"
url = "https://wiki.corp.example.com/health"
period = 60
regions = [".42.datacenter"]
}Two rules apply:
- A monitor that targets a private region targets that region only. It cannot also run from a public region.
- A monitor with an address inside a private network must target a private region. The public probes refuse such addresses.
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-probeWhat 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 familyRemoving 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-probeThe 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.appIf 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.sigThe 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 3C58A 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.gzThe current version number is at sartar.app/dl/sartar-probe/latest.txt.