Sentry comes with a built-in queue to process tasks in a more asynchronous fashion. For example when an event comes in instead of writing it to the database immediately, it sends a job to the queue so that the request can be returned right away, and the background workers handle actually saving that data.
Sentry relies on the Celery library for managing workers.
Sentry configures tasks with a special decorator that allows us more explicit control over the callable.
from sentry.tasks.base import instrumented_task @instrumented_task( name="sentry.tasks.do_work", queue="important_queue", default_retry_delay=60 * 5, max_retries=None, ) def do_work(kind_of_work, **kwargs): # ...
There's a few key differences we practice:
- The task name must be declared.
- Tasks must accept `**kwargs`` to handle rolling compatibility.
- Tasks should automatically retry on failure.
Workers can be run by using the Sentry CLI.
$ sentry run worker
Sentry schedules routine jobs via a cron process:
SENTRY_CONF=/etc/sentry sentry run cron
Sentry supports two primary brokers which may be adjusted depending on your workload: RabbitMQ and Redis.
The default broker is Redis, and will work under most situations. The primary limitation to using Redis is that all pending work must fit in memory.
BROKER_URL = "redis://localhost:6379/0"
If your Redis connection requires a password for authentication, you need to use the following format:
BROKER_URL = "redis://:password@localhost:6379/0"
If you run with a high workload, or have concerns about fitting the pending workload in memory, then RabbitMQ is an ideal candidate for backing Sentry’s workers.
BROKER_URL = "amqp://guest:guest@localhost:5672/sentry"