Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Log a warning for modules that log too often #139708

Open
wants to merge 4 commits into
base: dev
Choose a base branch
from
Open

Log a warning for modules that log too often #139708

wants to merge 4 commits into from

Conversation

abmantis
Copy link
Contributor

@abmantis abmantis commented Mar 3, 2025

Proposed change

This records how often modules log in a specific time window, and logs a warning for those that do it too often.

This serves as a base for the feature. In the future we could improve this by trying to find which integrations depend on the noisy modules, and guide the user to check if debug logging is enabled for those integrations, for example.

Type of change

  • Dependency upgrade
  • Bugfix (non-breaking change which fixes an issue)
  • New integration (thank you!)
  • New feature (which adds functionality to an existing integration)
  • Deprecation (breaking change to happen in the future)
  • Breaking change (fix/feature causing existing functionality to break)
  • Code quality improvements to existing code or addition of tests

Additional information

  • This PR fixes or closes issue: fixes #
  • This PR is related to issue:
  • Link to documentation pull request:
  • Link to developer documentation pull request:
  • Link to frontend pull request:

Checklist

  • The code change is tested and works locally.
  • Local tests pass. Your PR cannot be merged unless tests pass
  • There is no commented out code in this PR.
  • I have followed the development checklist
  • I have followed the perfect PR recommendations
  • The code has been formatted using Ruff (ruff format homeassistant tests)
  • Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

If the code communicates with devices, web services, or third-party tools:

  • The manifest file has all fields filled out correctly.
    Updated and included derived files by running: python3 -m script.hassfest.
  • New or updated dependencies have been added to requirements_all.txt.
    Updated by running python3 -m script.gen_requirements_all.
  • For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.

To help with the load of incoming pull requests:

@abmantis abmantis marked this pull request as draft March 3, 2025 18:25
@abmantis abmantis marked this pull request as ready for review March 3, 2025 19:49
self._log_counts[logger_name] = LoggerCount(1, now)
return

ellapsed_time = now - module_count.start_time
Copy link
Contributor

Choose a reason for hiding this comment

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

Typo: ellapsed -> elapsed

module_count.start_time = now
return

module_count.count += 1
Copy link
Member

Choose a reason for hiding this comment

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

I think we should only count if level is not debug, as debug log is not something that should be enabled by default and is usually very noisy since you are planning to gather as much as information as possible, I think we don't want this to create a warning as it might drive developers to reduce debug logging which is the opposite of what is debug used to.

Copy link
Contributor

Choose a reason for hiding this comment

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

I agree. I would not be able to remove logging from the ZHA modules, for example, that communicate with radios over serial and effectively log nonstop at DEBUG. This is honestly one of the reasons I dislike the DEBUG < INFO < WARNING divide, as some logging belongs in a TRACE level that won't be enabled even with DEBUG.

@puddly
Copy link
Contributor

puddly commented Mar 3, 2025

Does this affect modules that log at a lower log level (i.e. too much debug logging), or only those that log with a level that Core is affected by?

My understanding of logging here is that as long as we don't perform string interpolation when formatting log messages, it's going to be nearly free unless enabled, no?

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

Successfully merging this pull request may close these issues.

3 participants