OSC Tokyo 2016/Fall

Tags:

★自己紹介と利用ツール
・GMO
Nagios / Zabbix / Colectd
ZabbixはAPIベースでの監視ができる

さくら
HobbitやSimon
→Zabbixに移行
"自動化"がし易い（Action Script）

仮想化技術
OSC監視ツール
ノウハウやドキュメントが多い
fluentd / erastic search
kibana / zabbix

ミラクル
メインはZabbixを使ってる
ツールに対する監視方法の考察

Nagiosは英語のドキュメント。ヨーロッパから生まれた。からアメリカでは知られてない？

★上手く行っていないこと
Hobbitでの監視サーバ7台
Zabbixだと監視項目が10-20万
監視対象数と項目数が膨大になると動作が遅くなる
マシンスペックにも問題
ボトルネックはデータベース
→MySQLのチューニングが大事（HouseKeeper）
項目数、間隔、対象を適切に絞る
Zabbixのマシンスペック（性能）問題
→Nagiosはそれがない（軽いね）
仮想OSたとZabbixはきつめではある
---DBのボトルネック、ハードウェアのボトルネック
---完全な運用ノウハウがOpenStackでも活用されるべき

★何を正解かだと考えて運用しているのか
サービスダウンが一番まずい
チケットを発行して素早く処理する  Hatfool
アラートポイントを設定して最初の担当者にわかるように、ノウハウを集める
---
ハードウェアの故障だけで人間が動くようにする
ユーザの行動から自動で制限をかけるようにする
ハードウェア対応は人間で
---
ユーザによって異なる
複数のサービスを関するのに一台の監視サーバだと出来なくないが管理が大変になる。
パフォーマンスがダウンする。適度に分ける。分散させる。Hatfool一番上に置くと様々なツールがうまく使える。
---
複数のZabbixを一度に監視するにはHatfoolいい。

★最近の課題やトピック
適材適所でツール活用
データドックの利用で長期保存
Docker/PaaSのコンテナ監視
---
負荷によってサーバの台数が変化。
ZabbixのAutoDiscoveryで自動登録。
最初に設計をしっかりする！！
→後付だと自動化を想定しにくくなる
---
仮想ネットワークの監視
SDMはいいけどそれなしで何か出来ないか
---
壊れそうなときにアラート（線形代数の知識）
Zabbixはログ監視は苦手
情報がどこにあるか示すツール（Hathoolでもいいかも）

情報発信／情報収集
fluentd  /  toolの知見を広げてベストプラクティスを提示できるとよい

Hathoolはいいぞー