Skip to content

Customizable Log Management System#6417

Open
kdrewes wants to merge 8 commits intofastify:mainfrom
kdrewes:logManagementSystem
Open

Customizable Log Management System#6417
kdrewes wants to merge 8 commits intofastify:mainfrom
kdrewes:logManagementSystem

Conversation

@kdrewes
Copy link

@kdrewes kdrewes commented Dec 17, 2025

Prerequisites

[✓] run npm run test && npm run benchmark --if-present
[✓] tests and/or benchmarks are included
[✓] documentation is changed or added
[✓] commit message and code follows the Developer's Certification of Origin and the Code of conduct

Proposal

Implement a customizable log management system through an encapsulated plugin

Description

Hello, I've been working on customizing the log management system which originally was derived from #4463.
As previously specified in #4463, we currently have a log management system set in place which only displays a default message, "incoming request", as shown below:

if (disableRequestLogging === false) {
  childLogger.info({ req: request }, 'incoming request')
}

The purpose of this PR is to allow the user to customize the log management system so they can include criteria and data that is compatible with their particular project.

For this particular feature, I have implemented a plugin approach rather than hard-coding the logger through route.js.
The objective of the plugin approach is to produce an object or plugin that is encapsulated by a childLogger object. This plugin will possess and inherit all the log management system properties it needs to create a customizable log management system. In addition, it can be reused and shared through several different Fastify projects.

Advantages

• Object is reusable

• Contains settings and properties directly adopted through the childLogger object. As a result, it has the capability to perform more functionalities and logic.

• The whole entire Log Management system is now encapsulated through an object. Therefore it makes it easier to perform functionalities. It’s also much more organized and maintainable than the previous approaches.

• Scalable and adaptable.

Modifications

fastify.js

Added customRequestLog factory option:

const customRequestLog = typeof options.customRequestLog === 'function'
  ? options.customRequestLog
  : (req) => 'incoming request'

Updated onBadUrl and buildAsyncConstraintCallback error paths:

if (disableRequestLogging === false) {
  childLogger.info({ req: request }, customRequestLog(request))
}

fastify.d.ts:

Added TypeScript type definition:

customRequestLog?: (request: FastifyRequest) => string,

examples/custom-logger-plugin.js

Added example plugin demonstrating hook-based logging:

function customLogger (fastify, options, done) {
  fastify.addHook('onRequest', (request, reply, done) => {
    request.log.info({
      req: request,
      timestamp: new Date().toISOString(),
      method: request.method,
      url: request.url,
      ip: request.ip
    }, 'Custom Request Log')
    done()
  })
  done()
}

docs/Reference/Server.md

Included documentation for customRequestLog option

Please tell me what you think. Thank you

kdrewes and others added 8 commits December 13, 2025 21:52
…nd included custom-logger-plugin.js demonstration.
• examples/custom-logger-plugin.js
• fastify.js
• Rebased logManagementSystem branch onto main branch
• Began writing documentation in /docs/Reference/Server.md
- Added customRequestLog factory option to fastify.js
- Added TypeScript type definition to fastify.d.ts
- Updated documentation in docs/Reference/Server.md
- Added example plugin in examples/custom-logger-plugin.js
@github-actions github-actions bot added documentation Improvements or additions to documentation typescript TypeScript related labels Dec 17, 2025
Copy link
Member

@Eomm Eomm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Quick share of my opinion on the logger topic:
instead of adding an option for each line in the framework (such as:
customRequestLog, requestIdLogLabel, disableRequestLogging and probably other that I'm missing), I would just create a small layer that that user can totally replace without getting mad with all the combinations of these parameters.

It could by my christmas time funny task

@Eomm Eomm linked an issue Dec 17, 2025 that may be closed by this pull request
2 tasks
@kdrewes
Copy link
Author

kdrewes commented Dec 18, 2025

Quick share of my opinion on the logger topic: instead of adding an option for each line in the framework (such as: customRequestLog, requestIdLogLabel, disableRequestLogging and probably other that I'm missing), I would just create a small layer that that user can totally replace without getting mad with all the combinations of these parameters.

It could by my christmas time funny task

Hi @Eomm, thank you for the suggestion! I agree, I think this would be a much cleaner approach. Before I start, I'd like to make sure I understand correctly, are you suggesting I include a replaceable logging layer that would handle all framework logging (request logs, error logs, etc.) that users could swap out entirely? I'll work on this and keep you updated. And yes, maybe it can be an early Christmas gift! Thank you again.

@Eomm
Copy link
Member

Eomm commented Dec 22, 2025

are you suggesting I include a replaceable logging layer that would handle all framework logging (request logs, error logs, etc.) that users could swap out entirely?

Yes: right now the user can already change the logger (by implementing a well defined API), but we have some "system logs" that users wants to customize.

If we want to deliver this feature as non-breaking I think we should proceed like this:

  1. list all the current system logs (if I try to make the list from memory: req in, respose out, handler errors)
  2. choose the API. For example I can think of these options
  3. systemLog(target, level, args) where target could be fastify.log or req.log or reply.log
  4. or if the system logs are just three { logRequest(), logReply(), logError() }
  5. other ideas?
  6. deprecate some options such as disableRequestLogging with this new option

In this way, we will never have another feature request regarding the default log lines because they will be totally replaceable

@kdrewes
Copy link
Author

kdrewes commented Dec 25, 2025

Sounds good, thank you for this suggestion, I think this approach will make the codebase more efficient and less error prone. If I have any questions I will be sure to let you know. Thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

documentation Improvements or additions to documentation typescript TypeScript related

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Request logging customization

2 participants