Skip to main content
Ungathered Thoughts

GlitchTip API CLIent

In GlitchTip's community chat a few days ago, a user asked about filtering event logging and issue reports in GlitchTip.

Depending on your GlitchTip / Sentry client library, you have various options to control what gets reported to Sentry or GlitchTip. The Python and Drupal Raven integrations support Sentry's before_send pattern, while other client libraries may or may not allow you to "silence" reports that might generate a lot of noise in your Sentry.

An example of this I've seen is reports for each 404 hit in some applications, which can result in a bunch of needless events and eventually issues in GlitchTip that are associated with the 404s.

There was a question raised in the GlitchTip channel about how to automatically silence messages in GlitchTip. The user asking didn't have access to filter clientside, so they were looking for a solution to remove entries within GlitchTip.

My take is that the preferred order of solving this is:

  1. If at all possible, prevent issues being recorded from the client. Eliminating the event report means less data is gathered in GlitchTip. This is optimal.
  2. If you can't handle it in the client configuration, you have to do it at the GlitchTip side.
    1. A WAF-style filter in front of GlitchTip may be an option to prevent the submission reaching GlitchTip at all. This might be a configuration in a reverse proxy that GlitchTip sits behind.
    2. Filtering could be introduced in GlitchTip to provide configurable filters - but event reporting is a performance critical pathway in GlitchTip, so this would need to be kept light.
    3. Filtering can also be implemented in GlitchTip's ingest path - this was the maintainer's recommendation in thread. This is also a performance-sensitive path in GlitchTip so needs to be carefully tested.
    4. Once the event is ingested and the item created, there's capacity to remove the item from GlitchTip.

It struck me that you could do something like:

# Get a token from /profile/auth-tokens in GlitchTip.
export GLITCHTIP_API_TOKEN=ABCDEF
curl -H 'Accept: application/json' \
  -H "Authorization: Bearer $GLITCHTIP_API_TOKEN" \
  'https://glitchtip.example.org/api/0/organizations/some-org/issues/?query=is:unresolved%20level:warning&project=2' \
  | jq '.[].id' \
  | while read ISSUE_ID ; do
  curl -H 'Accept: application/json' \
    -X DELETE \
    -H "Authorization: Bearer $GLITCHTIP_API_TOKEN" \
    'https://glitchtip.example.org/api/0/organizations/some-org/issues/$ISSUE_ID'

I figured I'd test this out, and the one-liner grew into a little bash script to show or delete issues from GlitchTip. Deleting issues should delete related events.

This is not the ideal solution - we want to reduce waste as a first step, recycle second; similarly we want to reduce event capture as a first step, and then as a second strategy remove events that we shouldn't have captured. (Maybe that wanted a fishing analogy, IDK.)

But, as a strategy for periodically clearing out events we don't want captured ... it might work. And that might be useful to me, or you. The tool is now available as xurizaemon/gt-cli.

I'm wondering at how I named it now, as I don't at all expect this to become the GlitchTip CLI. The Django app already has a local CLI, ./manage.py, and this has a couple commands only for the remote API. It's an experiment which I'm sharing just to share. If you find it useful, all the better!

A more efficient approach would likely be to PR some additional ./manage.py subcommands to filter out issues/events.