[Sentry Plugin] Add Ability to Make Requests to Multiple Instances

hillmandj commented 2 years ago

Currently the Sentry Plugin makes use of the proxy configuration in app-config.yaml to set a target and Authorization header when making requests to Sentry. This is convenient when an organization only has one instance of Sentry, but larger orgs may have different instances of sentry that they need to make requests to. We should enhance the Sentry plugin to allow orgs to connect to multiple instances of Sentry.

Feature Suggestion

Acceptance Criteria:

Users can set different Sentry hosts to connect to
Users can pass different Authorization / API Keys to each respective host
An annotation in catalog-info.yaml files should be provided to allow users to set their respective host for a given component / service

Possible Implementation

One possible implementation, as mentioned by @freben in the Backstage discord channel is to build a dedicated Sentry backend plugin that follows a similar pattern to how the Jenkins backend plugin is setup. Please see the Jenkins multiple instances documentation for context.

This would allow users to set this configuration with respect to instances and their authorization keys on the backend, and not affect the front end implementation very much. This may look something like this:

sentry:
  instances:
    - name: default
      baseUrl: https://sentry.example.com
      apiKey: [API_KEY_1]
    - name: another-instance
      baseUrl: https://sentry-foo.example.com
      apiKey: [API_KEY_2]

An annotation could then be added to the catalog-info.yaml file to point to the correct instance like so:

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: artist-lookup
  annotations:
    'sentry.io/project-slug': YOUR_PROJECT_SLUG
    'sentry.io/instance-name': another-instance

If no annotation is provided for instance-name, it should fall back to the default instance.

Context

This has been brought up on the Backstage discord, but essentially some orgs make use of multiple instances of Sentry for a variety of reasons. In some cases it has to do with ownership of services being delegated to engineers in specific regions, in other cases different hosts are used or spun up per environment (rather than leveraging passing environment to Sentry). There may also be other considerations when it comes to whether or not multiple instances should be stood up (rate limiting, costs, etc.).

Though I'm sure many small to medium sized organizations can get by with a single instance, larger orgs are more likely to use multiple instance of Sentry, and would need this enhancement in order to render all of their Sentry data across services.

freben commented 2 years ago

Or perhaps adding the instance name as an optional prefix part of the slug if possible. One annotation may be more convenient than two; this is something that I've seen other plugins do.

Would love it if you got around to contributing this!

namco1992 commented 2 years ago

Hi @hillmandj @freben,

We've been following this topic for a while too, thanks for taking the initiative!

Besides the Jenkins example mentioned in the issue, there are a few discussions out there, to name a few: https://github.com/RoadieHQ/roadie-backstage-plugins/issues/235 https://github.com/RoadieHQ/roadie-backstage-plugins/tree/main/plugins/frontend/backstage-plugin-argo-cd#support-for-multiple-argocd-instances---option-1

Each of them is tackling the issue with different approaches. The Prometheus plugin went with a more sophisticated proxy config:

proxy: 
  '/prometheus/api':
    target: http://localhost:9090/api/v1/
  '/prometheusTeamB/api':
    target: http://localhost:9999/api/v1/

prometheus:
   proxyPath: /prometheus/api
   instances:
     - name: prometheusTeamB
       proxyPath: /prometheusTeamB/api

And for the ArgoCD plugin, the frontend even supports both proxy and backend plugin (https://github.com/RoadieHQ/roadie-backstage-plugins/blob/main/plugins/frontend/backstage-plugin-argo-cd/src/api/index.ts#L133).

As I read from the discussion here, does it mean that building a backend plugin is a preferred approach for such use case?

hillmandj commented 2 years ago

As I read from the discussion here, does it mean that building a backend plugin is a preferred approach for such use case?

@namco1992 that's my understanding. I don't have a very strong opinion, but based on what you put here I think the pattern for Jenkins plugin is a bit cleaner. I do agree that it would be good to standardize this approach, but I'm not sure how that would be enforced. @freben any thoughts?

github-actions[bot] commented 1 year ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

backstage / backstage