障害対応・運用におけるトリアージ的対応とZabbixの活用 Zabbix Conference Japan 2015 発表資料 http://www.zabbix.com/jp/conference_japan_2015.php 日時：2015年11月20日(金) 会場：パレスサイトビル マイナビルーム #zabconfjp2015

1. 障害対応・運用における
トリアージ的対応と
Zabbixの活用
～なぜZabbixを採用したのか？
その核心と拡張
Technology Evangelist
前佛 雅人 a.k.a @zembutsu
Zabbix Conference Japan 2015
#zabconfjp2015

2. 2
本日の内容
‣ Zabbixを導入した理由
• トリアージ的な運用フローをZabbixで統一
• メンテナンス・フリーを実現するZabbixの諸機能
運用業務の標準化
‣ サービス・ディスカバリと API 連携
• IoT や Docker 時代にも対応する API 基盤
進化に適応するZabbix
2015年11月20日(金)に東京で開催の、
Zabbix Conference Japan 2015
(#ZabConfJp2015) のスライド資料を、
公開用に整形したものが、こちらです。
今年も登壇の機会をいただきました。
大変ありがとうございました。
今回は「なぜ私がZabbixを使うようになっ
たか？」という、根本的な考えについて
皆様と共有できればと思っています。

3. 指揮本部用(災害現場用)
No. 氏 名(Name) 年齢(Age) 性別(Sex)
男 (M)
女 (F)
住 所(Address) 電話(Phone)
トリアージ実施者氏名トリアージ実施日時・時刻
月 日 時 分
AM
PM
搬 送 機 関 名 収容医療機関名
トリアージ実施場所 救 出 場 所
トリアージ実施機関 医 師
救急救命士
そ の 他
死 亡 重 篤
重 傷 中程度
軽 傷
傷 病 名
トリアージ区分
O Ⅰ Ⅱ Ⅲ
トリアージ・タッグ
O
Ⅰ
Ⅱ
Ⅲ
特記事項(搬送・治療上特に留意すべき事項)
トリアージ・タッグ
O
Ⅰ
Ⅱ
Ⅲ
そ の 他 の 応 急 措 置 の 状 況 等
前 後
O
Ⅰ
Ⅱ
Ⅲ
O
Ⅰ
Ⅱ
O
Ⅰ
ぜんぶつ 「クラウド婚活中だ！」
などと意味不明な発言
前半はトリアージの考え方と、運用に活用
したらZabbixが私の場合に最適だった話。

4. 4
自己紹介
‣ @zembutsu a.k.a. 前佛雅人
- Technology Evangelist; Creationline, Inc. – 2 yrs
- Data Center Operations Engineer – 15+ yrs
興味関心：運用監視自動化、趣味でOSSやクラウド系の検証・情報発信
- SlideShare http://slideshare.net/zembutsu
- Blog http://pocketstudio.jp/log3
書籍・記事
- Serf/Consulで管理を自動化！ (Gihyo.jp)
http://gihyo.jp/admin/feature/01/serf-consul
- HashiCorpのツール群からみる
インフラ構築運用の未来 (Think IT)
http://thinkit.co.jp/book/2015/03/05/5700
Why am I here?
+MasahitoZembutsu
ASIN: B015WS2EDA ISBN-10: 4844339265 ISBN-10: 4774174416
最近はDocker等々を触っていますが、
元々はデータセンタでのサーバ運用なり
ホスティングのサポートも携わってました。

5. なぜZabbixだったのか？
1 Why I choose Zabbix?

6. 6
‣ 業務内容
• データセンタ（ホスティングサービス）におけるサーバ運用保守
‣ 時代の変化
• 90年代 PCを使ってインターネットの利用
– 限定的な利用
– テレホーダイ
• 00年代 携帯電話を使ったウェブ系サービスの台頭
– データ転送量やアクセス集中の傾向が大きく変化
どうしてZabbixだったの？ 様々なツールやサービスがあるなかで、
どうしてZabbixを選んだのか？皆さん、
障害対応大好きですか！私も大好き！！
（たぶん）
その過程で、ある仮説モデルが役立つと
考え、そこにピッタリとハマッたからです。

7. 7
‣ 監視体制
• Nagios（サーバの死活監視）
• MRTG（ネットワーク流量の監視）
‣ 運用手法
• 属人的になりがちな運用
• 属人的なトラブルシュート
課題：運用対象が増えても、均一のサービス品質を保つには？
それまでの運用 ｉモードや EzWeb 等のケータイを通した
コンテンツの普及。テレホーダイのような
アクセスのピークは徐々に生活時間帯に
移動してきます。
監視対象のサーバや機器だけでなく、
お客さまの数も増えていきました。その
中で、サービス品質をいかに保つのか。
既存システムでは限界を感じていました。

8. そこで思いついたのが、これです。

9. 例えば…

10. サーバや機器
Servers, Routers, Appliances…
最近、サーバの
様子がちょっと
おかしいのだが
サーバであれば、何かおかしいときに、
ログインして、状況を確認します。

11. サーバや機器
Servers, Routers, Appliances…
最近、サーバの
様子がちょっと
おかしいのだが
Operator
・ログ確認
・コマンド実行
・各種調査
メモリ足りない
サーバであれば、何かおかしいときに、
ログインして、状況を確認します。

12. サーバや機器
Servers, Routers, Appliances…
人間
as we, Human
最近、サーバの
様子がちょっと
おかしいのだが
最近、頭が
痛いんです…
Doctor
・血液検査
・レントゲン
・触診
Operator
・ログ確認
・コマンド実行
・各種調査
メモリ足りない
貧血ですね
これって、考えてみると人でも同じです。

13. http://www.flickr.com/photos/changereality/9221281165 by Warner Vermaak

14. サーバや機器
Servers, Routers, Appliances…
人間
as we, Human
…
system halt
……。
（返事がない）
DoctorOperator
・Reboot
サーバ停止は心停止！原因特定よりも蘇生を！
これはいけないこれはいけない
致命的な状態なら、
すぐに対処が必要。
これは、サーバも
人間も同じです。

15. ……
しかし、要救護者が一人ならまだしも、

16. ………… ………… ……
事件や事故などで、たくさんの人の…

17. ………… ………… ………… ……… ……
対応が必要な場合は、どうしたら…？？

18. ………… ………… ………… ……… ……
答えはあります。「トリアージ」です。

19. 19
トリアージ(Triage)
‣ 救急救命時の手法
• 戦場や大規模災害に於いて、傷病者を迅速・簡易に判断・治療する
• トリアージは精度を高めるため、何度も繰り返す
目的は、出来るだけ多くの命を救うため
症状レベルに応じて患者の対応度「区分」し、治療する
‣ 語源
• フランス語の trier （より分け、分別する）の名詞形
• コーヒー豆の「選別」 … 品質が落ちるのを防ぐため→ナポレオン時代
そのトリアージに用いるのが「トリアージ・
タッグ」です。以降、コンピュータ業界に
あわせて「トリアージ・タグ」と呼びます。

20. 緊急度順
1. 赤 … 直ちに治療が必要
2. 黄 … 準救急治療群（数時間余裕）
3. 緑 … 軽傷（歩行可能）
4. 黒 … 生命兆候がない（死）
5. 黒…助かる見込みが極めて低い、
もしくは、治療のために多くの医療
従事者の関与・治療が必要な場合
参考情報：トリアージ 東京都福祉保健局
http://www.fukushihoken.metro.tokyo.jp/iryo/kyuukyuu/saigai/triage.html
指揮本部用(災害現場用)
No. 氏 名(Name) 年齢(Age) 性別(Sex)
男 (M)
女 (F)
住 所(Address) 電話(Phone)
トリアージ実施者氏名トリアージ実施日時・時刻
月 日 時 分
AM
PM
搬 送 機 関 名 収容医療機関名
トリアージ実施場所 救 出 場 所
トリアージ実施機関 医 師
救急救命士
そ の 他
死 亡 重 篤
重 傷 中程度
軽 傷
傷 病 名
トリアージ区分
O Ⅰ Ⅱ Ⅲ
トリアージ・タッグ
O
Ⅰ
Ⅱ
Ⅲ
特記事項(搬送・治療上特に留意すべき事項)
トリアージ・タッグ
O
Ⅰ
Ⅱ
Ⅲ
そ の 他 の 応 急 措 置 の 状 況 等
前 後
現場でのトリアージと、病院でのトリアー
ジがありますが、ここではシンプルに考え
ます。まずは診察して、状況確認です。

21. 緊急度順
1. 赤 … 直ちに治療が必要
2. 黄 … 準救急治療群（数時間余裕）
3. 緑 … 軽傷（歩行可能）
4. 黒 … 生命兆候がない（死）
5. 黒…助かる見込みが極めて低い、
もしくは、治療のために多くの医療
従事者の関与・治療が必要な場合
参考情報：トリアージ 東京都福祉保健局
http://www.fukushihoken.metro.tokyo.jp/iryo/kyuukyuu/saigai/triage.html
指揮本部用(災害現場用)
No. 氏 名(Name) 年齢(Age) 性別(Sex)
男 (M)
女 (F)
住 所(Address) 電話(Phone)
トリアージ実施者氏名トリアージ実施日時・時刻
月 日 時 分
AM
PM
搬 送 機 関 名 収容医療機関名
トリアージ実施場所 救 出 場 所
トリアージ実施機関 医 師
救急救命士
そ の 他
死 亡 重 篤
重 傷 中程度
軽 傷
傷 病 名
トリアージ区分
O Ⅰ Ⅱ Ⅲ
トリアージ・タッグ
O
Ⅰ
特記事項(搬送・治療上特に留意すべき事項)
トリアージ・タッグ
O
Ⅰ
そ の 他 の 応 急 措 置 の 状 況 等
前 後
重篤であれば、このように赤のカードを。
軽傷であれば緑と。これらはフローチャー
トのように、手順が決まっています。
おや、何か似ていませんか？

22. ………… ………… ………… ……… ……
適切なトリアージ（タグ付け）の実施で、
誰を対応すべきか、一目瞭然です。

23. LB
active
LB
stand-by
App App App App App
DB DB
ハッと気づきました。これは、サーバや
サービスの監視モデルになるのでは？

24. LB
active
LB
stand-by
App App App App App
DB DB
障害が発生したら、闇雲にアラート対応
するのではなく、迅速な状況把握と優先
度付け。

25. 25
‣ トラブルシュートの効率化
• 原因を迅速に把握する
• ログを読むとは別のアプローチ
‣ 状況の把握と整理
• 一覧性、検索可能であること
‣ サービス品質向上
• 「いつ」から「何」がおかしいか？
そのために、時系列監視の必要性
何を持って異常と判断するかの基盤が欲し
くて、それは従来のツール群では、実現
することができませんでした。そこで、
Zabbixの有用性に気づきます。

26. これは「トリガ」の一覧表示画面です。
時系列のイベント情報と、「重要度」を
一覧して見られます。

27. トリアージ「タグ」を実現する機能こそが
Zabbixに始めからありました。

28. そしてもう１つ重要な機能が、トリガに対
する依存関係の設定です。

29. トリアージ「判定」を行うように、トリガ間
に親子関係を設定します。これは、不要
なアラートを減らし、人間が何に対応すべ
きか分かりやすくするものです。

30. 心臓は正常
脳死状態
死活監視は正常
サービスは停止状態
致命的な障害
PING
サービス障害
HTTP
サービス障害
SSH
軽度の障害
HTTP
軽度の障害
SSH
軽度の障害
ICMP
これがあると、明らかに不要な通知を消せ
ます。サーバのPINGが到達しないなら、
HTTP・SSHの通知が不要なのは自明。
さらに、人間で言う脳死状態のように、
サーバが生きてるが停止しているような
状態の監視にも応用可能です。

31. 致命的な障害
PING
サービス障害
HTTP
サービス障害
SSH
軽度の障害
HTTP
軽度の障害
SSH
軽度の障害
ICMP
{Base Template:icmppingloss[,5,,,].last(0)}>50 |
{Base Template:icmppingsec[,5,,,,].last(0)}=0
依存関係付きテンプレート
{Base Template:net.tcp.service[http,,80].count(5m,0)}>3 &
{Base Template:net.tcp.service[http,,80].last(0,300)}=0
{Base Template:net.tcp.service[ssh,,22].count(5m,0)}>3 &
{Base Template:net.tcp.service[ssh,,22].last(0,300)}=0
{Base Template:net.tcp.service[http,,80].last(0)}=0
{Base Template:net.tcp.service[http,,80].last(0)}=0
{Base Template:net.tcp.service[ssh,,22].last(0)}=0
このように依存関係を組みあわせたトリガ
が比較的簡単に使えますし、テンプレート
化して、使い回しも楽です。

32. 32
‣ 計測してみないと分からない
• 血液成分や血圧
• レントゲン
• 体重
• 歩数
• 心拍数
• 睡眠時間
データを取ることで、はじめて客観的な傾向や関連が分かる
次の行動に移すことができる
運用は健康な生活、監視は健康診断
計測してみないとわからないのは、体も
サーバも同じです。

33. 最近、この体に付けるデバイスで計測し、
分かったことがあります。

34. これは心拍数ですが、出社中は就寝時の
ように低く安定！！ そりゃ、座りっぱな
しなら脈も上がりませんし、カロリー消費
しませんし、体重も増えるわけです。とい
うか、早死にしそう。。
計測で「運動しよう」「体を動かそう」とい
う次の行動が促されました。

35. サーバも、体も同じですよね。
まずはデータの取得から。

36. 一度取ってしまえば、長期的な傾向は
把握しやすくなります。

38. 38
もう１つ、Zabbix採用に至った課題
‣ 環境変化
• ウェブ系・携帯電話キャリア向けサービス
常時ネットに接続するのが当たり前
‣ 既存の監視システムの限界
• 監視間隔
• 無制限に届くアラートの制御
• 通知順位・エスカレーション問題
• 監視の手間

39. 私も夜はゆっくり眠りたい！！！

40. 40
‣ 平時における運用
• サーバやネットワーク機器などの死活監視、リソース監視
– 異常が無いかどうか、定期的なチェック
• 例：人間でいうところの健康診断、結果をカルテで管理、医者が治療
• サービス監視とシステム監視の分離（例：人間の脳死状態を検知）
‣ 緊急時の運用
• より迅速な原因の切り分けと対応
• 例：災害時におけるトリアージ
運用とは何かを再定義した

41. 41
‣ 内蔵機能
• テンプレート機能
• 重要度の活用
• アラートの依存関係設定（無駄なアラートを減らす）
• アクションの定義
– 予備アラート設定
• 通知エスカレーション
• 通知機能のメンテナンス・フリー化
• LLD + SNMP
‣ 外部システム連携
• メールのスレッド化やパトランプ連携
課題を解消したZabbixの諸機能

42. 42
ZABBIXの通知メールをスレッド化してみる | Pocketstudio.jp log3
http://pocketstudio.jp/log3/2013/06/07/zabbix-email-alerts-threadin/
通知メールのスレッド化 当時はメールが主体だったのでメーラーで
状況把握ができるように工夫できました。

43. 43
アクションと通知の活用
1. 標準死活監視グループ
No. 重要度 トリガ名称
監視
間隔
(秒)
条件
通知順番(エスカレーション)
復旧
通知
依存
関係
STEP 1 STEP n 最終 STEP
経過 内容 繰り返し 経過 内容 繰り返し 経過 内容 繰り返し
1Disaster 【緊急】 Server is down 60pingパケットロス50%以上＆ping応答0秒 0 予備通知(メール) → 3分 障害通知(メール) 15分毎4回 15分 通知停止メール ○
2High 【サービス障害】 SSH (TCP:22) 605分間に3度のダウン検出＆3分間正常 0 予備通知(メール) → 3分 障害通知(メール) 15分毎4回 15分 通知停止メール ○ 1
3High 【サービス障害】 HTTP (TCP:80) 605分間に3度のダウン検出 0 予備通知(メール) → 3分 障害通知(メール) 15分毎4回 15分 通知停止メール ○ 1
4Average 【通知】 SSH (TCP:22) 60ポートのダウン検出 0 予備通知(メール) → 3分 障害通知(メール) 15分毎4回 15分 通知停止メール ○ 2
5Average 【通知】 HTTP (TCP:80) 60ポートのダウン検出 0 予備通知(メール) → 3分 障害通知(メール) 15分毎4回 15分 通知停止メール ○ 3
6Average 【通知のみ】 ICMP応答時間超過 60ping応答5秒以上 0 予備通知(メール) → 3分 障害通知(メール) 15分毎4回 15分 通知停止メール ○ 1
7Information ※各種アラート用 60重要度が "Information" の項目 0 予備通知(メール)
2. サービス(Public IP アドレス)監視グループ
No. 重要度 トリガ名称
監視
間隔
(秒)
条件
通知順番(エスカレーション)
復旧
通知
依存
関係
STEP 1 STEP n 最終 STEP
経過 内容 繰り返し 経過 内容 繰り返し 経過 内容 繰り返し
1Disaster Public IP is down 20Public IP の HTTP down 検出時 0 notice通知 → 3分 apwarning通知 15分毎3回 1分 通知停止メール ○
通知の自動エスカレーション・本文自動変更・acknowledgeログ・自動停止
時間経過や応答(acknowledge)に応じて
通知のエスカレーションも可能です。

44. 44
‣ 対お客さま
• きめ細かな通知需要に対応
• 障害発生時、直ぐに原因が分かる（GUI)
満足度向上
‣ 社内
• トラブルシュートの属人化や、設定における手間を極力減らした
品質向上
結果

