Sign In

Asynchronous Workers

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.

Registering a Task

Sentry configures tasks with a special decorator that allows us more explicit control over the callable.

Copied
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.

Running a Worker

Workers can be run by using the Sentry CLI.

Copied
$ sentry run worker

Starting the Cron Process

Sentry schedules routine jobs via a cron process:

Copied
SENTRY_CONF=/etc/sentry sentry run cron

Configuring the Broker

Sentry supports two primary brokers which may be adjusted depending on your workload: RabbitMQ and Redis.

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.

Copied
BROKER_URL = "redis://localhost:6379/0"

If your Redis connection requires a password for authentication, you need to use the following format:

Copied
BROKER_URL = "redis://:password@localhost:6379/0"

RabbitMQ

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.

Copied
BROKER_URL = "amqp://guest:guest@localhost:5672/sentry"
You can edit this page on GitHub.