-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
feat(profiling): Run profiling on self-hosted #2154
Conversation
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 don't see any configuration for integrating it with the web
or snuba
containers? Or is it meant to be just like this? I'd like to try it on my own server 😄
Co-authored-by: Reinaldy Rafli <[email protected]>
@aldy505 Good point, I added those. |
We might need to wait for getsentry/snuba#4195. |
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.
Actually I'm a bit curious about the SENTRY_DSN
environment variable that can be applied to snuba and vroom container. If they're left empty, I suppose no error message will be sent to the internal
project of people's self-hosted instance.
Vroom's defined here: https://github.com/getsentry/vroom/blob/c2cf9653f5bb9b2e4a02f0548956b790547e9048/cmd/vroom/config.go#L8
docker-compose.yml
Outdated
snuba-profiling-profiles-consumer: | ||
<<: *snuba_defaults | ||
command: consumer --storage profiles --auto-offset-reset=latest --max-batch-time-ms 1000 --no-strict-offset-reset | ||
snuba-profiling-functions-consumer: | ||
<<: *snuba_defaults | ||
command: consumer --storage functions --auto-offset-reset=latest --max-batch-time-ms 1000 --no-strict-offset-reset |
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.
Should these be added to the list of sentry image's depends_on field?
Here:
self-hosted/docker-compose.yml
Lines 39 to 50 in 8aa571c
snuba-consumer: | |
<<: *depends_on-default | |
snuba-outcomes-consumer: | |
<<: *depends_on-default | |
snuba-sessions-consumer: | |
<<: *depends_on-default | |
snuba-transactions-consumer: | |
<<: *depends_on-default | |
snuba-subscription-consumer-events: | |
<<: *depends_on-default | |
snuba-subscription-consumer-transactions: | |
<<: *depends_on-default |
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 added vroom
as a depends_on
since web
needs to POST to vroom
, but then the consumers only depends on kafka
technically. I think it's good like this.
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.
Will profiling be released under CalVer? If so, would need to add VROOM
to
self-hosted/scripts/bump-version.sh
Line 10 in 1fa7734
sed -i -e "s/^\(SENTRY\|SNUBA\|RELAY\|SYMBOLICATOR\)_IMAGE=\([^:]\+\):.\+\$/\1_IMAGE=\2:$NEW_VERSION/" .env |
That's correct, the Sentry SDK won't be activated and nothing will be sent. I was expecting the user to pass the right DSN via an environment variable. Do you know how other services are handling that? |
We might as well need to ping @hubertdeng123 for help. There is an "internal" project that should've been set up during the first install of Sentry, but I don't know on how to acquire the DSN and put it into the environment variable / configuration that can be consumed by Snuba and Vroom. |
Snuba is very similar, retrieves |
I guess we can skip that one for now? |
Yep |
sentry-zookeeper" | ||
|
||
before=$(get_volumes) | ||
|
||
test "$before" == "" || test "$before" == "$expected_volumes" | ||
|
||
source install/create-docker-volumes.sh |
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.
got it, safe to remove then
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.
🚀
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.
Let's hold off on merging until we cut 23.5.2 (related to inc-389).
23.5.2 is out now, this can be merged now |
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.
Just a little bit more..
Note about the exposed port: if you don't specify it as exposed port, that port will still be opened to other containers. Having a new exposed ports might cause a vulnerability for people who didn't set up a proper OS firewall.
…each the service Co-authored-by: Reinaldy Rafli <[email protected]>
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.
LGTM!
This PR aims to add support for profiling on self-hosted.
Fixes #1838.