Ansible

Ansible: Log Visibility Control

Michael Mikhailidi

Oct 10, 2024 • 2 min read

Ansible, originally developed as a state management tool, relies on logs to track play progress and target states due to its distributed execution. Let's discuss a few methods for controlling log content and visibility.

The Ansible allows you to define log verbosity for all command line tools and task runs on AWX/AAP. All you need to do for the command-line interface is pass option -v along with the other command arguments. The verbosity level depends on the count of v's in the argument.

Verbosity	Level
-v	Verbose. Ansible commands show an extra details
-vv	More verbose. More details in the task output.
-vvv	Debug. Ansible output contains debugging infomration on commands execution
-vvvv	Debug with Connection Details. At this level, Ansible records connection logs and protocol details.
-vvvvv	TMI. I've never used that one
-vvvvvv	TMI. I've never used this one either.

The "magic variable" ansible_verbosity reflects the requested level of verbosity. This variable can be used to change code behavior or bypass task output.

 $ ansible-playbook -i hosts.yml -vvv ansible-logs.yml

Executing Ansible playbook with the debugging verbosity level.

If you don't develop custom modules and filters using Python, your most common log content control tools are debug task and no_log attribute.

The debug lets you dump variable content or a message into the play log. The additional parameter "verbosity" controls the execution of the task. The debug task will be skipped if the command or play runs with the verbosity below the current level. The screenshot below demonstrates how the verbosity value changes the command behavior.

The task skipped, because requeired verbosity isn't met.

While the verbosity parameter controls the debug task behavior, the generic attribute no_log allows you to censor any task, including the debug. Alternatively, you can hide logging for the whole play if it operates with sensitive information. To avoid source code changes during tests or debug cases, compute the no_log value and expose the censored information when needed. The code snippet below calculates the attribute's value from the run verbosity and other variables.

- name: Log Content Control
  hosts: localhost
  no_log: no
  vars:
    nologs: |
     "{{ (2 >= ansible_verbosity or tower_user_id is defined )|bool }}" 
  tasks:
    - debug:
         msg: |
         "I'm visible at level {{ ansible_verbosity }} and
         logs are {{ 'hidden' if nologs else 'visible' }}."
         verbosity: 2 
       no_log: "{{ nologs }}"

Calculate no_log value

The attribute accepts a boolean value, and if set to True, Ansible does not record command output. The screenshot below depicts task messages when no_log is active.

Ansible play output with the disabled logging.

❗

I do not recommend using the calculated no_log values, especially in production environments. While it could be a convenience for the regular command-line Ansible, it may compromise security in the Ansible Automation Platform environments.

A short summary:

Ansible verbosity settings (-v[v[v[v[v[v]]]]]]) define the verbosity level during the command execution.
The debug command allows you to log extra information, with account of the verbosity.
The magic variable "ansible_verbosity" allows you to alter play behavior or adjust the log level for your custom tasks and roles.
The generic no_log attribute censors sensitive information. It should be hard coded to avoid data leaks through the execution logs.