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.

219 lines
7.2 KiB

10 years ago
9 years ago
9 years ago
10 years ago
10 years ago
10 years ago
9 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](/stuff/screenshots/welcome.png?raw=true "Welcome Page")
  5. ![Screenshot of My Checks page](/stuff/screenshots/my_checks.png?raw=true "My Checks Page")
  6. ![Screenshot of Period/Grace dialog](/stuff/screenshots/period_grace.png?raw=true "Period/Grace Dialog")
  7. ![Screenshot of Channels page](/stuff/screenshots/channels.png?raw=true "Channels Page")
  8. 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.
  9. It is live here: [http://healthchecks.io/](http://healthchecks.io/)
  10. The building blocks are:
  11. * Python 2 or Python 3
  12. * Django 1.9
  13. * PostgreSQL or MySQL
  14. ## Setting Up for Development
  15. These are instructions for setting up HealthChecks Django app
  16. in development environment.
  17. * prepare directory for project code and virtualenv:
  18. $ mkdir -p ~/webapps
  19. $ cd ~/webapps
  20. * prepare virtual environment
  21. (with virtualenv you get pip, we'll use it soon to install requirements):
  22. $ virtualenv --python=python3 hc-venv
  23. $ source hc-venv/bin/activate
  24. * check out project code:
  25. $ git clone https://github.com/healthchecks/healthchecks.git
  26. * install requirements (Django, ...) into virtualenv:
  27. $ pip install -r healthchecks/requirements.txt
  28. * make sure PostgreSQL server is installed and running, create
  29. database "hc":
  30. $ psql --user postgres
  31. postgres=# create database hc;
  32. * create database tables and the superuser account:
  33. $ cd ~/webapps/healthchecks
  34. $ ./manage.py migrate
  35. $ ./manage.py createsuperuser
  36. * run development server:
  37. $ ./manage.py runserver
  38. The site should now be running at `http://localhost:8080`
  39. To log into Django administration site as a super user,
  40. visit `http://localhost:8080/admin`
  41. ## Configuration
  42. Site configuration is kept in `hc/settings.py`. Additional configuration
  43. is loaded from `hc/local_settings.py` file, if it exists. You
  44. can create this file (should be right next to `settings.py` in the filesystem)
  45. and override settings as needed.
  46. Some useful settings keys to override are:
  47. `SITE_ROOT` is used to build fully qualified URLs for pings, and for use in
  48. emails and notifications. Example:
  49. SITE_ROOT = "https://my-monitoring-project.com"`
  50. `SITE_NAME` has the default value of "healthchecks.io" and is used throughout
  51. the templates. Replace it with your own name to personalize your installation.
  52. Example:
  53. SITE_NAME = "My Monitoring Project"
  54. ## Database Configuration
  55. Database configuration is stored in `hc/settings.py` and can be overriden
  56. in `hc/local_settings.py`. The default database engine is SQLite. To use
  57. PostgreSQL, create `hc/local_settings.py` if it does not exist, and put the
  58. following in it, changing it as neccessary:
  59. DATABASES = {
  60. 'default': {
  61. 'ENGINE': 'django.db.backends.postgresql',
  62. 'NAME': 'your-database-name-here',
  63. 'USER': 'your-database-user-here',
  64. 'PASSWORD': 'your-database-password-here',
  65. 'TEST': {'CHARSET': 'UTF8'}
  66. }
  67. }
  68. For MySQL:
  69. DATABASES = {
  70. 'default': {
  71. 'ENGINE': 'django.db.backends.mysql',
  72. 'NAME': 'your-database-name-here',
  73. 'USER': 'your-database-user-here',
  74. 'PASSWORD': 'your-database-password-here',
  75. 'TEST': {'CHARSET': 'UTF8'}
  76. }
  77. }
  78. You can also use `hc/local_settings.py` to read database
  79. configuration from environment variables like so:
  80. import os
  81. DATABASES = {
  82. 'default': {
  83. 'ENGINE': os.env['DB_ENGINE'],
  84. 'NAME': os.env['DB_NAME'],
  85. 'USER': os.env['DB_USER'],
  86. 'PASSWORD': os.env['DB_PASSWORD'],
  87. 'TEST': {'CHARSET': 'UTF8'}
  88. }
  89. }
  90. ## Sending Emails
  91. healthchecks must be able to send email messages, so it can send out login
  92. links and alerts to users. You will likely need to tweak email configuration
  93. before emails will work. healthchecks uses
  94. [djmail](http://bameda.github.io/djmail/) for sending emails asynchronously.
  95. Djmail is a BSD Licensed, simple and nonobstructive django email middleware.
  96. It can be configured to use any regular Django email backend behind the
  97. scenes. For example, the healthchecks.io site uses
  98. [django-ses-backend](https://github.com/piotrbulinski/django-ses-backend/)
  99. and the email configuration in `hc/local_settings.py` looks as follows:
  100. DEFAULT_FROM_EMAIL = '[email protected]'
  101. DJMAIL_REAL_BACKEND = 'django_ses_backend.SESBackend'
  102. AWS_SES_ACCESS_KEY_ID = "put-access-key-here"
  103. AWS_SES_SECRET_ACCESS_KEY = "put-secret-access-key-here"
  104. AWS_SES_REGION_NAME = 'us-east-1'
  105. AWS_SES_REGION_ENDPOINT = 'email.us-east-1.amazonaws.com'
  106. ## Sending Status Notifications
  107. healtchecks comes with a `sendalerts` management command, which continuously
  108. polls database for any checks changing state, and sends out notifications as
  109. needed. Within an activated virtualenv, you can manually run
  110. the `sendalerts` command like so:
  111. $ ./manage.py sendalerts
  112. In a production setup, you will want to run this command from a process
  113. manager like [supervisor](http://supervisord.org/) or systemd.
  114. ## Database Cleanup
  115. With time and use the healthchecks database will grow in size. You may
  116. decide to prune old data: inactive user accounts, old checks not assigned
  117. to users, records of outgoing email messages and records of received pings.
  118. There are separate Django management commands for each task:
  119. * Remove old records from `api_ping` table. For each check, keep 100 most
  120. recent pings:
  121. ````
  122. $ ./manage.py prunepings
  123. ````
  124. * Remove checks older than 2 hours that are not assigned to users. Such
  125. checks are by-products of random visitors and robots loading the welcome
  126. page and never setting up an account:
  127. ```
  128. $ ./manage.py prunechecks
  129. ```
  130. * Remove records of sent email messages older than 7 days.
  131. ````
  132. $ ./manage.py pruneemails
  133. ````
  134. * Remove user accounts that match either of these conditions:
  135. * Account was created more than a month ago, and user has never logged in.
  136. These can happen when user enters invalid email address when signing up.
  137. * Last login was more than a month ago, and the account has no checks.
  138. Assume the user doesn't intend to use the account any more and would
  139. probably *want* it removed.
  140. ```
  141. $ ./manage.py pruneusers
  142. ```
  143. When you first try these commands on your data, it is a good idea to
  144. test them on a copy of your database, not on the live database right away.
  145. In a production setup, you should also have regular, automated database
  146. backups set up.
  147. ## Integrations
  148. ### Pushover
  149. To enable Pushover integration, you will need to:
  150. * register a new application on https://pushover.net/apps/build
  151. * enable subscriptions in your application and make sure to enable the URL
  152. subscription type
  153. * add the application token and subscription URL to `hc/local_settings.py`, as
  154. `PUSHOVER_API_TOKEN` and `PUSHOVER_SUBSCRIPTION_URL`