ZabbixのAPIを使って運用を楽しくする話

ZabbixのAPIを使って
運用を楽しくする話
Masahito Zembutsu @zembutsu
Technology Evangelist , Creationline, Inc.
Apr 12, 2014 , Tokyo, ZABBIX-JP 6th Meetup #zabbix_jp
Serf the Liberator – 始まりの物語
×

今日の概要
 1. ZABBIX API 超入門
➡ シェルで始める ZABBIX API ( 言語知識不要 )
• 今日、今すぐ始めましょう♪
まずは ZABBIX API を、このスライドが終わるこ
とには「すぐ使える！」事を目指しましょう。
API というと難しい印象がありますが、ZABBIX
の API は、シェルスクリプトでコマンドを実行
するだけで、簡単に使えます。プログラムの専
門的な知識が無くても大丈夫です（＾ω＾）

今日の概要
 2. Serf と Zabbix の連携
➡ Serf とは？
➡ API を使えば、こんな事が簡単にできるよ！
• ZABBIX × Serf 連携による自動監視オペレーション
そして、個人的に最近注目しているツール ‘Serf’
と ZABBIX を連携する話。API を使います。
Serf の基本的（真面目な話）と、ここはデモも。

今日の概要
➡ Serf とは？
 3. 仕事は楽しいかね？
➡ Serf the Liberator 【叛逆の物語】
最後は、 API を使った自動化に至った個人的な
動機や、考えている事（兵站）を整理しました。
ちょっとポエムと言いますか、チラ裏的な…。
叛逆の物語…あっ（察し

今日の概要
➡ Serf とは？
 3. 仕事は楽しいかね？
➡ Serf the Liberator 【叛逆の物語】
テーマは「APIを使って仕事を楽しく！」です。

今日は仕事を「楽しく」する話。
「楽」という漢字の語源は、木の棒
の上に糸を張った事のような楽器。
私は、まるで炎上プロジェクトの
PM 的な印象を受けましたががが

“良い仕事とは、堅実な作業の積み重ねだ。”
GUNSLINGER GIRL
APIというと、難しい印象がありま
すが、そんな事はないと思います。
API が行うのは、様々な作業。ふと、
こんな言葉をおもい出します。

ZABBIX API 超入門
1/3Let us start ZABBIX API
■■■
ちょうにゅうもん

API
 API = Application Programming Interface
➡ ソフトウェアが相互にデータをやりとりする
インターフェースの仕様
• 関数
• プロシージャー
• 変数
• データ構造
 ZABBIX API は Web API である
➡ HTTP を使って ZABBIX サーバに処理を要求
➡ JSON 形式でデータをやりとり
• JSON-RPC
 参考：Getting started with Zabbix API
http://blog.zabbix.com/getting-started-with-
zabbix-api/1381/
ZABBIX の API について触れる前に、
そもそも API って何でしょうか？
という所を抑えましょう。
ちなみに API 系の記事は、ウェブ
上には @ike_dai さん、@sechiro
さん、@mikeda さん達による詳し
い解説があります。ありがとうご
ざいました。参考になりました。

RPC
 RPC = Remote Procedure Call
➡ “プログラムから別のアドレス空間（通常、共有ネットワーク上の別のコン
ピュータ上）にあるサブルーチンや手続きを実行する事を可能にする技術。
遠隔鉄続き呼び出しとも。その際に、遠隔相互作用の詳細を明示的にコー
ディングする必要が無い。つまり、プログラマはローカルなサブルーチン呼
び出しと基本的に同じコードをリモート呼び出しについても行う。”
 プロトコル
➡ 仕様上の基本機能
• 定義した手続きの呼び出しはユニークである
• リクエストメッセージに対応するレスポンスメッセージ提供
• サービスの呼び出しや、呼び出されに応答する認証
➡ ポイントは、
• リモート上のプログラムに対し、
実行する手続きと引数を要求（コール）する。
➡ 様々な仕様
• JSON-RPC 2.0は Zabbix が採用
 起源
RFC 707 (1976年発表)
RPC という概念そのものは、昔から
プログラム間のデータ通信で用いら
れました。一種の仕様ですね。

JSON-RPC
 JSON-RPC 2.0
