OTP Logger: Per‑module filter not updating after handler reload

Question

OTP Logger per‑module filtering
Since OTP 21, Logger supports custom filter modules that can be attached per handler. The handler’s filter is set to the module’s return value for each log message, allowing fine‑grained suppression of noise.
Dynamic update concern
When a filter module is edited and recompiled, the usual approach is to call logger:reload_handler/2 to apply the changes. However, the OTP documentation does not clarify whether the reload picks up the new module code or if the handler still references the old bytecode until a full node restart.
Additionally, the coexistence of the legacy error_logger can produce duplicate messages if both systems are active, further complicating noise reduction.
Given these uncertainties, we need to know how to reliably update filter logic at runtime and avoid silent loss of critical alerts.

When a custom filter module is recompiled, does logger:reload_handler/2 load the new code, or must the node be restarted?
Is there a documented mechanism to hot‑reload filter modules without handler removal?
What best practice ensures that per‑module filters remain effective while minimizing duplicate logs from error_logger?

Tasadduq Burney · Answer

Direct answer
logger:reload_handler/2 does not load recompiled filter code from disk. It reapplies the handler configuration already stored in Logger, so a recompiled filter module keeps executing the previously loaded bytecode until you explicitly load the new beam and reattach the filter. A node restart is not required.

Confirmed facts (OTP 21+)

logger:reload_handler/2 reconfigures handler options but does not trigger code loading for filter modules.
OTP Logger provides no filter-only hot-reload API.
By default, error_logger events are bridged into Logger, so an active legacy error_logger sink can emit the same event twice.

Likely explanation
The handler invokes a filter fun captured when the handler was configured. After recompilation, running Erlang processes continue with the old beam unless the code server loads the new one. Reloading the handler without reloading the module therefore reinstalls the old filter fun.

Steps to update the filter at runtime

Load the recompiled beam:
code:load_abs("/path/to/your_filter.beam").

Confirm the code server points to the new beam:
code:which(your_filter).

Replace the filter on the existing handler:
logger:remove_handler_filter(HandlerId, your_filter),
logger:add_handler_filter(HandlerId, your_filter, #{}).
Or rewrite the handler config and reload:
logger:set_handler_config(HandlerId, #{filter => {your_filter, []}}),
logger:reload_handler(HandlerId, #{filter => {your_filter, []}}).

Emit a marker message and verify suppression matches the new logic.

Preventing duplicate error_logger output
If alerts appear twice, the legacy error_logger tty handler is likely still active alongside Logger. Confirm whether the node was started interactively or embedded; interactive starts usually enable the legacy tty sink. Disable the legacy sink only after verifying Logger captures every alert severity you need.

Verification

Run logger:which_handlers/0 before and after the change and compare the filter configuration.
Trigger error_logger:report([{tag, marker}], "test") and confirm it appears exactly once through Logger.

Assumption: this behavior applies to OTP 21 and later. Verify on your target release before applying to production.

Missing diagnostic detail: Is the legacy error_logger tty handler still active on your node? This determines whether you must suppress it to eliminate duplicates.

OTP Logger: Per‑module filter not updating after handler reload

OTP Logger per‑module filtering

Dynamic update concern

1 answer

Direct answer

Confirmed facts (OTP 21+)

Likely explanation

Steps to update the filter at runtime

Preventing duplicate error_logger output

Verification

Your perspective belongs here.

0 question comments