Zabbixのテンプレートを使っている人なら1度は通る道、それが「テンプレートJSON地獄」です。
- Zabbixのテンプレートは試行錯誤を凝らせばより優れたモニタリングツール
- しかし、JSONを修正しての複製は謎のエラーの連発
- 「同じUUIDは許さん」としつこく怒られる
この記事は、開発中・稼働中のシステム監視のためにZabbixテンプレートを複製しようとしたら、本気でブチ切れそうになったエンジニア（とAIサポートシステム）の戻らぬ戦いの記録である。
なぜやろうとしたのか
開発中・稼働中のシステムではすでにZabbixによる監視・通知が稼働中。そこに「ディスクI/Oだけ分離して監視強化したい」という構想が浮かび、Zabbixの既存テンプレートをベースに一部機能を切り出して「カスタムテンプレート」を作る必要が出てきた。
特定のホストだけ、I/Oのボトルネックを疑う事象が発生したが、他ホストでは問題ない。テンプレートのDisk I/Oのサンプリング間隔・しきい値を変更すると、他のホスト監視まで影響し、警告地獄or知らぬ間に文鎮システムになる可能性があったので、カスタムテンプレートが最適解かもと思った。
ただし、GUIで「複製」をやるとき、紐付いているホストがあると複製ができないというZabbixの制限がある。GUIで済まそうとすると、ホストからテンプレを削除（割り当て解除）→複製→再割り当てを行う必要がある。
もちろん割り当て解除している間はホストデータが収集されない。監視対象がクリティカルなシステムであれば、このダウンタイムは許容できない。（今回は学習としてやったのも大きい）
どうしよう→「エクスポートボタンあるな？」から地獄は始まった。
GUIから1から作り直すのは面倒。エクスポートしてJSON修正で一気にやった方が早いだろう、と思って手を出したのが運の尽き。
これをやろうとした
- オリジナルのテンプレートをエクスポート
- JSON内のテンプレート名やDescriptionを変更
- UUIDをオリジナルとは別物にするために全部更新
- 不要なvalue_mapsを削除（実はこれが罠）
- テンプレート名を変更し、ホストからは紐づけない状態に
- さあインポートじゃあああああああああ
『「Value map with the same UUID already exists」』
ここから長い旅が始まる──。
実際に直面したZabbix元祖トラップ
| エラー内容 | 原因 | 解決策 |
|---|---|---|
| Value map with the same UUID already exists | UUIDがテンプレ内で重複 | UUIDを新規生成 |
| Trigger with same UUID exists | Trigger UUIDの不更新 | TriggerのUUIDも全体変更 |
| Graph "System Load" not found | Graph名称変更したけどDashboardで参照されてる | Graph名もちゃんと統一 |
| Linked trigger cannot be moved | 共有されてるTriggerの別テンプレへの移動 | Expression内のhostを変更 |
| LLD rule with the same UUID already exists | LLD UUIDの重複 | 一つずつUUID変更（地道） |
| Value map not found | 削除したvalue_mapsが他から参照されてた | 素直に復元＆UUID変更（詳細は下記） |
| Graph ID exists | 既存テンプレのgraphとIDかぶり | UUIDとgraph名をセットで変更 |
このあたり、Zabbix公式の「インポート整合性チェック」が相当厳密。
ValueMapを削除して詰んだ件
最初は「使ってないし、不要だろう」と思って value_maps セクションごと削除。すると、インポート時に
Value map not found
と怒られる。
何が問題かというと、他のセクション（TriggerやLLDのアイテムプロトタイプなど）が削除した value_map を参照していたため。
解決策：
- まずはオリジナルテンプレートの value_maps セクションを復元
- name だけではなく uuid もすべて新規で差し替え（他と被らないように）
- さらにそれを参照している item や graph などの記述内の host 名、template 名もきっちり変更
これでやっと解決！
構造の可視化（Zabbixテンプレート構成）
テンプレートは以下のような依存関係構造をしている：
template
├── dashboard
│ └── graph
│ └── item
│ └── prototype (LLD)
├── value_maps
├── triggers
├── graphs
├── discovery_rules
上位層（ダッシュボード）で参照している要素を先に削除・変更すると整合性エラーになる。必ず「下から順番に」見直していくことが重要。
テンプレート内部のUUIDや依存データはDBで管理されている
Zabbixのテンプレート関連データは、バックエンドのDB（MySQL, PostgreSQL）に保存されている。
たとえば：
SELECT * FROM graphs WHERE graphid = 2229;
のようなクエリで、エラーに出たIDの情報が取得できる。Zabbixが保持しているUUIDやtemplateのlinkはすべてデータベースにあるため、整合性のトラブルは「DBで確認→テンプレJSONを修正」の流れで攻略できる。
学びポイント
- ZabbixのテンプレートJSONは、静的なID(ユニークなUUID)で自分を表す
- UUIDが１箇所でも被っていたら完全にアウト（テンプレ全体がインポート拒否）
- value_maps / graph / trigger / dashboard / LLD rule… すべてにUUIDがある
- expression中のhost名も変更が必要（テンプレ名が元と同じだと拒否される）
- グラフ内のitem定義もhost指定なので注意
- Zabbixのテンプレート構成要素ごとの依存関係（例：ダッシュボード→グラフ→アイテム→LLD）を理解して順序立てて修正すべし
ChatGPT（AI）との連携の威力
今回の修正作業では、ChatGPT（OpenAI）を活用して以下の支援を受けた：
- UUIDの高速生成（ハイフンなしバージョンを大量に生成）
- JSONの構成や依存関係の整理
- エラーの意味や該当箇所の特定とナビゲーション
- 思考の整理、戦略の選択肢提示（「この順で修正したら効率いい」など）
UUIDの書式について：
ZabbixではUUIDv4を要求するが、形式としては「xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx」（32文字、ハイフンなし）で記述されている。
ChatGPTに以下のように頼むとサクッと出力してくれる：
# 例：32文字のUUIDを5個（ハイフンなし）
for i in {1..5}; do cat /proc/sys/kernel/random/uuid | tr -d '-' ; done
これで uuid フィールドに使える値を大量に生成可能。
スピンオフ的Tips
- SublimeTextでUUIDを一括検索・置換（便利）
- ChatGPTでUUID自動生成（32文字、ハイフン除去）
- host名の変更(特にtrigger expression内)
- 全テンプレを自分用にリファクタリング可能
- 必要ならvalue_mapsやgraphも名前変更
- 必要に応じて dashboard の name も変更（dashboard と graph の紐付きもある）
- Git管理しておくと編集時に比較できて安心
- ChatGPTと分担しながら「JSON職人」するのが効率的（自動化＋判断）
おまけ
今回、手動でUUIDを更新していったが、これ、本当にサービス化できる。
「Zabbixテンプレ複製メーカー」
みたいなWebサービスを作るのもありかもしれない…（ブクブク）
テンプレのJSONファイルアップロード→UUID全再生成→host名書き換え→value_maps再割り当て
とかできたら神。
結論
ZabbixテンプレートJSONは「悩みどころの多い混乱データ」だけど、理解して解答を持ってまた修正にあたれば、簡単に「自分だけのカスタムテンプレート」が作れるようになる。
今回もカスタムテンプレートを「切り出して」作ろうと思ったが、結果カスタムのフルバージョン「Linux By Zabbix Agent ( I/Oカスタム) 」ができてしまった。
オリジナルの「Linux By Zabbix Agent 」は他のホストでも使っているので、代替テンプレートが作れたのは大きい。
個人レベル揮発でも、システムの監視を強化・最適化すれば、人間の負荷を軽減できる事を今回の体験を通して完璧に学んだんだぜぇ。←
書いてる間にもテンプレ複製してる人いるかもしれない。
その人の手間が1分でも減ったら本望です。