➡ http://www.jsonrpc.org/specification
• JSON-RPC is a stateless, light-weight remote
procedure call (RPC) protocol.
(１つの通信において以前の状態を保持しない )
➡ リクエストオブジェクトの仕様
• ‘jsonrpc’ … JSON-RPC で“2.0” と明示の必要あり
• 'method‘ … 呼び出されるメソッド名
• 'param‘ … パラメータ（変数など）
• ‘id’ … 整数または NULL
➡ レスポンスオブジェクトの仕様
• ‘jsonrpc’ … JSON-RPC で“2.0” と明示の必要あり
• ‘result’ … 正常処理時は必須
• ‘error’ … 以上処理時は必須
• ‘id’ … 必須。ただしエラー時は NULL に
ZABBIX API を使って、リクエスト
の要求や、処理結果の受け取りは、
JSON-RPC 2.0 の仕様通りです。
この情報 ( JSON 形式 ) を、ZABBIX
サーバに対して HTTP でリクエスト
します。

ZABBIXのデータの流れ
Zabbix Server
実際の処理の流れを見てみましょう。

Zabbix Server
user.login
Zabbix Client
【 user.login】
https://www.zabbix.com/documentation/2.2/manual/api/reference/user/login
通信時には、まず「user.login」という名
前の「メソッド」を呼び出さなくてはいけ
ません。メソッドは「命令」のようなもの。
ログイン ID とパスワードは、通常の
ZABBIX の WebUI にログインするときのも
のを使用します。

Zabbix Server
Auth ID (sessionid)
Zabbix Client
よし、通れ！
認証トークン
IDとパスワードが一致して認証に成功す
ると、「認証トークン」が結果として表
示されます。次回以降は、このトークン
を元に処理をします
【 user.login】
https://www.zabbix.com/documentation/2.2/manual/api/reference/user/login

Zabbix Server
認証トークン
host.get
【 host.get 】
https://www.zabbix.com/documentation/2.2/manual/api/reference/host/get
先ほどの「トークン」を元に、ホスト情
報一覧を表示する「host.get」メソッド
を呼び出すことが出来ます。

Zabbix Server
認証トークン
ホスト情報色々
（こいつは認証済みか）、
わかった、おらよっ！
【 host.get 】
https://www.zabbix.com/documentation/2.2/manual/api/reference/host/get
正常に処理されれば、ホスト情報一覧が
JSON 形式のデータで表示されます。あと
は、プログラムでデータを加工します。

一連の流れをまとめると
Zabbix Server
user.login
Zabbix Client
Auth ID (sessionid)認証トークン
host.get
ホスト情報色々
この時のやりとりが、全て JSON-RPC 形
式で、HTTP を通して行われます。扱う
データ形式は、JSON 形式というもの。

user.loginを手動で試す… 前に
 そのまえに必要なもの
➡ Linux とかのコンソール
➡ cURL ( curl コマンド )
• http://curl.haxx.se/
• コマンドらいんで HTTP 通信出来る
yum install curl
➡ jq
• http://stedolan.github.io/jq/
• JSON の grep や sed/awk みたいもの
yum install jq
 Mac OS の Terminal や Windows の
sygwin でも大丈夫のはず…
cURL は、ZABBIX サーバにリクエストを
要求する時に用います。jq は、受け取っ
たデータの加工に用います。

user.login
 user.login とは
➡ API でログインし、認証用トークンを作成
➡ このトークンを使って、次に実際の処理を要求
 パラメータ
➡ user … Zabbix のユーザ名 ( 必須 )
➡ password … パスワード (必須 )
➡ userData … 詳細情報表示を表示するか
(true または false , オプション)
 戻り値
➡ result … 認証用トークン
{
"id": 1,
"params": {
"password": "zabbix",
"user": "admin"
},
"method": "user.login",
"jsonrpc": "2.0"
}
実際に送るデータは、こんな感じ

user.login
#!/bin/sh
json=‘{“jsonrpc”:“2.0”,“method”:"user.login","params":{"user":"admin“,
"password":"zabbix"},"id":1}'
curl -s -XGET -H "Content-Type:application/json-rpc“ ¥
-d $json http://127.0.0.1/zabbix/api_jsonrpc.php | jq -r '.result'
{
"id": 1,
"params": {
"password": "zabbix",
"user": "admin"
},
"method": "user.login",
"jsonrpc": "2.0"
}
では、実際にリクエストを送ってみます。
こんなスクリプトを用意するか、直接実行します。json=の行、 ‘{ … }’ 内は、実際には改行が入りません。

