AnsibleのCallback Plugin設計入門|実行結果をJSON出力・Slack通知・ARAで可視化する方法

運営:リナックスマスター.JP(代表 宮崎智広)
HOME > Linux技術 リナックスマスター.JP(Linuxマスター.JP) > Ansible > AnsibleのCallback Plugin設計入門|実行結果をJSON出力・Slack通知・ARAで可視化する方法
「Playbookを実行したが、どのタスクで何分かかったか後から確認できない」「チームメンバーに実行結果を共有するのが面倒で、失敗に気づかず翌朝まで放置してしまう」

Ansibleには実行結果を受け取って処理できるCallback Pluginという仕組みがあります。これを活用すれば、タスク実行時間の計測・Slack通知・実行履歴のDB管理まで、Playbook実行の可視化を設計レベルで制御できます。

この記事では、RHEL 9系~10系(Ubuntu 22.04 LTSでも同様)を想定環境として、Ansible Callback Pluginの仕組みから実践的な設定パターンまでを解説します。

この記事のポイント

・Callback PluginはPlaybook実行イベントを受け取る拡張点。ansible.cfgで有効化できる
・profile_tasksで各タスクの実行時間を計測してボトルネックを特定できる
・community.general.slackでPlaybook完了時にSlackチャンネルへ通知できる
・ARAはPlaybook実行履歴をDBで管理するOSSで、チーム運用の標準ツールとして使われている


「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

Callback Pluginが解決する「可視化の問題」

Ansibleを個人の検証環境で使う段階では、ターミナルに流れるログを目で追えば十分です。しかしサーバー台数が増え、チームでPlaybookを実行するようになると、次の問題が浮かび上がります。

・誰がいつどのPlaybookを実行したか記録がない
・タスクのどのステップに何分かかったか後から追えない
・失敗通知を見落として翌朝まで気づかない

これらはすべて「実行結果の可視化設計」の問題です。Ansibleのアーキテクチャには、この問題をPlaybookのコードを変えずに解決できる仕組みが最初から組み込まれています。それがCallback Pluginです。

Callback Pluginとは何か

Callback Pluginは、Playbook実行中に発生するイベント(タスク開始・終了・失敗・Playbook完了など)を受け取って任意の処理を行うプラグインです。

Ansibleの実行フローを簡単に示すと以下のようになります。

# Playbook実行時のCallback Pluginの呼び出しフロー(概念図) ansible-playbook site.yml を実行 ↓ PlaybookエンジンがイベントをCallbackに送信 ├── v2_playbook_on_start (Playbook開始時) ├── v2_runner_on_ok (タスク成功時) ├── v2_runner_on_failed (タスク失敗時) ├── v2_runner_on_changed (タスクで変更発生時) └── v2_playbook_on_stats (統計情報・Playbook末尾) ↓ 各Callback Pluginが受け取って処理(表示・保存・通知)

プラグインは ansible.cfg の callbacks_enabled で有効化します。複数のプラグインを同時に有効化でき、それぞれが独立してイベントを処理します。

Ansibleに搭載されているCallback Pluginは大きく2種類に分かれます。

・stdout callback:ターミナルへの標準出力フォーマットを制御する。stdout_callback で指定し、1つだけ有効化できる
・aggregate callback:stdout callbackとは独立して動作する追加プラグイン。callbacks_enabled で複数有効化できる

標準搭載Callback Pluginを使う

ansible-coreとcommunity.generalコレクションには、追加インストールなしで使えるCallback Pluginが含まれています。

1. ansible.cfgで基本設定をする

Callback Pluginは ansible.cfg の [defaults] セクションで設定します。

[defaults] # ターミナル出力を見やすいYAML形式に変更 stdout_callback = yaml # 追加のCallback Pluginを有効化(カンマ区切りで複数指定可) callbacks_enabled = profile_tasks

stdout_callback = yaml に設定すると、デフォルトの minimal よりもタスク結果が読みやすい形式で表示されます。

2. profile_tasksで実行時間を計測する

profile_tasks プラグインは各タスクの実行時間を計測し、Playbook終了時に時間の長い順に一覧表示します。長時間かかるタスクのボトルネック特定に役立ちます。

Playbook実行後、末尾に以下のような一覧が出力されます(出力例・環境により異なります)。

