Backups and Monitoring¶
If you host your own pretix instance, you also need to care about the availability of your service and the safety of your data yourself. This page gives you some information that you might need to do so properly.
There are essentially two things which you should create backups of:
Your SQL database (MySQL or PostgreSQL). This is critical and you should absolutely always create automatic backups of your database. There are tons of tutorials on the internet on how to do this, and the exact process depends on the choice of your database. For MySQL, see
mysqldumpand for PostgreSQL, see the
pg_dumptool. You probably want to create a cronjob that does the backups for you on a regular schedule.
- Data directory
The data directory of your pretix configuration might contain some things that you should back up. If you did not specify a secret in your config file, back up the
.secrettext file in the data directory. If you lose your secret, all currently active user sessions, password reset links and similar things will be rendered invalid. Also, you probably want to backup the
mediasubdirectory of the data directory which contains all user-uploaded and generated files. This includes files you could in theory regenerate (ticket downloads) but also files that you might be legally required to keep (invoice PDFs) or files that you would need to re-upload (event logos, product pictures, etc.). It is up to you if you create regular backups of this data, but we strongly advise you to do so. You can create backups e.g. using
rsync. There is a lot of information on the internet on how to create backups of folders on a Linux machine.
There is no need to create backups of the redis database, if you use it. We only use it for non-critical, temporary or cached data.
To monitor whether your pretix instance is running, you can issue a GET request to
https://pretix.mydomain.com/healthcheck/. This endpoint tests if the connection to the
database, to the configured cache and to redis (if used) is working correctly. If everything
appears to work fine, an empty response with status code
200 is returned.
If there is a problem, a status code in the
5xx range will be returned.
If you want to generate detailed performance statistics of your pretix installation, there is an
https://pretix.mydomain.com/metrics (no slash at the end) which returns a
number of values in the text format understood by monitoring tools like Prometheus. This data
is only collected and exposed if you enable it in the Metrics section of your
pretix configuration. You can also configure basic auth credentials there to protect your
statistics against unauthorized access. The data is temporarily collected in redis, so the
performance impact of this feature depends on the connection to your redis database.
Currently, mostly response times of HTTP requests and background tasks are exposed.
If you want to go even further, you can set the
profile option in the Django settings
section to a value between 0 and 1. If you set it for example to 0.1, then 10% of your requests
(randomly selected) will be run with cProfile activated. The profiling results will be saved
to your data directory. As this might impact performance significantly and writes a lot of data
to disk, we recommend to only enable it for a small number of requests – and only if you are
really interested in the results.
The metrics available in pretix follow the standard metric types from the Prometheus world. Currently, the following metrics are exported:
Counter. Counts requests to Django views, labeled with the resolved
url_name, the used HTTP
Histogram. Measures duration of requests to Django views, labeled with the resolved
url_name, the used HTTP
Counter. Counts executions of background tasks, labeled with the
status. The latter can be
Histogram. Measures duration of successful background task executions, labeled with the
Gauge. Measures number of instances of a certain model within the database, labeled with the
modelname. Starting with pretix 3.11, these numbers might only be approximate for most tables when running on PostgreSQL to mitigate performance impact.
The number of background tasks in the worker queue, labeled with
The age of the longest-waiting in the worker queue in seconds, labeled with