user.login
$ ./auth.sh
{"id":1,"result":"4ffc67c712229cd683ae50fc05ae28c5","jsonrpc": "2.0"}
実行して正常に認証が通ると、”result” として、認証用の
トークンが表示されます。結果を見やすくするためには…
※スクリプトは Github に置きました。こちらをご利用ください。
https://github.com/zembutsu/zabbix-api-tools/blob/master/auth.sh

user.login
$ ./auth.sh | jq ‘.’
{
"id": 1,
"result": "4ffc67c712229cd683ae50fc05ae28c5",
"jsonrpc": "2.0"
}
jq コマンドの出番です。
見やすいよう、改行を入れてくれます。

user.login
$ ./auth.sh | jq ‘.result’
4ffc67c712229cd683ae50fc05ae28c5
それだけでなく、結果を grep のように
フィルタすることも出来ます。”result”
の価だけを表示するときは ‘.result’ です。

host.get
curl -s -XGET ¥
-H "Content-Type:application/json-rpc" ¥
-d '{"auth":"cc2590561f7474cfb613c934a45a69c4","id":2,"params":{"output":"extend"},"method":"host.get","jsonrpc":"2.0"}' ¥
http://127.0.0.1/zabbix/api_jsonrpc.php
{
"jsonrpc": "2.0",
"method": "host.get",
"params": {
"output": "extend"
},
"id": 2,
"auth": "##TOKEN##"
}
では次に、ZABBIX に登録しているホス
ト情報の一覧取得です。メソッド
「host.get」を用います。’’params”は
パラメータを指定します。ここでは、
全ての情報を表示したいので
「”output”:”extend”；と指定します。
ちなみに、curl のオプションは
・’-X’ メソッド ‘GET’ の指定
・‘-H’ ヘッダ情報の追加
・’-d’ データ
最後に URL です。

