2019-01-27

ドミニオンカードの収納方法

ドミニオンを買い揃えていくとどうしてもカードの収納が課題になる

色々試したものの、ようやく省スペースで整理しやすい形が決まったのでまとめておく。

使うもの

カードスリーブ（2019/1月現在売り切れ中、再入荷はあるのかな･･･？)

arclight.sakura.ne.jp

ダイソージョイントラックCHRシリーズ

バスケット(後述)を並べておく用。キャビネットなどでも良い。
(画像なし)

ダイソー引き出し整理バスケットスリム

カード束の収納用。樹脂系ケースコーナーに置いてある。
青いラベルのワイド版があるので間違いに注意。

f:id:rook5963:20190127212214j:plain

ダイソーソフトゴムテープ(4コールともう1段太いの)

カードを束ねるゴムにする。裁縫コーナーに置いてある。

f:id:rook5963:20190127212222j:plain

ボンドウルトラ多用途SU

これはダイソーではなくホームセンター等に置いてある。

f:id:rook5963:20190127212235j:plain

ラベルシール

整理バスケットに貼ってどのシリーズのバスケットかわかるようにする。

収納はシリーズごとで1つバスケットを用意する。
枚数の少ない錬金術と収穫祭は1バスケットにしているが、それ以外は1バスケットに収める。

まずソフトゴムテープをハサミで切る。
切る長さは「アクションカード10枚束の前周の9割」の長さ(12cm)にする。

枚数の違うカード(銅貨とか)は適宜カード束前周の9割に整える。

その後、切ったゴムの両端5mが重なるようにボンドウルトラ多用途SUでくっつける。
乾燥時間は最低2時間、24時間置くと完全に固まる。
この接着剤は空気中の水蒸気と反応して凝固するため、空気が乾燥する冬は加湿しながらやると固まりやすい。
細かいコツとして「接着剤を塗りこまない」のと「厚く少し盛り上がるように塗ってくっつけること」

f:id:rook5963:20190127212241j:plain

これを大量に作り、王国カードをどんどん束ねて、どんどん整理バスケットに収めていき
組み立てたジョイントラックに整理バスケットを並べればいい感じにカード類を収められる。

ゴムはかなり緩い感じになるが、きつくするとカードが変形してしまうため
あえて緩くしている。

f:id:rook5963:20190127212152j:plain

f:id:rook5963:20190127212142j:plain

---------
収納について検討したことも載せておく。

まずカードの収納は割と早い段階で「ゴムで束ねる」ことを考えた。
ただ樹脂ゴムは劣化するとスリーブにくっついてしまうため、ソフトゴムテープを使うことに決めた。

また、長めに仕立てることで一まとめにカードを扱える最低限の収縮にしてカードの変形を防ぐようにしている。

しかし、このゴムを輪にするために接着する方法は割と色々試した。
このゴムの布部分の接着は一般的な瞬間接着剤を使うと、布に吸われ布の中で固まってしまう。

ボンドウルトラ多用途SUは布に吸われづらく、布の接着にも対応しているため、ここに行き着いた。
ただ塗りこんでしまうとやはり布が接着剤を吸ってしまうため、布の表面に乗せる感じで塗るようにした。

カードの収納はドミニオンカードのサイズに合わせて整理バスケットスリムになった。
色々ホームセンターで収納できそうな箱を探したが、ちょうど収まるのはこれになった。
整理バスケットワイドでも収納できるが、カードが横向きに収める形になり、カードを取り出す時に
カード名が見づらいためスリムの方で縦に収められるようにした。

2018-05-04

Windows10 Sモード解除方法

あんまり明記されている記事がなかったので記憶頼りで記載。

Windows10 Sモード(S mode)について、外部のアプリインストールを不可にするモード。

何かソフトをインストールする場合はMicrosoft Storeから選んでインストールとなる。

ブラウザからセットアップをダウンロードしてインストールをしようとすると、ブラウザのステータスバーに「セキュリティチェックをしています」で止まってしまう。

このSモードは今後全エディションで有効になる、とのこと。

解除方法はMicrosoft Storeを起動し、「Switch」のキーワードで検出された一番上位に

「Windows Proへ変更」(キーワードうろ覚え)を選び切り替え処理を行う。

10分くらい処理をした後、Sモードが解除される。

今後出荷分のPCは通常Sモード有効状態となるらしいので、備忘録として記載。

画像等はまたサンプリングできそうであれば付けて本記事アップデートします。

2018-04-12

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

2018-01-20

ZabbixAPI item.update