45. 45
‣ チーム全体がデータセンタへ
• データセンタ内のネットワーク運用チームと協力
‣ 新サービス化
• 自分たちの既存サービスの枠が障害に
‣ お客さまとの信頼関係
• ホットライン
• チャット
Zabbix以外の施策 ツールありき、ではなく、本来お客さまが
求めていた運用、その実現に動きました。
偶然にも、自分たちの求めていた機能が
Zabbixに揃っていたのです。あるのなら、
使わない手はありません。必要があれば、
サポートが得られる！というのも
大きな理由でした。

46. 46
‣ 障害予測への活用
• 本当に欲しかったのは「緊急地震速報」のような検出システム
‣ クラウド環境・コンテナ環境・IoTへの対応
• ・・・？
現在の展望 そして、また時代が変わろうとしています。

47. アラート検出
通知
人的対応
状況復帰
定点監視
定期作業
監視設計
報告書作成
これまでの運用・監視は、人的対応を
いかに正確・迅速に行うかがカギでした。

48. 人が動くのを手助けする＝自動的な処理。
これは、人ありきのシステム。
パトランプもそうですよね。Zabbixとも
連携することができます。メールよりも
速く状況を速くするために。
でも、その「人」が課題になり始めている

49. サービス・ディスカバリと連携
2 Cooperation based on service discovery

