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形式を作成して実行する方式とする。


また、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/get

公式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については別ページにて詳しく記載する。

 

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形式を作成して実行する方式とする。


また、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/create

公式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の良いところである。

 

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などある程度の件数に
絞って実行する方が安全である。

 

ZabbixAPIを使う作業環境

ZabbixAPIを使う際のZabbixServerのバージョン等は公式を参照するとし

本項では、ZabbixAPIにPOST/GETする際のJSONの処理環境について記載する。

 

REST APIを使え、JSONを処理できればそれでOKなのですが、この辺りは記載が曖昧なことが多いため私の使用環境を記載する。

 

基本はLinuxOS上より以下2つのツールを使用する

・json2zabbix.sh

github.com

上記ツールは以下のような概要仕様となっている。

・認証トークンを取得し、引数で指定したJSONに固定文字を認証コードに置き換えてZabbixAPIを発行する

最初に認証を使用するUserIdとPasswordを編集すれば、あとはJSONファイルを渡すだけでOKなため便利に使わせて頂いている。

しかし認証関係以外で2箇所変更して使用している。

・$json -> "$json"に修正し、アイテム名などにスペースがある場合にも正常に動くようにする。

curlの末尾に | jq "."  を 追加し、ZabixAPI応答のJSONを整形出力する(jqについては後述)

 

・jq

https://stedolan.github.io/jq/

シェルで使用できるJSONパーサ。やや書式に癖はあるものの、awksedくらいに使いこなせば非常にJSON処理が便利になるツール。

主に*.createなど、作成したJSONをZabbixAPIに送る前に書式チェックを行うために使用したり、*.getなどで取った値を任意にパースする場合に使用する。

詳細は公式Doc参照。

 

そして、item.get等はZabbixの公式DocのAPIページのものを使用すればとりあえず取れるものの

item.createなどはなんらかの一覧を変換しながらJSONをおこすようにしている。

 

JSONは改行や文字列外のスペースは無視して処理されるため、json2zabbix.shでの処理を前提に以下のような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},

{"name": "TestItemd", "key_": "system.run[/usr/local/bin/d.com]","hostid": "10106", "type" :0, "value_type": 3, "delay": 60, "status": 1},

{"name": "TestItemay", "key_": "system.run[/usr/local/bin/ay.com]","hostid": "10106", "type" :0, "value_type": 3, "delay": 60, "status": 1},

{"name": "TestItemaz", "key_": "system.run[/usr/local/bin/az.com]","hostid": "10106", "type" :0, "value_type": 3, "delay": 60, "status": 1}

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

まず冒頭行をZabbixAPIで固定的に使用するものを記載し、paramsを配列で開いておく。

末尾行では配列を閉じ、authにjson2zabbix.shで認証トークン置換用の##TOKEN##を記載した行を書いておく。

 

中間の行については、CSVExcel等のリストを作成しておき、サクラエディタで置換を駆使して各行を起こしている。

例えば、アイテム名, 実行ファイル名 という一覧を作成しておき、

・ /usr -> ", "key_": "system.run[/usr/ の置換

・各行頭に{"name": " を正規表現で追加。

・","hostid": "10106", "type" :0, "value_type": 3, "delay": 60, "status": 1}, を各行末に追加

という具合である。

そして、一番末尾のコンマをJSONの配列書式に合わせて手動削除し、

上記したJSONの行頭と行末を手動でペーストしてZabbixAPI用のJSONファイルとしている。

 

もちろんitem.create以外でもtrigger.create等でも同様の方式で作成している。

(詳細は別項とし、本項ではjson2zabbix.shとjq、それらに合わせたJSONの記載形式を主眼に記載している。)

 

あとは作成したファイルを

bash json2zabbix.sh xxxx.json

とすることでZabbixAPIを使用してZabbixアイテム作成等を行う。

 

ここのオペレーションの肝は「置換を駆使する」ことで、行数が10行でも100行でも作業量の差が出ないことが重要である。

また、JSONの書式になれておくことと、必要に応じて正規表現が使えることが望ましい。

 

やや曖昧ではあるが、「大量の作業をAPIでさくっと処理する」の肝はこの大量行の置換処理に掛かっている点をご理解頂きたい。

 

 

ZabbixAPIを使うメリット

これは私が現状使っていて享受しているメリットを記載する。

 

ZabbixAPIはZabbixで行う大半の操作が可能、逆に言えばGUI済むのであれば敢えて扱いの難しいAPIを使う必要はない。

しかし、「大量の設定を追加・修正する」際に、ZabbixAPIが使える場合天と地ほど作業時間の差が出る。

 

例1) 新規追加のシステム(サーバ群)を新規監視登録する場合

「こんな監視をしてください」というリストが構築担当から提供される場合が多い。

CPU・メモリ等のリソース監視は概ねお任せにされるが、特定プロセスやサービス監視、ポート監視、ログ監視等は指定されるケースが多い。

この量が尋常でなく多い場合のGUI操作では、アイテム名とアイテムキーの一部を書き換えながら1つずつ複製していく操作になることが多い。

ところが「複製」→「追加」とせず、「更新」としてしまうと追加済みのアイテムが置き換わったりして、入力操作も手間であればその後の入力内容確認も手間である。

 

ZabbixAPIであれば渡されたリストから、「アイテム名」と「アイテムキー」をテキスト変換等で生成し、最終的にitem.createのAPIで使用可能なJSONに置換していく作業で完了となる。

テンプレートの作成が終わっていて、純粋に300個のポート監視アイテムのみを追加であれば、1~2時間もあれば設定可能である。(もっと定型化を進めれば30分切りも難しくないと思う)

 

ディスカバリを活用すれば不要かもしれないが、構築中サーバなどでは難しいかもしれない。

 

例2) 登録済みトリガーの閾値を一定のルールで置換する場合

