Comprehensive Guide to Ansible-Playbook Module Execution Logging and Output Retrieval

Nov 23, 2025 · Programming · 9 views · 7.8

Keywords: Ansible logging | module output | debugging techniques

Abstract: This article provides an in-depth exploration of methods to obtain detailed logs and output information during Ansible-Playbook module executions. By analyzing the usage of -v parameter, configuration file log path settings, and the distinction between remote logging and module stderr output, it offers complete solutions. The article includes specific code examples to demonstrate how to view script execution outputs and return codes, helping users better debug and monitor Ansible automation tasks.

Problem Background and Requirements Analysis

When using Ansible for automated deployment and management, users often need to view detailed output information during module execution. Taking the script module as an example, when executing shell scripts on remote hosts, users expect to see script stdout, stderr, and return codes. However, the default ansible-playbook output only shows task execution status (such as ok, changed, etc.), lacking detailed execution specifics.

Verbose Output Mode: -v Parameter

Ansible provides a verbose output mode that displays detailed module execution information by adding the -v parameter. Here is a complete example:

$ cat test.sh
#!/bin/bash
echo Hello World
exit 0

$ cat Hello.yml
---
- hosts: MyTestHost
  tasks:
  - name: Hello yourself
    script: test.sh

$ ansible-playbook -v Hello.yml

After executing the above command, the output will include detailed execution results of the script module:

PLAY [MyTestHost] ****************************************************************

GATHERING FACTS ***************************************************************
ok: [MyTestHost]

TASK: [Hello yourself] ********************************************************
ok: [MyTestHost] => {
    "changed": false,
    "rc": 0,
    "stderr": "",
    "stdout": "Hello World\n"
}

PLAY RECAP ********************************************************************
MyTestHost                    : ok=2    changed=0    unreachable=0    failed=0

From the output, we can see that the script's stdout is "Hello World\n", return code rc is 0, and stderr is empty. This is exactly the detailed information users expect to see.

Configuration File Logging

In addition to command-line output, Ansible supports saving execution logs to files. By setting the log_path parameter in the Ansible configuration file, automatic log recording can be achieved.

Create or edit the Ansible configuration file and add the following content:

[defaults]
log_path=/path/to/ansible.log

Ansible searches for configuration files in the following priority order:

After configuration, all ansible-playbook execution logs will be recorded in the specified file, facilitating subsequent analysis and auditing.

Distinction Between Remote Logging and Module Output

In Ansible's logging system, two important concepts need to be distinguished:

Remote Logging: Refers to recording module execution parameters and related information on managed nodes. By default, Ansible records module invocation information on remote hosts via /usr/bin/logger, but the command module can disable this feature using the stealth=yes parameter.

Module Stderr Debugging: Refers to debug information generated during module execution being returned to the control node via stderr output. This is exactly what the -v parameter displays, including script outputs, return codes, and other detailed information.

This design ensures a balance between security and debugging convenience. Sensitive information can be protected by disabling remote logging, while debug information is safely returned through the stderr channel.

Practical Application Recommendations

In practical usage, it is recommended to choose appropriate logging methods based on different scenarios:

By properly utilizing these features, the maintainability and debuggability of Ansible automation tasks can be significantly improved.

Copyright Notice: All rights in this article are reserved by the operators of DevGex. Reasonable sharing and citation are welcome; any reproduction, excerpting, or re-publication without prior permission is prohibited.