host.get
curl -s -XGET ¥
http://127.0.0.1/zabbix/api_jsonrpc.php
{"jsonrpc":"2.0","result":[{"maintenances":[],"hostid":"10084","proxy_hostid":"0","host":"Zabbix
server","status":"0","disable_until":"0","error":"","available":"1","errors_from":"0","lastaccess":"0","ipmi_authtype":"-
1","ipmi_privilege":"2","ipmi_username":"","ipmi_password":"","ipmi_disable_until":"0","ipmi_available":"0","snmp_disable_u
ntil":"0","snmp_available":"0","maintenanceid":"0","maintenance_status":"0","maintenance_type":"0","maintenance_from":"0
","ipmi_errors_from":"0","snmp_errors_from":"0","ipmi_error":"","snmp_error":"","jmx_disable_until":"0","jmx_available":"0","
jmx_errors_from":"0","jmx_error":"","name":"Zabbix
server","flags":"0","templateid":"0"},{"maintenances":[],"hostid":"10195","proxy_hostid":"0","host":"Overview
Layer","status":"0","disable_until":"0","error":"","available":"0","errors_from":"0","lastaccess":"0","ipmi_authtype":"-
1","ipmi_privilege":"2","ipmi_username":"","ipmi_password":"","ipmi_disable_until":"0","ipmi_available":"0","snmp_disable_u
ntil":"0","snmp_available":"0","maintenanceid":"0","maintenance_status":"0","maintenance_type":"0","maintenance_from":"0
","ipmi_errors_from":"0","snmp_errors_from":"0","ipmi_error"
実行すると、こんな感じで大量のデータ
が出てくる訳ですが。。。

host.get
curl -s -XGET ¥
http://127.0.0.1/zabbix/api_jsonrpc.php | jq '.‘
{
"id": 2,
"result": [
{
"templateid": "0",
"ipmi_available": "0",
"ipmi_disable_until": "0",
"ipmi_password": "",
"ipmi_username": "",
"ipmi_privilege": "2",
"ipmi_authtype": "-1",
"lastaccess": "0",
"errors_from": "0",
"maintenances": [],
jq を通すと、こんなにも読みやすく

まとめ
 API をコマンドラインで試すには
➡ curl と jq を使いこなそう
 どんな API があるの？
➡ Zabbix にかかわること、ほぼ全て
• https://www.zabbix.com/documentation/2.2/manual/api
 あとは、試してみましょう♪♪
 Perl や Ruby や PHP など、プログラミン
グの知識や経験がなくても試せます。
その他にも、アイテムを追加したり、グラフの情
報を取得したり、色々な操作が可能です。詳しく
は公式ドキュメントをご覧下さい。

おまけ： ./json2zabbix.sh
#!/bin/bash
json_auth='{"jsonrpc":"2.0","method":"user.login","params":{"user":"admin","password":"zabbix"},"id":1}'
rpc_url='http://127.0.0.1/zabbix/api_jsonrpc.php'
ZABBIX_TOKEN=`curl -s -XGET -H "Content-Type:application/json-rpc" ¥
-d $json_auth $rpc_url | jq -r '.result'`
#echo "####### TOKEN = $ZABBIX_TOKEN"
if [ $1 ]; then
json=`cat $1 | jq '.' -c | sed -e s/##TOKEN##/$ZABBIX_TOKEN/ `
curl -s -XGET -H "Content-Type:application/json-rpc" ¥
-d $json $rpc_url
else
echo "JSON to ZABBIX Request"
echo "Usage: json2zabbix.sh <filename>"
fi
Github にスクリプトを置きました。引数として
JSON 形式のファイル（ただし認証トークンの箇
所は ##TOKEN## としておきます）を実行する
と、認証→リクエストを自動的に行います。
例：$ ./json2zabbix.sh host.get.json
https://github.com/zembutsu/zabbix-api-
tools/blob/master/json2zabbix.sh
https://github.com/zembutsu/zabbix-api-
tools/blob/master/host.get.json

げ
ぇ
っ
明
日
ま
で
50台
API が真価を発揮するのは、こんなシーンです。
サーバの追加や環境構築はまだしも、監視設定の
投入は、なかなか骨が折れそうに、心も折れそう

SerfとZABBIX連携
2/3Let us start ZABBIX API
■■■
れんけい

Serf と ZABBIX 連携
 動機
➡ ZABBIX 管理の自動化
 仕組み
➡ Serf のイベント ( ノード参加・離脱 ) と ZABBIX 連携
• 既定の role に従って、
ZABBIX のグループや監視対象を制御
➡ ZABBIX サーバには ZABBIX API ( JSON ) でリクエスト
➡ Serf のタグ機能でホスト情報 ( hostid ) を記憶
 特長
➡ ZABBIX ホスト管理の自動化（迅速かつフレキシブル）
 今後の展開
➡ Chef 等の構成管理ツールとの連携
➡ クラウド事業者が提供する API と連携した仕組み
1.join
Serf クラスタ
3. Monitoring
Serf のクラスタ参加・離脱のタイミングで、
ZABBIX サーバに API をリクエストします。

Serf とは
 Serf
➡ http://serfdom.io/
➡ “サービス検出とオーケストレーションツール”
• ゴシッププロトコル (SWIM) を拡張
• 分散型、高可用性、耐障害性
 開発状況
➡ オープンソースで公開・開発が進行中
• Vagrant ( Oracle 社製 Virtual Box 管理ツール ) の作者、Mitchel Hashimoto 氏らが開発
• 開発言語は go 言語：Linux, Mac OS X, Windows のバイナリが配布中
➡ リリース状況
• 2013年10月23日に version 0.1.0 が初リリース → 現在は v.0.5.0
 ライセンス
➡ Mozilla Public license, version 2.0 拙作ながら、解説こちら→
http://www.slideshare.net/zembutsu/serf-the-liberator-2nd

Serf の特長
 サービス検出とオーケストレーション
※参考 http://www.serfdom.io/intro/
メンバーシップ
• エージェント間で相互通信
• 高速・軽量
• 非中央集権型
• 情報が直ぐに伝わる
障害検知
• 標準で実装済み
• 障害情報は直ぐに全体に伝わる
カスタムイベント
• メンバーシップ管理
• イベントやクエリを一斉実行
（デプロイやプロセス再起動）
• フレキシブルかつ軽量
イベントとZABBIX API のリクエストを連携します。

適用例
 ウェブサーバとロードバランサ
➡ ウェブサーバの稼働状況に応じて、ロードバランサの適用・除外を行う
 Memcached や Redis クラスタ
➡ Serf のメンバーシップと、それぞれのクラスタを連携
 デプロイ時のトリガ
➡ Serf の ‘event’ システムを用いて、ノードがメッセージ受信時、ただちにデプロイ開始
 DNS レコードの更新
➡ ノードの参加・離脱のタイミングで即時にレコードを更新
 単純な監視
➡ ‘query’ を用いて、uptime を全ノードに対して同時実行し、結果を表示
 サービス検出のための基礎部分を構築
➡ 上記の例を実現するための仕組みを、Serf は内包している。
➡ いずれも中央集権型ではなく、マスターは不要。耐障害性を持っている。
※ http://www.serfdom.io/intro/use-cases.html

他ツールとの比較
 Zookeepr, doozerd, etcd
➡ Serf と同様のクライアント・サーバ型のアーキテクチャ
• これらは、（ツールとして使うには）比較的複雑な分散システム
➡ Serf が提供する機能は、メンバーシップ管理、障害検知、ユーザイベントのみ。
 Chef, Puppet 等々
➡ 構成管理ツールは、メンバシップ管理までは行う。
➡ ツールの目的は、タスクを処理することで、迅速な実行や障害検知意識されていない。
➡ Serf は、これらツールと並行利用出来る。
 Fabric
➡ Fabric は、デプロイ・システム管理ツール。
• Serf より優れている点がいくつか（例：コマンド実行エラー時に、何か処理を実行）
• 実行速度の遅さや、ノード検出に関する課題がある。
➡ Serf は、何かしら実行結果(output_が必要なときに連携する使い方
• Fabric が Serf ノードに対して問い合わせを行い、Serf は一斉に実行

Serf の基本的な使い方
 セットアップと実行
 エージェントの起動
$ cd /tmp
$ wget -O 0.5.0_linux_amd64.zip https://dl.bintray.com/mitchellh/serf/0.5.0_linux_amd64.zip
$ unzip 0.5.0_linux_amd64.zip
# mv ./serf /usr/local/bin
$ serf agent
動かすのは超簡単。
バイナリをダウンロードし
て実行するだけ。
シンプルなのが、Serf の魅
力の一つかなと思います。
※参考：Serf設定オプションまとめ
http://pocketstudio.jp/log3/2014/03/29/serf_configuration_quick_guide/

イベントハンドラ
 イベントで、任意のコマンドを実行
➡ メンバーシップに関連するイベント
• member-join
• member-failed
• member-leave
• member-reap
• member-update
➡ カスタムイベント・クエリ
• event
• query
 データは環境変数や標準入力から取得
➡ イベント名称は、${SERF_EVENT} ( bash )
※参考【Serf】イベントハンドラを整理してみる
http://pocketstudio.jp/log3/2014/04/01/serf_event_handlers/
このイベント処理が肝心です

ハンドサイン画像ジェネレーター
http://bzmm.jp/hs_gene/
こんなイメージ

Serf は、イベント発生をトリガとして
任意の処理（コマンドを実行する事）
ができます。

ノードが3台に増えたとしても、同時に
実行できるのが大きな特長です。

もっと増えても、同時に。

もっと増えても。。。

いってみよう！
やってみよう！
Let’s register!

デモ環境 ( VirtualBox )
manager
192.168.39.3
192.168.39.1(VIP/LVS)
API ( JSON-RPC )
node1
192.168.39.11
node2
192.168.39.12
node3
192.168.39.13
node4
192.168.39.14
node5
192.168.39.15
10.0.0.2
こんな感じの環境を用意しました。
当日は mysqld が oom-killer で止
まってしまいました、、失敗、、
申し訳ありません。。。

Workflow orchestration
serf manager
( cluster )
Zabbix Server
join to cluster
serf agent
event:
member-join
call: zabbix-add
role:web
name:web1
JSON Request
LVS Server
ipvsadm
–A –t <LVS> -s <NODE> -g
host.create
interfaces, group,
templates
JSON Return
event:
settag
hostid
user
HTTP/HTTPS
zbx-screen-add screen.get
hsize
screen-update
screen.update
graph-update graph.get
graphitem.get
graphids
graph-update
graph.update
graphid, gitems

見るんじゃない、感じるんだ！
Don’t think! Feel!

$ serf agent –iface=eth1 –discover=serf –log-level=debug ¥
–event-handler=user:settag=/opt/serf/changetag.pl –tag role=web
$ serf agent –iface=eth1 –discover=serf –log-level=debug ¥
--event-handler=/opt/serf-lvs/ADP.pl
serf manager
serf node
イベントが発生する度に、この Perl スクリプトを実行。
イベント毎に、ZABBIX Server に対する JSON リクエストや
LVS ( ipvsadm ) を制御します。このとき、処理対象の role
も判断材料に用います。
serf のタグで ‘web’ や ‘db’ など、サーバの役割を明示。
web であれば、HTTP の監視を行い、LVS に追加。
db であれば、MySQL の監視を行うように区別します。

serf agent を起動するだけで、自動的にホスト登録と監視を開始。ZABBIX 画面に一切ログインすること
なく設定を行えます（Serf と連携し、IP アドレスの情報を自動的に渡しています）。
HTTP
Template

同様に Serf を起動します。node2 では ‘web’、node3 は ‘db’ とすると、自動的に設定が開始され
ます。本当は、ここでクラウド系サービスと連携してインスタンスを立ち上げ、更に Chef 等の構
成管理ツールと連携すると面白いかも。
なお、障害等でのnode 停止時も、規定時間 ( 初期値24時間 ) ノード情報を持たせておき、その後
ノード削除させることもできます。
HTTP
Template
MySQL
Template

単純にホストを追加・削除するだけで無く、スク
リーンのグラフを自動登録させる事も出来ます。
XML 編集の呪縛から解放・・！

その他にも、グループ
分けしたアイテム毎
（Load Average や
CPU idle)に、１つのグ
ラフに動的に追加・削
除させる事も出来ます。
面倒な処理は、Serf と
連携したフレームワー
クが自動処理します。
※ちなみに、この機能
は Zabbix 2.4 で実装さ
れるべく開発がすすん
でいるようです。
ﾅﾝﾃ／ (^o^) ＼ｺｯﾀｲ
他にも、ZABBIX に関
わる様々な処理を（既
存のシステムや設定、
そして業務フローを変
えること無く）自動化
できます。
運用や監視が楽しくな
りそうな予感が！！！
これも ZABBIX が API
を持っているからこそ。

叛逆の物語
3/3Serf the Liberator
■■■

さて、【叛逆の物語】。何に対す
る叛逆か？人間の、システムに
対する叛逆を起こしましょう。
基本的に、私は仕事とは「楽し
く」あるべきと考えています。

ですが、残念ながら、現在の業務
フローなり運用は、既定のシステ
ムありきで ”人間がシステムに使
役されている”印象を強く受けます。

私と運用監視
 はじめは二次対応
➡ エスカレーション対応が中心
 ウェブアプリ・ソーシャルゲームの隆盛
➡ 要望
• 止めたくないサービス
• より迅速な対応が必要
➡ 新しいサービスの提供
• 公称90分で物理サーバ提供(事実上10分以内)
• 物理サーバの管理＋専用のUIで24時間対応
 このあたりの裏側は、過去の資料をあわ
せてご覧下さい。
 参考：
サーバ運用の現場でひたすら監視し続ける
エンジニアの手の内のすべて
http://www.slideshare.net/zembutsu/ss-
17453167

当時の問題
 物理サーバの提供（プロビジョニング）
➡ 問題無し
➡ ただし、監視や業務フローが追いつかない事が
（データセンタのサーバ設置と、運用は別部隊）
 とはいえ監視はスタート
➡ 自分たちが一次対応も行うために
• より細かな監視設定
• 利用者や通知レベルに応じた柔軟な通知設定
• オープンソース（挙動はコードを読めば分かる）
➡ でも、そろそろ限界かも
• 一度に大量のサーバが追加・削除
• ホスト情報の管理（wikiやExcel・・・）
 参考：
オープンソー文化とホスティングの未来
http://www.slideshare.net/zembutsu/op
en-source-culture-and-hosting-services-
future

げ
ぇ
っ
明
日
ま
で
50台

そこで、ZABBIXですが
 API を使った柔軟な監視が出来ないか？
➡ ZABBIX は JSON-RPC な API を持つ
➡ コンソールにログインしなくても制御
➡ ディスカバリー機能による省力化
 欠点
➡ ZABBIX のディスカバリー機能は便利だが、複雑
なネットワークでは利用出来ない（ZABBIXはホス
ト情報に紐付いた設定なので、同一セグメントに
役割の違うサーバを配置しても）
➡ お客さまのアプリケーションデプロイが追いつい
ていない。構成管理は Chef や Puppet, Ansible 等
があるが、
➡ このまま進むと、開発も運用も…
業務フローにすべて乗るかと言え
ば、そうではなくて、課題が様々。
API は便利でしたが、当時は
「Serf」のような複数サーバで簡
単に同時実行できるというツール
は無かったように思います。

ニンゲンヤメマスカ?
Do you resign as human being?
It is necessary to answer the following questions to start OPERATION.
YES はい
はい YES
運用を続けるためには、イカの質問に答える必要があります。

私はこれで、人間をやめました。
？？？
「こんなの絶対おかしいよ！」

Serf
それは世界を暴くシステム
Serf the Liberator

ここがSerfとEtcdを使いどころ
 非中央集権型の自動実行アーキテクチャ
➡ シンプル
➡ 耐障害性、SPOF の排除
• Etcd … Raftプロトコルによる高一貫性
• Serf … SWIM(Gossip)プロトコルによる伝播性
➡ オープンソース
• ポータビリティが高い（どこでも動く）
– 物理もクラウドも関係無い
• 導入コストは必要なし
➡ イベントハンドラが業務フローに乗りやすい
• 既存のフローに合わせて実装しやすい
• 拡張性が高い
➡ ZABBIX との連携
• Serf はイベント発行トリガ
• Etcd はデータストア
 この仕組みがオーケストレーション
 似たようなツール群は、ベンダが提供す
る高価なツールだったり（利用者との規
模感があわない）、オープンソースでも
Zookeeper 等や Jenkins 等を組みあわせ
れば出来ますが、どれも複雑。それら
ツールを使いこなすための学習コストが
かかりますし、ツールが出来ない事は
「運用に使えない」問題。
 クラウド API と連携することで、更に幅
も拡がる。
 このように使えるような監視サービスな
り運用システムがあっても良いのでは
今はこんな事を考えています。
運用の為のフレームワーク。

へいたん(仮) HEITAN = 兵站 ( logistics ) 的な運用支援フレームワーク
インフラと運用のあるべき姿を定義し、それをコードで維持運用する
けいおん風ジェネレータ
http://k-0n.com/

へいたん(仮) HEITAN = 兵站 ( logistics ) 的な運用支援フレームワーク
インフラと運用のあるべき姿を定義し、それをコードで維持運用する
けいおん風ジェネレータ
http://k-0n.com/
オープンソースで公開したいなぁ。
仕事でも使えないかなぁ（ﾁﾗｯ

へいたん（仮）とはクラウド
系の API や構成管理ツールと
連携した運用フレームワーク。
機能例：
ノードがダウンしたら「ある
べきノード数」に戻るような
作業を行う（インスタンス起
動→構成管理→監視開始→
サービス投入、一方古いイン
スタンスは破棄する）。
なお、この動作は、コードと
して定義されている。
まだ青写真レベルですが、
Serf と ZABBIX のお陰で現実
性が高まった気がします。

コンパネなんて飾りです。偉い人にはそれが(略
 加速する事業（ビジネス）
➡ 求められる”敏捷性”
➡ 求められる”効率性”
➡ 目的は、変化に対応するため
• スマートフォンとネットワークの普及により、
コンピューティングが、現実世界レイヤと繋がった。
• リアルタイムで進行する現実世界に対応するための
情報通信基盤に対するニーズが増えているのでは。
 インフラ基盤の環境構築・運用という課題
➡ 迅速に環境は整うようになった、次はどうする？
➡ より効率的に使うための方法は無いか？
• Infrastructure as a Code という考え方
• RESTful API の活用
 “Effectivity and Agility”
 開発・運用の現場では、人間の稼働時間
なり、人間が稼働することが、コストな
りサービス展開上のリスクになりはじめ
ていないでしょうか。
 敏感にattention気づいてよ
（監視システムかな？）
敏感に solution じわじわきてる
（障害対応かな？）
 REST = Representational State Transfer
 API = Application Programming Interface

コンパネなんて飾りです。偉い人にはそれが(略
 加速する事業（ビジネス）
➡ 求められる”敏捷性”
➡ 求められる”効率性”
➡ 目的は、変化に対応するため
• スマートフォンとネットワークの普及により、
コンピューティングが、現実世界レイヤと繋がった。
• リアルタイムで進行する現実世界に対応するための
情報通信基盤に対するニーズが増えているのでは。
 インフラ基盤の環境構築・運用という課題
➡ 迅速に環境は整うようになった、次はどうする？
➡ より効率的に使うための方法は無いか？
• Infrastructure as a Code という考え方
• RESTful API の活用
 “Effectivity and Agility”
 開発・運用の現場では、人間の稼働時間
なり、人間が稼働することが、コストな
りサービス展開上のリスクになりはじめ
ていないでしょうか。
 REST = Representational State Transfer
 API = Application Programming Interface

いまここにある未来
 運用をもっと楽しく
➡ 運用コストとは
• 省力化や自動化の文脈で語られるのは
運用担当者の削減。しかし、これは正しいのか？
• 結果としてコスト削減が品質低下では
– 蓄積されないノウハウ
– 俗人化され続けるシステム
➡ 「人間が楽しく働く仕組み」という視点
• 本来の生産性向上とは
– 工業や農業においては、手工業からの脱却が機械化
– 人間は業務フローや品質改善に注力
• 情報通信作業においても
– 「システムに使役される人間」からの脱却
– 「システムを使役する人間」に
 結論：いますぐ ZABBIX API を始めましょう
 本来は、ここを効率化すること、つまり
オーケストレーションを導入して自動化
ないし省力化することが、製品やサービ
スの品質の向上につながり、結果として
売り上げ増加に結びつくのでは。
 「運用のコード化」という概念の必要性。
 本当に欲しかったもの
複雑な運用手順書や体制ではなくて、
「コードで運用を調律する」システム。
見かけ上のツールではなく、本質を暴く
のがSerf。担当者の属人性もなくなるし、
障害発生時や運用のシミュレーションが
しやすくなる。そろそろ、運用も次のレ
イヤに進まなくてはいけないのかも。私
はコレをビビビッとオペレーションと呼
んでいます。ーー今日よりも鮮やかに。

http://www.flickr.com/photos/mikebaird/4177569971/ by Ewan Bellamy
乗るしかない、
このビッグウェーブに！

参考資料
 ZABBIX API に関する一次情報
➡ Getting started with Zabbix API | Zabbix Weblog
• http://blog.zabbix.com/getting-started-with-zabbix-api/1381/
➡ ドキュメント
• https://www.zabbix.com/documentation/2.2/manual/api
 日本語の ZABBIX API 情報
➡ 第4回 Zabbix APIを使った外部ツールとの連携 | Think IT ← @ike_dai さんの記事
• http://thinkit.co.jp/story/2012/05/11/3541
➡ Perl から Zabbix API を叩いてみる。 - 双六工場日誌 ← @sechiro さんの記事
• http://sechiro.hatenablog.com/entry/20101218/1292639424
➡ ZabbixAPI触ってみた - mikedaの日記 ← @mikeda さんの記事
• http://mikeda.hatenablog.com/entry/20110501/1304228313
➡ Zabbix API を始める人向けの情報をまとめてみた ← @halchiyo さんの記事
• http://log4hc.wordpress.com/2012/08/10/zabbix_api_summary/

おしまい。ありがとうございました。
 よい子の皆も API を試してみよう！お兄さんとの約束さ！
@zembutsu
みんな～
API ためさなイカ

ZabbixのAPIを使って運用を楽しくする話

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à ZabbixのAPIを使って運用を楽しくする話

Similaire à ZabbixのAPIを使って運用を楽しくする話 (20)

Plus de Masahito Zembutsu

Plus de Masahito Zembutsu (20)

Dernier

Dernier (9)

ZabbixのAPIを使って運用を楽しくする話