アイテムのヒストリ保持期間変更等、「一括更新」で対応可能な内容であれば良いが

アイテム名やアイテムキー、トリガー名やトリガーキーなどはGUIでは1件ずつ書き換えることになる。

しかしZabbixAPIを駆使すれば、現在登録されているポート監視の全件を抽出し、トリガー条件式を書き換えて全件更新することも可能である。

 

上記のような作業で、Zabbixへの操作に関わる部分は、ZabbixAPIを使えるようになってから、ほぼ私一人で可能な状態となった。

 

 

作業時間を見積もる際、1アイテム登録1分、1トリガー登録1分で積算してもかなりタイトになりがちであるが、ZabbixAPIを使用すると同種の登録や変更であれば、その数に因らず作業時間は延びなくなる。

4000~5000アイテムと同数のトリガーの設定時に、ZabbixAPI使いはじめ当時は手探りもあり、15人日を要していたが、使い慣れた現状であれば5人日で実施可能でだろう。

ZabbixAPIの記事事始め

3年ぶりレベルでブログを書く。

本稿ではなんで記事を書き始めるかを書く。

 

Zabbixって割と使われてます。システム監視ソフトとしてはそんなにお金掛からずでも優秀なソフトなのでとりあえず使ってるところは少なくない。

 

で、ちゃんとした使い方だとZabbixスペシャリストだのプロフェッショナルの資格を取りに行けば良いのですが、それとは別にAPIという方法がZabbixにはあるものの、この情報が(少なくとも日本語圏には)少ないので、何か書いて残していこうかなと思ったのが本稿の目的です。


いやQiitaとかSlideShareとかで記事はあるんですよ。

それが読みづらいとかじゃなく「足りない」のです。

導入部の触りとしては全然良いのですけど、使いこなしとか細かいTipsレベルに落とし込もうとすると粗い情報なので足りないのですね。

 

なのでその辺の情報を落としこむ記事をしばらく書いて行こうかなと。

 

いやだって「アイテムキー」のAPIフィールド名が「key_」でアンダースコアが付くとかさ、

「トリガー名」のAPIフィールド名が「description」で「説明」が「comment」なんですよ?

初見殺しにも程があるってもんです。和訳の問題かもしれないけど。

 

その辺のTips含めて細かく書いていけたらいいなあ、ということでしばらく不定期に書きたいと思ったりします。

すき家の5/29ストが茶番だった件

ストライキした側

http://www.bengo4.com/topics/1583/

ストを決行したのは「グループ会社の工場のアルバイト」

このアピールをおこなった「ちば合同労働組合」に聞いたところ、「ストライキは、すき家の店舗ではなく、グループ会社の工場で働くアルバイト従業員が、一人で決行した」という答えが返ってきた。

 

ストライキを止めた側

http://buzzap.jp/news/20140529-zensho-union/

組合予算のページの2011年度組合活動に関する事業会計収支計算書(編集部注:掲載されている組合予算の最新版に当たります)では「会費・入会金収入」が0となっている他、予定予算の全ての収入・支出が0とされ、組合員が誰も存在していないばかりか、活動実態が全く見て取れません。

 一応労働組合はこのゼンショーユニオンとは別にゼアンというものがあるらしい。

ただまあ対象が正社員のみで、店長以下は非正社員なので

パート・アルバイト専用労働組合として割れてるんだろうと思ってます。

 

しかし、ちば合同労働組合にしろゼンショーユニオンにしろ

みんな徒党組んで数で勝負せず、青い鳥を検索してるんだろうなあってのが透けて見えた現代的な話に見えました、まる。