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.

184 lines
5.4 KiB

  1. # Self-Hosted Healthchecks
  2. Healthchecks is open-source, and is licensed under the BSD 3-clause license.
  3. As an alternative to using the hosted service at
  4. [https://healthchecks.io](https://healthchecks.io), you have the option to host a
  5. Healthchecks instance yourself.
  6. The building blocks are:
  7. * Python 3.6+
  8. * Django 3
  9. * PostgreSQL or MySQL
  10. ## Setting Up for Development
  11. You can set up a development environment in a Python
  12. [virtual environment](https://docs.python.org/3/tutorial/venv.html)
  13. on your local system to develop a new feature, write a new integration
  14. or test a bugfix.
  15. The following instructions assume you are using a Debian-based OS.
  16. * Install dependencies:
  17. $ sudo apt-get update
  18. $ sudo apt-get install -y gcc python3-dev python3-venv
  19. * Prepare directory for project code and virtualenv. Feel free to use a
  20. different location:
  21. $ mkdir -p ~/webapps
  22. $ cd ~/webapps
  23. * Prepare virtual environment
  24. (with virtualenv you get pip, we'll use it soon to install requirements):
  25. $ python3 -m venv hc-venv
  26. $ source hc-venv/bin/activate
  27. * Check out project code:
  28. $ git clone https://github.com/healthchecks/healthchecks.git
  29. * Install requirements (Django, ...) into virtualenv:
  30. $ pip install wheel
  31. $ pip install -r healthchecks/requirements.txt
  32. * Create database tables and a superuser account:
  33. $ cd ~/webapps/healthchecks
  34. $ ./manage.py migrate
  35. $ ./manage.py createsuperuser
  36. With the default configuration, Healthchecks stores data in a SQLite file
  37. `hc.sqlite` in the project directory (`~/webapps/healthchecks/`).
  38. * Run tests:
  39. $ ./manage.py test
  40. * Run development server:
  41. $ ./manage.py runserver
  42. * From another shell, run the `sendalerts` management command, responsible for
  43. sending out notifications:
  44. $ ./manage.py sendalerts
  45. At this point, the site should now be running at `http://localhost:8000`.
  46. ## Accessing Administration Panel
  47. Healthchecks comes with Django's administration panel where you can manually
  48. view and modify user accounts, projects, checks, integrations etc. To access it,
  49. if you haven't already, create a superuser account:
  50. $ ./manage.py createsuperuser
  51. Then, log into the site using the superuser credentials. Once logged in,
  52. click on the "Account" dropdown in top navigation, and select "Site Administration".
  53. ## Sending Emails
  54. Healthchecks needs SMTP credentials to be able to send emails:
  55. login links, monitoring notifications, monthly reports.
  56. Specify SMTP credentials using the `EMAIL_HOST`, `EMAIL_PORT`, `EMAIL_HOST_USER`,
  57. `EMAIL_HOST_PASSWORD`, and `EMAIL_USE_TLS` environment variables. Example:
  58. ```ini
  59. EMAIL_HOST=my-smtp-server-here.com
  60. EMAIL_PORT=587
  61. EMAIL_HOST_USER=my-username
  62. EMAIL_HOST_PASSWORD=mypassword
  63. EMAIL_USE_TLS = True
  64. ```
  65. You can read more about handling outbound email in the Django documentation,
  66. [Sending Email](https://docs.djangoproject.com/en/3.1/topics/email/) section.
  67. ## Receiving Emails
  68. Healthchecks comes with a `smtpd` management command, which starts up a
  69. SMTP listener service. With the command running, you can ping your
  70. checks by sending email messages.
  71. Start the SMTP listener on port 2525:
  72. $ ./manage.py smtpd --port 2525
  73. Send a test email:
  74. $ curl --url 'smtp://127.0.0.1:2525' \
  75. --mail-from '[email protected]' \
  76. --mail-rcpt '[email protected]' \
  77. -F '='
  78. ## Sending Status Notifications
  79. The `sendalerts` management command continuously polls the database for any checks
  80. changing state, and sends out notifications as needed.
  81. When `sendalerts` is not running, the Healthchecks instance will not send out any
  82. alerts.
  83. Within an activated virtualenv, run the `sendalerts` command like so:
  84. $ ./manage.py sendalerts
  85. In a production setup, make sure the `sendalerts` command can survive
  86. server restarts.
  87. ## Database Cleanup
  88. With time and use the Healthchecks database will grow in size. You may
  89. decide to prune old data: inactive user accounts, old checks not assigned
  90. to users, old records of outgoing email messages and old records of received pings.
  91. There are separate Django management commands for each task:
  92. Remove old records from the `api_ping` table. For each check, keep 100 most
  93. recent pings:
  94. $ ./manage.py prunepings
  95. Remove old records of sent notifications. For each check, remove notifications that
  96. are older than the oldest stored ping for the corresponding check.
  97. $ ./manage.py prunenotifications
  98. Remove inactive user accounts:
  99. ```bash
  100. $ ./manage.py pruneusers
  101. ```
  102. Remove old records from the `api_tokenbucket` table. The TokenBucket
  103. model is used for rate-limiting login attempts and similar operations.
  104. Any records older than one day can be safely removed.
  105. $ ./manage.py prunetokenbucket
  106. Remove old records from the `api_flip` table. The Flip objects are used to track
  107. status changes of checks, and to calculate downtime statistics month by month.
  108. Flip objects from more than 3 months ago are not used and can be safely removed.
  109. $ ./manage.py pruneflips
  110. When you first try these commands on your data, it is a good idea to
  111. test them on a copy of your database, and not on the live system.
  112. In a production setup, you will want to run these commands regularly, as well as
  113. have regular, automatic database backups set up.
  114. ## Next Steps
  115. Get the [source code](https://github.com/healthchecks/healthchecks).
  116. See [Configuration](../self_hosted_configuration/) for a list of configuration options.