50. 50
再び時代は動く
‣ 00年代後半
• スマートフォンの登場
‣ 10年代
• スマートフォンの性能向上と、幅広い普及（シェア上昇）
• Dockerというコンテナ管理プラットフォームの普及
• IoTの潮流 ← New!!

51. IoTではありませんが、現実世界の問題
解決として、取得したデータをリモートの
Zabbixサーバ上に保管するのは去年から
試していました。

53. これから始めるZabbix Sender(2) Raspberry Pi の温度データを送るには？
http://pocketstudio.jp/log3/2015/01/08/howto-use-zabbix-sender-with-raspberry-pi/
今年の秋は暑いな～と思っていたら、夏以
降も室温は高いまま。

54. あとは録画サーバのHDD容量監視。

55. これから始めるZabbix Sender(3) nasneのHDD容量や状態を監視するには
http://pocketstudio.jp/log3/2015/01/10/howto-monito-nasne-usage-and-status/
監視も出来て、アラートも飛ばせるので、
容量不足で録画失敗は、もうしません。

56. とはいえ、課題になるのが、これです。
IPアドレスが変わると、毎回設定を手で
変更しなくてはいけませんでした。

57. Dockerコンテナや、IoTなどが流行ってく
ると、次の例えのような時代になってきた
と感じます。

