# plugin logging/debug output

**URL:** <https://forum.ansible.com/t/plugin-logging-debug-output/45856>\
**Category:** Get Help\
**Tags:** dev, plugin, ansible-devel\
**Created:** [May 28, 2026, 8:51am UTC](https://forum.ansible.com/t/plugin-logging-debug-output/45856 "2026-05-28T08:51:04Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![christoph](https://avatars.discourse-cdn.com/v4/letter/c/eb8c5e/32.png) [@christoph](https://forum.ansible.com/u/christoph)\
**Post date:** [May 28, 2026, 8:51am UTC](https://forum.ansible.com/t/plugin-logging-debug-output/45856/1 "2026-05-28T08:51:04Z")

</div>

**plugin debug/log output**

i’m trying to figure out what options are there to produce debug/log output of a custom (python) plugin. And control the amount of logging during playbook execution

**display**  
My understanding is that action plugin is executed on the controller.  
An action plugin could use display and the verbosity level

```auto
from ansible.utils.display import Display
display = Display()
display.v('this is a verbose message')
display.vv('this is a very verbose message')

```

Output will end up on in the controller output.  
Verbosity level can be controlled by the number of `-v` flags (`-vv`, `-vvv`, …)

**module**  
an module plugin is executed on the client. Interaction with the controller is via json on stdout. If verbosity is high enough, stderr is also captured and logged.

It has no access to display.

If writing a python based plugin it is advised to use

```auto
from ansible.module_utils.basic import AnsibleModule
module = AnsibleModule(...)

```

module has a few methods.

```auto
# this will end in journald/syslog on the client
module.log('this is a module log message') 

# this will end in journald/syslog on the client if environment variable ANSIBLE_DEBUG=1 is set
module.debug('this a module debug message')

# this will be in the controller output
module.warn('this is a module warning message') # stored in _global_warnings
module.exit_json() # adds warnings from _global_warnings to the returned json
# will be parsed by the controller and displayed in the output
# it will not end up in journald/syslog

```

Personal remark: it’s not very intuitive that log/debug is on the client and warn on the controller

**logging**  
standard python logging is to stderr.

For module plugins, if verbosity level is high enough it is captured and logged on the controller.

the current verbosity level can be found at `module._verbosity`

**return**  
a module plugin can capture all its logs and return them with the final exit\_json. To control the amount of logging check `module._verbosity` (which is a private variable, but i found community modules that accessing it, `lx_container.py`)

Something along

```auto
logs = []
module = AnsibleModule(...)

def debug(msg):
  if module._verbosity > 3:
    logs.append(f"[DEBUG] {msg}")

def info(msg):
  if module._verbosity > 2:
    logs.append(f"[INFO] {msg}")

debug('debug message')
info('info message')
module.exit_json({'logs': logs})

```

**questions**  
did i miss an option? What is the most ansible way?

---

<div class="post-metadata">

**Author:** ![shertel](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/shertel/32/1241_2.png) [@shertel](https://forum.ansible.com/u/shertel)\
**Post date:** [June 2, 2026, 1:24pm UTC](https://forum.ansible.com/t/plugin-logging-debug-output/45856/2 "2026-06-02T13:24:20Z")

</div>

If I needed logging for multiple actions/modules in a collection, I’d add a common module option to configure whether or not to return logs, put those actions/modules in a [module\_defaults group](https://docs.ansible.com/projects/ansible/latest/playbook_guide/playbooks_module_defaults.html#module-defaults-groups) so the logging can be configured in one place for all tasks, and write a simple aggregate callback to display it. That way, the module option (or a callback option) could be configured using the [ansible\_verbosity variable](https://docs.ansible.com/projects/ansible/latest/reference_appendices/special_variables.html#term-ansible_verbosity), but could also be configured based on other conditions, which could be convenient if verbose return data/connection details/etc are not necessary. Another benefit of an aggregate callback is that the action plugins and modules would follow the same pattern for logging.

I don’t think I’d populate the `logs` return based on `self._verbosity`, because it feels like it overloads the meaning of that option and is limiting.