Add support for Sentry Crons to Celery Beat

[antonpirker]

Add a decorator for celery beat tasks (or something like) where you related a sentry monitor_id with the task.

In the task submit this events to sentry:

When the task starts:

{
    "event_id":"6650bef0d8ba4a70be1d9a5ed6ee5dff",
    "sent_at":"2023-03-01T14:08:34Z",
    "dsn":"xxx",
    "sdk":{
        "name":"sentry.python.celery",
        "version":"1.16.0"
    }
}
{"type":"check_in","content_type":"application\/json"}
{
    "check_in_id":"39588134018140db8b7eb6628bccb636",
    "monitor_id":"4dc8556e-0392-45c7-bd56-9f8cf513ea42",
    "status":"in_progress",
    "duration":null
}

When the task finishes (or errors, the the status needs to be "error"):

{
    "event_id":"ff8bd082278e48d9b6632f88d642cdba",
    "sent_at":"2023-03-01T14:08:34Z",
    "dsn":"xxx",
    "sdk":{
        "name":"sentry.python.celery",
        "version":"1.16.0"
    }
}
{"type":"check_in","content_type":"application\/json"}
{
    "check_in_id":"39588134018140db8b7eb6628bccb636",
    "monitor_id":"4dc8556e-0392-45c7-bd56-9f8cf513ea42",
    "status":"ok",
    "duration":null
}

[evanpurkhiser]

The ideal for this will be that the user does nothing other than

Enable Sentry Crons for all of my celery beat tasks

We have (are currently adding) added upsert support to checkins with user defined slugs (getsentry/sentry#42881).

This means we will add a parameter to the checkin to allow specifying what the schedule of the monitor is, and upon first checkin it will autoamtically create the monitor with the specified monitor slug. Still TBD what passing the schedule with the checkin will look like (we'll want to translate the celery schedule to match what sentry expects), but doing this essentially means there should be practically zero configuration needed to start monitoring celery tasks.

Also worth noting is that ingest is very likely going to only support referencing monitors via the slugs and not by GUID.

So in your examples I think what this would look like is:

{
    "event_id":"6650bef0d8ba4a70be1d9a5ed6ee5dff",
    "sent_at":"2023-03-01T14:08:34Z",
    "dsn":"xxx",
    "sdk":{
        "name":"sentry.python.celery",
        "version":"1.16.0"
    }
}
{"type":"check_in","content_type":"application\/json"}
{
    "monitor_slug":"my-monitor",
    "check_in_id":"39588134018140db8b7eb6628bccb636",
	"schedule": "* * * * *",
    "status":"in_progress",
    "duration":null
}

[antonpirker]

Thanks for the update @evanpurkhiser
"Enable Sentry for all celery beat tasks" seems cool (and not that hard to do. We create a CeleryCronsIntegration and when loaded it slaps the decorator on all tasks.)

Celery beat tasks can have multiple things as a schedule:
a) a int number of seconds (specifying and interval)
b) a timedelta (specifying an interval)
c) a crontab
d) a solar scheduling (where you say: at "sunset" at geo location lat,lon)

What I understand from the UI of crons in the backend c) will be easy, and also a), and b) are easy.
The solar one d) (or other custom scheduling that people implemented) will be not working right now. But I guess it is OK if we do not suppport everything under the sun at the beginning.

[evanpurkhiser]

Yes exactly. And yeah I don’t think we’ll need to support everything under the sun. I can imagine we produce some logging in the SDK that says “NOTICE: Unable to enable auto cron monitor instrumentation for xyz”

cc @dcramer to make sure this all aligns with his vision of this integration