58. 58
‣ 監視対象の指数関数的増大
• 環視ポイントの増加
– 死活監視
– リソース監視
– サービス監視
• 動的にインフラとなるシステムやネットワークが変化する
ホスト名と IP アドレスの管理の限界
• コンテナ IDや IPv6 をどのように管理するのか
• 人的コストという課題
ペットから家畜の時代

59. Mercury Venus Earth Moon Mars Jupiter Saturn Uranus Pluto Neptune
みなさん、これから何を連想されます？
業界的な所で。

60. Mercury Venus Earth Moon Mars Jupiter Saturn Uranus Pluto Neptune
コンピュータ資源が
貴重だった時代
コンピュータ資源が
空気のような時代
物理サーバ
PC
クラウド
コンテナ ←New!
IoTデバイス ←New!
ホスト名に星・神話・SFにちなむものを
つけていたと思います。覚えやすいように。
でも今は…

63. サーバ
OS のカーネル空間
Docker サーバ
ユ
ー
ザ
プ
ロ
セ
ス
ユ
ー
ザ
プ
ロ
セ
ス
ユーザ空間
ユ
ー
ザ
プ
ロ
セ
ス
ユーザ空間
• Cgroups
• Namespaces
 mount
 UTS
 IPC
 PID
 Network
 User
