Diagnostics for issue reporting on forum / github

Hi all,

Long ramble (skip to next section if you wish)

I see, often multiple times per day, the same questions / requests from the same section of folk...

  • Post your startup log
  • What node version are you using?
  • Do you have n or nvm installed?
  • What hardware you running on?
  • What user is running node-red?
  • What browser are you using?
  • Is node-red running on the same hardware?
  • What other nodes do you have installed?
  • Did you restart node-red after updating nodes?

And the same answers - for example...

  • Where do i get the startup log?
  • what is nvm?
  • I dont know!

Then after 15 posts, the good old "Ah you are running as root" or "Ah that version is too old" etc etc.

I do worry about forum fatigue & the affect it could have on this amazing community should the handful of really active support guys get fed up.

OK Enough waffle. :wink:

Feature Request...

What are your thoughts on having a core action "Gather Diagnostics" that would provide the following information ...

  • Server Side Diagnostics
    • Node & NPM Version
    • Node-RED Version
    • Node-RED running time
    • Node-RED Port
    • Host Name
    • IP address(es)
    • Hardware Info
    • OS & version
    • CWD
    • Username & group info
    • Installed nodes
    • Etc etc (please suggest)
  • Client Side Diagnostics
    • Browser Info (type/version)
    • OS & version
    • Current URL
    • Etc etc (please suggest)

I would propose this info be presented with a Copy for forum/github button (that copies the data in a markdown table or bullet list - perhaps in a collapsed summary and click to reveal format.

Off the top of my head, I would expect this action would be password protected? Possible to disable via settings.js (but always available from localhost or 127.0.0.1)?


I believe this would greatly reduce the noise on the forum and provide much better diagnosis of issues.

Thoughts and comments welcome.

Ta.

3 Likes

Yes very worthwhile idea i think Steve.

Are you saying this would be built into NR rather than using OS tools ?

i.e. would we have to wait on Nick or the other leaders to make this happen ?

or is this something we would do through scripting on Windows/Linux ?

Craig

1 Like

My preference is built in to node-red (so it is a source of truth)

Asking someone to run a script is just asking for more hassle.

While I love the idea, I don't think it should be in Node-red because of the different platforms (@craigcurtin don't forget macOS or where it is built into different devices) that NR can run on. It could become a support nightmare getting it to work because of the differences in OS's and even browsers.

What if it could it be a part of the NR install but not be part of NR? That way someone could build it and it could be tested seperate from NR. Then when it is working well, maybe request that there be a way for NR to kick it off???

Paul, I would say that is exactly the reason to run from within node-red. Nodejs abstracts much of the OS differences away. Also, more importantly, the running node process can reveal much about itself and has access to other (potentially valuable) information (like node-red plugins loaded, node-red version number, etc)

So while something could be done external (scripting etc), I believe the better solution is to come from the running process.

Ultimately, I would like to see a diagnostics tar be generated that can be analysed or used by the Devs for replicating issues. Or be used by some auto/AI analyser.

1 Like

I think that having a diagnostics dump feature for Node-RED would be a nice feature indeed. Whether built in or as an external command I don't think would bother me either way. In general, I think it would be best to have this as a completely separate package so that it could be maintained separately as I think it would be something that would evolve over time (probably quite rapidly to begin with). It could always be included as a dependency in node-red if needed.

I am not sure that you could do diagnostics for the browser though so that might not be feasible.

Some specifics for node-red, I would want to know:

  • Something about how/where Node-RED is installed. Global vs local, admin vs user.

  • Whether docker was involved.

  • Whether node.js was installed using a version manager.

  • About the platform not just the OS.

  • Whether there is a desktop running on the Node-RED server.

  • The log from Welcome to Node-RED through to [info] Started flows

    Actually, I think that is really hard to do, especially if using systemd because, unless you configure the journaling to save to permanent storage, it will restart each day I think. Actually, the log goes to syslog which may be rotated each day but you have to pick out the node-red stuff and to do that, you have to know the systemd service name which might node be node-red depending on how it was set up. OK, that reminds me that you can specify a date range to journalctl - that would probably work.

    Ah yes: sudo journalctl -u nrmain -f --since=2021-08-01 --no-hostname works (note different service name)

    You always want to see any errors in the log of course as well.

On the client side, I would also want to know whether the client desktop and browser are running on the same device as the node-red server. You will also want any errors shown in the console of the dev tools.

Thinking about it - it might be possible to craft a web-page that gets some of the core client information. Not the browser console though, that isn't accessible for obvious security reasons.


Updates:

  1. A dump of the current Heap size would also be useful.
  2. Not just installed nodes but versions as well.
2 Likes

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.