starred/monolog

Fork 0

mirror of https://github.com/Seldaek/monolog.git synced 2026-04-27 08:35:53 +03:00

[GH-ISSUE #1865] Support more flexible normalizer #797

New issue

Closed

opened 2026-03-04 02:18:06 +03:00 by kerem · 5 comments

kerem commented

2026-03-04 02:18:06 +03:00

Owner

Originally created by @torreytsui on GitHub (Jan 3, 2024).
Original GitHub issue: https://github.com/Seldaek/monolog/issues/1865

Many times, I encountered use cases around custom normalization.

NormalizerFormatter::normalize / is_object($data)

To name a few:

Normalize a custom exception to include extra fields into the context
Normalize a custom object to include extra fields into the context
Redact fields from a custom object and selectively normalize non PII information into the context

I understand that we can write our Processor or a Formatter or implement the JsonSerializable to achieve that.

But I can also see that the "nomalization" logic was the main customisation we really needed in those use cases.

The NormalizerFormatter class is great and I don't want to duplicate its logic.

What do you think if we make it more flexible and customizable?

Suggestion 1: introduce protected normalizeObject() method

// Monolog/Formatter/NormalizerFormatter.php

protected function normalize(mixed $data, int $depth = 0): mixed
{
    if (is_object($data)) {
        return $this->normalizeObject($data, $depth);
    }
}

Suggestion 2: introduce normalizer components

// Monolog/Formatter/NormalizerFormatter.php

public function __construct(..., $normalizers);

protected function normalize(mixed $data, int $depth = 0): mixed
{
    // Loop through each normalizer, check its support, and invoke $normalizer->normalise($data, $depth)
}

Or other suggestions? or not really worth it?

Originally created by @torreytsui on GitHub (Jan 3, 2024). Original GitHub issue: https://github.com/Seldaek/monolog/issues/1865 Many times, I encountered use cases around custom normalization. ```php NormalizerFormatter::normalize / is_object($data) ``` To name a few: - Normalize a custom exception to include extra fields into the context - Normalize a custom object to include extra fields into the context - Redact fields from a custom object and selectively normalize non PII information into the context I understand that we can write our Processor or a Formatter or implement the JsonSerializable to achieve that. But I can also see that the "nomalization" logic was the main customisation we really needed in those use cases. The `NormalizerFormatter` class is great and I don't want to duplicate its logic. **What do you think if we make it more flexible and customizable?** Suggestion 1: introduce protected normalizeObject() method ```php // Monolog/Formatter/NormalizerFormatter.php protected function normalize(mixed $data, int $depth = 0): mixed { if (is_object($data)) { return $this->normalizeObject($data, $depth); } } ``` Suggestion 2: introduce normalizer components ```php // Monolog/Formatter/NormalizerFormatter.php public function __construct(..., $normalizers); protected function normalize(mixed $data, int $depth = 0): mixed { // Loop through each normalizer, check its support, and invoke $normalizer->normalise($data, $depth) } ``` Or other suggestions? or not really worth it?

kerem

2026-03-04 02:18:06 +03:00

closed this issue
added the
Feature
label

kerem commented

2026-03-04 02:18:07 +03:00

Author

Owner

@cesarreyes3 commented on GitHub (Mar 20, 2024):

Would this help me if I want to customize the file:line format?
github.com/Seldaek/monolog@479c936d2c/src/Monolog/Formatter/LineFormatter.php (L261)

@cesarreyes3 commented on GitHub (Mar 20, 2024): Would this help me if I want to customize the `file:line` format? https://github.com/Seldaek/monolog/blob/479c936d2c230d8c467bdb3882afab45a6e6b8ad/src/Monolog/Formatter/LineFormatter.php#L261

kerem commented

2026-03-04 02:18:07 +03:00

Author

Owner

@Seldaek commented on GitHub (Apr 12, 2024):

IMO you can already extend and override normalize(), handling any special types you want to handle, then defer to the parent method for the rest. I don't really see what a more complicated system would bring there given this isn't a very common case I think.

@Seldaek commented on GitHub (Apr 12, 2024): IMO you can already extend and override `normalize()`, handling any special types you want to handle, then defer to the parent method for the rest. I don't really see what a more complicated system would bring there given this isn't a very common case I think.

kerem commented

2026-03-04 02:18:07 +03:00

Author

Owner

@cobbles commented on GitHub (Nov 26, 2025):

This may be a separate request but I thought I would ask on this thread in case it helps give context. We have a use case where we would like to limit the length of of the stack trace to a max length so that large logs to stdout do not get truncated and resulting in invalid json.

Before I extend NormaliserFormatter is this a feature that would be desired?

If so I am happy to raise the Issue/PR for review

@cobbles commented on GitHub (Nov 26, 2025): This may be a separate request but I thought I would ask on this thread in case it helps give context. We have a use case where we would like to limit the length of of the stack trace to a max length so that large logs to stdout do not get truncated and resulting in invalid json. Before I extend `NormaliserFormatter` is this a feature that would be desired? If so I am happy to raise the Issue/PR for review

kerem commented

2026-03-04 02:18:07 +03:00

Author

Owner

@Seldaek commented on GitHub (Dec 30, 2025):

@cobbles IMO a max stack trace length would be ok as a standard option on NormalizerFormatter that can be changed via a setter, if you want to send a PR for that

@Seldaek commented on GitHub (Dec 30, 2025): @cobbles IMO a max stack trace length would be ok as a standard option on NormalizerFormatter that can be changed via a setter, if you want to send a PR for that

kerem commented

2026-03-04 02:18:07 +03:00

Author

Owner

@Seldaek commented on GitHub (Dec 30, 2025):

But otherwise closing this issue as I don't think there's anything to address here.

@Seldaek commented on GitHub (Dec 30, 2025): But otherwise closing this issue as I don't think there's anything to address here.