コンテナ
https://hub.docker.com/
Docker Hub
(レジストリ)
Docker
クライアント
"docker" デーモン
TCP:2375,TCP:2376(TSL),UnixSocket
Ubuntu
レポジトリ
MySQL
レポジトリ
tag:latest
tag:14.04
…
tag:latest
tag:5.7
…docker run …
Docker
コンテナ

64. サーバ
OS のカーネル空間
Docker サーバ
ユ
ー
ザ
プ
ロ
セ
ス
ユ
ー
ザ
プ
ロ
セ
ス
ユーザ空間
ユ
ー
ザ
プ
ロ
セ
ス
ユーザ空間
• Cgroups
• Namespaces
 mount
 UTS
 IPC
 PID
 Network
 User
コンテナ
https://hub.docker.com/
Docker Hub
(レジストリ)
Docker
クライアント
"docker" デーモン
TCP:2375,TCP:2376(TSL),UnixSocket
Ubuntu
レポジトリ
MySQL
レポジトリ
tag:latest
tag:14.04
…
tag:latest
tag:5.7
…docker run …

65. • Cgroups
• Namespaces
 mount
 UTS
 IPC
 PID
 Network
 User
仮想サーバではなく、プロセスが隔離さ
れた状態。これをどう監視する？

66. zem@dev:~$ docker run -ti ubuntu /bin/bash
root@bdf6207621c7:/# ps -ef
UID PID PPID C STIME TTY TIME CMD
root 1 0 0 01:11 ? 00:00:00 /bin/bash
root 16 1 0 01:11 ? 00:00:00 ps -ef
root@bdf6207621c7:/#
コ ン テ ナ 内 の プ ロ セ ス
コンテナの中には、独立したプロセス。
コンテナIDと呼ばれるホスト名のような
ものもあります。

