こんにちは！現場のインフラやSREを支える中で、こんな悩みに直面したことはありませんか？
「新しいサーバーを立てるたびに、Excelやスプレッドシートの資産台帳（CMDB）を手動で更新している……」
「気づけば現場の物理・仮想サーバーの構成が変わりすぎて、監視ツール上の実態と台帳が完全に乖離している……」
「監査の前になると、慌てて全台のシリアル番号やOSバージョンを目視確認して回るハメになる……」
痛いほどよくわかります。その手作業、エンジニアの貴重な時間とモチベーションを削るだけの「無駄なノイズ」でしかありません。
オブザーバビリティ（可観測性）の世界において、監視とは単に「障害に気づくこと」ではありません。「システム全体の真実の姿（State of Truth）を常に把握し続けること」です。
今回は、Zabbixが持つ「自動インベントリ収集機能」をフル活用し、OSやハードウェア情報を完全自動で外部CMDB（今回は汎用的なRedmineやAPIを想定）へと同期させ、資産管理の手間を完全にゼロにするデータエクスポート基盤の作り方を、現場の知見をたっぷり込めて優しく解説します。
これをマスターすれば、あなたのチームの資産管理業務は劇的にラクになりますよ。さあ、一緒に「手作業ゼロの世界」へ踏み出しましょう！
—
1. Zabbixインベントリ情報の基本設定と取得項目のカスタマイズ
まず、Zabbixの「自動インベントリ」がどういう仕組みで動いているのか、その本質を理解しましょう。
Zabbixエージェントは、ホストのOS種別、ホスト名、カーネルバージョン、ハードウェアのシリアル番号といった情報を、実は標準ですでに持っています。これを手動ではなく、「ホスト登録と同時に自動で吸い上げる（自動インベントリ）」ように設定するのが第一歩です。
ステップ1：ホストグループまたはテンプレートでの有効化
個別のホストごとに設定するのはプロの仕事ではありません。必ずテンプレート側で設定します。
1. Zabbixフロントエンドにログインし、`設定` > `テンプレート` から対象のテンプレート（例: `Template OS Linux by Zabbix agent`）を開きます。
2. `ホストインベントリ`タブを開きます。
3. ラジオボタンを [自動] に切り替えます。
たったこれだけで、Zabbixはこのテンプレートが適用された瞬間から、裏側でインベントリ情報の収集を始めます。
ステップ2：標準外のカスタム項目（独自メタデータ）の追加
OSやシリアル番号だけでは、現場のCMDB要件（例えば「設置ラック番号」「プロジェクトコード」「担当者ID」など）を満たせないことが多いです。Zabbixでは、ここに独自のインベントリ項目を追加できます。
1. `管理` > `一般` > `ホストインベントリ` に進みます。
2. 使われていないフィールド（例: `インベントリアカウント (Mac) [macaddress_a]` や `社内資産番号 [asset_tag]` など）のラベル名を、自社の運用に合わせて変更します。
3. エージェントのユーザーパラメータ（UserParameter）や、Zabbix Sender、あるいはローレベルディスカバリー（LLD）を活用して、これらのフィールドに値を流し込みます。
—
2. 外部CMDBへ自動連携するスクリプト実装（Python版）
データがZabbixに集まるようになったら、次はそれを「定期的に外部のCMDB（今回はREST APIを持つシステム、またはRedmine等のチケット/カスタムフィールド）へプッシュする仕組み」を作ります。
ここでは、ZabbixのAPIからインベントリ情報を取得し、外部システムへ綺麗に整形して流し込む、実用的なPythonスクリプトを解説します。
全体アーキテクチャ
[Zabbix Server] –(Zabbix API)–> [Python Sync Script] –(REST API)–> [外部CMDB / Redmine]
実装コード (`zabbix_cmdb_sync.py`)
このスクリプトは、Zabbixから全ホストのインベントリ情報を取得し、変更があった場合（あるいは定期バッチとして）外部CMDBに同期するイメージです。丁寧なコメントを入れているので、そのまま読み解いてみてください。
!/usr/bin/env python3
import requests
import json
import sys
— 設定値 —
ZABBIX_URL = “http://zabbix.example.com/zabbix/api_jsonrpc.php”
ZABBIX_USER = “Admin”
ZABBIX_PASSWORD = “your_zabbix_password”
CMDB_API_URL = “https://cmdb.example.com/api/v1/assets”
CMDB_API_TOKEN = “your_cmdb_bearer_token”
def get_zabbix_token():
“””Zabbix APIに認証し、Authトークンを取得する”””
payload = {
“jsonrpc”: “2.0”,
“method”: “user.login”,
“params”: {
“user”: ZABBIX_USER,
“password”: ZABBIX_PASSWORD
},
“id”: 1
}
response = requests.post(ZABBIX_URL, json=payload)
result = response.json()
if “result” in result:
return result[“result”]
else:
print(f”Zabbix認証エラー: {result.get(‘error’)}”, file=sys.stderr)
sys.exit(1)
def fetch_zabbix_inventories(auth_token):
“””Zabbixからホストのインベントリ情報を一括取得する”””
payload = {
“jsonrpc”: “2.0”,
“method”: “host.get”,
“params”: {
“output”: [“hostid”, “host”],
“selectInventory”: [
“name”, “os”, “serialno_a”, “asset_tag”,
“ip_address_a”, “hardware”, “software”
],
“filter”: {“status”: 0} # 有効なホストのみ
},
“auth”: auth_token,
“id”: 2
}
response = requests.post(ZABBIX_URL, json=payload)
return response.json().get(“result”, [])
def sync_to_cmdb(inventory_data):
“””取得したインベントリデータを外部CMDBのAPIへ送信する”””
headers = {
“Authorization”: f”Bearer {CMDB_API_TOKEN}”,
“Content-Type”: “application/json”
}
for host in inventory_data:
inv = host.get(“inventory”, {})
if not inv:
continue # インベントリが無効なホストはスキップ
payload = {
“hostname”: host.get(“host”),
“os_version”: inv.get(“os”),
“serial_number”: inv.get(“serialno_a”),
“asset_tag”: inv.get(“asset_tag”),
“primary_ip”: inv.get(“ip_address_a”),
“hardware_info”: inv.get(“hardware”)
}
# 外部CMDBへアップサート（登録・更新）リクエスト
try:
res = requests.post(CMDB_API_URL, json=payload, headers=headers, timeout=10)
if res.status_code in [200, 201]:
print(f”[SUCCESS] 同期完了: {payload[‘hostname’]}”)
else:
print(f”[WARNING] 同期失敗 ({payload[‘hostname’]}): ステータス {res.status_code} – {res.text}”)
except requests.exceptions.RequestException as e:
print(f”[ERROR] 通信エラー ({payload[‘hostname’]}): {e}”, file=sys.stderr)
def main():
print(“— Zabbix & CMDB 同期プロセス開始 —“)
token = get_zabbix_token()
hosts = fetch_zabbix_inventories(token)
print(f”同期対象ホスト数: {len(hosts)}台”)
sync_to_cmdb(hosts)
print(“— 同期プロセス終了 —“)
if __name__ == “__main__”:
main()
このスクリプトをLinuxの `cron` や Kubernetesの `CronJob` に登録し、1日1回（または数時間おきに）実行するだけで、あなたが寝ている間にも資産台帳が勝手に最新の状態にアップデートされる基盤が完成します。
—
3. 資産台帳との乖離を防ぎ、ITILプロセスを効率化する運用のコツ
ツールとスクリプトを導入しただけでは、真のオブザーバビリティは達成できません。現場を回すシニアエンジニアとして、運用を成功させるための「3つの極意」を伝授します。
1. 「正解（Single Source of Truth）」の主導権をZabbixに持たせる
「CMDBを直せばZabbixが直る」のか、「Zabbix（実態）を直せばCMDBが直る」のか。ここが曖昧だと現場は崩壊します。
インフラストラクチャのハードウェアやOS情報に関しては、「Zabbixが自動収集した実態データこそが正義（Single Source of Truth）」と定義してください。人間が手動でCMDBを書き換えても、夜間バッチでZabbixの最新データによって上書きされる（あるいはアラートが出る）設計にすることで、「台帳の放置・腐敗」を根絶できます。
2. 変更管理プロセス（ITIL）との統合
新サーバーの構築から廃止までのライフサイクルにおいて、この自動同期基盤は次のように機能します。
- 構築時: プロビジョニング完了後、Zabbixエージェントが自動デプロイされ、Zabbixにホストが登録される。数分後のバッチでCMDBに自動登録される（「登録漏れ」の撲滅）。
- ハードウェア交換時: メモリ増設やパーツ交換でシリアル・ハードウェア情報が変わった場合、Zabbixが検知して自動でCMDB側も更新される（「台帳と実態の乖離」の撲滅）。
- 廃止時: ホストが削除され、監視から外れると同時に、CMDB側でもステータスが「廃棄」に自動変更される。
3. 「幽霊サーバー（ゾンビ資産）」の検知アラート
逆に、こういう使い方もできます。「CMDBには登録されているのに、Zabbixからインベントリが取れなくなった（＝長期間通信がない）ホスト」を検知するクエリを組むのです。これにより、電源が切られたままラックに眠っている「幽霊サーバー」や、撤去漏れの仮想マシンをあぶり出すことができます。
—
まとめ
今回は、Zabbixの自動インベントリ収集機能と外部連携スクリプトを組み合わせ、資産管理の手間をゼロにするデータエクスポート基盤の作り方を解説しました。
- Zabbixのテンプレートでホストインベントリを[自動]にする。
- Python等の軽量なスクリプトとZabbix APIを使い、cronで定期的に外部CMDBへプッシュする。
- 「実態（Zabbix）を正とする」ルールを敷くことで、人間による手作業や台帳の不整合を完全に排除する。
これをマスターすれば、毎日の面倒な棚卸し作業や監査前のデータかき集めに怯える必要はもうなくなります。浮いた膨大な時間を、より本質的なシステムの改善や新しい技術の検証に充ててください。
あなたの運用の現場が、もっとスマートでエキサイティングな場所になることを応援しています！