1561320 - Support sentry again somehow

Status: RESOLVED FIXED

(Taskcluster :: Services, enhancement)

Description

[Brian Stack [:bstack]]

Probably a simpler way than before. Options include:

1. directly configuring sentry keys in each service
2. having a thing that stuffs records from stackdriver into sentry
3. ???

Comment 1

[Dustin J. Mitchell [:dustin] (he/him)]

Pete notes that workers still use the auth sentry endpoint.

I mildly object to having a sentry-specific endpoint in the auth service. Imagine down the road that we get users with three other error-reporting services (companyA, companyB, companyC). Then we have four endpoints: auth.sentryDSN, auth.companyAKey, auth.companyBCreds, auth.companyCToken. And we'll need to configure the auth service to support getting credentials for only one of those. In that case, what do the other three endpoints return? 400? 404? It seems a very odd fit for an API.

Other options might be:

• Modify workers to take sentry keys (and eventually, other error-reporting services' credentials) directly in their config
• auth.reportError(..) that forwards the error on to the configured service
• auth.errorReportingCredentials(targetService) that returns credentials for the named service (e.g., "companyB") in an AnyOf schema.

I'm totally fine with not solving this now and sticking with the working-just-fine auth.sentryDSN endpoint (but perhaps with the new code in tc-lib-monitor reflecting future plans). Given priorities and available engineering time, that is probably a good choice.

Comment 3

[Dustin J. Mitchell [:dustin] (he/him)]

We agreed yesterday that while this is still something we want to do, it does not block the handover to cloudops -- we'll continue the status quo through that handover.

Comment 4

[Dustin J. Mitchell [:dustin] (he/him)]

I optimistically thought I could hack on this. I don't have time :)