67. root@bdf6207621c7:/# ls
bin dev home lib64 mnt proc run srv tmp var
boot etc lib media opt root sbin sys usr
root@bdf6207621c7:/# df
Filesystem 1K-blocks Used Available Use% Mounted on
rootfs 20511356 12952564 6493836 67% /
none 20511356 12952564 6493836 67% /
tmpfs 250896 0 250896 0% /dev
shm 65536 0 65536 0% /dev/shm
tmpfs 250896 0 250896 0% /sys/fs/cgroup
/dev/disk/by-label/DOROOT 20511356 12952564 6493836 67% /etc/hosts
tmpfs 250896 0 250896 0% /proc/kcore
tmpfs 250896 0 250896 0% /proc/latency_stats
tmpfs 250896 0 250896 0% /proc/timer_stats
コ ン テ ナ 内 の フ ァ イ ル シ ス テ ム 個々にファイルシステムを持ちますが、
容量そのものは、ホスト側と共有です。

68. root@bdf6207621c7:/# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
361: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
group default
link/ether 02:42:ac:11:00:25 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.37/16 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::42:acff:fe11:25/64 scope link
valid_lft forever preferred_lft forever
root@bdf6207621c7:/# ip route
default via 172.17.42.1 dev eth0
172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.37
コ ン テ ナ 内 の ネ ッ ト ワ ー ク
コンテナ間でネットワークも設定できます。

69. Ｚ氏の場合
Munin 3.0.0b1
l o c a l P C
sudo apt-get update
sudo apt-get install git
git clone git://github.com/munin-monitoring/munin
cd munin
perl Build.PL
sudo apt-get install gcc pkg-config libssl-dev build-essential
sudo apt-get install expat libexpat1 libexpat1-dev libexpat1-dev
sudo apt-get install libxml2-dev libxml-libxml-perl libcairo-gobject-perl libglib2.0-dev libglib-perl
sudo apt-get install libcairo-perl libcairo-gobject-perl libgraphics-primitive-driver-cairo-perl
sudo apt-get install libcairo2-dev libpango1.0-dev
sudo cpan -i XML::Parser XML::Dumper
sudo cpan -i Alien::RRDtool
sudo cpan -i Test::Class Test::MockModule Test::MockObject Test::LongString Test::Differences
sudo cpan -i File::Slurp
sudo ./Build installdeps
./Build test
sudo ./Build installe
cd /usr/local/etc/munin/
sudo mkdir /usr/local/etc/munin/plugins
sudo cp munin.conf.sample munin.conf
sudo cp munin-node.conf.sample munin-node.conf
sudo munin-node-configure --shell --families=contrib,auto | sh -x
リ モ ー ト の サ ー バ
Dockerコンテナは、ファイルシステムも
持ちます。なので、これまで手動で環境
の再構築が必要なケースでも

