You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

80 lines
4.0 KiB

  1. # Configuring Checks
  2. In SITE_NAME, a **Check** represents a single service you want to
  3. monitor. For example, when monitoring cron jobs, you would create a separate check for
  4. each cron job to be monitored. SITE_NAME pricing plans are structured primarily
  5. around how many checks you can have in your account. You can create checks
  6. either in SITE_NAME web interface or by calling [Management API](../api/).
  7. ## Name, Tags, Description
  8. Describe each check using an optional name, tags, and description fields.
  9. ![Editing name, tags and description](IMG_URL/edit_name.png)
  10. * **Name**: names are optional, but it is a good idea to set them.
  11. Good naming becomes especially important as you add more checks to the
  12. account. SITE_NAME will display check names in the web interface, in email reports,
  13. and notifications.
  14. * **Tags**: a space-separated list of optional labels. Use tags to organize and group
  15. checks within a project. You can tag checks by the environment
  16. (`prod`, `staging`, `dev`, etc.) or by role (`www`, `db`, `worker`, etc.) or using
  17. any other system.
  18. * **Description**: a free-form text field with any related information for your team
  19. or your future self. Describe the cron job's role, who set it up, what to do in
  20. case of failures, where to look for additional information.
  21. ## Simple Schedules
  22. SITE_NAME supports two types of schedules: **Simple** and **Cron**. Use Simple
  23. schedules for monitoring processes that you expect to run at relatively regular time
  24. intervals: once an hour, once a day, once a week.
  25. ![Editing the period and grace time](IMG_URL/edit_simple_schedule.png)
  26. For the simple schedules, you can configure two parameters, Period and Grace Time.
  27. * **Period** is the expected time between pings.
  28. * **Grace Time** is the additional time to wait before sending an alert when a check
  29. is late. Use this parameter to account for small, expected deviations in job
  30. execution times.
  31. ## Cron Schedules
  32. Use "cron" for monitoring processes with more complex schedules. This monitoring mode
  33. ensures that jobs run **at the correct time**, and not just at correct time intervals.
  34. ![Editing cron schedule](IMG_URL/edit_cron_schedule.png)
  35. You will need to specify Cron Expression, Server's Time Zone, and Grace Time.
  36. * **Cron Expression** is the cron expression you specified in the crontab.
  37. * **Server's Time Zone** is the timezone of your server. The cron daemon typically uses
  38. system's local time. If the machine is not using the UTC timezone, you need to
  39. specify it here.
  40. * **Grace Time**, same as for simple schedules, is how long to wait before sending an
  41. alert for a late check.
  42. ## Filtering Rules
  43. In the "Filtering Rules" dialog, you can control several advanced aspects of
  44. how SITE_NAME handles incoming pings for a particular check.
  45. ![Setting filtering rules](IMG_URL/filtering_rules.png)
  46. * **Allowed request methods for HTTP requests**. You can require the ping
  47. requests to use HTTP POST. Use the "Only POST" option if you run into issues of
  48. preview bots hitting the ping URLs when you send them in email or post them in chat.
  49. * **Filter by keywords in the Subject line**. When pinging [via email](../email/),
  50. look for specific keywords in the subject line. If the subject line contains any of
  51. the keywords listed in **Success Keywords**, SITE_NAME will assume it to be a success
  52. signal. Likewise, if it contains any of the keywords listed in **Failure Keywords**,
  53. SITE_NAME will treat it as an explicit failure signal.
  54. For example, this is useful if your backup software sends an email after each backup
  55. run with a different subject line depending on success or failure.
  56. * **Pinging a Paused Check**. Normally, when you ping a paused check, it leaves the
  57. paused state and goes into the "up" state (or the "down" state
  58. in case of [a failure signal](../signaling_failures/)).
  59. You can change this behavior by selecting the "Ignore the ping, stay in
  60. the paused state" option. With this option selected, the paused state becomes "sticky":
  61. SITE_NAME will ignore all incoming pings until you explicitly *resume* the check.