An introduction to Logging

Logging is used to represent state transformations within an application. When things go wrong, we need logs to establish what change in state caused the error.

But the problem is that obtaining, transferring, storing and parsing logs is expensive. Because of this it is crucial to only log what is necessary; only logs that can be acted upon should be stored. Log only actionable information.

Logging can- and probably should- be used for much more than just error diagnostics. A well-designed logging system can also be used for business analytics (e.g., how is the system being used) as well as for system monitoring (e.g., what kind of load are we experiencing).

In the back end world, there have been some great logging frameworks to choose from as the need for those arose a lot earlier. For example in Java, you can take a pick between Java’s own logging engine, java.util.logging or some great external frameworks like Logback or the most popular Log4j.

In the front end world, things haven’t gotten that far yet, but there are options that can help you do the extra mile (and of course get rid of trivial console.log messages ). Two such Javascript libraries for the front end are the minimal but powerful loglevel and the browser-bunyan, a port of the awesome node.js logging module for the browser.

Apart from the JSON exporting capability, Bunyan has the concept of child loggers, which can be used to create different loggers for different components of the application. That gives great flexibility as to what fields and extra info you want to include in specific parts of your application only. Bunyan also incorporates streams, which are the ‘output’ settings of its loggers.

Applications can also write log files by themselves. For example, popular servers like Apache, Nginx, MySQL, and more can write log files in /var/log. Some of these log files are written by the application itself. Others are created through syslog.

How do Linux system log files get created? The answer is through the syslog daemon, which listens for log messages on the syslog socket and then writes them to the appropriate log file.

What’s Syslog?

The word “syslog” is an overloaded term and is often used in short to refer to one of these:

Syslog daemon— a program to receive, process, and send syslog messages. It can send syslog remotely to a centralized server or write it to a local file. Common examples include rsyslogd and syslog-ng. In this usage, people will often say “sending to syslog.”

Syslog protocol— a transport protocol specifying how logs can be sent over a network and a data format definition for syslog messages (below). It’s officially defined in rfc-5424. The standard ports are 514 for plaintext logs and 6514 for encrypted logs. In this usage, people will often say “sending over syslog.”

Syslog messages— log messages or events in the syslog format, which includes a header with several standard fields. In this usage, people will often say “sending syslog.”

Syslog messages or events include a header with several standard fields, making analysis and routing easier. They include the timestamp, the name of the application, the classification or location in the system where the message originates, and the priority of the issue.

References:

https://www.freecodecamp.org/news/you-should-have-better-logging-now-fbab2f667fac/

https://www.loggly.com/ultimate-guide/linux-logging-basics/

https://winderresearch.com/logging-vs-tracing-vs-monitoring/