|
<h1>SITE_NAME Documentation</h1>
|
|
<p>SITE_NAME is a service for monitoring cron jobs and similar periodic processes:</p>
|
|
<ul>
|
|
<li>SITE_NAME <strong>listens for HTTP requests ("pings")</strong> from your cron jobs and scheduled
|
|
tasks.</li>
|
|
<li>It <strong>keeps silent</strong> as long as pings arrive on time.</li>
|
|
<li>It <strong>raises an alert</strong> as soon as a ping does not arrive on time.</li>
|
|
</ul>
|
|
<p>SITE_NAME works as a <a href="https://en.wikipedia.org/wiki/Dead_man%27s_switch">dead man's switch</a> for processes that need to
|
|
run continuously or on a regular, known schedule. For example:</p>
|
|
<ul>
|
|
<li>filesystem backups, database backups</li>
|
|
<li>task queues</li>
|
|
<li>database replication status</li>
|
|
<li>report generation scripts</li>
|
|
<li>periodic data import and sync jobs</li>
|
|
<li>periodic antivirus scans</li>
|
|
<li>DDNS updater scripts</li>
|
|
<li>SSL renewal scripts</li>
|
|
</ul>
|
|
<p>SITE_NAME is <em>not</em> the right tool for:</p>
|
|
<ul>
|
|
<li>monitoring website uptime by probing it with HTTP requests</li>
|
|
<li>collecting application performance metrics</li>
|
|
<li>error tracking</li>
|
|
<li>log aggregation</li>
|
|
</ul>
|
|
<h2>Concepts</h2>
|
|
<p>A <strong>Check</strong> represents a single service you want to monitor. For example, when
|
|
<a href="monitoring_cron_jobs/">monitoring cron jobs</a>, you would create a separate check for
|
|
each cron job to be monitored. Each check has a unique ping URL, a set schedule,
|
|
and associated integrations. For the available configuration options, see
|
|
<a href="configuring_checks/">Configuring checks</a>.</p>
|
|
<p>Each check is always in one of the following states, depicted by a status icon:</p>
|
|
<dl>
|
|
<dt><span class="status ic-new"></span></dt>
|
|
<dd><strong>New</strong>. A newly created check that has not received any pings yet. Each new
|
|
check you create will start in this state.</dd>
|
|
<dt><span class="status ic-up"></span></dt>
|
|
<dd><strong>Up</strong>. All is well, the last "success" signal has arrived on time.</dd>
|
|
<dt><span class="status ic-grace"></span></dt>
|
|
<dd><strong>Late</strong>. The "success" signal is due but has not arrived yet.
|
|
It is not yet late by more than the check's configured <strong>Grace Time</strong>.</dd>
|
|
<dt><span class="status ic-down"></span></dt>
|
|
<dd><strong>Down</strong>. The "success" signal has not arrived yet, and the Grace Time has elapsed.
|
|
When a check transitions into the "Down" state, SITE_NAME sends out alert
|
|
messages via the configured integrations.</dd>
|
|
<dt><span class="status ic-paused"></span></dt>
|
|
<dd><strong>Paused</strong>. You can manually pause the monitoring of specific checks. For example,
|
|
if a frequently running cron job has a known problem, and a fix is scheduled but
|
|
not yet ready, you can pause monitoring of the corresponding check temporarily to
|
|
avoid unwanted alerts about a known issue.</dd>
|
|
<dt><span class="status ic-up"></span><div class="spinner started"><div class="d1"></div><div class="d2"></div><div class="d3"></div></div></dt>
|
|
<dd>Additionally, if the most recent received signal is a "start" signal,
|
|
this will be indicated by three animated dots under check's status icon.</dd>
|
|
</dl>
|
|
<hr />
|
|
<p><strong>Ping URL</strong>. Each check has a unique <strong>Ping URL</strong>. Clients (cron jobs, background
|
|
workers, batch scripts, scheduled tasks, web services) make HTTP requests to the
|
|
ping URL to signal a start of the execution, a success, or a failure.</p>
|
|
<p>SITE_NAME supports two ping URL formats:</p>
|
|
<ul>
|
|
<li><code>PING_ENDPOINT<uuid></code><br>
|
|
The check is identified by its UUID. Check UUIDs are assigned
|
|
automatically by SITE_NAME, and are guaranteed to be unique.</li>
|
|
<li><code>PING_ENDPOINT<project-ping-key>/<name-slug></code><br>
|
|
The check is identified by project's <strong>Ping key</strong> and check's
|
|
<strong>slug</strong> (its name, converted to lowercase, spaces replaced with hyphens).</li>
|
|
</ul>
|
|
<p>You can append <code>/start</code>, <code>/fail</code> or <code>/<exitcode></code> to the base ping URL to send
|
|
"start" and "failure" signals. The "start" and "failure" signals are optional.
|
|
You don't have to use them, but you can gain additional monitoring insights
|
|
if you do use them. See <a href="measuring_script_run_time/">Measuring script run time</a> and
|
|
<a href="signaling_failures/">Signaling failures</a> for details.</p>
|
|
<p>You should treat check UUIDs and project Ping keys as secrets. If you make them public,
|
|
anybody can send telemetry signals to your checks and mess with your monitoring.</p>
|
|
<p>Read more about Ping URLs in <a href="http_api/">Pinging API</a>.</p>
|
|
<hr />
|
|
<p><strong>Grace Time</strong> is one of the configuration parameters you can set for each check.
|
|
It is the additional time to wait before sending an alert when a check
|
|
is late. Use this parameter to account for small, expected deviations in job
|
|
execution times. If you use "start" signals to
|
|
<a href="measuring_script_run_time/">measure job execution time</a>, Grace Time also sets the
|
|
maximum allowed time gap between "start" and "success" signals. If a job
|
|
sends a "start" signal but then does not send a "success" signal within grace time,
|
|
SITE_NAME will assume the job has failed, and send out alerts.</p>
|
|
<hr />
|
|
<p>An <strong>Integration</strong> is a specific method for delivering monitoring alerts when checks
|
|
change states. SITE_NAME supports many different types of integrations: email,
|
|
webhooks, SMS, Slack, PagerDuty, etc. You can set up multiple integrations.
|
|
For each check, you can specify which integrations it should use.</p>
|
|
<p>For more information on integrations, see
|
|
<a href="configuring_notifications/">Configuring notifications</a>.</p>
|
|
<hr />
|
|
<p><strong>Project</strong>. To keep things organized, you can group checks and integrations in <strong>Projects</strong>.
|
|
Your account starts with a single default project, but you can create any number
|
|
of additional projects as needed. You can transfer existing checks between projects
|
|
while preserving their configuration and ping URL.</p>
|
|
<p>Each project has a configurable name, a separate set of API keys, and a separate
|
|
project team. The project's team is the set of people you have granted read-only or
|
|
read-write access to the project.</p>
|
|
<p>For more information on projects, see <a href="projects_teams/">Projects and teams</a>.</p>
|