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とされ、組合員が誰も存在していないばかりか、活動実態が全く見て取れません。

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

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

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

 

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

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

「2020年問題」の底辺からの観点

日経 IT技術者がいない みずほ不安の「2020年問題」

http://blogs.yahoo.co.jp/news_matome4946/15386435.html

 

書き出すと纏まらないのでダイジェストに。

 

・技術者は居るところには居るし、集まってます。優秀な人が優秀な人を呼ぶので人は偏在します。

   あそこはやばいってところは裏表多様に情報共有がされてみんなで避けてるだけです。

 

・技術の会社を名乗る技術のない会社は魅力がないです。

    アウトソーシングとかオフショアで技術力という屋台骨を外出しして、文字通り骨抜きになったという指摘は少なくとも4~5年前にはなされています。

 

・優秀な技術者を惹きつける魅力の一つは、別の優秀な人からリスペクトを受けることです。

   誰の褒め言葉でも良いわけではなく、優秀ではない人が褒めちぎるとむしろ別の意図がないかを探します。

 

・新卒を生え抜き人材とするスパルタ教育は多くの理由により成功率が低いことを察してください。そもそも人材育成に高い成功率はありません。

貴方の入社同期は今どこで何をしているか思い出すと、その理由に幾つか思い当たるはずです。

 

・人のメディアを使わず、自分のメディアを使って喋る方が受けは良いですよ。

 直接喋るって割と重要。時間かかるけど。

 

さて寝よう。

メモリのホットスワップはまだか

http://japanese.engadget.com/2014/04/15/sk-hynix-128gb-ddr4-dimm-2015-pc-1tb/

128GBのメモリとかどこに使うんだ。

仮想サーバホストを集約するか、RAM Diskくらいしかないと思う。

 

それよりも、できるならメモリのホットスワップ対応はよ。

 

とはいえメモリ異常時にどのアドレスが破損しててそれがどのモジュールにマッピングされてるかとかOS~BIOSレベルで拾えるのかはやや疑問。

できるなら、2GB☓4枚のモジュールで1枚分だけホットスワップにしておいて、可能なら破損時に破損箇所以外のメモリ情報を全部ホットスワップ化しているメモリに移動して切り離し、無理ならOSは一回再起動させてメモリ切り離しですかねえ。

 

昨今Disk回りはなんとかなることが多くなって来たので次点でメモリの対障害性向上があると色々助かります。

仕事がつまらんとか言ってる奴

この世の中に楽しい仕事なんてあるわけないだろ。

 

だたそこにあるのは「仕事」ってだけで

それをするのが楽しいと思う自分がいるか

そうは思わない自分がいるかの2つだけだ。

 

だから「仕事を楽しめる人」は居ても「楽しい仕事」が転がってることなんかないんだよ。

そんなものは就職・転職サイトの流言に過ぎない。存在しないんだから。

 

仕事を楽しいと言ってる人はクレイジーで、とりあえずあまり深く考えず目の前のことに全力を傾けたり、なんかそうでない人とは違う観点持ってやってたりする。だから楽しいんだ。

 

そうなれないのなら、仕事に対してどこまでなら我慢できるか自分の中で落とし所を付けて、それを保てるように仕事と遊びの量を調整しながらやっていく。

 

社会で生きるってそういうことだと思うぞ。

 

|-')とまあ春先なので駄文を投下しておこう。