forked from GithubBackups/healthchecks
Grammar and style fixes, updated illustration.
This commit is contained in:
parent
66a1a108bf
commit
e63aa9fe8d
Binary file not shown.
Before Width: | Height: | Size: 54 KiB After Width: | Height: | Size: 53 KiB |
@ -3,65 +3,67 @@
|
||||
monitor. For example, when monitoring cron jobs, you would create a separate check for
|
||||
each cron job to be monitored. SITE_NAME pricing plans are structured primarily
|
||||
around how many checks you can have in your account. You can create checks
|
||||
either in SITE_NAME web interface or by calling <a href="../api/">API</a>.</p>
|
||||
either in SITE_NAME web interface or by calling <a href="../api/">Management API</a>.</p>
|
||||
<h2>Name, Tags, Description</h2>
|
||||
<p>Describe each check using optional name, tags and description fields.</p>
|
||||
<p>Describe each check using an optional name, tags, and description fields.</p>
|
||||
<p><img alt="Editing name, tags and description" src="IMG_URL/edit_name.png" /></p>
|
||||
<ul>
|
||||
<li><strong>Name</strong>: names are optional, but it is a good idea to set them.
|
||||
Good naming becomes especially important as you add more checks in the
|
||||
account. Names are displayed in the web interface, in email reports and in the
|
||||
notifications that SITE_NAME sends out.</li>
|
||||
account. SITE_NAME will display check names in the web interface, in email reports,
|
||||
and in notifications.</li>
|
||||
<li><strong>Tags</strong>: a space-separated list of optional labels. Use tags to organize and group
|
||||
checks within a project. You can tag checks by environment
|
||||
(<code>prod</code>, <code>staging</code>, <code>dev</code>, ...) or by role (<code>www</code>, <code>db</code>, <code>worker</code>, ...) or using
|
||||
checks within a project. You can tag checks by the environment
|
||||
(<code>prod</code>, <code>staging</code>, <code>dev</code>, etc.) or by role (<code>www</code>, <code>db</code>, <code>worker</code>, etc.) or using
|
||||
any other system.</li>
|
||||
<li><strong>Description</strong>: a free-form text field with any related information for your team
|
||||
or for your future self: what is being monitored, who set it up,
|
||||
what to do in case of failures, where to look for additional information.</li>
|
||||
or your future self. Describe the cron job's role, who set it up, what to do in
|
||||
case of failures, where to look for additional information.</li>
|
||||
</ul>
|
||||
<h2>Simple Schedules</h2>
|
||||
<p>SITE_NAME supports two types of schedules: "simple" and "cron". Use "Simple" schedules
|
||||
for monitoring processes that are expected to run at relatively regular time
|
||||
<p>SITE_NAME supports two types of schedules: <strong>Simple</strong> and <strong>Cron</strong>. Use Simple
|
||||
schedules for monitoring processes that you expect to run at relatively regular time
|
||||
intervals: once an hour, once a day, once a week.</p>
|
||||
<p><img alt="Editing the period and grace time" src="IMG_URL/edit_simple_schedule.png" /></p>
|
||||
<p>For simple schedules you configure two time durations, Period and Grace Time.</p>
|
||||
<p>For the simple schedules, you can configure two parameters, Period and Grace Time.</p>
|
||||
<ul>
|
||||
<li><strong>Period</strong>: the expected time between pings</li>
|
||||
<li><strong>Grace Time</strong>: when a check is late, how long to wait before sending an alert.
|
||||
Use this variable to account for small, expected deviations in job execution times.</li>
|
||||
<li><strong>Period</strong> is the expected time between pings.</li>
|
||||
<li><strong>Grace Time</strong> 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.</li>
|
||||
</ul>
|
||||
<h2>Cron Schedules</h2>
|
||||
<p>Use "cron" for monitoring processes with more complex schedules, and to ensure
|
||||
jobs run <strong>at the correct time</strong> (not just at correct time intervals).</p>
|
||||
<p>Use "cron" for monitoring processes with more complex schedules. This monitoring mode
|
||||
ensures that jobs run <strong>at the correct time</strong>, and not just at correct time intervals.</p>
|
||||
<p><img alt="Editing cron schedule" src="IMG_URL/edit_cron_schedule.png" /></p>
|
||||
<p>You will need to specify Cron Expression, Server's Time Zone and Grace Time.</p>
|
||||
<p>You will need to specify Cron Expression, Server's Time Zone, and Grace Time.</p>
|
||||
<ul>
|
||||
<li><strong>Cron Expression</strong>: enter the same expression you've used in the crontab.</li>
|
||||
<li><strong>Server's Time Zone</strong>: cron daemon typically uses the local time of the machine it is
|
||||
running on. If the machine is not using UTC timezone, you need to tell SITE_NAME
|
||||
what timezone to use.</li>
|
||||
<li><strong>Grace Time</strong>: same as for simple schedules, how long to wait before sending an alert
|
||||
for a late check.</li>
|
||||
<li><strong>Cron Expression</strong> is the cron expression you specified in the crontab.</li>
|
||||
<li><strong>Server's Time Zone</strong> is the timezone of your server. The cron daemon typically uses
|
||||
system's local time. If the machine is not using the UTC timezone, you need to
|
||||
specify it here.</li>
|
||||
<li><strong>Grace Time</strong>, same as for simple schedules, is how long to wait before sending an
|
||||
alert for a late check.</li>
|
||||
</ul>
|
||||
<h2>Filtering Rules</h2>
|
||||
<p>In the "Filtering Rules" dialog you can control several advanced aspects of
|
||||
<p>In the "Filtering Rules" dialog, you can control several advanced aspects of
|
||||
how SITE_NAME handles incoming pings for a particular check.</p>
|
||||
<p><img alt="Setting filtering rules" src="IMG_URL/filtering_rules.png" /></p>
|
||||
<ul>
|
||||
<li><strong>Allowed request methods for HTTP requests</strong>. You can require the ping
|
||||
requests to use HTTP POST. Use the "Only POST" option if you run into issues of
|
||||
preview bots hitting the ping URLs when you send them in email or post them in chat.</li>
|
||||
<li><strong>Filter by keywords in the Subject line</strong>. When pinging via <a href="../email/">email</a>,
|
||||
<li><strong>Filter by keywords in the Subject line</strong>. When pinging <a href="../email/">via email</a>,
|
||||
look for specific keywords in the subject line. If the subject line contains any of
|
||||
the keywords listed in <strong>Success Keywords</strong>, SITE_NAME will assume it to be a success
|
||||
signal. Likewise, if it contains any of the keywords listed in <strong>Failure Keywords</strong>,
|
||||
SITE_NAME will treat it as an explicit failure signal.
|
||||
This is useful, for example, if your backup software sends an email after each backup
|
||||
For example, this is useful if your backup software sends an email after each backup
|
||||
run with a different subject line depending on success or failure.</li>
|
||||
<li><strong>Pinging a Paused Check</strong>. When you ping a paused check, normally it leaves
|
||||
the paused state and goes into the "up" or "down" state (depending on the type of
|
||||
the ping). This changes if you select the "Ignore the ping, stay in the paused state"
|
||||
option: the paused state becomes "sticky". SITE_NAME will ignore all incoming pings
|
||||
until you explicitly <em>resume</em> the check.</li>
|
||||
<li><strong>Pinging a Paused Check</strong>. Normally, when you ping a paused check, it leaves the
|
||||
paused state and goes into the "up" state (or the "down" state
|
||||
in case of <a href="../signalling_failures/">a failure signal</a>).
|
||||
You can change this behavior by selecting the "Ignore the ping, stay in
|
||||
the paused state" option. With this option selected, the paused state becomes "sticky":
|
||||
SITE_NAME will ignore all incoming pings until you explicitly <em>resume</em> the check.</li>
|
||||
</ul>
|
@ -4,59 +4,60 @@ In SITE_NAME, a **Check** represents a single service you want to
|
||||
monitor. For example, when monitoring cron jobs, you would create a separate check for
|
||||
each cron job to be monitored. SITE_NAME pricing plans are structured primarily
|
||||
around how many checks you can have in your account. You can create checks
|
||||
either in SITE_NAME web interface or by calling [API](../api/).
|
||||
either in SITE_NAME web interface or by calling [Management API](../api/).
|
||||
|
||||
## Name, Tags, Description
|
||||
|
||||
Describe each check using optional name, tags and description fields.
|
||||
Describe each check using an optional name, tags, and description fields.
|
||||
|
||||

