Adding an entirely separate API for introspection strikes me as counter-productive — instead of merely having to maintain the logging API that you already maintain, you will additionally now have an entirely separate and second API that also has to be maintained forever.

Reading back over the current logging documentation, it looks like the problem is that the documentation only includes verbs — the methods that can be invoked — but not adjectives: the attributes that are attached to each logger, handler, and filter. This is contrary to modern Python APIs, which typically document their attributes and offer direct access to them; within the Standard Library, cf the threading.Thread object for one that has done a good job of moving into the modern world with directly-accessible attributes.

So my guess would be that you should discard the idea of a separate introspection API, and simply document that attributes of each logger, handler, and filter that today are already perfectly introspectable. Check out the logging_tree code if you want to make sure that you are “promoting” into document-hood all of the attributes that I needed in order to do my introspecting there.