Thursday 06 November 2026 11:30:00 +0900 (0:00:02.312) 0:00:05.401 *** =============================================================================== install nginx ----------------------------------------------------- 2.31s configure nginx template ------------------------------------------ 1.58s start nginx service ----------------------------------------------- 0.80s Gathering Facts --------------------------------------------------- 0.71s

「install nginx」が最も時間を消費しているのが一目でわかります。チューニング対象を絞り込んだら、ansible.cfg の pipelining = True や forks 増加と組み合わせることで、実行時間をさらに短縮できます。

3. jsonプラグインで実行結果をファイル出力する

json プラグインはPlaybook実行結果をJSON形式で標準出力に流します。リダイレクトと組み合わせることで、後からスクリプトで解析できる機械可読な記録を作れます。

# 実行結果をタイムスタンプ付きのJSONファイルに保存する例 ANSIBLE_STDOUT_CALLBACK=json ansible-playbook site.yml \ > /var/log/ansible/$(date +%Y%m%d_%H%M%S).json 2>&1

ただし stdout_callback は1つしか設定できないため、ターミナルで人間向けの出力を見ながら記録も残したい場合は、後述するARAを使う方が実用的です。

Slack通知Callback Pluginを設定する

Playbookが完了・失敗した際にSlackチャンネルへ通知するには、community.general コレクションの slack プラグインを使います。

1. community.generalをインストールする

# community.generalコレクションをインストール ansible-galaxy collection install community.general

2. Slack Incoming Webhook URLを用意する

Slackの管理画面からIncoming Webhook URLを発行します。このURLはシークレット情報のため、ansible.cfg にハードコードせず、Ansible Vaultで暗号化した変数として管理することを推奨します。

Ansible VaultによるシークレットのPlaybook組み込み設計については、Ansibleの構成管理設計の基礎と合わせて習得するとより実践的です。

3. ansible.cfgでプラグインを設定する

[defaults] callbacks_enabled = community.general.slack [callback_slack] webhook_url = https://hooks.slack.com/services/TXXXXXXXX/BXXXXXXXX/XXXXXXXXXX channel = #ansible-notify username = AnsibleBot

これでPlaybook実行のたびに成功・失敗いずれの結果もSlackに通知されます。失敗のみ通知したい場合はカスタムCallback Pluginが必要ですが、まずは全通知から始めて運用ノイズを見極めるのが現実的なアプローチです。

ARAでPlaybook実行履歴を管理する

ARA(ARA Records Ansible)は、Playbook実行履歴をSQLiteやPostgreSQLに自動保存し、WebブラウザーやAPIで参照できるOSSです。個人の検証から本番チームの運用管理まで幅広く使われています。

1. ARAのインストールとCallback設定

# ARAとAPIサーバーをインストール pip3 install ara[server] # ARAがインストールしたCallback Pluginのパスを確認する python3 -c "import ara; print(ara.__file__.replace('__init__.py', 'plugins/callback'))" # 出力例(環境により異なります) # /usr/local/lib/python3.11/site-packages/ara/plugins/callback

確認したパスを ansible.cfg に設定します。

[defaults] # ARAのCallback Pluginのパスを追加 callback_plugins = /usr/local/lib/python3.11/site-packages/ara/plugins/callback callbacks_enabled = ara_default

2. ARA APIサーバーを起動する

# DBの初期化とAPIサーバーの起動 ara-manage migrate ara-manage runserver 0.0.0.0:9191

3. ARAのWeb UIで実行履歴を参照する

ブラウザーで http://localhost:9191 にアクセスすると、以下の情報が確認できます。

・いつ誰がどのPlaybookを実行したか(実行ユーザー・ホスト名・開始時刻)
・各タスクの成否・所要時間・実際に変更した内容の差分
・ホストごとの実行結果の差異(同じPlaybookを10台で実行した場合の比較)
・gather_factsで収集したホスト情報の変化履歴

jsonプラグインで手動管理するよりもはるかに実用的です。チームでAnsibleを運用する場合の標準ツールとして広く採用されています。

カスタムCallback Pluginを開発する考え方

標準プラグインでカバーできない要件(社内チケットシステムへの自動登録・特定タスクのみ通知など)が出てきた場合は、カスタムCallback Pluginを開発します。

