I have multiple node.js apps running at my VPS, and I access to it through ssh. Right now I start them in the way:
nohup node server.js
That looks good but I get whole logs to nohup.out, and what's more important and not efficient is about restarting of stopping them.
If I do ps -A | grep node I will get an output like:
9172 ? 00:00:01 node
9178 ? 00:00:00 node
...
So, how can I identify them?
I also knew about nodemon and it's great! But however logging out ssh breaks the magic.
I think maybe some more advanced tools would help out. What's the best approach for this?
Just in case, I use Nginx on top (port 80) and do reverse proxy, but I'd be ok changing that.
One solution (there are many) is pm2: https://github.com/Unitech/pm2
It's a process manager for node, and comes with a variety of features, some of which include the ability to spread your app across multiple CPU cores while providing an easy TTY management view of the applications. It also has the ability to reload the apps without stopping them.
If the readme's not sufficient, I found this post useful in understanding the basics: http://devo.ps/blog/2013/06/26/goodbye-node-forever-hello-pm2.html
You can run nodemon under --quiet mode and it'll suppress all nodemon output (and keep your logging working).
Related
I'd like to check the status of an app registered with pm2 remotely such that other web-based monitoring services can give us a notification when something breaks.
Are there any options available to remotely check the status of a process in pm2 remotely? One possibility is to have a web script remotely eval() the pm2 status command and look for certain keywords, and make that script accessible on the web for the notification tool. This doesn't seem ideal, though, as we're using an eval command and maybe a regex of that output just to see what is going on.
Any advice?
I wrote a simple web interface for PM2.
You can simply start a websocket connection to /logs and get your application(s) stats updates such as status, uptime, cpu usage, memory usage, restarts in realtime.Feel free to use and contribute. Cheers!
https://github.com/doorbash/pm2-web
The best option is to use keymetrics. It's free to monitor upto 4 processes(great for development and side projects), easy to link an instance/server but quickly turns out to be very expensive when you scale up.
You could always try switching to other alternatives like upstart or pm2-gui.
I have been using forverjs for my server but for some reason the server stopped and the server didn't restart again. Is foreverjs reliable?
Should i use any other libs?
Found there are many libs like pm2, nodemon, upstart, systemd, nginx. Which one should ensure my application running all the time. also can these tools handle large loads of requests?
There are multiple questions within your question to analyze.
Is foreverjs reliable?
forever is a very popular package. As seen on GitHub, it has 75 contributors and 636 commits. This question is mainly opinion-based, but 9/10 (maybe 10/10) experienced developers would say it's reliable for it's purpose (I expand below).
Should i use any other libs?
Reliability is achieved through sturdy software design and not just packages you choose. I have used forever and pm2 production processes for years without any problems on their end. They include great features for reliability, such as attempting to restart your application if it crashes. Packages are not supposed to fix terminal bugs in your code.
Found there are many libs like pm2, nodemon, upstart, systemd, nginx.
Which one should ensure my application running all the time.
This can be found through reading their GitHub descriptions. I use nodemon for quickly testing code as it's written. For example, I start the nodemon process and it begins my Node.js process. When I edit my code and press save, the Node.js process is automatically stopped and restarted with the new code. nodemon should not be used alone for a long-running production server, since it will stop when you exit your shell. pm2 and forever are effective libraries and you can investigate upstart, systemd, and nginx if necessary.
Regarding #Kalana Demel's answer, I consider using forever to run nodemon as using forever in my explanation above.
how to ensure my application is reliable all the time
For an overall answer to your question, you should be writing tests to ensure your code is reliable. If you've written effective unit and integration tests, choosing a package to run the process will be trivial (and not related to reliability), since you should not expect it to crash.
nodemon is a good option, you can use a combination of forever and nodemon using,
forever start -c nodemon app.js
Also in my experience forever is very reliable, try
forever logs app.js
to see what exactly caused the error
pm2 is good option in these cases, I personally use pm2 in all my node.js servers, it provides alot of more important functionalities in comparison to others.
One of the best thing about it can be easily integrated with keymetrics/newrelic for analytics of the server.
Also pm2 will give you cpu/memory usage, you can even configure the restart limit and interval.
I've searched a lot to figure out this question, but I didn't get clear explanation. Is there only one difference thing that clustered app can be scaled out and forked app cannot be?
PM2's public site explains Cluster mode can do these feature but no one says about pros of Fork mode (maybe, it can get NODE_APP_INSTANCE variable).
I feel like Cluster might be part of Fork because Fork seems like to be used in general. So, I guess Fork means just 'forked process' from the point of PM2 and Cluster means 'forked process that is able to be scaled out'. Then, why should I use Fork mode?
The main difference between fork_mode and cluster_mode is that it orders pm2 to use either the child_process.fork api or the cluster api.
What does this means internally?
Fork mode
Take the fork mode as a basic process spawning. This allows to change the exec_interpreter, so that you can run a php or a python server with pm2. Yes, the exec_interpreter is the "command" used to start the child process. By default, pm2 will use node so that pm2 start server.js will do something like:
require('child_process').spawn('node', ['server.js'])
This mode is very useful because it enables a lot of possibilities. For example, you could launch multiple servers on pre-established ports which will then be load-balanced by HAProxy or Nginx.
Cluster mode
The cluster will only work with node as it's exec_interpreter because it will access to the nodejs cluster module (eg: isMaster, fork methods etc.). This is great for zero-configuration process management because the process will automatically be forked in multiple instances.
For example pm2 start -i 4 server.js will launch 4 instances of server.js and let the cluster module handle load balancing.
Node.js is single-thread.
That means only 1 core of your Intel quad-core CPU can execute the node application.
It called: fork_mode.
We use it for local dev.
pm2 start server.js -i 0 helps you running 1 node thread on each core of your CPU.
And auto-load-balance the stateless coming requests.
On the same port.
We call it: cluster_mode.
Which is used for the sake of performance on production.
You may also choose to do this on local dev if you want to stress test your PC :)
Documentation and sources are really misleading here.
Reading up on this in the sources, the only differences seems to be, that they use either node cluster or child_process API. Since cluster uses the latter, you are actually doing the same. There is just a lot more custom stdio passing around happening inn fork_mode. Also cluster can only be communicated with via strings, not objects.
By default you are using fork_mode. If you pass the the -i [number]-option, you're going into cluster_mode, which you generally aim for w/ pm2.
Also fork_mode instance probably can't listen on the same port due to EADDRINUSE. cluster_mode can. This way you also can structure you app to run on the same port being automatically load balanced. You have to build apps without state then though e.g. sessions, dbs.
I know to start my Node app I type in the Win shell, node app.js.
But this is obviously not how a webhost would maintain a Node webserver (ie what happens if there is a power outage, a Node exception, etc).
I see things like Forever and running Node as a Windows service, but I feel like the creator of Node must have had a different idea? Something like Apache is installed as a Windows Service so that it runs even if the server reboots - what is the correct method of doing this for Node? I don't like the idea of introducing another piece of software just to keep the server going.
Thanks.
The problem is that many systems do not do that. For instance MongoDB doesn't even run like that on windows.
The best solution I have found is this https://nssm.cc/
Also you have to consider even on Linux you need to run something like upstart to keep node programs running when you close the console.
I am trying to set up a development environment for node.js. I assumed at first that it requires something similar to the traditional, "localhost" server approach. But I found myself at a loss. I managed to start a node.js hello world app from the terminal. Which doesn't looked like a big deal - having to start an app from the console isn't that hard. But, after some tweaking, I found out that the changes aren't shown in the browser immediately - you need to "node [appName here]" it again to run.
So, my question is:
Is there a software or a tutorial on how to create a more "traditional" development server on your local machine? Along with port listening setup, various configurations, root directories etc (things that are regular in stacks like XAMMP, BitNami or even the prepackaged Ubuntu LAMP). Since I'm new at node.js, I can't really be sure I'm even searching for the right things on google.
Thanks.
Take a look at :
https://github.com/remy/nodemon
it'll allow you to do - nodemon app.js
and the server will restart automatically in case of failure.
To do this I built a relatively small tool in NodeJS that allows me to start/stop/restart a NodeJS child process (which contains the actual server) and see/change configuration option and builds/versions of the application, with admin options available on a different tcp port. It also monitors said child process to automatically respawn it if there was a error (and after x failed attempts stops trying and contacts me).
While I'm prohibited from sharing source code, this requires the (built-in) child_process module, which has a spawn method that returns a child process I guess, which contains a pid (process id) which you can use with the kill method to kill said child process. Instead of killing it you could also work with SIGINT an catch it within your child application to first clean up some stuff and then exit. It's relatively easy to do.
Some nice reading material regarding this.
http://nodejs.org/docs/v0.5.5/api/child_processes.html