70. Ｚ氏の場合
Munin 3.0.0b1
l o c a l P C
sudo apt-get update
sudo apt-get install git
git clone git://github.com/munin-monitoring/munin
cd munin
perl Build.PL
sudo apt-get install gcc pkg-config libssl-dev build-essential
sudo apt-get install expat libexpat1 libexpat1-dev libexpat1-dev
sudo apt-get install libxml2-dev libxml-libxml-perl libcairo-gobject-perl libglib2.0-dev libglib-perl
sudo apt-get install libcairo-perl libcairo-gobject-perl libgraphics-primitive-driver-cairo-perl
sudo apt-get install libcairo2-dev libpango1.0-dev
sudo cpan -i XML::Parser XML::Dumper
sudo cpan -i Alien::RRDtool
sudo cpan -i Test::Class Test::MockModule Test::MockObject Test::LongString Test::Differences
sudo cpan -i File::Slurp
sudo ./Build installdeps
./Build test
sudo ./Build installe
cd /usr/local/etc/munin/
sudo mkdir /usr/local/etc/munin/plugins
sudo cp munin.conf.sample munin.conf
sudo cp munin-node.conf.sample munin-node.conf
sudo munin-node-configure --shell --families=contrib,auto | sh -x
リ モ ー ト の サ ー バ
zembutsu/muinin3
Dockerfile
D o c k e r H u b
docker push
zembutsu/muinin3
docker pull
zembutsu/muinin3
docker run
docker commit
docker bulid
Dockerコンテナ化することにより、どこで
も実行できるようになりました。簡単に、
迅速にです。

71. 仮想化の環境で作るよりも、コマンドを
実行するだけでDockerコンテナは簡単に
環境の構築・破棄ができるように。

72. それでもZabbixで大丈夫かな…？って
心配になりますよね。対策はあるのでしょ
うか…

74. 74
‣ ローレベル・ディスカバリ
• Zabbix 内蔵のホストやサービスの自動検出機能
– ネットワークやディスクなど、システム基盤
– SNMP
– 任意コード
‣ LLD は設定が手軽
• 「ペットから家畜へ」の答えの一つかも
LLDは答えの一つ Zabbixが持つ機能の１つが、ペットから
家畜時代の答えかもしれません。

75. ネットワーク範囲を ping で監視し、疎通
したら自動的にホストを監視登録。

76. 同様に、ファイルシステム・NIC・SNMPも

79. 【ZABBIX】やっぱりLLD(ローレベルディスカバリ)は最高だぜ！ | Pocketstudio.jp log3
http://pocketstudio.jp/log3/2013/07/08/howto-zabbix-low-level-discovery/

80. 80
‣ ローレベル・ディスカバリ
• Zabbix 内蔵のホストやサービスの自動検出機能
– ネットワークやディスクなど、システム基盤
– SNMP
– 任意コード
‣ LLD は設定が手軽
• 「ペットから家畜へ」の答えの一つかも
ただし、何を監視するかは Zabbix が認識する必要がある
LLDは答えの一つ Zabbix側で何を監視するかは、常に決め
なくてはいけません。トリガもそうです。
あと、自動削除が出来ないのが、LLDの
唯一の弱点。。

82. そこで、再び仮説モデルを検証しました。
飛行機の管制が、役立つのではと。

83. http://www.flightradar24.com

84. このサイトは、飛行機をクリックすると、
どのような位置、経路、目的が簡単に
把握できます。
どうして把握できるのでしょうか？

85. 管制塔
・肉眼での監視限界
Control Center
空港の管制塔からは、視界の範囲が限ら
れています。人間だけで監視は大変。
そこで…

86. 管制塔 レーダー
・肉眼での監視限界 ・山の裏側、夜間も見える
・より正確な位置・高度
Control Center RADER ( radio detection and ranging)
レーダーの出番です。飛行機の情報を
人間以上に正確に収集します。

87. 管制塔 レーダー
管制官
・肉眼での監視限界 ・山の裏側、夜間も見える
・より正確な位置・高度・時系列の位置把握・記録
・正確な状況判断と的確な指示
Control Center
Operator
RADER ( radio detection and ranging)
そして、そのデータを元に、管制官が
状況を知ることができます。

88. ZabbixのLLD
中央集権モデル
監視間隔や監視性能は
Zabbixサーバに依存
つまり、Zabbix（監視システム全般）と
同じような関係があるのではと。

