User Journey tracking documentation

[RafaelGSS]

This issue aims to track the remaining tutorials under documentation folder.

The https://github.com/nodejs/diagnostics/issues/439 contains the documents created in the WG Deep Dive and we are working to transpose them into live documents.

• [ ] Abnormal Termination
  • [X] Using exit stack traces
  • [X] Using diagnotics report
  • [X] Using valgrind
  • [ ] Using llnode
• [ ] CPU
  • [ ] Monitoring Excessive CPU Usage
• [ ] Crash
  • [ ] What is a crash (intro)
  • [ ] Using node report
  • [ ] Using llnode (https://github.com/nodejs/llnode/issues/401)
• [ ] Hang
  • [X] Using trace sigint
  • [X] Using Chrome DevTools
  • [ ] Using node report
• [x] Live Debugging (https://github.com/nodejs/nodejs.org/pull/4772)
  • [x] Using Node Inspector
• [x] Memory (https://github.com/nodejs/nodejs.org/pull/4728)
  • [x] Using Heap Profiler
  • [X] Using Heap Snapshot
  • [X] Using GC Traces
  • [X] Using Native Tools
• [x] Poor Performance (https://github.com/nodejs/nodejs.org/pull/4928)
  • [X] Using V8 Profiler
  • [X] Using Linux Perf
• [ ] Tracing
  • [ ] Using Trace Events

Feel free to update this description when a tutorial is done.

cc: @nodejs/diagnostics

[RafaelGSS]

What we are supposed to do in the CPU journey? It looks pretty similar to what we did in Profiling.

[mhdawson]

@RafaelGSS a few thoughts:

1. The goal was to be based on a user journey (ie problem->resolution) versus tool based. In that context we should probably rename "Profiling" to "Poor Performance".
2. CPU should then likely be "Excessive CPU usage". The symptoms would be different (ie performance could be fine, but you may be using more CPU than expected/wanted). The Debugging might then be the same as figuring out where CPU is used will be the same between the 2.

[RafaelGSS]

Excellent, I agree.

[RafaelGSS]

I'm adding it to the agenda to discuss how we can expose it to the community in a call for help. Maybe a tweet could be enough?

[github-actions[bot]]

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.

[tony-go]

Hey @mhdawson @RafaelGSS 👋

A question regarding "Monitoring Excessive CPU Usage" we want to help Node.Js users to have a real-time CPU monitoring solution or an on-demand tool that is runnable locally?

[RafaelGSS]

Hey @mhdawson @RafaelGSS wave

A question regarding "Monitoring Excessive CPU Usage" we want to help Node.Js users to have a real-time CPU monitoring solution or an on-demand tool that is runnable locally?

The idea is to show a few ways to monitor excessive CPU usage. Each step can be either an open-source tool or a built-in one.

[RafaelGSS]

@nodejs/diagnostics The memory set of documents is done, so I think we can move it to nodejs.org. The remaining question is: Where it should be placed?

cc: @nodejs/website

[mhdawson]

I think this might be the right page - https://nodejs.org/en/docs/guides/

[tony-go]

@nodejs/diagnostics The memory set of documents is done, so I think we can move it to nodejs.org. The remaining question is: Where it should be placed?

cc: @nodejs/website

Once we merge it to the nodejs.org website, should we delete it from here and put a link to the nodejs.org repo?

[RafaelGSS]

@nodejs/diagnostics The memory set of documents is done, so I think we can move it to nodejs.org. The remaining question is: Where it should be placed? cc: @nodejs/website

Once we merge it to the nodejs.org website, should we delete it from here and put a link to the nodejs.org repo?

I think we can point to the nodejs.org repo, but the exercises like #572 should remain here.

[RafaelGSS]

@No9 We have a mention to lldb when diagnosing of Abnormal Termination, but given the fact that llnode is an lldb plugin and most of its content will be covered in Using llnode, sounds reasonable to remove Using lldb from the list, what do you think?

[RafaelGSS]

@nodejs/website is that possible to get some insights from the guides we are creating? I'm not sure if that's getting traction. In case not, I'd suggest to the team to close this issue even without completing the list.

By insights I mean, visualizations per day in comparison to other pages

[Trott]

@nodejs/website is that possible to get some insights from the guides we are creating? I'm not sure if that's getting traction. In case not, I'd suggest to the team to close this issue even without completing the list.

By insights I mean, visualizations per day in comparison to other pages

We removed Google Analytics/tracking some years ago. (I'd be fine with putting it back, but I'm also fine deferring to the people who really want to err on the side of privacy in these things.) We do have some log files that can be crunched to get usage, but I believe that would involve people from @nodejs/build.

[RafaelGSS]

Don't we use Cloudflare? IIRC we can get the same insights from their dashboards.

[richardlau]

We do use CloudFlare but access to that is restricted to the build-infra team.

The CloudFlare data is where the numbers for https://nodejs.org/metrics/ (leading to https://storage.googleapis.com/access-logs-summaries-nodejs/index.html) come from. Those only contain numbers for the downloads -- code in https://github.com/nodejs/build/tree/main/ansible/roles/metrics filters for the download files and strips out identifying information before publishing to the Google storage bucket.

[RafaelGSS]

Happy to add it to the agenda if someone else wants to pursue this work.