Browse Source

Add content about the new slug-based ping URLs in docs/introduction.md

pull/563/head
Pēteris Caune 3 years ago
parent
commit
5905560583
No known key found for this signature in database GPG Key ID: E28D7679E9A9EDE2
2 changed files with 28 additions and 8 deletions
  1. +14
    -4
      templates/docs/introduction.html
  2. +14
    -4
      templates/docs/introduction.md

+ 14
- 4
templates/docs/introduction.html View File

@ -58,12 +58,22 @@ this will be indicated by three animated dots under check's status icon.</dd>
<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>While the "success" signals are essential, "start" and "failure" are optional.
<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
by using them. See <a href="measuring_script_run_time/">Measuring script run time</a> and
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 ping URLs as secrets. If you make them public, anybody can send
telemetry signals to your checks and mess with your monitoring.</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>
<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


+ 14
- 4
templates/docs/introduction.md View File

@ -68,13 +68,23 @@ Each check is always in one of the following states, depicted by a status icon:
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.
While the "success" signals are essential, "start" and "failure" are optional.
SITE_NAME supports two ping URL formats:
* `PING_ENDPOINT{uuid}`<br>
The check is identified by its UUID. Check UUIDs are assigned
automatically by SITE_NAME, and are guaranteed to be unique.
* `PING_ENDPOINT{project-ping-key}/{name-slug}`<br>
The check is identified by project's **Ping key** and check's
**slug** (its name, converted to lowercase, spaces replaced with hyphens).
You can append `/start`, `/fail` or `/{exitcode}` 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
by using them. See [Measuring script run time](measuring_script_run_time/) and
if you do use them. See [Measuring script run time](measuring_script_run_time/) and
[Signaling failures](signaling_failures/) for details.
You should treat ping URLs as secrets. If you make them public, anybody can send
telemetry signals to your checks and mess with your monitoring.
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.
---


Loading…
Cancel
Save