Logs flooding with line Dropping aggregate

[apentori]

Describe the bug

The log Dropping aggregate from topics beacval in mode Debug don't bring any information and is filling the logs, making it difficult to debug. Could it be move to the level TRACE or remove entirely.

To Reproduce
Steps to reproduce the behavior:

1. Platform details (OS, architecture): linux x86 (but should be for every platform.
2. Branch/commit used: 25.11.0
3. Commands being executed: run the BN node normaly
4. Relevant log lines: Dropping aggregate

Screenshots

Additional context

Improving the log visibility help the Node Operator, it's a small change that will make a lot of good in this cruel world !

[apentori]

Same for the log :

DBG 2025-12-11 15:57:19.250+00:00 Aggregate received                         topics="beacval" delay=252ms226us646ns

If the delay value is important, then it would be better to set traces in the code (https://nim-lang.org/docs/estp.html).

[tersec]

Generally, DBG is supposed to be verbose. The idea is that whatever the ultimate fate of these messages, we should see it in logs. Similarly, if a message shows up and it's rejected, DBG is generally the log level we target for that to ensure we can see it at all. So, they do provide information.

Probably will not remove these. For me, they're a substantial part of the reason to run DBG at all.

DBG logs aren't meant to read en masse, one log level at a time. Typically I start by filtering out certain logs I know aren't relevant. Sometimes, that includes the ones highlighted here, sometimes not (e.g., when looking at why head might not be updating properly).

[apentori]

My main issue with those logs is they don't provide any context to the aggregate that is being received or dropped. Without any ID or any context variables it's the same as having a log saying Something is happening.

The only information (from my point of view) that those 2 logs bring is:

• The beacon node is in general receiving aggregate (data already available with the metrics : beacon_aggregates_received_total)
• The beacon node is dropping aggregates because they have already been received (data already available with the metrics : beacon_aggregates_dropped_total)
• The delay in aggregate reception, however since there is no identifier it can only be use to have an idea of the delay trend.

I can see they usefulness in the development phase where you don't want to have an entire Metrics stack running,
However for the Operational perspective, they seems less relevant due to the low information they bring compare to the metrics.

Once again, i would advocate to add Traces in Nimbus.

[yakimant]

I agree, I also see this particular Dropping aggregate useless if no identity added.
They all look the same. But probably you get the context from previous log message, not sure if that is a correct approach.

[arnetheduck]

They all look the same. But probably you get the context from previous log message, not sure if that is a correct approach.

agree, these logs are not very useful in their current shape .. the idea behind the logs is to have a log for when a message "enters" the system subsequently is processed (outcome) and one should be easy to tie to the other either by logging their content or an id of some sort