-
Notifications
You must be signed in to change notification settings - Fork 17
Sentry UI profiling and metrics #4635
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
noracato
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice job. Just one question about the document policy!
| Sentry.init do |config| | ||
| # Set release version | ||
| config.release = 'stable.01' | ||
| config.release = Settings.version |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should start to manually update the string here. Settings.version comes from the docker compose on the (production) server, and will not change when we deploy.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I find the idea of manually setting it here for each release too easy to forget. I think it would be best to come up with a rather automatic way, if not fully automatic perhaps a automatic check during one of our CI/CD steps. And that goes for all our apps actually (at least all apps that use Sentry).
For example, I see a couple of routes depending on what's possible:
- A: We add another entry
Settings.release(to config/settings.yml) reading from a new ENV variable if we find a way to keep that ENV updated with the current "git release tag" (not sure if that is possible both in beta and production).
release: <%= ENV.fetch('RELEASE_TAG', '2026-01') %>
- B: We populate the
Settings.releaseourselves and we make sure that during a relevant CI/CD step we corroborate that this value is indeed the current "git release tag" (If its easier for the CI/CD check we could even use a dedicated RELEASE file)
release: <%= File.read(File.join(__dir__, 'RELEASE')).strip rescue '2026-01' %>
Isn't something like this reasonable?
| before_action :ensure_modern_browser | ||
|
|
||
| after_action :teardown_current | ||
| after_action :set_document_policy_header |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need this for every action?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need it according to Sentry docs. For every action? I believe so, in this case since all etmodel requests are basically the UI requests we want to profile.
e0d900a to
811cafd
Compare
Description
Added Sentry UI profiling (automatic instrumentation) and Sentry metrics to count the amount of times data export files are being downloaded.
Type of change
Checklist
Related Issues
Closes #4633