-
Notifications
You must be signed in to change notification settings - Fork 156
[RUM Profiler] Add profiling
context to Long Task and View events
#3583
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: main
Are you sure you want to change the base?
[RUM Profiler] Add profiling
context to Long Task and View events
#3583
Conversation
profiling_status
to Long Task and View events
* - failed-to-lazy-load: The Profiler script failed to be loaded by the Browser. (may be connection issue or the chunk was not found) | ||
* - failed-to-start: The Profiler failed to start. (most probable cause if when the web server did not return the `Document-Policy: js-profiling` HTTP Response header) | ||
* - running: The Profiler is running. | ||
* - stopped: The Profiler is stopped. |
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.
🥜 nitpick: not sure exactly how this status is planned to be used but from an end-user perspective, looking for events with profiles by searching @profiling_status: stopped
seems a bit odd to me.
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 expect a lot of View or Long Tasks will have this stopped
but overall it will be used by us on the UI to be able to let users know why there is no Profiling data.
export type ProfilingStatus = | ||
| 'not-available-in-slim-bundle' | ||
| 'initializing' | ||
| 'missing-profiling-experimental-feature' |
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.
💬 suggestion: we'll probably won't provide a version with experimental flag to customers, so not sure if this case need to be handled
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.
As long as we have an experimental version, I think we should keep it. It will help us identify issues with potential design partners.
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.
afaik, we don't want to communicate experimental flag to external parties.
cleanupTasks.push(stopLongAnimationFrameCollection) | ||
} else { | ||
startLongTaskCollection(lifeCycle, configuration) | ||
startLongTaskCollection(lifeCycle, configuration, profilerApi) |
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.
💬 suggestion: instead of passing profilerApi around, it could be interesting to see if you could subscribe to the assemble hook instead.
look at hooks.register(HookNames.Assemble
usages.
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 did just that in the last commit. PTAL and let me know if that's what you envisioned.
bec3ff0
to
7944d6f
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3583 +/- ##
==========================================
- Coverage 92.44% 92.41% -0.04%
==========================================
Files 322 323 +1
Lines 8129 8147 +18
Branches 1838 1839 +1
==========================================
+ Hits 7515 7529 +14
- Misses 614 618 +4 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
profiling_status
to Long Task and View eventsprofiling
context to Long Task and View events
Bundles Sizes Evolution
🚀 CPU Performance
🧠 Memory Performance
|
HookNames.Assemble, | ||
({ eventType }): DefaultRumEventAttributes => ({ | ||
type: eventType, | ||
profiling: profilerApi.getProfilingContext(), |
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.
My guess is that I should filter on the eventType
I'm interested in before actually appending the profiling
context. WDYT ? I kinda expected the typechecker to yell at me 🤔
29ed0f3
to
1ffc8d9
Compare
… rum-event-format types for Profiler
1ffc8d9
to
6b6bb99
Compare
@@ -33,7 +33,8 @@ | |||
"test:e2e:ci:bs": "yarn build && yarn build:apps && yarn test:e2e:bs", | |||
"test:compat:tsc": "node scripts/check-typescript-compatibility.js", | |||
"test:compat:ssr": "scripts/cli check_server_side_rendering_compatibility", | |||
"rum-events-format:sync": "scripts/cli update_submodule && scripts/cli build_json2type && node scripts/generate-schema-types.js", | |||
"rum-events-format:sync": "scripts/cli update_submodule && yarn rum-events-format:generate", | |||
"rum-events-format:generate": "scripts/cli build_json2type && node scripts/generate-schema-types.js", |
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 found it useful to generate locally the files I had checked-out in the rum-events-format
submodule, mainly to confirm everything works as expected.
It's slightly different from rum-events-format:sync
because there is no sync, on the file generation taken from the submodule.
Motivation
This PR is based on work done in DataDog/rum-events-format#274 defining the context.
Changes
_dd.profiling
field onRumViewEvent
,RumLongTaskEvent
(updated therum-events-format
PR)View emitted now has a

profiling
field in_dd
:Long Task emitted also has a

profiling
field in_dd
:These status have been designed so that it will be possible to aggregate them when a single view is receiving multiple of them
For Long Tasks, there is no aggregation so it's easier and the exact status of the Profiler that is collected on Long Task collection is the one used, always.
Test instructions
_dd.profiling.status
field on top level of bothViews
andLong Task
events, with a meaningful status.Checklist