ZabbixAPI trigger.create

本項ではトリガーの作成を行うAPIについて記載する。

http://kyou.hatenadiary.jp/entry/2017/12/25/233314
ZabbixAPIを使うメリット で記載した「新規追加のシステム(サーバ群)を新規監視登録する場合」に使用する

http://kyou.hatenadiary.jp/entry/2018/01/01/010131
ZabbixAPIを使う作業環境 で記載した環境のため、json2zabbix.shで使うJSON形式を作成して実行する方式とする。

また、Zabbix公式Docで参照するページは以下2つになる
https://www.zabbix.com/documentation/3.0/manual/api/reference/trigger/object
https://www.zabbix.com/documentation/3.0/manual/api/reference/trigger/create


作成要領としてはitemと大きく変わることがない、と思いきや留意する点がある。

1, GUI上の項目名(日本語の場合)とTriggerAPIのProperty Nameが一致しない(Trigger関連API全般)

2, Triggerの元となるItemは[TemplateName:item.key]もしくは[Hostname:item.key]の形式で指定する(Trigger create及びupdate)

3, trigger.getで特に指定しない場合、条件式はitemidで表示される(Trigger get及びupdate)

またGUIでの作成と同様に、条件式内のitemが既に作成されていない場合trigger.createは失敗する


公式Docのアイテム作成JSONのサンプルは以下のとおり
{
"jsonrpc": "2.0",
"method": "trigger.create",
"params": {
"description": "Processor load is too high on {HOST.NAME}",
"expression": "{Linux server:system.cpu.load[percpu,avg1].last()}>5",
"dependencies": [
{
"triggerid": "14062"
}
]
},
"auth": "038e1d7b1735c6a5436ee9eae095879e",
"id": 1
}

各パラメータの詳細を記載する。
jsonrpc: これは"2.0"固定

method: "item.update"でアイテム作成を指定する。必須項目。

description: 必須項目。トリガー名。nameに該当すると考えて良い。

expression: 必須項目。トリガー条件式。ダブルクォーテーション使用時はエスケープに留意のこと。

dependencies: トリガー依存の指定。作成済みのトリガーIDを指定する。

auth: ZabbixAPIの認証トークン。必須項目。json2zabbix.shの場合は ##TOKEN## を記載する。

id: ZabbixAPIの実行ID。必須項目。とりあえず1で良い。

 

また、サンプルに無い項目であるが留意するパラメータとして

comment: GUIの[説明]項目に該当する。

status: 有効/無効の指定。すぐに障害でイベントが発生して欲しくない場合に無効状態で作成する場合に使っている。
画面上は2択の割にパラメータ型はIntegerなので注意。指定内容は公式Docコピーだが以下のとおり。
0 - (default) enabled;
1 - disabled.
また、ややこしいことにstateという別パラメータがあるが、これはreadonlyで、設定したトリガーが使用可能or使用不可を表すパラメータでありtrigger.getで使用する。


実際に使用するパターンとしては、新規追加の監視項目にitem.getでitem.nameとitem._keyを一覧取得し
item.nameを置換してtrigger.description
item._keyを置換してtrigger.expressionにする場合が多い。

例えば、アイテム名: ポート監視[10080] であれば置換で ポート監視【異常】[10080] といった具合である。
アイテムキーについては net.tcp.port(10080) を前後にテンプレート名や条件式を付け加える。


trigger.createを使う上で留意したいのは、APIを使えば大量処理が可能になるとは言え
相応のパターン化ができなければ大した省力化にはならない点がある。これは監視設計の問題である。

Zabbixの設定として同システムやシステム内の類似機能を提供するホストをサブグループ化する等もあるが
それ以前の話として、システムのSLAに応じて各トリガー条件式に設定する閾値に統一性を持たせたり
ホスト横断的なものであれば、トリガー名に命名規則を使うことで、特定パターンの監視設定を抽出しやすくする等を
考慮する必要がある。

APIは整理のない監視データを整理する魔法の杖ではなく
あくまでパターン抽出とその置換処理が肝心である点は改めて記載をしておきたい。