Upcoming SlideShare
障害対応・運用におけるトリアージ的対応とZabbixの活用
- 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. 一度取ってしまえば、長期的な傾向は 把握しやすくなります。
- 37. 38 もう１つ、Zabbix採用に至った課題 ‣ 環境変化 • ウェブ系・携帯電話キャリア向けサービス 常時ネットに接続するのが当たり前 ‣ 既存の監視システムの限界 • 監視間隔 • 無制限に届くアラートの制御 • 通知順位・エスカレーション問題 • 監視の手間
- 38. 私も夜はゆっくり眠りたい！！！
- 39. 40 ‣ 平時における運用 • サーバやネットワーク機器などの死活監視、リソース監視 – 異常が無いかどうか、定期的なチェック • 例：人間でいうところの健康診断、結果をカルテで管理、医者が治療 • サービス監視とシステム監視の分離（例：人間の脳死状態を検知） ‣ 緊急時の運用 • より迅速な原因の切り分けと対応 • 例：災害時におけるトリアージ 運用とは何かを再定義した
- 40. 41 ‣ 内蔵機能 • テンプレート機能 • 重要度の活用 • アラートの依存関係設定（無駄なアラートを減らす） • アクションの定義 – 予備アラート設定 • 通知エスカレーション • 通知機能のメンテナンス・フリー化 • LLD + SNMP ‣ 外部システム連携 • メールのスレッド化やパトランプ連携 課題を解消したZabbixの諸機能
- 41. 42 ZABBIXの通知メールをスレッド化してみる | Pocketstudio.jp log3 http://pocketstudio.jp/log3/2013/06/07/zabbix-email-alerts-threadin/ 通知メールのスレッド化 当時はメールが主体だったのでメーラーで 状況把握ができるように工夫できました。
- 42. 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)に応じて 通知のエスカレーションも可能です。
- 43. 44 ‣ 対お客さま • きめ細かな通知需要に対応 • 障害発生時、直ぐに原因が分かる（GUI) 満足度向上 ‣ 社内 • トラブルシュートの属人化や、設定における手間を極力減らした 品質向上 結果
- 44. 45 ‣ チーム全体がデータセンタへ • データセンタ内のネットワーク運用チームと協力 ‣ 新サービス化 • 自分たちの既存サービスの枠が障害に ‣ お客さまとの信頼関係 • ホットライン • チャット Zabbix以外の施策 ツールありき、ではなく、本来お客さまが 求めていた運用、その実現に動きました。 偶然にも、自分たちの求めていた機能が Zabbixに揃っていたのです。あるのなら、 使わない手はありません。必要があれば、 サポートが得られる！というのも 大きな理由でした。
- 45. 46 ‣ 障害予測への活用 • 本当に欲しかったのは「緊急地震速報」のような検出システム ‣ クラウド環境・コンテナ環境・IoTへの対応 • ・・・？ 現在の展望 そして、また時代が変わろうとしています。
- 46. アラート検出 通知 人的対応 状況復帰 定点監視 定期作業 監視設計 報告書作成 これまでの運用・監視は、人的対応を いかに正確・迅速に行うかがカギでした。
- 47. 人が動くのを手助けする＝自動的な処理。 これは、人ありきのシステム。 パトランプもそうですよね。Zabbixとも 連携することができます。メールよりも 速く状況を速くするために。 でも、その「人」が課題になり始めている
- 48. サービス・ディスカバリと連携 2 Cooperation based on service discovery
- 49. 50 再び時代は動く ‣ 00年代後半 • スマートフォンの登場 ‣ 10年代 • スマートフォンの性能向上と、幅広い普及（シェア上昇） • Dockerというコンテナ管理プラットフォームの普及 • IoTの潮流 ← New!!
- 50. IoTではありませんが、現実世界の問題 解決として、取得したデータをリモートの Zabbixサーバ上に保管するのは去年から 試していました。
- 51. これから始めるZabbix Sender(2) Raspberry Pi の温度データを送るには？ http://pocketstudio.jp/log3/2015/01/08/howto-use-zabbix-sender-with-raspberry-pi/ 今年の秋は暑いな～と思っていたら、夏以 降も室温は高いまま。
- 52. あとは録画サーバのHDD容量監視。
- 53. これから始めるZabbix Sender(3) nasneのHDD容量や状態を監視するには http://pocketstudio.jp/log3/2015/01/10/howto-monito-nasne-usage-and-status/ 監視も出来て、アラートも飛ばせるので、 容量不足で録画失敗は、もうしません。
- 54. とはいえ、課題になるのが、これです。 IPアドレスが変わると、毎回設定を手で 変更しなくてはいけませんでした。
- 55. Dockerコンテナや、IoTなどが流行ってく ると、次の例えのような時代になってきた と感じます。
- 56. 58 ‣ 監視対象の指数関数的増大 • 環視ポイントの増加 – 死活監視 – リソース監視 – サービス監視 • 動的にインフラとなるシステムやネットワークが変化する ホスト名と IP アドレスの管理の限界 • コンテナ IDや IPv6 をどのように管理するのか • 人的コストという課題 ペットから家畜の時代
- 57. Mercury Venus Earth Moon Mars Jupiter Saturn Uranus Pluto Neptune みなさん、これから何を連想されます？ 業界的な所で。
- 58. Mercury Venus Earth Moon Mars Jupiter Saturn Uranus Pluto Neptune コンピュータ資源が 貴重だった時代 コンピュータ資源が 空気のような時代 物理サーバ PC クラウド コンテナ ←New! IoTデバイス ←New! ホスト名に星・神話・SFにちなむものを つけていたと思います。覚えやすいように。 でも今は…
- 59. サーバ 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 コンテナ
- 60. サーバ 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 …
- 61. • Cgroups • Namespaces mount UTS IPC PID Network User 仮想サーバではなく、プロセスが隔離さ れた状態。これをどう監視する？
- 62. 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と呼ばれるホスト名のような ものもあります。
- 63. 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 コ ン テ ナ 内 の フ ァ イ ル シ ス テ ム 個々にファイルシステムを持ちますが、 容量そのものは、ホスト側と共有です。
- 64. 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 コ ン テ ナ 内 の ネ ッ ト ワ ー ク コンテナ間でネットワークも設定できます。
- 65. Ｚ氏の場合 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コンテナは、ファイルシステムも 持ちます。なので、これまで手動で環境 の再構築が必要なケースでも
- 66. Ｚ氏の場合 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コンテナ化することにより、どこで も実行できるようになりました。簡単に、 迅速にです。
- 67. 仮想化の環境で作るよりも、コマンドを 実行するだけでDockerコンテナは簡単に 環境の構築・破棄ができるように。
- 68. それでもZabbixで大丈夫かな…？って 心配になりますよね。対策はあるのでしょ うか…
- 69. 74 ‣ ローレベル・ディスカバリ • Zabbix 内蔵のホストやサービスの自動検出機能 – ネットワークやディスクなど、システム基盤 – SNMP – 任意コード ‣ LLD は設定が手軽 • 「ペットから家畜へ」の答えの一つかも LLDは答えの一つ Zabbixが持つ機能の１つが、ペットから 家畜時代の答えかもしれません。
- 70. ネットワーク範囲を ping で監視し、疎通 したら自動的にホストを監視登録。
- 71. 同様に、ファイルシステム・NIC・SNMPも
- 72. 【ZABBIX】やっぱりLLD(ローレベルディスカバリ)は最高だぜ！ | Pocketstudio.jp log3 http://pocketstudio.jp/log3/2013/07/08/howto-zabbix-low-level-discovery/
- 73. 80 ‣ ローレベル・ディスカバリ • Zabbix 内蔵のホストやサービスの自動検出機能 – ネットワークやディスクなど、システム基盤 – SNMP – 任意コード ‣ LLD は設定が手軽 • 「ペットから家畜へ」の答えの一つかも ただし、何を監視するかは Zabbix が認識する必要がある LLDは答えの一つ Zabbix側で何を監視するかは、常に決め なくてはいけません。トリガもそうです。 あと、自動削除が出来ないのが、LLDの 唯一の弱点。。
- 74. そこで、再び仮説モデルを検証しました。 飛行機の管制が、役立つのではと。
- 75. http://www.flightradar24.com
- 76. このサイトは、飛行機をクリックすると、 どのような位置、経路、目的が簡単に 把握できます。 どうして把握できるのでしょうか？
- 77. 管制塔 ・肉眼での監視限界 Control Center 空港の管制塔からは、視界の範囲が限ら れています。人間だけで監視は大変。 そこで…
- 78. 管制塔 レーダー ・肉眼での監視限界 ・山の裏側、夜間も見える ・より正確な位置・高度 Control Center RADER ( radio detection and ranging) レーダーの出番です。飛行機の情報を 人間以上に正確に収集します。
- 79. 管制塔 レーダー 管制官 ・肉眼での監視限界 ・山の裏側、夜間も見える ・より正確な位置・高度・時系列の位置把握・記録 ・正確な状況判断と的確な指示 Control Center Operator RADER ( radio detection and ranging) そして、そのデータを元に、管制官が 状況を知ることができます。
- 80. ZabbixのLLD 中央集権モデル 監視間隔や監視性能は Zabbixサーバに依存 つまり、Zabbix（監視システム全般）と 同じような関係があるのではと。
- 81. ZabbixのLLD 中央集権モデル Consulのサービスディスカバリ 非中央集権モデル 監視間隔や監視性能は Zabbixサーバに依存 個々の監視対象（サービス）や間隔は エージェントが定義 秒単位で数千ノードを一斉管理 役割が違うのではないでしょうか。
- 82. ZabbixのLLD 中央集権モデル Consulのサービスディスカバリ 非中央集権モデル アンチ・エントロピー 監視間隔や監視性能は Zabbixサーバに依存 個々の監視対象（サービス）や間隔は エージェントが定義 秒単位で数千ノードを一斉管理 KVS サービス カタログ ・HTTP ・API ・DNS Anti-Entropy - Consul by HashiCorp https://www.consul.io/docs/internals/anti-entropy.html
- 83. 91 ‣ 役割は、現実世界における「レーダー」 • どこで、どのようなサービスが動いているのか監視・検出 – 秒単位で状況を監視 – 非中央集中型（アンチ・エントロピー） • サービスの状態をカタログ(KVS)で管理 • 選択肢 – Consul ( HashiCorp ) – Etcd ( CoreOS ) + SkyDNS – ZooKeeper サービス・ディスカバリ
- 84. 92 ‣ Zabbixは「管制塔」、サービスディスカバリは「レーダー」 • 肉眼よりも多くの情報を正確・自動的に収集 ‣ 構成 • Zabbix + LLD + APIサーバ + サービス・ディスカバリ • Zabbix + API サーバ + サービスディスカバリ ‣ 意味：司令塔(Zabbix)を補うサービス・ディスカバリ • ホストやサービスの自動登録・自動削除 • サービスに応じたアラートの自動設定・削除 監視環境が変わっても、これまでの運用手法が活用出来る APIがZabbixと結び付ける
- 85. KVS 運用担当 サービス・ディスカバリ機構Zabbix API GW Zabbixとサービス・ディスカバリを連携する、トリアージ的運用支援モデル
- 86. KVS 運用担当 サービス・ディスカバリ機構Zabbix API GW Zabbixとサービス・ディスカバリを連携する、トリアージ的運用支援モデル サービス・カタログ ホスト名・IPアドレス・サービス名等 レーダー Radar (radio detection and ranging)
- 87. KVS 運用担当 サービス・ディスカバリ機構Zabbix API GW Zabbixとサービス・ディスカバリを連携する、トリアージ的運用支援モデル API サービス・カタログ ホスト名・IPアドレス・サービス名等 トリアージ 優先度の判断支援 管制塔 Control Center レーダー Radar (radio detection and ranging)
- 88. トラブルシューティング 時系列リソース推移 (Munin) 監視間隔の短時間化 障害発生予測システム 傾向分析 (MRTG Holt-Winters Seasonal Method) アラート最適化 (Zabbix) トリアージ的対応 予防のための統計的手法 障害発生時の自動化処理 Pythagoras(仮) Refectier(仮) 興味と変遷 物理監視 動的に変化する環境の監視 「点から面へ」 クラウドやコンテナとの自動化連携 サポート業務 多分これからは、ピタゴラスイッチ的な あるいは、人体の神経モデルのような 仕組みが求められているのかもしれないと 思っています。
- 89. まとめ 3 Wrap up
- 90. 102 まとめ ‣ Zabbixを導入した理由 • トリアージ的な運用フローをZabbixで統一 • メンテナンス・フリーを実現するZabbixの諸機能 運用業務の標準化 ‣ サービス・ディスカバリと API 連携 • IoT や Docker 時代にも対応する API 基盤 進化に適応するZabbix
- 91. 103 ‣ 何か気になる所はありますか？ 質疑応答 指揮本部用(災害現場用) No. 氏 名(Name) 年齢(Age) 性別(Sex) 住 所(Address) 電話(Phone) トリアージ実施者氏名トリアージ実施日時・時刻 月 日 時 分 AM PM 搬 送 機 関 名 収容医療機関名 トリアージ実施場所 救 出 場 所 トリアージ実施機関 医 師 救急救命士 そ の 他 死 亡 重 篤 重 傷 中程度 軽 傷 傷 病 名 トリアージ区分 O Ⅰ Ⅱ Ⅲ トリアージ・タッグ O Ⅰ @zembutsu ておくれ
Login to see the comments