Repository navigation
Expectation about tier of support from diagnostic tools and VMs #157
Description
Action items:
- Look for feedback from users about their dependencies on existing diagnostic tools (e.g. do they block an upgrade of Node.js because tool X stops working on newer version of Node.js)
- Look for feedback from the developers of the diagnostic tools about their support for Node.js updates (e.g. if there is going to be a change in Node.js that is going to break a tool, are they willing to support it and how long would that take)
- Look for feedback from VM vendors about their support for the development of diagnostic tools (e.g. if they are going to break an existing tool, are they willing to provide support to work with the tools and unbreak those, what level of priority would that be)
- Create a table (or tables) about different tier of support among different category of tools, Node.js core and the VM vendors
Activity
[-]Expectation about tier of support from diagnostic tools[/-][+]Expectation about tier of support from diagnostic tools and VMs[/+]mmarchini commentedon Feb 23, 2018
I made a non-exhaustive list of tools we have today (either inside Node.js core, in the VM or as external tools). If I forgot anything, feel free to edit the list and include it.
Tracing
OS/External Tracing Tools
Other
Profiling
V8
External Stack Samplers
Heap and Memory Analysis
Step Debugging
Other tools
mmarchini commentedon May 24, 2018
Diagnostics WorkGroup Deep Dive Meeting on Expected Support Tiers - 2018-??-??
Time
TBD
Agenda
Brainstorm of available diagnostic tools
Before discussing support tiers for diagnostic tools, we need to know which
tools we have today and how stable they are.
Questions we need to answer
Support tiers for tools outside Node.js core
Most diagnostic tools we have today exist outside of Node.js core, which means
it's harder for us to keep them updated and working, even if they're under the
Node.js Foundation (i.e., llnode).
Questions we need to answer
be part of CITGM? (or even something else)
node-report).
Node.js/V8 Support Tiers
Some tools rely on V8's non-supported APIs and features to work (i.e., Linux
perf, llnode, DTrace, 0x with --prof, etc.). Those tools are relevant in Node.js
context because they usually offer greater granularity and less overhead when
diagnosing an application (qualities important for i.e., servers but not so
relevant to browsers).
Questions we need to answer
Discuss possible support tiers for diagnostic tools
Define support tiers with their respective expectations
Questions we need to answer
Define criteria for tools to go under a specific support tier
Questions we need to answer
Invited
yunong commentedon May 25, 2018
Should we discuss this during the upcoming collaboration summit? There's already a session booked for diagnostics. cc @mhdawson
Otherwise, we (Netflix) would be happy to host a diagnostic summit at our offices in Los Gatos, CA at some point.
mhdawson commentedon May 25, 2018
I think we should add to the topics we discuss at the collaborator's summit. It's also good to start planning for the next summit dedicated to diagnostics. The only thing I'd add on that front is that there was some discussion that maybe the next one should be in Europe?
jasnell commentedon May 25, 2018
I can look into having nearForm host in Ireland if y'all would like :) maybe around NCEU so we can consolidate travel.
davidmarkclements commentedon May 25, 2018
If not nearForm hosting, I think it would be awesome if the V8 team host at Google, Munich /cc @hashseed @bmeurer
mhdawson commentedon May 25, 2018
I like the idea of consolidating travel with NCEU.
yunong commentedon Jun 5, 2018
@mhdawson Given the conversation from the collaborator's summit, can we start to get alignment on tiers of support for the toolchain that @mmarchini has listed here?
mhdawson commentedon Jun 5, 2018
@yunong lets start with a list of the tools and then we can build the matrix which answers the questions above for each tool.
yunong commentedon Jun 10, 2018
@mhdawson Is this something we can discuss at the next WG meeting?
mhdawson commentedon Jun 11, 2018
Sure, adding the agenda tag.
mmarchini commentedon Jun 21, 2018
@mhdawson I believe we can use the list above as a starting point.
mhdawson commentedon Jul 4, 2018
I put together this gist as a starting point for what we might PR into the project somewhere:
https://gist.github.com/mhdawson/ead071dde71f71ae5af11ccbaca4f1ec
Please take a look and maybe we can discuss in the next WG meeting.
hybrist commentedon Jul 5, 2018
I'm somewhat tempted to add something along the lines of "gathering vs. visualization/processing vs. 'online'" to the table. But I'm not sure yet what exactly that would mean. But I think the table as-is would be valuable to bring into the project.
mhdawson commentedon Jul 5, 2018
@jkrems, I had similar thoughts in that its important that we don't break the generation of the data needed by externals tools, but a bit less so if the data is available and the tools themselves need a fix. If you can think of a good way to fit it in let me know/
mhdawson commentedon Jul 18, 2018
PR based on tiers discussion in last Diagnostics meeting: nodejs/node#21870
gireeshpunathil commentedon Oct 25, 2019
should this remain open? [ I am trying to chase dormant issues to closure ]
github-actions commentedon Jul 18, 2020
This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is removed or a comment is made.
github-actions commentedon Aug 5, 2022
This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is removed or a comment is made.