Sentry / Glitchtip

Hi everyone,

We wanted to ask if there are any plans of sending front end errors e.g. loading form errors to Sentry API ( GlitchTip is an open source implementation of this API)

It would be great to have the issues users are facing (then it’ would be also easier to have issues from non technical people), or is this already done by sentinel ? :thinking:

1 Like

So, I don’t know of any active plans in motion for sending this data anywhere. Client-side errors are captured and recorded as feedback docs. Sentinel does collect all these docs in the medic-users-meta database. So, the data is there but is not automatically exported anywhere else.

With that in mind, there are several options for how we could proceed. We could expand the existing outbound push functionality to also support pushing from medic-users-meta. This would result in a highly configurable/customizable approach for pipelineing feedback (and other meta docs) to external systems.

Another alternative would be to have a more opinionated approach where the CHT has native support for pushing feedback to a configured Sentry API endpoint. (So the end-result is basically the same, but would require less “custom” configuration on each instance.)

I love to see that GlitchTip works with Grafana so we could feasibly include error visualization in CHT Watchdog (cc. @mrjones )!


@magp18 do you have any thoughts on these two alternatives? In general, I think it is best if the CHT integration/interop is not tightly coupled with a particular 3rd-party API so the community is not vender-locked into a particular implementation. However, often one 3rd-party API becomes so widely used that it is a de-facto “standard”. (I am thinking of stuff like the Prometheus metrics api. I would not be opposed to the CHT having an endpoint that natively provided metrics in the format expected by Prometheus.) I don’t have any experience really at all with Sentry/GlitchTip/etc. Is the Sentry API pretty much an “industry standard” or are there other competing alternatives?

If there are a number of different platforms similar to Sentry/GlitchTip that all use competing APIs, then perhaps it is better to just have an “outbound”-style configuration that folks could use to push feedback does to whatever error aggregation service they used…

Heya! Thanks for including me.

Three things come to mind on this topic (see below). They may not be applicable, but let me know if you have any questions!

  1. Watchdog does already include number of feedback docs, see below and reference docs. One thing to note in this graph I grabbed from a production instance is that for 6mo period, it created around 1,000 documents. Update: many of these are likely automated. We do know which are automated and which were manaully submitted by end users (see bottom visualizations below)
  2. Watchdog does have the concept of leveraging data in a postrges database populated by couch2pg or CHT Sync. We see this in the setup docs with one the key targets being CHT Sync backlog metric.
  3. While it’s no longer actively maintained, the cht-app-monitoring-data-ingest repository was an effort to have graphs and alerts in Superset capturing the causes of earlier outages. One the causes of outages errors surfaced in feedback documents. Later, the project focused having these metrics be shown in watchdog.

Sample graph from #1 above

Sample images from item #3 above (source A and B):


1 Like

Thanks both for the comments already! I also just heard of it but my colleague says it seems to be standard.

But the feedback pipeline is already good enough I think.

Thanks also for your answer @mrjones , cht watchdog is something we haven’t explored a lot but it looks like we should look into it, screenshot B looks like what we are looking for!

2 Likes