|
||||
|
||||
* **Name**: names are optional, but it is a good idea to set them.
|
||||
Good naming becomes especially important as you add more checks in the
|
||||
account. Names are displayed in the web interface, in email reports and in the
|
||||
notifications that SITE_NAME sends out.
|
||||
account. SITE_NAME will display check names in the web interface, in email reports,
|
||||
and in notifications.
|
||||
* **Tags**: a space-separated list of optional labels. Use tags to organize and group
|
||||
checks within a project. You can tag checks by environment
|
||||
(`prod`, `staging`, `dev`, ...) or by role (`www`, `db`, `worker`, ...) or using
|
||||
checks within a project. You can tag checks by the environment
|
||||
(`prod`, `staging`, `dev`, etc.) or by role (`www`, `db`, `worker`, etc.) or using
|
||||
any other system.
|
||||
* **Description**: a free-form text field with any related information for your team
|
||||
or for your future self: what is being monitored, who set it up,
|
||||
what to do in case of failures, where to look for additional information.
|
||||
or your future self. Describe the cron job's role, who set it up, what to do in
|
||||
case of failures, where to look for additional information.
|
||||
|
||||
## Simple Schedules
|
||||
|
||||
SITE_NAME supports two types of schedules: "simple" and "cron". Use "Simple" schedules
|
||||
for monitoring processes that are expected to run at relatively regular time
|
||||
SITE_NAME supports two types of schedules: **Simple** and **Cron**. Use Simple
|
||||
schedules for monitoring processes that you expect to run at relatively regular time
|
||||
intervals: once an hour, once a day, once a week.
|
||||
|
||||

