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 は、シェルスクリプトでコマンドを実行するだけで、簡単に使えます。プログラムの専門的な知識が無くても大丈夫です（＾ω＾）

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

今日の概要  1. ZABBIX API 超入門 ➡ シェルで始める ZABBIX API ( 言語知識不要 ) • 今日、今すぐ始めましょう♪  2. Serf と Zabbix の連携 ➡ Serf とは？ ➡ API を使えば、こんな事が簡単にできるよ！ • ZABBIX × Serf 連携による自動監視オペレーション  3. 仕事は楽しいかね？ ➡ Serf the Liberator 【叛逆の物語】最後は、 API を使った自動化に至った個人的な動機や、考えている事（兵站）を整理しました。ちょっとポエムと言いますか、チラ裏的な…。叛逆の物語…あっ（察し

今日の概要  1. ZABBIX API 超入門 ➡ シェルで始める ZABBIX API ( 言語知識不要 ) • 今日、今すぐ始めましょう♪  2. Serf と Zabbix の連携 ➡ Serf とは？ ➡ API を使えば、こんな事が簡単にできるよ！ • ZABBIX × 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のデータの流れ 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のデータの流れ Zabbix Server Auth ID (sessionid) Zabbix Client よし、通れ！認証トークン IDとパスワードが一致して認証に成功すると、「認証トークン」が結果として表示されます。次回以降は、このトークンを元に処理をします【 user.login】 https://www.zabbix.com/documentation/2.2/manual/api/reference/user/login

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

ZABBIXのデータの流れ 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 ¥ -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","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 ¥ -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 | 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/ こんなイメージ

ハンドサイン画像ジェネレーター http://bzmm.jp/hs_gene/ Serf は、イベント発生をトリガとして任意の処理（コマンドを実行する事）ができます。

ハンドサイン画像ジェネレーター http://bzmm.jp/hs_gene/ ノードが3台に増えたとしても、同時に実行できるのが大きな特長です。

ハンドサイン画像ジェネレーター http://bzmm.jp/hs_gene/ もっと増えても、同時に。

ハンドサイン画像ジェネレーター http://bzmm.jp/hs_gene/ もっと増えても。。。

いってみよう！やってみよう！ 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

つまりですね、 well…

いまここにある未来  運用をもっと楽しく ➡ 運用コストとは • 省力化や自動化の文脈で語られるのは運用担当者の削減。しかし、これは正しいのか？ • 結果としてコスト削減が品質低下では – 蓄積されないノウハウ – 俗人化され続けるシステム ➡ 「人間が楽しく働く仕組み」という視点 • 本来の生産性向上とは – 工業や農業においては、手工業からの脱却が機械化 – 人間は業務フローや品質改善に注力 • 情報通信作業においても – 「システムに使役される人間」からの脱却 – 「システムを使役する人間」に  結論：いますぐ 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を使って運用を楽しくする話

by Masahito Zembutsu, Technology Evangelist at Creationline, Inc. on Apr 13, 2014

Statistics

Views

Actions

1 Embed 13

Accessibility

Categories

Upload Details

Usage Rights

Report content

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