Several INFO logs from azure-eventhubs from while using logging

[prabdeb]

• azure-eventhubs:
• 5.0.0:
• alpine3.11:
• python:3.8:

Describe the bug Several INFO logs from azure-eventhubs from while using logging and enabling INFO log for my application

To Reproduce Program to reproduce the behaviour:

import logging
from azure.eventhub import EventHubConsumerClient

logger = logging.getLogger('myprogram')
logging.basicConfig(level=logging.INFO)

logging.info("start receiving events from eventhub a")
consumer_client = EventHubConsumerClient.from_connection_string(
            eh_connection_str,
            eh_onsumer_group,
            eventhub_name=eh_name,
            checkpoint_store=checkpoint_store,
        )
with consumer_client:
    consumer_client.receive(
        on_event=on_event, 
        starting_position="-1",  # "-1" is from the beginning of the partition.
    )
logging.info("events received from eventhub a")
logging.info("executing rest of my program")

This was flushing lot of logs (I have to scan several event hubs in loop) and the program was getting hard to get useful info log for my application.

Workaround taken to disable explicitly some loggers -

# Disable Logger for Azure Event Hubs
logging.getLogger("uamqp.connection").disabled = True
logging.getLogger("uamqp.c_uamqp").disabled = True
logging.getLogger("azure.eventhub._eventprocessor.event_processor").disabled = True
logging.getLogger("uamqp.authentication.cbs_auth").disabled = True
logging.getLogger("azure.core.pipeline.policies.http_logging_policy").disabled = True
logging.getLogger("uamqp.receiver").disabled = True

Expected behaviour It will nice to have a flag/settings for disabling the INFO logs from azure-eventhub or flag to change the log level to DEBUG.

As most of the INFO logs come from azure-eventhub and its sub components might be useful only while debugging.

[lmazuel]

Hi @prabdeb Loggers in Python are hierarchical based on their name, see from the doc: https://docs.python.org/3.8/howto/logging.html#loggers

The names are period-separated hierarchical structures. Multiple calls to getLogger() with the same name will return a reference to the same logger object. Loggers that are further down in the hierarchical list are children of loggers higher up in the list. For example, given a logger with a name of foo, loggers with names of foo.bar, foo.bar.baz, and foo.bam are all descendants of foo.

Loggers have a concept of effective level. If a level is not explicitly set on a logger, the level of its parent is used instead as its effective level. If the parent has no explicit level set, its parent is examined, and so on - all ancestors are searched until an explicitly set level is found. The root logger always has an explicit level set (WARNING by default). When deciding whether to process an event, the effective level of the logger is used to determine whether the event is passed to the logger’s handlers.

Which means playing with root loggers should be enough in your case. Usually, the best approach is not to disable them but to put a higher log level:

# Disable Logger for Azure Event Hubs
logging.getLogger("uamqp").getLevel(logging.CRITICAL)  # Low level uAMQP are logged only for critical
logging.getLogger("azure").getLevel(logging.CRITICAL)  # All azure clients are logged only for critical

This gives you the full flexibility to configure your logs.

Please close this issue if this answers your question, otherwise please let me know how we can get further. Thanks!

[prabdeb]

Thank you @lmazuel that helps, so that we can switch of all the info logs from those two libraries.

[fjgsanandres]

# Disable Logger for Azure Event Hubs
logging.getLogger("uamqp").getLevel(logging.CRITICAL)  # Low level uAMQP are logged only for critical
logging.getLogger("azure").getLevel(logging.CRITICAL)  # All azure clients are logged only for critical

Is this "getLevel" correct? Shouldn't it be "setLevel"?

[CodeProcessor]

Yeah, it should be setLevel.