|
||||
|
||||
For simple schedules you configure two time durations, Period and Grace Time.
|
||||
For the simple schedules, you can configure two parameters, Period and Grace Time.
|
||||
|
||||
* **Period**: the expected time between pings
|
||||
* **Grace Time**: when a check is late, how long to wait before sending an alert.
|
||||
Use this variable to account for small, expected deviations in job execution times.
|
||||
* **Period** is the expected time between pings.
|
||||
* **Grace Time** 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.
|
||||
|
||||
## Cron Schedules
|
||||
|
||||
Use "cron" for monitoring processes with more complex schedules, and to ensure
|
||||
jobs run **at the correct time** (not just at correct time intervals).
|
||||
Use "cron" for monitoring processes with more complex schedules. This monitoring mode
|
||||
ensures that jobs run **at the correct time**, and not just at correct time intervals.
|
||||
|
||||

|
||||
|
||||
You will need to specify Cron Expression, Server's Time Zone and Grace Time.
|
||||
You will need to specify Cron Expression, Server's Time Zone, and Grace Time.
|
||||
|
||||
* **Cron Expression**: enter the same expression you've used in the crontab.
|
||||
* **Server's Time Zone**: cron daemon typically uses the local time of the machine it is
|
||||
running on. If the machine is not using UTC timezone, you need to tell SITE_NAME
|
||||
what timezone to use.
|
||||
* **Grace Time**: same as for simple schedules, how long to wait before sending an alert
|
||||
for a late check.
|
||||
* **Cron Expression** is the cron expression you specified in the crontab.
|
||||
* **Server's Time Zone** is the timezone of your server. The cron daemon typically uses
|
||||
system's local time. If the machine is not using the UTC timezone, you need to
|
||||
specify it here.
|
||||
* **Grace Time**, same as for simple schedules, is how long to wait before sending an
|
||||
alert for a late check.
|
||||
|
||||
## Filtering Rules
|
||||
|
||||
In the "Filtering Rules" dialog you can control several advanced aspects of
|
||||
In the "Filtering Rules" dialog, you can control several advanced aspects of
|
||||
how SITE_NAME handles incoming pings for a particular check.
|
||||
|
||||