89. ZabbixのLLD
中央集権モデル
Consulのサービスディスカバリ
非中央集権モデル
監視間隔や監視性能は
Zabbixサーバに依存
個々の監視対象（サービス）や間隔は
エージェントが定義
秒単位で数千ノードを一斉管理
役割が違うのではないでしょうか。

90. ZabbixのLLD
中央集権モデル
Consulのサービスディスカバリ
非中央集権モデル
アンチ・エントロピー
監視間隔や監視性能は
Zabbixサーバに依存
個々の監視対象（サービス）や間隔は
エージェントが定義
秒単位で数千ノードを一斉管理
KVS
サービス
カタログ
・HTTP
・API
・DNS
Anti-Entropy - Consul by HashiCorp
https://www.consul.io/docs/internals/anti-entropy.html

91. 91
‣ 役割は、現実世界における「レーダー」
• どこで、どのようなサービスが動いているのか監視・検出
– 秒単位で状況を監視
– 非中央集中型（アンチ・エントロピー）
• サービスの状態をカタログ(KVS)で管理
• 選択肢
– Consul ( HashiCorp )
– Etcd ( CoreOS ) + SkyDNS
– ZooKeeper
サービス・ディスカバリ

92. 92
‣ Zabbixは「管制塔」、サービスディスカバリは「レーダー」
• 肉眼よりも多くの情報を正確・自動的に収集
‣ 構成
• Zabbix + LLD + APIサーバ + サービス・ディスカバリ
• Zabbix + API サーバ + サービスディスカバリ
‣ 意味：司令塔(Zabbix)を補うサービス・ディスカバリ
• ホストやサービスの自動登録・自動削除
• サービスに応じたアラートの自動設定・削除
監視環境が変わっても、これまでの運用手法が活用出来る
APIがZabbixと結び付ける

93. KVS
運用担当 サービス・ディスカバリ機構Zabbix API GW
Zabbixとサービス・ディスカバリを連携する、トリアージ的運用支援モデル

94. KVS
運用担当 サービス・ディスカバリ機構Zabbix API GW
Zabbixとサービス・ディスカバリを連携する、トリアージ的運用支援モデル
サービス・カタログ
ホスト名・IPアドレス・サービス名等
レーダー Radar
(radio detection and ranging)

95. KVS
運用担当 サービス・ディスカバリ機構Zabbix API GW
Zabbixとサービス・ディスカバリを連携する、トリアージ的運用支援モデル
API
サービス・カタログ
ホスト名・IPアドレス・サービス名等
トリアージ
優先度の判断支援
管制塔 Control Center レーダー Radar
(radio detection and ranging)

97. トラブルシューティング
時系列リソース推移
(Munin)
監視間隔の短時間化
障害発生予測システム
傾向分析
(MRTG Holt-Winters Seasonal Method)
アラート最適化
(Zabbix)
トリアージ的対応
予防のための統計的手法
障害発生時の自動化処理
Pythagoras(仮) Refectier(仮)
興味と変遷
物理監視
動的に変化する環境の監視
「点から面へ」
クラウドやコンテナとの自動化連携
サポート業務
多分これからは、ピタゴラスイッチ的な
あるいは、人体の神経モデルのような
仕組みが求められているのかもしれないと
思っています。

101. まとめ
3 Wrap up

102. 102
まとめ
‣ Zabbixを導入した理由
• トリアージ的な運用フローをZabbixで統一
• メンテナンス・フリーを実現するZabbixの諸機能
運用業務の標準化
‣ サービス・ディスカバリと API 連携
• IoT や Docker 時代にも対応する API 基盤
進化に適応するZabbix

103. 103
‣ 何か気になる所はありますか？
質疑応答
指揮本部用(災害現場用)
No. 氏 名(Name) 年齢(Age) 性別(Sex)
住 所(Address) 電話(Phone)
トリアージ実施者氏名トリアージ実施日時・時刻
月 日 時 分
AM
PM
搬 送 機 関 名 収容医療機関名
トリアージ実施場所 救 出 場 所
トリアージ実施機関 医 師
救急救命士
そ の 他
死 亡 重 篤
重 傷 中程度
軽 傷
傷 病 名
トリアージ区分
O Ⅰ Ⅱ Ⅲ
トリアージ・タッグ
O
Ⅰ
@zembutsu
ておくれ