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.

293 lines
9.2 KiB

10 years ago
9 years ago
9 years ago
9 years ago
9 years ago
10 years ago
10 years ago
10 years ago
10 years ago
  1. # healthchecks
  2. [![Build Status](https://travis-ci.org/healthchecks/healthchecks.svg?branch=master)](https://travis-ci.org/healthchecks/healthchecks)
  3. [![Coverage Status](https://coveralls.io/repos/healthchecks/healthchecks/badge.svg?branch=master&service=github)](https://coveralls.io/github/healthchecks/healthchecks?branch=master)
  4. ![Screenshot of Welcome page](/static/img/welcome.png?raw=true "Welcome Page")
  5. ![Screenshot of My Checks page](/static/img/my_checks.png?raw=true "My Checks Page")
  6. ![Screenshot of Period/Grace dialog](/static/img/period_grace.png?raw=true "Period/Grace Dialog")
  7. ![Screenshot of Cron dialog](/static/img/cron.png?raw=true "Cron Dialog")
  8. ![Screenshot of Integrations page](/static/img/channels.png?raw=true "Integrations Page")
  9. healthchecks is a watchdog for your cron jobs. It's a web server that listens for pings from your cron jobs, plus a web interface.
  10. It is live here: [http://healthchecks.io/](http://healthchecks.io/)
  11. The building blocks are:
  12. * Python 3
  13. * Django 2
  14. * PostgreSQL or MySQL
  15. ## Setting Up for Development
  16. These are instructions for setting up healthchecks Django app
  17. in development environment.
  18. * prepare directory for project code and virtualenv:
  19. $ mkdir -p ~/webapps
  20. $ cd ~/webapps
  21. * prepare virtual environment
  22. (with virtualenv you get pip, we'll use it soon to install requirements):
  23. $ virtualenv --python=python3 hc-venv
  24. $ source hc-venv/bin/activate
  25. * check out project code:
  26. $ git clone https://github.com/healthchecks/healthchecks.git
  27. * install requirements (Django, ...) into virtualenv:
  28. $ pip install -r healthchecks/requirements.txt
  29. * healthchecks is configured to use a SQLite database by default. To use
  30. PostgreSQL or MySQL database, create and edit `hc/local_settings.py` file.
  31. There is a template you can copy and edit as needed:
  32. $ cd ~/webapps/healthchecks
  33. $ cp hc/local_settings.py.example hc/local_settings.py
  34. * create database tables and the superuser account:
  35. $ cd ~/webapps/healthchecks
  36. $ ./manage.py migrate
  37. $ ./manage.py createsuperuser
  38. * run development server:
  39. $ ./manage.py runserver
  40. The site should now be running at `http://localhost:8080`
  41. To log into Django administration site as a super user,
  42. visit `http://localhost:8080/admin`
  43. ## Configuration
  44. Site configuration is kept in `hc/settings.py`. Additional configuration
  45. is loaded from `hc/local_settings.py` file, if it exists. You
  46. can create this file (should be right next to `settings.py` in the filesystem)
  47. and override settings as needed.
  48. Some useful settings keys to override are:
  49. `SITE_ROOT` is used to build fully qualified URLs for pings, and for use in
  50. emails and notifications. Example:
  51. ```python
  52. SITE_ROOT = "https://my-monitoring-project.com"
  53. ```
  54. `SITE_NAME` has the default value of "Mychecks" and is used throughout
  55. the templates. Replace it with your own name to personalize your installation.
  56. Example:
  57. ```python
  58. SITE_NAME = "My Monitoring Project"
  59. ```
  60. `REGISTRATION_OPEN` controls whether site visitors can create new accounts.
  61. Set it to `False` if you are setting up a private healthchecks instance, but
  62. it needs to be publicly accessible (so, for example, your cloud services
  63. can send pings).
  64. If you close new user registration, you can still selectively invite users
  65. to your team account.
  66. ## Database Configuration
  67. Database configuration is stored in `hc/settings.py` and can be overriden
  68. in `hc/local_settings.py`. The default database engine is SQLite. To use
  69. PostgreSQL, create `hc/local_settings.py` if it does not exist, and put the
  70. following in it, changing it as neccessary:
  71. ```python
  72. DATABASES = {
  73. 'default': {
  74. 'ENGINE': 'django.db.backends.postgresql',
  75. 'NAME': 'your-database-name-here',
  76. 'USER': 'your-database-user-here',
  77. 'PASSWORD': 'your-database-password-here',
  78. 'TEST': {'CHARSET': 'UTF8'}
  79. }
  80. }
  81. ```
  82. For MySQL:
  83. ```python
  84. DATABASES = {
  85. 'default': {
  86. 'ENGINE': 'django.db.backends.mysql',
  87. 'NAME': 'your-database-name-here',
  88. 'USER': 'your-database-user-here',
  89. 'PASSWORD': 'your-database-password-here',
  90. 'TEST': {'CHARSET': 'UTF8'}
  91. }
  92. }
  93. ```
  94. You can also use `hc/local_settings.py` to read database
  95. configuration from environment variables like so:
  96. ```python
  97. import os
  98. DATABASES = {
  99. 'default': {
  100. 'ENGINE': os.environ['DB_ENGINE'],
  101. 'NAME': os.environ['DB_NAME'],
  102. 'USER': os.environ['DB_USER'],
  103. 'PASSWORD': os.environ['DB_PASSWORD'],
  104. 'TEST': {'CHARSET': 'UTF8'}
  105. }
  106. }
  107. ```
  108. ## Sending Emails
  109. healthchecks must be able to send email messages, so it can send out login
  110. links and alerts to users. Put your SMTP server configuration in
  111. `hc/local_settings.py` like so:
  112. ```python
  113. EMAIL_HOST = "your-smtp-server-here.com"
  114. EMAIL_PORT = 587
  115. EMAIL_HOST_USER = "username"
  116. EMAIL_HOST_PASSWORD = "password"
  117. EMAIL_USE_TLS = True
  118. ```
  119. For more information, have a look at Django documentation,
  120. [Sending Email](https://docs.djangoproject.com/en/1.10/topics/email/) section.
  121. ## Receiving Emails
  122. healthchecks comes with a `smtpd` management command, which starts up a
  123. SMTP listener service. With the command running, you can ping your
  124. checks by sending email messages
  125. to `[email protected]` email addresses.
  126. Start the SMTP listener on port 2525:
  127. $ ./manage.py smtpd --port 2525
  128. Send a test email:
  129. $ curl --url 'smtp://127.0.0.1:2525' \
  130. --mail-from '[email protected]' \
  131. --mail-rcpt '[email protected]' \
  132. -F '='
  133. ## Sending Status Notifications
  134. healtchecks comes with a `sendalerts` management command, which continuously
  135. polls database for any checks changing state, and sends out notifications as
  136. needed. Within an activated virtualenv, you can manually run
  137. the `sendalerts` command like so:
  138. $ ./manage.py sendalerts
  139. In a production setup, you will want to run this command from a process
  140. manager like [supervisor](http://supervisord.org/) or systemd.
  141. ## Database Cleanup
  142. With time and use the healthchecks database will grow in size. You may
  143. decide to prune old data: inactive user accounts, old checks not assigned
  144. to users, records of outgoing email messages and records of received pings.
  145. There are separate Django management commands for each task:
  146. * Remove old records from `api_ping` table. For each check, keep 100 most
  147. recent pings:
  148. ```
  149. $ ./manage.py prunepings
  150. ```
  151. * Remove checks older than 2 hours that are not assigned to users. Such
  152. checks are by-products of random visitors and robots loading the welcome
  153. page and never setting up an account:
  154. ```
  155. $ ./manage.py prunechecks
  156. ```
  157. * Remove old records of sent notifications. For each check, remove
  158. notifications that are older than the oldest stored ping for same check.
  159. ```
  160. $ ./manage.py prunenotifications
  161. ```
  162. * Remove user accounts that match either of these conditions:
  163. * Account was created more than 6 months ago, and user has never logged in.
  164. These can happen when user enters invalid email address when signing up.
  165. * Last login was more than 6 months ago, and the account has no checks.
  166. Assume the user doesn't intend to use the account any more and would
  167. probably *want* it removed.
  168. ```
  169. $ ./manage.py pruneusers
  170. ```
  171. When you first try these commands on your data, it is a good idea to
  172. test them on a copy of your database, not on the live database right away.
  173. In a production setup, you should also have regular, automated database
  174. backups set up.
  175. ## Integrations
  176. ### Discord
  177. To enable Discord integration, you will need to:
  178. * register a new application on https://discordapp.com/developers/applications/me
  179. * add a redirect URI to your Discord application. The URI format is
  180. `SITE_ROOT/integrations/add_discord/`. For example, if you are running a
  181. development server on `localhost:8000` then the redirect URI would be
  182. `http://localhost:8000/integrations/add_discord/`
  183. * Look up your Discord app's Client ID and Client Secret. Add them
  184. to your `hc/local_settings.py` file as `DISCORD_CLIENT_ID` and
  185. `DISCORD_CLIENT_SECRET` fields.
  186. ### Pushover
  187. To enable Pushover integration, you will need to:
  188. * register a new application on https://pushover.net/apps/build
  189. * enable subscriptions in your application and make sure to enable the URL
  190. subscription type
  191. * add the application token and subscription URL to `hc/local_settings.py`, as
  192. `PUSHOVER_API_TOKEN` and `PUSHOVER_SUBSCRIPTION_URL`
  193. ### Telegram
  194. * Create a Telegram bot by talking to the
  195. [BotFather](https://core.telegram.org/bots#6-botfather). Set the bot's name,
  196. description, user picture, and add a "/start" command.
  197. * After creating the bot you will have the bot's name and token. Add them
  198. to your `hc/local_settings.py` file as `TELEGRAM_BOT_NAME` and
  199. `TELEGRAM_TOKEN` fields.
  200. * Run `settelegramwebhook` management command. This command tells Telegram
  201. where to forward channel messages by invoking Telegram's
  202. [setWebhook](https://core.telegram.org/bots/api#setwebhook) API call:
  203. ```
  204. $ ./manage.py settelegramwebhook
  205. Done, Telegram's webhook set to: https://my-monitoring-project.com/integrations/telegram/bot/
  206. ```
  207. For this to work, your `SITE_ROOT` needs to be correct and use "https://"
  208. scheme.