サーバ運用の現場でひたすら監視し続けるエンジニアの手の内のすべて
•
176 recomendaciones•43,483 vistas
2013年3月19日 Tokyo Linux Study #5 #tlstudy の発表スライドです。 ZABBIX(赤) × Munin(緑) 。どうして両方を使う事になったのか？という話しがメイン。 サブタイトル「@zembutsuがホスティングサービスの監視パワーを強化しようとするけどとんでもないことになる話」
Recomendados
Más contenido relacionado
Similar a サーバ運用の現場でひたすら監視し続けるエンジニアの手の内のすべて
Similar a サーバ運用の現場でひたすら監視し続けるエンジニアの手の内のすべて (20)
Más de Masahito Zembutsu
Más de Masahito Zembutsu (20)
Último
Último (9)
サーバ運用の現場でひたすら監視し続けるエンジニアの手の内のすべて
- 1. 我流の監視に悩む全てのサーバ運用者に贈る ～サーバ運用の現場でひたすら監視し続けるエンジニアの手の内のすべて～ There’s No Way I’ll Ever Regret It Masahito Zembutsu @zembutsu Mar 19, 2013 , Tokyo Linux Study 005 #tlstudy ×
- 2. 副題 @zembutsuがホスティングサービスの 監視パワーを強化しようとするけど とんでもないことになる話
- 3. Ops! DevOps 界隈では、Dev (開発) な方達により、 サービスの品質向上のための監視方法の改善や ノウハウが公開されはじめている。 Dev! が、 Ops (運用) 視点での情報は少なく、まるでOps が何もしていないような雰囲気を感じてしまう 今日この頃であります。 …これはいかん。
- 5. ホスティング運用サポートを担当するエンジ ニアが、Webサービスリリース後 Zabbix や Munin などの監視ツールを、どのように駆使 し、「何を」「どこまで」見ているのか。 明日から使えるノウハウを紹介。高負荷なア プリ運用を例に、その監視体制の裏側を余す ことなくお伝えします。
- 6. ホスティング運用サポートを担当するエンジ ニアが、Webサービスリリース後 Zabbix や Munin などの監視ツールを、どのように駆使 し、「何を」「どこまで」見ているのか。 明日から使えるノウハウを紹介。高負荷なア プリ運用を例に、その監視体制の裏側を余す ことなくお伝えします。
- 8. Office 2013 Microsoft Word Resource Monitoring Zabbix Resource Monitoring Munin Office 2013 赤 ( ZABBIX ) と 緑 ( Munin ) の 合体 ( ドッキング ) 的な話題です
- 9. 赤と緑… ( お察し下さい )
- 11. (意訳：コイツ馬鹿ww)
- 12. 鯖を捌く Ops的、何か DevOps!
- 13. ※職場イメージです This Photo is under creative commons license by torkildr http://www.flickr.com/photos/torkildr/3462606643/sizes/l/in/photostream/
- 14. 今日の内容 今日は、どうして自分が 仕事で Munin を使うよ うになったのか、Zabbix も使う事になったのか、 • 1. あらすじ という経緯がメインで す。 そして、Zabbix と • 2. Munin を使うに至った経緯 Munin 両方を合わせまし た！という今の取り組み • 3. Zabbix 〃 もご紹介します。 • 4. Munin × Zabbix • 5. まとめ （やっぱりMuninは最高だぜ）
- 15. 1 あらすじ /5 INTRODUCTION
- 16. 監視と言えば • Nagios (NetSaint) ベースの死活監視 – 5 分間隔 監視に使っているソフト – ICMP は、NetSaint を独自拡張し たツールを使っていまし – TCP ( SSH / HTTP ) た。 標準サービスとして提供し ていた監視対象は、サービ ス提供当初から、あまり変 わっていませんでした。
- 17. インターネットサービス変遷 • 1994-1995年 個人・企業向けISP相次いで公開 • 個人サイト・日記がブーム→共用レンタルサーバ • 1999年 ｉモード提供開始・２ちゃんねる開設 • コンテンツプロバイダの隆盛 • 2002年 Movable Type 2.0 公開 • ブログブームの幕開け • 2004年 ミクシィ・GREEサービス提供開始 • SNSの先駆け • 2006年 Facebook 一般向け開放,twitter提供開始 • 世界的にソーシャルの流れへ • 2008年 iPhone3 国内販売開始 • 時代はスマートフォン向けのサービスへ • 2010年 Andriod端末国内発売・iPad • スマートフォン向けコンテンツ制作の流れ
- 18. 主な技術トレンドの変遷 • 1996年 Yahoo! Japan 提供開始 • ポータルサイトが流行（リンク集） • 1998年 Google検索サービス提供開始 • 検索の精度向上 • 1999年 Hotmail、Salesforce提供開始 • ASP というサービス形態の登場 • 2004年 Gmail 登場、Xen 2.0 リリース • 仮想化が注目を受け始める • 2006年 Amazon Web Services “S3” 提供開始 • 2006年 Google CEO(当時)エリック・シュミットが • 「クラウド・コンピューティング」発言 • 2008年 Google App Engine (GAE) 提供開始 • PaaS という形態のサービス登場 • 2010年 Windows Azure 提供開始
- 19. インターネット利用者数推移 10,000 9,408 9,462 100% 9,091 8,811 9,000 利用者数 人口普及率 8,529 8,754 90% 7,730 7,948 8,000 80% 6,942 7,000 78.0% 78.2% 70% 75.3% 72.6% 73.0% 70.8% 6,000 5,593 66.0% 60% 64.3% 4,708 57.8% 5,000 50% 4,000 46.3% 40% 2,706 37.1% 3,000 30% 2,000 1,694 20% 1,155 21.4% 1,000 10% 13.4% 9.2% 0 0% 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 出典：総務省 平成22年通信利用動向調査 図表 ４-２ インターネット利用者数及び人口普及率の推移 http://www.soumu.go.jp/johotsusintokei/statistics/pdf/HR201000_001.pdf
- 20. インターネット利用者数推移 10,000 9,408 9,462 100% 9,091 8,811 9,000 利用者数 人口普及率 8,529 8,754 90% 7,730 7,948 8,000 80% 6,942 7,000 78.0% 78.2% 70% 75.3% 72.6% 73.0% 70.8% 6,000 5,593 66.0% 60% 64.3% 4,708 57.8% 5,000 50% 4,000 46.3% 40% 2,706 37.1% 3,000 30% 2,000 1,694 20% 1,155 21.4% 1,000 10% 13.4% 9.2% 0 0% 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 出典：総務省 平成22年通信利用動向調査 図表 ４-２ インターネット利用者数及び人口普及率の推移 http://www.soumu.go.jp/johotsusintokei/statistics/pdf/HR201000_001.pdf
- 21. 提供サービスの変遷 • 15年前からサービスの主流はウェブ系 – 日記・個人サイト・掲示板・メール – コーポレートサイト・社内メールサーバ • ユーザの規模感が確実に変わった – かつて…地道な宣伝広告/リンク→ゆっくり • 提供事業者は、ある程度ユーザ規模が想定できる • 専有サーバで、殆どのシステムを運用 – いま…ソーシャルネットを通じた伝播→いますぐ • 提供事業者は、ユーザ規模の想定が出来ない • システム規模とコストの見積もりが難しいので、 クラウド・コンピューティングとマッチ
- 22. ここまでのまとめ セーブしますか？ ○ はい × いいえ chaos • 這い寄る混沌 ←障害 – ネット利用者数の増加 – 予測可能な障害から、 予測不可能な障害の時代へ • 監視手法の変化を強いられている – 死活監視でこの先生きのこれるの？ – アラート検出後の対応では遅いケースも出てきた
- 23. ここまでのまとめ セーブしますか？ ○ はい × いいえ chaos • 這い寄る混沌 ←障害
- 24. 2 Munin 導入経緯 /5 RESOURCE MONITORING
- 25. はじまりはいつも障害 • 原因不明のサーバ障害への対応 – 何かあった時、ログ調査をしていては遅い 管理対象（機器）の増加により、 監視対象（サービスやリソース） も増加。結果、チェック時のタイ ムロス要因の一つになりがち。
- 26. お客さま vs ホスティング事業者 • お客さまのお申し立て – オタクらサーバ会社なんだから 障害起こったら面倒を見るのアタリまえじゃないの？ 仰有ることは、痛切に感じます。。 • ホスティング事業者の言い訳 – OSやミドルウェア運用など、ハードウェアに関する以 外は、基本的にお客さまでの対応をお願い申(略 すみません、すみません、、
- 27. 何とかならないものか… ( ﾟдﾟ)ﾊｯ! DevとOpsの対立に似ている・・・？ お互いの歩み寄りが必要ではないだろうか。 では、まずは自分たち（運用）がお客さま （開発）に近づこう！
- 28. そんな時に、Munin が舞い降りる 当初は無駄に入れたと思ってい • 勉強会経由で情報をゲット ましたが、データを蓄積するだ けでも後々役立ちました。 – Muninは個人鯖で検証済みだった – 使えそうだったので、すぐにサービス投入した • 自分の管理下は、ほぼ全台投入 • 想像以上にリソース監視が役立った – 管理台数が多いので（直接監視は数百台） – Muninがあったからこそ、 サーバ1台1台の情報を追えられた
- 29. そんな時に、Munin が舞い降りる 更に具体的な経緯や、実際の監視や対応 • 勉強会経由で情報をゲット 内容は、以下スライドをご覧下さい。 – Muninは個人鯖で検証済みだった – 使えそうだったので、すぐにサービス投入した • 自分の管理下は、ほぼ全台投入 • 想像以上にリソース監視が役立った – 管理台数が多いので（直接監視は数百台） – 1台1台の情報をを追うことは出来なかった http://slideshare.net/zembutsu/
- 30. Muninの良いところ、悪いところ • 良いところ 学習コストが低いため、直ぐに業務に導入出来ました。 – 状況把握が簡単になり、障害対応の迅速さが向上 – 必要に応じて、プラグインを追加出来た • 悪いところ 監視対象が増えてきた事による監視サーバ の負荷増大という課題が発生しました。 – グラフの描画が重い そして、スマートフォンの普及により、常 にアクセスが発生するサービスが増えまし – 監視間隔が5分 た。更に短い時間単位での監視や対応に対 する需要が高まります。 – アラート機能が貧弱
- 31. ここまでのまとめ セーブしますか？ ○ はい × いいえ • Munin導入 – もっと「アプリ(Dev)層」に近づく覚悟 – 何か起こった後のトラブルシュートが迅速になった • オープンソースだけども使える – 中はPerlで記述されており、挙動が分かったので 何かあっても自力で解決できた – プラグインの拡張も、スムーズに行えた
- 32. 3 Zabbix 導入経緯 /5 RESOURCE MONITORING
- 34. ZABBIXよ、 まちがい これがリソース監視だ。 こう思ってた時期が、私にもありました。。
- 35. はじまりはいつも障害（またか） • ロードバランサで障害が発生したという話 – 想定を上回るアクセス増 – 共用環境だったので影響範囲が大きい • 原因調査と切り分けに時間がかかる – 当時のモニタでは1分間隔 – 状況照会には、自分たちも時間がかかった
- 36. サポート体制 サーバの状況は、自分たちもMuninで把握で きました。ですが、上位機器の調査や切り分 けには、データセンタ事業者を通すため、 時間が掛かってしまいました。 データセンタ データセンタ サポート お客さま 事業者 対応部隊
- 37. サポート体制 データセンタ データセンタ サポート お客さま 事業者 対応部隊 対策として、自分たちも機器を直接監視し、状況の把 握を行えるように。お客さまには現状の問題報告を行 えますし、対応策も短時間で検討できるように。
- 38. ある障害を切っ掛けにZabbix導入 • 機器のSNMP情報を開示してもらう – 一報を貰ってからでは遅い • 有用なMIBの情報を調査 • snmpを叩くツールを自作 – 自分たちで、直接機器の状況を監視＋アラート • トラフィック • パケット 自分たちも、報告や連絡を待つだけとい • ポートの Up/Down う守りの姿勢からの転換。 • CPU 使用率 必要以上と思われる位の情報を手に入れ る事で、迅速な障害発生の把握と対応策 • メモリ使用率 を検討できる体制を整えることに。
- 39. こんなの見ています ZABBIXで監視しています。こ のグラフは上位機器のポート毎 のデータ転送量やパケットの IN/OUT 状況。
- 40. こちらは生の数値
- 45. ZABBIX を導入してみて… • 慣れるまで時間がかかるかもしれないが、 慣れると楽 Munin に比べると学習コス トは高めです。テンプレー トの概念を理解したり、UI • テンプレート機能が強力 について「慣れる」必要は – 設定や監視の使い回しが出来るので、 あります。でもそれは自転 車と同じで、慣れればたい 監視対象が多いときに有利 したことはありません。 • 機器のアラートも自分たちに直接届くように – 条件が自分たちで出来る • 例：メンテナンスモード自動判別
- 46. ここまでのまとめ セーブしますか？ ○ はい × いいえ • Zabbix導入 – もっと「ネットワーク層」に近づく覚悟 – 何か起こった後のトラブルシュートが更に速く • もう誰にも頼らない ←まちがい • 状況が把握できるだけでも違う 監視対象が増えて、仕事が増える ように見えるかもしれません。 しかし、サービス品質の向上には 必要な事だと考えました。
- 47. 4 Zabbix & Munin /5 RESOURCE MONITORING
- 48. リソース監視の限界(?) 単に監視間隔を短くして も、I/O増大の問題や、 RRDtoolデータ収集の失敗 により、機能しない… • Muninだけでは厳しいところが… – 管理台数の増加に伴う、画像生成サーバの負荷 – 様々なリソースを取得できているが、 有効活用できていない • 使えるアラートが欲しい – 5分間隔では遅い（かもしれない） • dstat でも良いけれど、変化が分かりづらい 結局コンソールに頼るシーンは出てき ても、Munin のようにリソースの変化 を知りたい場面も多い。
- 49. ZABBIX × Munin • 折角 ZABBIX 導入したんだし、 なにか出来ないかな？ …赤と緑…？？ ZABBIX Munin 見ていたテレビから 着想(インスパイア！) ビビッと きました！
- 50. ZABBIX × Munin • munin-node のデータを ZABBIX で読めたら… – リソース監視の精度向上 – アラートの精度向上 – これまで Munin で作成した資産の継続利用 ZABBIXであれば、数十秒単位の監視も行える ことを実績として確認済み。環境を一気に ZABBIXに移行する事も考えたが、一方、 Muninの監視体制（プラグインの拡張や対応 ノウハウ）も捨てがたい。再設定も面倒…。
- 51. やってみた 既に munin-node が入っている環 境には zabbix-agentd の追加セッ • ノード側の手順 トアップのみ。 – 1. munin-node のサーバに zabbix-agent を入れる – 2. zabbix_agentd.conf に UserParameter 追加 UserParameter=munin-node[*],/usr/local/bin/muninwalk $1 $2 –z $ muninwalk localhost load ※ muninwalk … munin-node の CLI localhost::load.load = 0.47 $ muninwalk localhost cpu https://github.com/zembutsu/muninwalk localhost::cpu.user = 99019422 localhost::cpu.nice = 258760164 localhost::cpu.system = 56428719 拙作の munin-node からデータを localhost::cpu.idle = 10082507505 localhost::cpu.iowait = 26402174 取得するコマンドラインツールと localhost::cpu.irq = 299767 localhost::cpu.softirq = 2369273 連携させました localhost::cpu.steal = 0 $ muninwalk localhost if_eth0 localhost::if_eth0.down = 158787814213 localhost::if_eth0.up = 123538652259
- 52. ZABBIX の作業 あとは、ZABBIX側でテンプレートを作 成します。Type”Zabbix agent”で、先 • テンプレート作成 ほど定義した情報を取得します。 引数１：ホスト名 – “Template Munin Linux” 引数２：muninwalkで取得したい munin-node の項目 • Item 例：Load Average
- 53. グラフの定義 • Graph 例：MySQL ※色も見た目も Munin と同じに設定 あとは、集めたデータを元にして、 Muninが生成するグラフと同じ配色 のグラフを定義します。
- 54. 最後にMunin風Screen作成 • Screen: Munin Style View 作成 & カスタムグラフ こんな感じで、Muninが生成する グラフ風の Screen (グラフや文字 の集合テンプレート ) を作成
- 55. 例えば、MySQLのクエリ Munin Zabbix
- 56. MySQLのスループット Munin 一部のグラフは、見やすくなるよう調整 Zabbix
- 57. DNSのクエリ Munin Zabbix
- 58. HDDのInput/Output状況 Munin グラフの描画の仕方がMuninとZABBIXで は違うため、ものによっては見方が変わ るものもあります。 Zabbix
- 59. Load Average Munin Zabbix
- 60. interrupts and context switches Munin 瞬間値が変動するものであれば、特に効 果を発揮できます。スパイクの特定精度 がMuninよりも高まります。 Zabbix
- 61. 自作プラグイン(AWS料金計算) Munin Muninで作成したプラグインのデータ を、そのままZABBIXに取り込めます。 ※ https://github.com/zembutsu/AWS-EstimateCharge Zabbix
- 62. Template Munin Linux 需要ありそうなら、この munin & ZABBIX用のテンプレート公開も 考えています。
- 63. ここまでのまとめ セーブしますか？ ○ はい × いいえ • ZABBIXとMuninのドッキング – サービス品質向上のために、更なる監視精度の向上 – ZABBIXとMuninは共存出来る！ お互いの良いところを取り込み 出力200%の成果を得られます!! • アラートや、細かな監視は ZABBIX （を目指し、調整中・・） – 期日指定のグラフ描画 – 自動的に流れるグラフなど、ZABBIX で視認性向上 • グラフの一覧性や比較のためには Munin – トラブルシュート時の複数サーバ比較や トレンドの監視には Munin は最適 – ただし、運用の属人性は発生
- 64. 5 まとめ /5 MEMORIES OF YOU
- 65. まとめ • サービスレベル向上は、時間との戦い – リソース監視は有効 まずは Munin が手軽 – 短時間での対応能力向上のために • サーバリソース … Munin を使い始める • ネットワーク機器 … ZABBIX を使い始める – 更なる向上のためにはドッキングが有効 • ZABBIX(赤)とMunin(緑) の連携を模索中 • 赤 × 青 もあるかも…
- 66. References • Munin 詳細は、他のスライドをご覧下さい（ ＾ω＾） http://slideshare.net/zembutsu/ 最後までご覧いただき、ありがとうございました。