|
||||
@ -64,15 +65,16 @@ how SITE_NAME handles incoming pings for a particular check.
|
||||
* **Allowed request methods for HTTP requests**. You can require the ping
|
||||
requests to use HTTP POST. Use the "Only POST" option if you run into issues of
|
||||
preview bots hitting the ping URLs when you send them in email or post them in chat.
|
||||
* **Filter by keywords in the Subject line**. When pinging via [email](../email/),
|
||||
* **Filter by keywords in the Subject line**. When pinging [via email](../email/),
|
||||
look for specific keywords in the subject line. If the subject line contains any of
|
||||
the keywords listed in **Success Keywords**, SITE_NAME will assume it to be a success
|
||||
signal. Likewise, if it contains any of the keywords listed in **Failure Keywords**,
|
||||
SITE_NAME will treat it as an explicit failure signal.
|
||||
This is useful, for example, if your backup software sends an email after each backup
|
||||
For example, this is useful if your backup software sends an email after each backup
|
||||
run with a different subject line depending on success or failure.
|
||||
* **Pinging a Paused Check**. When you ping a paused check, normally it leaves
|
||||
the paused state and goes into the "up" or "down" state (depending on the type of
|
||||
the ping). This changes if you select the "Ignore the ping, stay in the paused state"
|
||||
option: the paused state becomes "sticky". SITE_NAME will ignore all incoming pings
|
||||
until you explicitly *resume* the check.
|
||||
* **Pinging a Paused Check**. Normally, when you ping a paused check, it leaves the
|
||||
paused state and goes into the "up" state (or the "down" state
|
||||
in case of [a failure signal](../signalling_failures/)).
|
||||
You can change this behavior by selecting the "Ignore the ping, stay in
|
||||
the paused state" option. With this option selected, the paused state becomes "sticky":
|
||||
SITE_NAME will ignore all incoming pings until you explicitly *resume* the check.
|
||||
|
@ -1,12 +1,13 @@
|
||||
<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 services being monitored.</li>
|
||||
<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 regular, known schedule. For example:</p>
|
||||
run continuously or on a regular, known schedule. For example:</p>
|
||||
<ul>
|
||||
<li>filesystem backups, database backups</li>
|
||||
<li>task queues</li>
|
||||
|
@ -2,12 +2,13 @@
|
||||
|
||||
SITE_NAME is a service for monitoring cron jobs and similar periodic processes:
|
||||
|
||||
* SITE_NAME **listens for HTTP requests ("pings")** from services being monitored.
|
||||
* SITE_NAME **listens for HTTP requests ("pings")** from your cron jobs and scheduled
|
||||
tasks.
|
||||
* It **keeps silent** as long as pings arrive on time.
|
||||
* It **raises an alert** as soon as a ping does not arrive on time.
|
||||
|
||||
SITE_NAME works as a [dead man's switch](https://en.wikipedia.org/wiki/Dead_man%27s_switch) for processes that need to
|
||||
run continuously or on regular, known schedule. For example:
|
||||
run continuously or on a regular, known schedule. For example:
|
||||
|
||||
* filesystem backups, database backups
|
||||
* task queues
|
||||
|
Loading…
x
Reference in New Issue
Block a user