Introducing NodeJS-Dashboard | Hacker News Reader

Introducing NodeJS-Dashboard

formidable.com

A nice little dash. Surprisingly, I found the most valuable part of it is honestly just splitting stdout/stderr, as the rest of the data is relatively easy to access (except event loop lag, but there are packages like toobusy[https://www.npmjs.com/package/toobusy-js] to help with this).

It doesn't work in combination with nodemon or babel-watch (yet), but the code looks very clean & simple so I assume it'll be an easy update.

If you're looking for more granular reporting & monitoring I can heartily recommend pm2's web dashes [https://github.com/Unitech/pm2]. There are also terminal dashes around like pm2-gui [https://www.npmjs.com/package/pm2-gui].

Nice (and clean) work @formidable.

Anyone interested in this sort of thing should definitely check out blessed-contrib[0] which this is based on.

[0] https://github.com/yaronn/blessed-contrib

Not necessarily good to separate stdout from stderr. Sometimes you want to see an error in its context.

Then, if you have 800 requests per second, reading logs in this way will not be very valuable.

Best way I have found to manage logs is:

- give requests a unique id. use that id when logging anything related to that request.

- have logs in unformatted json format for size. e.g: use bunyan to save them, use bunyan-cli or jq to read them.

- use unix tools like grep, sort, uniq, wc, etc. to find things...

- you can also feed your logs to elasticsearch/kibana or another aggregator. e.g: logio.org.

Again, jq is very useful processing json. it can help you query logs and find what you need, and format results in any arbitrary way. Make your logs queryable, don't save formatted logs. you will make your life difficult in this way.

Nice! And I love webpack-dashboard[1] too!

Long, unreadable stack traces are still an issue though. pretty-error[2] helps.

[1] https://github.com/FormidableLabs/webpack-dashboard [2] https://npmjs.org/package/pretty-error

Pretty-error sounded cool until I read this: ...could potentially break packages that rely on node's original stack traces

Yeah I haven't run into that issue for a long time. It's there so that on the off chance that you do run into it, you know where to check first :)

Give it a whirl. If it breaks something, disable it (takes one line), and open an issue :)

Ok will do thanks!

Is there anyone interested in improving the UX of the stock nodejs in-terminal debugger but who just needs money to do so? Because the experience of "run this single test and pop into the debugger at line 14 to poke around" has several warts that I'm surprised haven't been fixed yet:

1) Having to call `cont` at the beginning rather than the debugger stopping at the actual place where the `debugger` line is placed.

2) Having to call `repl` in order to start printing things

3) After calling `repl`, not being able to get back to the mode where you can go to the next line and jump into functions.

4) If jumping into an express.js route, inspecting the request sometimes just results in the message "no frames".

Why not use chrome devtools to debug node? It's now a built-in feature as of v6.3.0 and no longer requires the 3rd-party and kinda buggy node-inspector module. Just use the --inspect command-line flag. (--debug-brk too if you want it to start paused on the first line.)

maybe you're on a test server (no GUI) and for whatever reason you also don't want to remote debug with node-inspector, you want it all quick and dirty via ssh ;)

Python's "baked in" command line debugger that you get via `import pdb; pdb.set_trace()` is awesome for this kind of quick and dirty ssh debugging so if you're looking for inspiration on how node's command line debugger should work, check it out. I always miss python's pdb when working with JS or PHP or... anything else.

<3 pdb and ipdb.

When working in ruby, check out binding.pry

I believe you could use SSH's -L flag to forward a port from the server, so you could run `node --inspect ...` on the server and use Chrome on your local machine.

1) Because then I have to move the mouse to click on tiny UI elements and that takes a long time.

2) Because then I need another browser window open and that takes up more screen real estate than a terminal

3) Because my browser background is white and reading code on it is less pleasant

4) Because then the place where I say "run these backend tests" and the place where I pop into the debugger are different.

as mentionned, now the chrome debugger is a first class citizen for Node. You don't need iron-node or node-inspector...

just run node with --inspect (and optionally --debug-brk) and hit the url that it returns with Chrome.

Works beautifully.

Extremely stupid question but when does it write to stderr without crashing the whole app?

Whenever there's an error which is non-fatal. Do console.error("Your error") and it'll write to stderr or alternatively process.stderr.write("Your Error\n").

Albeit rare in normal JS because it seems most things are fatal when they break, lots of libraries use it.

Couldn't make it work nicely with child-processes :(

Reply on news.ycombinator.com