# Ansible ping report **URL:** \ **Category:** Ansible Project\ **Created:** [November 3, 2023, 3:40pm UTC](https://forum.ansible.com/t/ansible-ping-report/38568 "2023-11-03T15:40:19Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![Dimitri\_Yioulos](https://avatars.discourse-cdn.com/v4/letter/d/b5ac83/32.png) [@Dimitri\_Yioulos](https://forum.ansible.com/u/Dimitri_Yioulos)\ **Post date:** [November 3, 2023, 3:40pm UTC](https://forum.ansible.com/t/ansible-ping-report/38568/1 "2023-11-03T15:40:19Z")
Hi, All. It’s been some time since I used Ansible, and this list. I’m happy to be back using both. I’ve created a [playbook to run pin, and create a report of output: ---
**Author:** ![system](https://us1.discourse-cdn.com/ansible/original/1X/1882d9a01da5d8996a862359b0913cc568a39b84.svg) [@system](https://forum.ansible.com/u/system)\ **Post date:** [November 6, 2023, 3:15pm UTC](https://forum.ansible.com/t/ansible-ping-report/38568/2 "2023-11-06T15:15:03Z")
Not all modules return a stdout nor stdout\_lines, ping is one of them, it returns 'data', check the RETURN DOCS for each module to know the structure of the registered var they return. ---
**Author:** ![Dimitri\_Yioulos](https://avatars.discourse-cdn.com/v4/letter/d/b5ac83/32.png) [@Dimitri\_Yioulos](https://forum.ansible.com/u/Dimitri_Yioulos)\ **Post date:** [November 6, 2023, 3:32pm UTC](https://forum.ansible.com/t/ansible-ping-report/38568/3 "2023-11-06T15:32:31Z")
Thanks, Brian. I suspected that was the case (I did read doc for the module), but was hoping there was some work-around. I’m still interested in trying to generate some type of report from Ansible ping. As you can see from the playbook I posted, that uses ICMP ping, which is not what I’m after. ---
**Author:** ![system](https://us1.discourse-cdn.com/ansible/original/1X/1882d9a01da5d8996a862359b0913cc568a39b84.svg) [@system](https://forum.ansible.com/u/system)\ **Post date:** [November 6, 2023, 5:03pm UTC](https://forum.ansible.com/t/ansible-ping-report/38568/4 "2023-11-06T17:03:22Z")
sorry, had only read the bottom, too used to people making that mistake, but you did not. ---
**Author:** ![vbotka](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/vbotka/32/359_2.png) [@vbotka](https://forum.ansible.com/u/vbotka)\ **Post date:** [November 6, 2023, 7:58pm UTC](https://forum.ansible.com/t/ansible-ping-report/38568/5 "2023-11-06T19:58:09Z")
Ignore unreachable hosts in a block     - block:         - ping:           register: out         - set\_fact:             unr: "{{ out.unreachable|d(false) }}"       ignore\_unreachable: true and declare the dictionary   h\_unr: "{{ dict(ansible\_play\_hosts\_all|                   zip(ansible\_play\_hosts\_all|                       map('extract', hostvars, 'unr'))) }}" For example, the below play - hosts: test\_01,test\_05,test\_06,test\_07   gather\_facts: false   vars:     h\_unr: "{{ dict(ansible\_play\_hosts\_all|                     zip(ansible\_play\_hosts\_all|                         map('extract', hostvars, 'unr'))) }}"   tasks:     - block:         - ping:           register: out         - set\_fact:             unr: "{{ out.unreachable|d(false) }}"       ignore\_unreachable: true     - debug:         var: h\_unr       run\_once: true       delegate\_to: localhost gives (abridged) ok: [test\_01 -\> localhost] =\>   h\_unr:     test\_01: false     test\_05: true     test\_06: true     test\_07: true ---
**Author:** ![dbs34](https://avatars.discourse-cdn.com/v4/letter/d/8dc957/32.png) [@dbs34](https://forum.ansible.com/u/dbs34)\ **Post date:** [November 7, 2023, 5:55pm UTC](https://forum.ansible.com/t/ansible-ping-report/38568/6 "2023-11-07T17:55:50Z")
would you mind sharing the whole, newly updated playbook? thank you! ---
**Author:** ![vbotka](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/vbotka/32/359_2.png) [@vbotka](https://forum.ansible.com/u/vbotka)\ **Post date:** [November 7, 2023, 7:15pm UTC](https://forum.ansible.com/t/ansible-ping-report/38568/7 "2023-11-07T19:15:30Z")
Sure, here is the gist [https://gist.github.com/vbotka/10c57962976dd1e2dd3e9411d3745c75](https://gist.github.com/vbotka/10c57962976dd1e2dd3e9411d3745c75) (Is it possible to reasonably format a code in Google Groups?) ---
**Author:** ![Dimitri\_Yioulos](https://avatars.discourse-cdn.com/v4/letter/d/b5ac83/32.png) [@Dimitri\_Yioulos](https://forum.ansible.com/u/Dimitri_Yioulos)\ **Post date:** [November 8, 2023, 2:22pm UTC](https://forum.ansible.com/t/ansible-ping-report/38568/8 "2023-11-08T14:22:49Z")
Vladimir, this is very good, and very appreciated. Your playbook looks for hosts that are pingable, and marks them as not unreachable. But, my goal is to see if hosts are Ansible-pingable (not ICMP-pingable; I believe there’s a difference) or not, then take all of the output, and create a report from it. Thus, i end up with a report of hosts that are either Ansible-pingable or not. ---
**Author:** ![Thanh\_Nguyen\_Duc](https://avatars.discourse-cdn.com/v4/letter/t/c89c15/32.png) [@Thanh\_Nguyen\_Duc](https://forum.ansible.com/u/Thanh_Nguyen_Duc)\ **Post date:** [November 8, 2023, 3:32pm UTC](https://forum.ansible.com/t/ansible-ping-report/38568/9 "2023-11-08T15:32:36Z")
You may try the attached playbook i am using for linux, windows will be similar as well. The report will be in html format Vào Th 4, 8 thg 11, 2023 vào lúc 22:22 Dimitri Yioulos \<[dimitri.g.yioulos@gmail.com](mailto:dimitri.g.yioulos@gmail.com)\> đã viết: > **(attachments)** > > [exportreport.yml](https://forum.ansible.com/uploads/short-url/hKOIj7cAwcI0bD5HNbBt6BR7nos.yml) (520 Bytes) > [linux\_ping.j2](https://forum.ansible.com/uploads/short-url/1cjrJvEvhIJzPdyf7YFPjgOaQtn.j2) (1.85 KB) > [general.yml](https://forum.ansible.com/uploads/short-url/l1KdkJRA9yoqDgAyFSN7JJ1WYL7.yml) (617 Bytes) > [createreport.yml](https://forum.ansible.com/uploads/short-url/lY59P9D188WBjoaOHPC3MujLlr7.yml) (1.73 KB) > [Daily\_LinuxPing.yml](https://forum.ansible.com/uploads/short-url/gNArq53rKCyPfFCWLteNKlJFQDu.yml) (1.29 KB) ---
**Author:** ![vbotka](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/vbotka/32/359_2.png) [@vbotka](https://forum.ansible.com/u/vbotka)\ **Post date:** [November 8, 2023, 9:06pm UTC](https://forum.ansible.com/t/ansible-ping-report/38568/10 "2023-11-08T21:06:31Z")
> ... my goal is to see if hosts are Ansible-pingable (not > ICMP-pingable; I believe there's a difference) or not, then take > \*all\* of the output, and create a report from it. Thus, i end up > with a report of hosts that are either Ansible-pingable or not. Dimitri, the play does what you want. The code is available also here [https://gist.github.com/vbotka/10c57962976dd1e2dd3e9411d3745c75](https://gist.github.com/vbotka/10c57962976dd1e2dd3e9411d3745c75) Let me help you to understand it step by step > > > - hosts: test\_01,test\_05,test\_06,test\_07 > > >   gather\_facts: false There are 4 hosts in the play. Setup is off, hence no connections to the remote host up till now > > > vars: > > > > > >   h\_unr: "{{ dict(ansible\_play\_hosts\_all| > > >                   zip(ansible\_play\_hosts\_all| > > >                       map('extract', hostvars, 'unr'))) }}" This dictionary will be evaluated when referenced in the debug task > > > tasks: > > > > > >   - block: > > >       - ping: > > >         register: out > > >       - set\_fact: > > >           unr: "{{ out.unreachable|d(false) }}" > > >     ignore\_unreachable: true Here come the first connections to the remote hosts. There are 2 tasks in the block. The first one is the Ansible module ping, not the ICMP ping. (Yes, you're right. There is a difference.) The second one is the module set\_fact. Because of the ignore statement the tasks in the block won't fail if a host is unreachable. If a host can be reached by ping there is no attribute \*unreachable\* in the registered dictionary \*out\*. Therefor, the value of the variables \*unr\* will be the default (alias d) value \*false\*. If a host can't be reached the value of the attribute \*unreachable\* is \*true\*. > > >   - debug: > > >       var: h\_unr > > >     run\_once: true > > >     delegate\_to: localhost Here is the report. Let's analyse the dictionary \*h\_unr\*. In the above block, all hosts created the variable \*unr\*. When you take the list of all hosts in the play \*ansible\_play\_hosts\_all\* [1] and \*map\* the function to \*extract\* the \*hostvars\* [2] variable \*unr\*      ansible\_play\_hosts\_all|map('extract', hostvars, 'unr') you get a list, for example, where only the first host was reached   [false, true, true, true] Then, \*zip\* this list with \*ansible\_play\_hosts\_all\*   [[test\_01,false], [test\_02,true], [test\_03,true], [test\_04,true]] and apply the function \*dict\* [3]. Below is the expected result. Enjoy! > > > gives (abridged) > > > > > > ok: [test\_01 -\> localhost] =\> > > > h\_unr: > > >   test\_01: false > > >   test\_05: true > > >   test\_06: true > > >   test\_07: true [1] [https://docs.ansible.com/ansible/latest/reference\_appendices/special\_variables.html](https://docs.ansible.com/ansible/latest/reference_appendices/special_variables.html) [2] [https://docs.ansible.com/ansible/latest/playbook\_guide/playbooks\_filters.html#selecting-values-from-arrays-or-hashtables](https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_filters.html#selecting-values-from-arrays-or-hashtables) [3] [https://docs.ansible.com/ansible/latest/playbook\_guide/playbooks\_filters.html#combining-items-from-multiple-lists-zip-and-zip-longest](https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_filters.html#combining-items-from-multiple-lists-zip-and-zip-longest)