-
-
Notifications
You must be signed in to change notification settings - Fork 505
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(sessions): Implement automatic session tracking #1715
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1715 +/- ##
==========================================
+ Coverage 98.40% 98.43% +0.03%
==========================================
Files 141 144 +3
Lines 8079 8312 +233
==========================================
+ Hits 7950 8182 +232
- Misses 129 130 +1
Continue to review full report at Codecov.
|
55a5c1e
to
02464a1
Compare
5b090de
to
a0b5702
Compare
So I'm gonna document my testing here one by one. First run, normal behavior with some success and error routes. We see that during normal behavior, there is one flusher thread and it is killed successfully before exiting. Thread Count log
|
My review is just very "on the surface", because I am not an Ruby export. But everything looks clean (and done the same way as in Python) |
thx for taking a look! |
Next test was to test the failure resiliency of the flusher. Basically checking two things
This was done with this commit to throw a random exception with 25% probability. Thread exception in rails log
The thread count log shows 0 for the flusher thread count when that exception happens and the thread crashes. A new one is eventually respawned on the the next Thread Count log
|
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 finally got time to do a more thorough review, sorry for the waiting.
The overall feature still looks good 👍 I only added some nitpick-ish naming/testing suggestions 🙂
@st0012 made some updates and left comments for the rest |
@sl0thentr0py since we're now close to completion, can you also add a changelog entry for the feature? preferably also include a simple description, related configs & Sentry doc, and a screenshot? Example: https://github.com/getsentry/sentry-ruby/releases/tag/4.8.0 |
@st0012 done! |
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.
🎉
@@ -189,11 +194,18 @@ def init(&block) | |||
@main_hub = hub | |||
@background_worker = Sentry::BackgroundWorker.new(config) | |||
|
|||
@session_flusher = if config.auto_session_tracking | |||
Sentry::SessionFlusher.new(config, client) |
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.
@sl0thentr0py I think we should also check if the SDK is deactivated before initializing the flusher, especially to avoid the additional thread that won't be used. We can use Configuration#enabled_in_current_env?
for it.
This adds automatic session tracking to our rack middleware (and hence rails).
The key components here are a
SessionFlusher
that spawns a new thread that sends pending aggregate sessions once a minute and a simpleSession
class for recording those individual sessions.Note that we currently only implement
request
mode sessions which are aggregated in the SDK as compared toapplication
mode sessions which are sent as soon as they finish. The main reason for this is the scale of most servers out there which would overload our ingestion pipelines.The
Session
class could potentially be extended in the future forapplication
mode sessions but for now it doesn't add much user value.There are a couple of TODOs left which are slightly orthogonal to the main feature so I will make separate PRs for those.
closes #1711
References
Implementation progress
In separate PRs
send_envelope
/send_event
exception handled / session crashed statusmoved to Addmechanism
to the exception interfaces #1743