本項ではアイテムの更新を行うAPIについて記載する。

http://kyou.hatenadiary.jp/entry/2017/12/25/233314
ZabbixAPIを使うメリットで記載した「登録済みトリガーの閾値を一定のルールで置換する場合」に使用する

大半のケースにおいてはZabbixGUI上の「一括更新」でカバーできるものの
テンプレートやホスト横断的に更新する場合に使用すると便利である。
またアイテム名やアイテムキーを対象にはできないため、その場合はitem.updateの出番となる。

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/item/object
https://www.zabbix.com/documentation/3.0/manual/api/reference/item/update

公式Docのアイテム作成JSONのサンプルは以下のとおり
{
"jsonrpc": "2.0",
"method": "item.update",
"params": {
"itemid": "10092",
"status": 0
},
"auth": "700ca65537074ec963db7efabda78259",
"id": 1
}

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

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

itemid: 必須項目。更新を行う対象のアイテムIDを指定する。更新したいアイテムIDはitem.get等で事前に把握しておく必要がある。
status: アイテムの有効/無効の状態。ここではサンプルとして指定のアイテムを有効にしている。

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

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

アイテムの内容を一斉に更新可能であるものの、ZabbixGUI側でも指定アイテムにチェックを入れて纏めて有効/無効であったり、「一括更新」機能で相当の状況はカバーできるため、出番が多いわけではない。

しかし、item.getで特定条件のアイテムIDを取得してきてテンプレートやホスト横断的に更新をかける場合や
GUI上でもチェックを入れるのがしんどくなる30個超の更新(私の場合･･･であるが)、またアイテム名やアイテムキーの一斉更新で
これを使えると大変便利になる。

itemidのみ指定し、後は更新したいフィールドだけをJSON内で記載する。公式サンプルの場合であれば
アイテムの状態を有効に切り替える以外に、他の内容は更新しない処理となる。

2018-01-12

ZabbixAPI item.get

本項ではアイテムの情報取得を行うAPIについて記載する。

http://kyou.hatenadiary.jp/entry/2017/12/25/233314
ZabbixAPIを使うメリットで記載した「登録済みトリガーの閾値を一定のルールで置換する場合」の前準備として使用する。

通常のホストやテンプレートごとのアイテム登録状況はZabbixGUI画面上は割と見やすいが
テンプレートやホスト横断的に取得する場合に取得する場合はZabbixAPIで取得した方が楽な場合が多い。
アイテム名やアプリケーション単位であれば良いが、特定アイテムキーを使ってる箇所などはZabbixGUI側が対応してないからである。

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

公式Docのアイテム作成JSONのサンプルは以下のとおり
{
"jsonrpc": "2.0",
"method": "item.get",
"params": {
"output": "extend",
"hostids": "10084",
"search": {
"key_": "system"
},
"sortfield": "name"
},
"auth": "038e1d7b1735c6a5436ee9eae095879e",
"id": 1
}

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

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

output: 出力形式を指定する。基本的にextendで良い。

hostids: このアイテムを追加するホストIDもしくはテンプレートIDを指定する。必須項目。Zabbixの内部管理上、ホストとテンプレートは区別されてなく、両者ともhostidという5桁の数字で管理されホストとテンプレート通じて一意である。また数値ではなく"数字"であるため、ダブルクォーテーションで括って文字列指定をする必要がある。よく忘れる。また特定のホストやテンプレートのIDを調べる場合、ZabbixGUI画面上のURLを調べると5桁数字が入っているのがそれである。
複数のホストやテンプレートを指定したい場合はここを配列にして渡せば良い。

search: 取得するアイテムの条件を指定する。item.get固有ではなく共通パラメータである。また、jq側のクエリで捌く方法もある。

sortfield: 出力するデータの出力順を制御する。jqで制御したり、jq処理後のbash側で処理しても良い。
個人的には最終的にcsvっぽくする場合が多いのでbashでsortすることが多い。

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

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

上記以外で個人的に割と使うパラメータは特にないが、むしろitem.getの出力結果をjqで処理するケースが多い。
また稀なケースとして、各テンプレートやホストごとのアイテム一覧を生成する際などは基本となるitem.get用のJSONを書いておき
host.getやtemplate.getで取得したhostidを次々置換しながら、各アイテムを一覧出力する場合もあった。

本項では以降item.getよりjqのクエリの書き方に焦点を移す。

item.get自体はhostidsを変えて使いまわし、以降はパイプ渡しするjqで処理を任せることが多い。
例えば
bash json2zabix.sh item.get.json | jq -c ".result|[.itemid,.name,.key_]"
という具合に、各行にアイテムID、アイテム名、アイテムキーを3つ並べた一覧を出力する。

