-1

I have a web app, with node backend. I'm finishing the backend now and I was wondering what should I use for logging. Particularly, whether should I log locally or to some remote location, something like Loggly for example. The reason why I want to go for remote is the ease of use - I can view all logs from the browser, instead of a terminal. I have too much stuff on my mind to implement a web interface myself. I just have one doubt, if each time I log something, I have to send a request to their server, won't this put much more load on my server than local logging? Or is it completely negligible? Also what if network failed? Should I also set up local logging, in case connection fails?

Maciej Krawczyk
  • 14,825
  • 5
  • 55
  • 67
  • yes, yes, yes, maybe, could be fixed, could be worked around, and yes. or... maybe the opposite – Kevin B Jun 08 '17 at 21:55

1 Answers1

2

While your question is somewhat at risk of closing as being opinion based, I will answer in hopes that it helps.

At this point, my go-to architecture is based on the 12-factor app (12factor.net).

If you follow those principles, you'll find that logging locations and such should not be a concern of the application itself. Log to stdout and stderr and then let the application forget about it.

With that done, your environment can then think about what to do with the logs out of band. In most cases, I'll then have a host based log shipper send logs to an ELK stack or Splunk or Loggly or whatever. Doesn't matter, the point is that your app doesn't (and shouldn't) care because logging ain't its business.

Paul
  • 35,689
  • 11
  • 93
  • 122
  • Listen to this guy. Just let the app stdout, stderr and forget about it. Let log daemon ship it to anywhere you like. – Tuan Anh Tran Jun 08 '17 at 22:45
  • Thanks for the tip. I guess I will use forever-monitor which is a separate node process that watches for crashes and has the ability watch for any console output, so I will just send the logs from there I guess. – Maciej Krawczyk Jun 09 '17 at 09:45
  • Actually I've been thinking more about this. Why not log from the application? That gives me much more flexibility. It's not like there's more code, I can just create my own module and use it like myLogger('message', { someData: true }) . And what flexibility stdout gives me, I would have to do something like console.log(JSON.stringify({ message: 'message', data: { someData: true })). and then outside the app parse json again. – Maciej Krawczyk Jun 09 '17 at 10:57
  • Logging to stdout is *not* the same thing as using only `console.log`. I still use things like `morgan` for request logging and `debug` for application logging (both fine logging utilities). If you like `Winston` that's another fine option, and feel free to roll your own. I'm specifically advising against configuring the log destination to be anything other than the stdout and stderr streams. That's orthogonal to how you setup / standardize/ write to those streams. – Paul Jun 09 '17 at 12:33