What is logging?


Storing of messages / events from the application to the file for future use.


An application log is a file of events that are logged by a software application. It contains errors, informational events and warnings. The format and content of an application log are determined by the developer of the software program, rather than the OS.


To expose an attack or identify the damage caused, you need to analyze the log events on your network in real-time. By collecting and analyzing logs, you can understand what transpires within your application. Log file contains many pieces of information that can be invaluable, especially if you know how to read them and analyze them.


An application normally contains code to write various types of events to an application log file. The log file can reveal message flow issues and application problems. It can also contain information about user and system actions that have occurred. Logged events typically include the following:


Warnings about low disk space

An operation that has been carried out

Any significant problems – known as an error events – that prevent the application from starting

A success audit to indicate a security event such as a successful logon

A failure audit to indicate an event such as a logon failure



Logging is a Structured Approach

The different levels of the log will be sent to the concerned people working at different specialties’, depending on their urgency.


Good frameworks have the capability to filter messages according to importance. Let’s go through the general information and the debugging process in detail:



The function of Info, is thus purely informational and they will be able to convey any fault or error. This is just general information that you can use when the primary interface remains inaccessible.


Examples of general information could be

            – Version information of the software- it is virtually impossible to keep working on a software without even knowing its version,

            – The users, mainly who uses the software and

            – The external services (web servers, databases, etc.)used by the software.


If there is an application error, it is this information that will be used for diagnosing the error.



A bolder step after the previous (information) stage. You can also say that it is the first important step that gives the indication of any trouble. When you receive a ‘Warn’ message, it means there is some problem along the way, but that users are continuing to use your application.


For example, if there is any trouble using the external services, you can expect this message to appear, but things are not very serious because there will be a secondary service handling the issue.



Things are starting to get more serious here and user experience is partially hindered. Failure level of the application has gone a notch higher as users are not able to use the app as earlier.


Once again, it could be the database connection that has been affected in some way and several attributes of the app gets rendered useless, and perhaps temporarily, as those can be corrected.



Fatal, as the name suggests shows that the level of failure has turned extremely critical. Any component that has been working as the backbone of the application has failed to perform, in which there is no option but terminate the application as a whole. Once the fatal message is registered, the users cannot use the application in anyway.



The logged messages that you see in the Debug level are targeted entirely towards the developers, and hence used mainly for debugging purposes. Though it largely depends on the application you are developing, through Debug, you can solve a number of problems concerning the application.


For example, you can rely on Debug messages to catch the existence of potential bugs in your application. The disadvantage with Debug is that it works optimally only during a particular development stage and in the case of certain applications. It segregates fine grained information that would help the developer debug the application.



Doing Node.js Logging Right


Using the console


The most basic kind of logging one can think of is using the built in console logging. With the console module, you can put messages on both the stdout and stderr:


console.log(‘some msg’) will put some msg to the standard output (stdout),

console.error(‘some error’) will put some error to the standard error (stderr).

This approach has a lot of flaws like you cannot turn it off or add log levels to it. For logging, we usually have requirements, which the console module can’t do.




When it comes to your application, you can do more sophisticated application logging.


For that, you can use one of the most popular package called winston. Winston is a multi-transport async logging library for Node.js.


You can add winston to your project by installing it:


npm install winston –save


Once you have it, you can add winston to your project this way:


const winston = require(‘winston’)


winston.log(‘info’, ‘Hello log files!’, {

  someKey: ‘some-value’



The snippet above will put the following line to stdout:


info: Hello log files! someKey=some-value


As you could see above, we are passing the info string to winston, which tells winston that the event it is going to log has a log level associated with it, which is info. By default, winston ships with the following log levels (custom levels can be added):







and silly.


You can set what levels to log with the following line:


winston.level = ‘debug’


At RisingStack, we usually set the configuration from an environment variable called LOG_LEVEL. This way we can dynamically change what should be logged:


winston.level = process.env.LOG_LEVEL


### What Should Not Be Logged

When you are logging on a silly level, you should try to log almost everything. Still, there is a rule of thumb that you should follow: never, ever log credentials, passwords or any sensitive information.


“Never, ever log credentials, passwords or any sensitive information.” via @RisingStack #nodejs #logging #security



Usually, more than one people has access to logs, so logging events containing credentials adds an extra security risk.


Default location for log file in forever can be found under ~/.forever/ folder with random file name with .log extension.


log file location can be found with the command


forever list


you can find something like this /home/vagrant/.forever/6n71.log


Forever takes command line options for output:

-l  LOGFILE      Logs the forever output to LOGFILE

-o  OUTFILE      Logs stdout from child script to OUTFILE

-e  ERRFILE      Logs stderr from child script to ERRFILE


forever start -o output.log -e error.log app.js



Doing ROR Logging Right


Default logging path for Rails is under the /log folder


Based on the environment Rails will automatically create a log file for example development.log, staging.log, etc


For development environment default log_level is debug

For staging and production default log_level is info


the above default values can be changed in the corresponding environment files under config/environments/ folder


config.log_level = :debug

config.log_level = :info

config.log_level = :error


command for logging in Rails


puts “Test Logger”

Rails.logger.debug “Test Logger”

Rails.logger.info “Test Logger”



Using the default logging library, Logger, will get you far, but you can improve the logs you get. There are tons of packages (called Gems in the Ruby world) available to you, but here are some of the most popular options:


Log4r: An easy-to-configure logging library, Log4r’s philosophy is based on the act of using simple puts statements. However, the library adds the following features (among many others) aimed at allowing you to control the information logged:


Hierarchical logging system (with the ability to assign each level a custom name)

Logger inheritance

Ability to output to multiple destinations

Execution tracing

Custom Formatting


Logging: Very similar to Log4r, but based on the design used for Java’s log4j library.


Lograge: Rails, by default, logs pretty much everything. Lograge aims to increase the usefulness and readability of Rails messages by reducing them to single lines.



You can use inbuilt commands of ubuntu `tail` or `vim` to read log file.