ちなみに
bash json2zabix.sh item.get.json | jq -c ".result|[.itemid,.name,.key_]|@csv"
というようなjqの機能でcsvフォーマットなどで出力できるが、文字列のダブルクォーテーションをバックスラッシュエスケープで出力されて
個人的に見づらいためあまり使用はしていない。

jqクエリの分かりづらい箇所として .name という先頭にドットを付けて各フィールドの名前を指定する必要がある。
ドットをつけない場合はjqはそれをラベルとみなしてしまう。

また、.result はresultフィールド配列全体要素を指す。item.getで10個のアイテムを取得したらそれ全てを指定している。
そして .result| でパイプを加えると以降のクエリはresult配列内を指すようになる。
その後 [.itemid,.name,.key_] で3つを配列として出力する、というクエリになる。

jq に -c のオプションをつけているのは改行抑止で、アイテムID、アイテム名、アイテムキーを纏めて1行で出して欲しいからである。

またjqのクエリに先にラベルをつけておいて、後続作業でitem.updateの処理をしやすくするなどもあるが
個人的にはそれは後々にテキストエディタの置換処理でつけることが多い。
(あまりラベルをつけてjqの出力を出す習慣がないからであるが)

これらの結果を使って、今の監視設定の状態を把握したり、item.update用のJSONを起こしたりする。
item.updateについては別ページにて詳しく記載する。

2018-01-09

ZabbixAPI item.create

本項ではアイテムの作成を行うAPIについて記載する。

http://kyou.hatenadiary.jp/entry/2017/12/25/233314
ZabbixAPIを使うメリットで記載した「新規監視登録」を大量に行う場合に使用する。

とはいえそもそもどんな監視を行うか？が明らかである必要がある。
監視対象のシステムやサーバの重要度やシステムのSLAに依存するため、適切な運用設計が行われているのが前提である。

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

公式Docのアイテム作成JSONのサンプルは以下のとおり
{
   "jsonrpc": "2.0",
   "method": "item.create",
   "params": {
     "name": "Free disk space on $1",
     "key_": "vfs.fs.size[/home/joe/,free]",
     "hostid": "30074",
     "type": 0,
     "value_type": 3,
     "interfaceid": "30084",
     "applications": [
       "609",
       "610"
     ],
     "delay": 30
   },
   "auth": "038e1d7b1735c6a5436ee9eae095879e",
   "id": 1
}

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

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

name: アイテム名を指定する。必須項目。""で括り文字列で指定する。日本語OK。また、GUIで使用するマクロ(組み込み・ユーザ)使用可能。

key_: アイテムキーを指定する。必須項目。key_の末尾アンダースコアをよく忘れる。誤字っぽいが正式なパラメータ名である。アイテムキー内にダブルクォーテーションを入れる場合はバックスラッシュでエスケープしておく。

hostid: このアイテムを追加するホストIDもしくはテンプレートIDを指定する。必須項目。Zabbixの内部管理上、ホストとテンプレートは区別されてなく、両者ともhostidという5桁の数字で管理されホストとテンプレート通じて一意である。また数値ではなく"数字"であるため、ダブルクォーテーションで括って文字列指定をする必要がある。よく忘れる。また特定のホストやテンプレートのIDを調べる場合、ZabbixGUI画面上のURLを調べると5桁数字が入っているのがそれである。
また、1アイテムごとに指定できるため複数のホストやテンプレートに対して処理可能である。

type: アイテムタイプを指定する。公式Docのコピーだが以下のとおり
0 - Zabbix agent
1 - SNMPv1 agent
2 - Zabbix trapper
3 - simple check
4 - SNMPv2 agent
5 - Zabbix internal
6 - SNMPv3 agent
7 - Zabbix agent (active)
8 - Zabbix aggregate
9 - web item
10 - external check
11 - database monitor
12 - IPMI agent
13 - SSH agent
14 - TELNET agent
15 - calculated
16 - JMX agent
17 - SNMP trap

value_type: データ型のこと。必須項目。公式Docのコピーだが以下のとおり
0 - numeric float
1 - character
2 - log;
3 - numeric unsigned;
4 - text

interfaceid: ホストに対して指定する場合に必須。IPアドレスとポートのペアでinterfaceidが振られているためそれを指定する。host.getから引くことが可能だが、個人的にホスト指定のアイテムは作成しない運用をしているのでGUIでの調べ方は知らない。
(各ホストはなんらかのテンプレートをリンクする前提でZabbixを運用しているため)