開発の基本構造は次のとおりです。

# カスタムCallback Pluginの骨格 # ファイル: callback_plugins/my_custom.py from ansible.plugins.callback import CallbackBase class CallbackModule(CallbackBase): CALLBACK_VERSION = 2.0 CALLBACK_TYPE = 'notification' CALLBACK_NAME = 'my_custom' CALLBACK_NEEDS_ENABLED = True def v2_runner_on_failed(self, result, ignore_errors=False): """タスク失敗時に呼ばれるメソッド""" host = result._host.get_name() task = result.task_name # ここに社内システムへの通知ロジックを書く pass def v2_playbook_on_stats(self, stats): """Playbook終了時に呼ばれるメソッド""" # ここに集計・レポート出力ロジックを書く pass

設計上の重要な考え方が1つあります。Callback Pluginは実行のたびに呼ばれるため、副作用(外部HTTPリクエスト・ファイル書き込み)は必ずエラーハンドリングを入れることです。プラグインが例外で落ちるとAnsible本体の実行がブロックされます。

Callback Pluginは callback_plugins = ./callback_plugins のようにプロジェクトのローカルディレクトリを指定することもできます。チーム全員が同じバージョンを使うには、Ansible Execution Environmentsにプラグインを含めてコンテナ化するのが確実な方法です。

よくあるトラブルと対処

1. callbacks_enabledを設定したのに有効にならない

・コレクション付きのプラグイン名(community.general.slack など)はFQCN形式で指定すること
・callback_plugins パスの設定が正しいか確認する
・ansible-doc -t callback -l で利用可能なプラグイン一覧を確認する

# 利用可能なCallback Pluginの一覧を確認する ansible-doc -t callback -l # 出力例(環境により異なります) # ansible.posix.cgroup_perf_recap Profiles tasks and hosts using cgroups # community.general.slack Sends play events to a Slack channel # ara.plugins.callback.ara_default Records Ansible and AWX/Tower data

2. profile_tasksの合計時間と実感が合わない

Gather Factsが時間を消費している場合は、gather_facts: false を設定してfact収集を無効化するか、fact cachingを使って前回収集した情報を再利用します。

# ansible.cfgでfact cachingを有効化する例 [defaults] fact_caching = jsonfile fact_caching_connection = /tmp/ansible_facts fact_caching_timeout = 86400

3. ARA APIサーバーへの接続タイムアウトが発生する

ARAのCallback Pluginは起動時にAPIサーバーへ接続します。サーバーが停止していると接続タイムアウトが発生します。接続先URLは環境変数 ARA_API_SERVER で指定でき、デフォルトは http://127.0.0.1:8000 です。

# 環境変数でAPIサーバーのURLを指定する export ARA_API_SERVER=http://ara.internal:9191 ansible-playbook site.yml

本記事のまとめ

Ansible Callback Pluginを目的別にまとめます。
用途 使うプラグイン 設定箇所
実行時間の計測 profile_tasks callbacks_enabled = profile_tasks
出力フォーマット改善 yaml stdout_callback = yaml
JSON形式で結果保存 json stdout_callback = json(リダイレクトと組み合わせる)
Slack通知 community.general.slack callbacks_enabled = community.general.slack
実行履歴のDB管理 ARA(ara_default) pip3 install ara[server] → callback_pluginsに追加
カスタム通知・連携 自作Callback Plugin CallbackBaseを継承してv2_runner_on_*を実装
Callback Pluginの最大のメリットは「Playbookのコードを変えずに可視化機能を追加できる」点です。まずは profile_tasks と stdout_callback = yaml から始め、チームの規模が大きくなったらARAの導入を検討するのが実践的な道筋です。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、AnsibleをはじめとしたLinuxサーバー自動化の実践スキルは、Ansibleハンズオンで体系的に学べます。コマンドの丸暗記ではなく、設計の考え方から習得したい方はぜひご覧ください。

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録

運営

リナックスマスター.JP(代表 宮崎智広)

株式会社イーネットマーキュリーが運営するLinux教育サイトです。代表の宮崎智広は現役のLinuxサーバー管理者として20年以上の実務経験を持ち、累計3,100名以上のエンジニアを指導してきました。実践型のLinuxセミナーや無料マニュアルの配布を通じてLinux人材の育成に取り組んでいます。