RISC-V（リスクファイブ）は、クリエイティブコモンズとして公開され、誰でも無料で利用可能なプロセッサの命令セットです。近年ではx86やArmに次ぐ命令セットとして注目度が高まっています。
RISC-Vの命令セットがISO/IEC JTC1による国際標準化に着手へ。第一歩として公開仕様提出者の承認を受ける － Publickey
RISC-Vを主導する団体RISC-V Internationalは、このRISC-Vの命令セットがISO/IEC JTC1による国際標準化の第一歩としてPAS（Publicly Available Specification）提出者の承認を受けたことを明らかにしました。
RISC-Vの命令セットがISO/IEC JTC1による国際標準化に着手へ。第一歩として公開仕様提出者の承認を受ける － Publickey
⇧ 標準化されていなかったんか...
Zabbixのテンプレートとは
「Zabbix」のWeb画面上からではなく、「Zabbix API」を利用して、「テンプレート」の登録・更新したいことあるあるだと思いますと。
そも、「Zabbix」の「テンプレート」とは？
概要
テンプレートの使用は、作業負荷を軽減し、Zabbix設定を合理化する優れた方法です。 テンプレートは、複数のホストに簡単に適用できるエンティティのセットです。
https://www.zabbix.com/documentation/current/jp/manual/config/templates
エンティティは次の通りです。
- アイテム
- トリガー
- グラフ
- ダッシュボード
- ローレベルディスカバリルール
- ウェブシナリオ
https://www.zabbix.com/documentation/current/jp/manual/config/templates
現実のホストの多くは同一またはかなり類似しているため、1つのホストに対して作成した一連のエンティティ (アイテム、トリガー、グラフなど) が多くのホストにとって役立つ可能性があることは当然のことです。 もちろん、新しいホストごとにエンティティをコピーすることもできますが、それでは手作業が多くなります。 代わりにテンプレートを使用すると、それらエンティティを1つのテンプレートにコピーし、そのテンプレートを必要なだけのホストに適用できます。
https://www.zabbix.com/documentation/current/jp/manual/config/templates
⇧ 上記の説明によると、監視対象の「ホスト」に対して、どんな情報を取得するようにするかをまとめたものということらしい。
ネット上の情報によると、
前回「ZABBIXの設定」ではホストの登録から基本的な監視までの手順を説明しました。ですが、監視対象ごとに1つ1つ監視設定をしていくのには、膨大な手間と時間がかかります。そこで今回は「テンプレート」という機能を使って、効率的に監視を行う方法を紹介します。
テンプレートとは、複数のアイテム、トリガー、グラフの設定をまとめた監視設定の集まりです。テンプレートを利用することで、複数の監視対象にまとめて同一の設定をすることができます。
また、1つの監視対象に複数のテンプレートを適用したり、複数のテンプレートを取りまとめて1つのテンプレートとすることもできます。例えば、LinuxのテンプレートとApacheのテンプレートを適用することで、Webサーバの監視をすぐに開始することができます。
⇧ 上記のようなイメージで、「テンプレート」を用意しておくと、使い回しができるということみたい。
Zabbix APIによるZabbixのテンプレートの登録・更新についてなど
で、
⇧ 上記のstackoverflowの話だと、ややこしいのだが、
- テンプレート自体の登録・更新
- ホストに割り当てるテンプレートの登録・更新
は、利用する「Zabbix API」が変わって来るっぽい。
■1. テンプレート自体の登録・更新
■2. ホストに割り当てるテンプレートの登録・更新
rulesオブジェクトは次のパラメーターをサポートします。
https://www.zabbix.com/documentation/current/jp/manual/api/reference/configuration/import
⇧ 注意したいのは、「2. ホストに割り当てるテンプレートの登録・更新」で利用される「Zabbix API」については、パラメーターによって、
- 登録
- 更新
を使い分ける必要があるということですかね...
あとは、ホストのIDを取得する「Zabbix API」とかも必要になってくると思うので、「ホスト」に紐付く「テンプレート」の登録・更新の処理を実装するために必要な情報を整理するのに時間がかかりそうなのよね...
やはり、「Zabbix API」と「Zabbix」が利用している「データベース」のどの「テーブル」と関係してくるのかがドキュメントなどで直ぐに把握することができない状態なのが辛過ぎるのよね...
「Zabbix」が利用している「データベース」については、「ER図（ERD：Entity Relationship Diagram）」とかも公式のドキュメントでは公開してくれていないから、「データベース」の各々の「テーブル」の関係性が全く不透明なこともあり、データが簡単に壊れると思いますしな...
2025年11月11日（火）追記：↓ ここから
ネットの情報を漁っていたところ、
⇧ 上記サイト様で、「ホスト」に紐付いた「テンプレート」については、「host.update」で「テンプレート ID」を更新すれば良いらしい。
そうなってくると、「configuration.import」との使い分けがよく分からなくなってくるのだが...
ちなみに、
⇧ 上記サイト様にありますように、「ホスト」の登録は、1件ずつ処理するしか無さそうなのよね。
つまり、10000台の「ホスト」を登録したいような場合、「Zabbix API」のリクエストを10000回愚直に実行するしかないと。
であるからして、「Zabbix」がインストールされているマシンとは別のマシンとかから「Zabbix API」のリクエストを送る形だと、パフォーマンスが落ちるかもですかな...
う～む...、「Zabbix」なかなかにカオス過ぎるんだが...
2025年11月11日（火）追記：↑ ここまで
毎度モヤモヤ感が半端ない…
今回はこのへんで。