applications: 各アイテムのアプリケーションを指定する。個人的にこのパラメータは使用せず、アイテム作成後にZabbixGUI画面の一括更新でアプリケーションを設定する。なのでApplicationIDは調べ方知りません。

delay: 更新間隔。必須項目。数値のためダブルクォーテーションで括ってはいけない。これもZabbixGUI画面の一括更新で変更可能なため、ZabbixAPIでは割と適当に指定して後から調整するケースが個人的には多い。

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

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

上記以外で個人的に割と使うパラメータは以下のとおり。

status: 有効/無効の指定。なんらかの変更に合わせたアイテム追加を事前にアイテムを無効状態で作成する場合に使っている。画面上は2択の割にパラメータ型はIntegerなので注意。指定内容は公式Docコピーだが以下のとおり。
0 - (default) enabled item
1 - disabled item
また、ややこしいことにstateという別パラメータがあるが、これはreadonlyで、設定したアイテムが使用可能or使用不可を表すパラメータでありitem.getで使用する。

history: ヒストリの保存期間を指定する。任意項目。ZabbixGUI画面の一括更新で変更可能なのでアイテム作成してから変更する場合もあるがたまに使う。
trends: トレンドの保存期間を指定する。任意項目。ZabbixGUI画面の一括更新で変更可能なのでアイテム作成してから変更する場合もあるがたまに使う。

さて、前置き長くなったがここからが本題である。上記のパラメータを理解したところで、これらを覚えて1文字ずつ打っていては何らメリットはない。
新規監視登録時には何らか一覧(Excel表)を作成し、こんな監視をして欲しいという構築担当の依頼があるとする。

共通部分ごとに細かくテンプレート分けをするのもひとつであるが、ZabbixAPIで使うJSONの生成であれば
「対象ホスト」「アイテム名」「アイテムキー」の3列の表を作る。その上でホスト同士の共通部分からテンプレート設計を起こしたら、
「テンプレート名」「アイテム名」「アイテムキー」の3列表にする。

あとはそれぞれ
hostid 「テンプレート名」 name 「アイテム名」 key_ 「アイテムキー」
と列挿入後、タブ区切りの状態でテキストエディタに移し、JSON用の波括弧{}やダブルクォーテーションを正規表現を使って挿入していく。
(Excelの状態だと記号類を解釈されたりするのでテキストエディタに移している)

置換やマクロなどを使い、以下のようなリストにする。(statusパラメータは必須ではないが個人的には入れてZabbixGUI上で有効にするパターンが多い)

{"name": "TestItema", "key": "system.run[/usr/local/bin/a.com]","hostid": "10106", "type" :0, "value_type": 3, "delay": 60, status": 1},
{"name": "TestItemb", "key_": "system.run[/usr/local/bin/b.com]","hostid": "10106", "type" :0, "value_type": 3, "delay": 60, "status": 1},
{"name": "TestItemc", "key_": "system.run[/usr/local/bin/c.com]","hostid": "10106", "type" :0, "value_type": 3, "delay": 60, "status": 1},

その後、1行目に以下を挿入し

{"jsonrpc": "2.0", "method": "item.create", "params": [

末行に以下を挿入する

],"auth": "##TOKEN##","id": 1}

そして下から2番目の末尾にあるコンマが余分になるため削って以下の形式することでJSON形式になる。

{"jsonrpc": "2.0", "method": "item.create", "params": [
{"name": "TestItema", "key": "system.run[/usr/local/bin/a.com]","hostid": "10106", "type" :0, "value_type": 3, "delay": 60, "status": 1},
{"name": "TestItemb", "key_": "system.run[/usr/local/bin/b.com]","hostid": "10106", "type" :0, "value_type": 3, "delay": 60, "status": 1},
{"name": "TestItemc", "key_": "system.run[/usr/local/bin/c.com]","hostid": "10106", "type" :0, "value_type": 3, "delay": 60, "status": 1}
],"auth": "##TOKEN##","id": 1}

ここでのポイントは
・1行目と末行を固定化し、他の部分は1アイテム1行に収まるようにする

・正規表現置換やテキスト置換、テキストエディタのマクロ等を使用し数行から数千行でも同等の操作で行うようにする。
(手作業でやっても良いが量に応じて作業時間が増えるため推奨しない)

・Excelだろうがエディタだろうがこだわりなく使えるものを使う
(もちろんawk&sedでも良いし、Pythonで書いて生成しても良い。自分が使いやすいものを使えば良い)

あとはこれを bash json2zabbix.sh xxxx.json として実行すればOK。
何らかエラーが出た場合は相応の対処が必要になるが、それば別途記載する。

また、エラー時の切り分けをする場合や、行が長すぎる場合などは
適当な行途中に

],"auth": "##TOKEN##","id": 1}

