Meaningful Application Logging

A piece of software does not speak to us. Sometimes we would like our application to explain what is going on and why something is not working as expected. For this reason, it is essential to teach the application how to talk to us through logs.

In this chapter, we will see how to implement meaningful application logs to help us understand what is going on in our software. It is vital to monitor that everything is working as expected, as well as to keep track of what has gone wrong.

You will learn how to set up the perfect logging configuration without losing essential information. Moreover, you will discover how to avoid logging sensible data and print out only what you need.

The learning path we will cover in this chapter is as follows:

• How to use Fastify’s logger
• Enhancing the default logger
• Collecting the logs
• Managing distributed logs

Technical requirements

As in the previous chapters, you will need the following:

• A working Node.js 18 installation
• The VS Code IDE from https://code.visualstudio.com/
• A public GitHub repository
• A working command shell

All the snippets in this chapter are on GitHub at https://github.com/PacktPublishing/Accelerating-Server-Side-Development-with-Fastify/tree/main/Chapter%2011.

How to use Fastify’s logger

Application logging is one of the pillars of application observability. It provides useful information to understand what the system is doing and narrow down where the bug arises. A good logging setup has the following qualities:

• Consolidate: This sends the logs to a designated output.
• Structure: This provides a format to query and analyze over text messages.
• Context: This adds metadata based on the execution environment.
• Security: This applies filter and data reduction to hide sensitive information.
• Verbosity: This sets the log severity based on the environment. Unfortunately, logging is not free, as it costs the system’s resources, so we can’t just log everything without impacting the application’s performance.

Generally, you can easily understand whether application logs are implemented correctly or not. But you should never underestimate the importance of logging.

In fact, when you are having...

Enhancing the default logger configuration

You know the options available in the logger, but what is a valuable configuration, and how can we integrate it into our application? First of all, we need to define which logs we expect for every request:

Figure 11.1 – Request logs logic

As shown in Figure 11.1, we expect these log lines for each request: one for the incoming request, optionally, how many handler’s log messages you implement, and finally, one for the response output. All these log lines will be connected to each other by the reqId (request-id) field. It is a unique identifier generated for each request whenever the server receives it. We already described the reqId property in Chapter 1 in the The Request component section.

We can start implementing this by doing the following:

• Exploiting the default request and response log implemented by Fastify
• Executing a custom log statement by using the onRequest and onSend...

Collecting the logs

Reading the logs can be done on your PC during development, but it is unrealistic to carry it out during production or even in a shared test environment. Reading the records is not scalable, but if you try to estimate the number of logs your application will write at the info level, you will get an idea.

Having 10 clients send 5 requests per second is equal to 100 lines per second per day. Therefore, the log file would be more than 8 million rows, just for a single application installation. If we scale the application to two nodes, we need to search in two different files, but if we followed this path, the log files would be useless because they would be inaccessible.

As mentioned at the beginning of this chapter, a good log setup allows us to consolidate to a log management software destination, so let’s see how to design it.

How to consolidate the logs

Before considering where to consolidate the logs, we must focus on the actor who submits the...

Managing distributed logs

Fastify has simplified our job many times, and it always has an excellent way to complete complex tasks. This is the case for distributed logs. By distributed records, we mean the situation of a single client’s HTTP request that leads to multiple requests across our application or the whole system. In the previous Enhancing the default logger configuration section, we learned how to add context to the Fastify logs, but how can we connect all those messages to a single HTTP request? And what about an external API call to another Fastify server? To do this, we must configure the reqId request-id properly.

The request-id is the identifier across your entire system to be able to trace all the logs generated by a single HTTP request. In Fastify, you can’t easily remove the request-id field from the output message, so whenever you use request.log or reply.log, you will get the reqId property.

We can customize the request-id field name and value...

Summary

In this chapter, we have discussed the importance of logging and how to focus on improving this feature. We have explored many new Fastify options to enhance the readability of the application’s logs. You now have a complete overview of the pino module and know how to customize it based on your system’s architecture.

We have successfully configured the log’s redaction to secure our log files and hide sensitive data, which is one of the hardest things to do, but we still made it easy, thanks to Fastify’s ready-to-use toolchain in production.

You have read about some architectural patterns to collect the logs in a complex scenario and the aspects you need to consider when dealing with logs.

You are ready to proceed to Chapter 12, where you will learn how to split our application into smaller and independent pieces.