Implement filtering logic for min_severity and trace_based parameters

[rads-1996]

Description

Implement Spec to filter logs based on min_severity and trace_based parameters.

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

• Added unit tests

Does This PR Require a Contrib Repo Change?

• Yes. - Link to PR:
• No.

Checklist:

• Followed the style guidelines of this project
• Changelogs have been updated
• Unit tests have been added
• Documentation has been updated

[github-actions]

This PR has been automatically marked as stale because it has not had any activity for 14 days. It will be closed if no further activity occurs within 14 days of this comment.
If you're still working on this, please add a comment or push new commits.

[rads-1996]

In progress

[github-actions]

This PR has been automatically marked as stale because it has not had any activity for 14 days. It will be closed if no further activity occurs within 14 days of this comment.
If you're still working on this, please add a comment or push new commits.

[rads-1996]

Waiting for logs stabilization to complete. Will bring this up in the SIG once that is done.

[MikeGoldsmith]

Thanks for the work on this @rads-1996. A few notes now that the referenced spec PR merged in September 2025:

• Architectural question: The spec added minimum_severity and trace_based as logger configuration parameters, but this implements them as a wrapping FilteringLogRecordProcessor. Worth confirming with the SIG whether the processor approach is the intended implementation strategy, or whether these should be configurable on the Logger/LoggerProvider directly.

• Potential bug: is_less_than_minimum_severity_level only guards against record.severity_number is None, but SeverityNumber.UNSPECIFIED (value 0) is not None. If a record has severity_number=UNSPECIFIED and minimum_severity_level=DEBUG (value 5), 0 < 5 is True so the record gets dropped — but the docstring says UNSPECIFIED should bypass filtering. There's no test covering this case.

Please can someone from @open-telemetry/python-approvers add a hold label to keep the stale bot off this while logs stabilization is in progress.

[rads-1996]

Thanks for the work on this @rads-1996. A few notes now that the referenced spec PR merged in September 2025:

• Architectural question: The spec added minimum_severity and trace_based as logger configuration parameters, but this implements them as a wrapping FilteringLogRecordProcessor. Worth confirming with the SIG whether the processor approach is the intended implementation strategy, or whether these should be configurable on the Logger/LoggerProvider directly.
• Potential bug: is_less_than_minimum_severity_level only guards against record.severity_number is None, but SeverityNumber.UNSPECIFIED (value 0) is not None. If a record has severity_number=UNSPECIFIED and minimum_severity_level=DEBUG (value 5), 0 < 5 is True so the record gets dropped — but the docstring says UNSPECIFIED should bypass filtering. There's no test covering this case.

Please can someone from @open-telemetry/python-approvers add a hold label to keep the stale bot off this while logs stabilization is in progress.

Thank you for taking a look at this. Initially I had implemented this with these configs directly on the Logger, but in the SIG it was suggested to go with this approach. I can bring it up again to see what folks think.

Gotcha, will take care of it. As previously discussed, this PR will be merged after the logs are stabilized, right?