How can I identify different services when they're all named 'server.js'?

Question

Following a common convention, I generally name the main file in a project server.js. However, this leads to situations like this:

  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
21049 root      20   0 2347568 1.133g      0 D  0.0 14.5   0:32.70 node ./server.js
28201 root      20   0 1261740  69332      8 S  0.0  0.8   4:04.46 node src/server.js
26652 root      20   0  776664   9324      8 S  0.0  0.1   0:00.09 node server.js

One of these services has a serious memory problem--but how do I figure out what it is?

Some possible solutions that come to mind:

• Name each one differently, like server-label-gen.js, server-order-mgt.js and so on. Problem: in addition to not exactly following the naming convention, I'd eventually like to standardize things like Dockerfiles but if the files are all named differently I would need templates instead of being able to just copy.
• Pass a dummy argument to the when starting the program, so it shows up as node ./server.js --name=label-gen. This has the same problem with templates, plus confusion over what this argument does (if I pass --name=order-mgt instead does it suddenly turn into an order server?)
• Change process.title to something more useful. This is a common approach (postgres does this, for example) but it seems tricky to get right.

Are there best practices for this sort of thing? It seems like it would be a common problem with microservices, but I can't find anything about how other people have solved it.

Answer 1

You can simply process.title = process.env.PROCESS_TITLE, or use something like process-title which relies on the name in the package.json.

I think this is the most straightforward approach one can think of. With Docker I wouldn't bother looking at single processes within the host (ps) but instead use the abstraction docker provides you (docker ps) if you really need to.

(in general microservices push things one level up so that you don't have to worry too much about the low-level drama, where orchestrators like k8s or openshift take care of process monitoring and so on)