{"jsonrpc": "2.0", "method": "item.create", "params": [

の2行を追加し、この行のところで別ファイル化することでファイルを半分にしつつJSON形式を維持するのも容易なのが
このZabbixAPI用JSONの良いところである。

2018-01-07

ZabbixAPI共通項目

本項は以下ページを意訳したページとなる。
https://www.zabbix.com/documentation/3.0/manual/api/reference_commentary

JSONでは各項目に対して、name: value の形式で指定を行うが、ZabbixAPIで使用する各パラメータについて
少し詳細に記載をする。

item.get(指定アイテム取得)を例に取る。
https://www.zabbix.com/documentation/3.0/manual/api/reference/item/get
上記ページよりJSONを指定するが、ここで各パラメータ(params[]配列の子要素)に指定する内容である。

{
   "jsonrpc": "2.0",
"method": "item.get",
"params": {
    "output": "extend",
    "hostids": "10084",
    "search": {
      "key_": "system"
    },
    "sortfield": "name"
},
"auth": "038e1d7b1735c6a5436ee9eae095879e",
"id": 1
}

まず留意するのはJSONの書式である「数値」と「文字列」である。

上記例では "id" の値である1のみダブルクォーテーションで括られていない。これは数値で指定していることを示す。
また "hostids" では "10084" を渡しているが、これはダブルクォーテーションで括られているため、文字列を指定していることを示す。

このパラメータが数値指定か文字列指定かなどを表すパラメータタイプはそれぞれAPIで使うmethodによって決められている。
このパラメータタイプは、各APIページのParametesの表に記載してあるType列がそれに該当する。
例えば、item.getのhostidsは String/Arrayであるため文字列指定なのである。

そして各データタイプは以下のとおり

・bool
true または falseを指定する。
尚、アイテムやトリガーの有効/無効はWeb画面上はOn/Offスイッチのようになっているが、ZabbixAPI上はStatusパラメータでIntegerタイプである点に注意。

・flag
こちらもboolのようであるが、nullなどの指定もある。(あまり使ったことないので詳細分かりません)

・integer
整数タイプ。ダブルクォーテーションで括らないようにする点に注意。

・float
浮動小数タイプ。ダブルクォーテーションで括らないようにすれば良いと思うが、使った記憶がないため詳細不明。

・string
文字列タイプ。ダブルクォーテーションで括る。hostidなど数字で構成された文字列に注意。

・text
文字列タイプ。stringとほぼ一緒だが最大文字列長が長い？

・timestamp
UNIXTIMEでのタイプスタンプ。数値で指定する。

・array
配列。他の要素と組み合わせられる。例えばhostidsのString/Arrayであれば文字列を配列で複数指定可能になる。
item.getでhostidsに複数のhostやtemplate(※)を指定すれば、それを一括で取得可能。
Arrayを使用する場合は、その要素を角括弧でJSONの配列形式にしておく必要がある。

・object
よくわかりません。

・query
クエリー式。一部ZabbixAPIではQueryタイプで受け付ける値が指定されているものがあるが、原則は以下の2つ。

extend
指定された内容を詳細展開する。例えばoutputパラメータにextendを指定すると実際のitemidやname、key_を展開して表示する。
またtrigger.getのselectItemsの場合であれば、無指定の場合トリガー条件式のアイテムキー部分がitemidで表示されるが
ここにextendを指定しておくと、item.key_の内容を展開して出力してくれる。

count
指定された内容をカウントした数値を返す。

以下は補足になるが
また、reference_commentaryページの下半分にはCommon "get" methd parametersというGET系のZabbixAPI共通指定可能パラメータがある。
https://www.zabbix.com/documentation/3.0/manual/api/reference_commentary

ここにあるsearchやsearchWildcardsEnabledについてはZabbixAPI使用対象の持っているデータ量に注意して使用することを勧める。
これは内部的にMariaDB(mysql)に対してそのままSQLのSelectクエリとなるが、当然データ量の多い箇所に大量の結果が出るような指定をすれば
DBへの負荷となるからである。
アイテムやトリガーなどはDBキャッシュに乗っている可能性も高いが、ヒストリなどを対象にする場合は適宜limitで5000などある程度の件数に
絞って実行する方が安全である。