OSSで作るOpenStack監視システム

Editor's Notes

• #3: 本日のアジェンダです。 はじめに 物理と仮想それぞれのサーバー監視に使える小ねたを。 　仮想監視でzabbixが増えると、画面も増えるので統一したい ログ監視システムについて
• #4: 弊社NTTソフトウェアではOpenStackのEssex版から研究所の裏で開発に携わっておりまして、 開発・試験・運用で監視と“特にログ監視・解析"が重要でした。 グループ内でも、OpenStackのログ監視大変だという声が出ており、 弊社ではこの課題解決するためにOSS製品を組み合わせて"安く"実現できたので ご紹介します。この課題をOSS製品の組み合わせで解消したので、ご紹介いたします。
• #5: そもそもOpenStackの監視システムに何が必要かを出してみました。 共通の項目として、・・・ 物理側の監視には、・・・ 仮想側の監視には、・・・ ログ監視には、・・・ が必要かと思われます。
• #6: これらをOSS製品の組み合わせで実現させたのでご紹介させていただきます。
• #7: OpenStackを１アプリケーションとして考える 1個のアプリケーションとして考えると簡単です。 　IaaSだから難しそうとか考えずに、「ただのアプリケーションだから、こういうものを見ないといけない」があるはず。 　普段アプリケーション開発したら監視どうやってます？ほぼその通りで大丈夫です。 物理監視と仮想監視を一緒に考えない。 　物理はあれを見て・・・仮想はあれを見て・・・あれ・・・この項目は物理側だよな・・・仮想側じゃないよな・・・？って考えると混乱します。 　きっちり分けて考えましょう。 きっちり分けたら、物理側の障害は物理側で、仮想側の障害は仮想側で検知しましょう。 ログ監視はEFK stack + Norikra + zabbixです。 本日は是非これを覚えて帰ってください。
• #8: まず、色々とお話を始める前に、物理と仮想のレイヤをきっちりと別けます。 物理側といったらここ 仮想側といったらこの部分になります。
• #11: 一般的なAPPの監視に必要なものは当然必要です。 それ以外にOpenStackだからこそ必要なものとしては、 以下のミドル　サービス監視　リソース監視です OpenStackは様々なmiddlewareの集合体です。 それぞれのmiddlewareが機能しなくなると、OpenStackに悪影響を与えるためしっかりと見張りましょう。 ミドルウェアや各プロセスが正常に動いているように見えても、実はサイレント故障が起きており正常動作していないときがあります。 OpenStackとして正常に動作しているかを確認しましょう。 仮想資源が枯渇すると、上で動いているVMに影響が出ることがあります。 収容設計等を見直す機会にもなりますので見ておいたほうが良いでしょう。
• #12: 作り込みは最低限だけということで、 公開されているものを有効活用しましょう ミドルウェア・サービスともにsensu用やnagios用が監視スクリプトを公開しているのでそれを使います。 その際に使う機能としてUserParameter機能があります。
• #13: これは、スクリプトの実行結果を監視アイテムとして取得するものです。 nova- hypervisor-showの結果から、起動しているvm数の情報を取得させています。 この仕組みを使えば、ミドルウェア・サービスともに必要な情報が取得できます。
• #14: 物理側はこれくらいです。 他は難しく考えず従来どおりの監視で大丈夫です。 続いて仮想側の監視です。 　仮想マシンは作っては消え作っては消えるので、そのたびに監視設定をしていたのでは非効率です。 　自動化しましょう。 仮想資源の故障をどうやって見つけるか。
• #15: まずは前提として、監視サーバをどこに配置しますか。 方法としては 物理上のzabbix-serverで一元管理する方法と Project毎にzabbixを設置する方法があります。 うちでは、Project毎に使う人が違うことを想定してzabbix-serverを分けています。 こうすることで、各Project管理者は自分のProjectのzabbixを見れますし、zabbixの収集詰まりも抑えられます。
• #16: 監視することはできても、数十台～数百台のマシンに監視設定を適用させるのは大変ですよね。 人手でちまちまと設定反映させていくのは大変なので、自動で監視設定してもらいましょう。 zabbixの自動登録を使います。 この設定をしておくと、zabbix-agentからzabbix-serverに対して通知を飛ばします。 通知受け取ったzabbix-serverは、あらかじめ設定した条件にしたがって監視設定を反映させます。 　　・metadata 　　　zabbix-agent.confのmetadata="<foo>" 　　　zabbixの自動登録でmetadataが"foo"ならテンプレート"bar"を適用とする。 　　　サーバ構築の際にansible,chef,puppet等の構成管理ツールでzabbix-agentを埋め込むか、GlanceのImageにあらかじめ組み込んでおくと良いでしょう。 　　　用途ごとにmetadataの設定を変えてあげればOK
• #17: Zabbix-server側に、metadataが**だったら、templateは**を適用と設定しておくと、 監視対象が増えていっても、同じ監視設定が勝手に適応される。 仮想環境の監視でもこれは使える。 監視対象ノードが増えていっても設定するのは最初の１回だけ。 　そのノード用のテンプレートを作って自動登録の設定をするだけ。 仮想マシンの場合、GlanceのImageにzabbix-agentと設定を事前に埋め込んでおくとベスト。
• #18: 増えるVMの監視追加は前述の自動追加を使う。 問題は、監視対象削除の方 　VM一覧とzabbixの監視ホストの突合せを定期的に行って、不一致があれば対処するツールを作っている人もいるようですが、 　ここでは単純に、一定時間見えなくなったら消す。という方法にします。
• #19: マシンの電源OFFすると、zabbixへアラートがあがります。 障害起因で落ちたなら、アラートを無視しないで復旧にさせます。 自分で電源落としたもしくは削除したなら、そのアラートを無視しますね。 一定時間放置されていたら、もう使わないと判断して、監視対象から外す。 直さないってことは使わないってことですから。再度使うにしても、自動登録が動いて監視対象に再設定されます。 ネットワークディスカバリ機能で指定したセグメントでIP疎通取れるかをチェック 今まで登録されていた→消えた。となれば監視設定から外す。
• #20: 仮に故障箇所がcinderが作ったvolumeだけとします。 矢印のようにVMがCinderのvolumeをマウントしていたとします。 ある日突然CinderのVolumeがここだけ壊れました。 他のVMのマウントしているvolumeは壊れてないです。 さて、これどうやって検出します？
• #21: 監視項目がこんな風にあったとすると、
• #24: 右側の方法でzabbix-serverを配置していくと・・・
• #25: Project毎にzabbixが増えるので気が付いたらタブが恐ろしいほど増えていることがあります そこでHatoholを使ってzabbix画面を一元化する方法をオススメします。 コレを使うと、
• #26: Zabbix1の情報 Zabbix2の情報のように1画面で複数のzabbixの情報を取ってこれるので画面の一元化に一役買っています。
• #29: 最後にログ監視についてです。 収集 可視化 解析の効率化 自動で解析　通知をやって欲しいですね。
• #30: ログ監視に使うものです。 検索エンジンにElasticsearch ログ収集にFluentd ログ可視化にKibana いわゆるEFK stackです ログ解析にNorikra 異常通知にZabbixを使っています。
• #31: Kibanaで可視化できる。やったー。 で終わってませんか。 グラフで見れば違いがわかって一目瞭然とか思っていませんか。 そこで登場するのがNorikraです。
• #32: Norikraって何？って思っている人が多いと思うので、簡単にご紹介します。 要約すると、スキーマレスでSQLストリーミング解析ができるOSS製品です。 ちなみにNorikraの名前の元は、日本の飛騨山脈(北アルプス)の乗鞍岳のようです。
• #33: 　▲Norikraの内部では、EsperTech Inc.がOSSとして公開しているEsperを利用しており、 　　CEP (Complex Event Processing)エンジンが組み込まれている 　　 　　流れてくるログを一定期間のみ抽出→解析する→捨てる→ループ 　　鹿威しのイメージ 　▲SQLストリーミング解析 条件式はSQL文で書くので、 　　SQL強い人ならなんでもできる
• #34: OpenStackの動いているサーバにFluentdを入れて、ログを収集します。 収集したログは監視サーバ内のFluentdへ転送し、Elasticsearch Norikra Flileへ転送します。 Elasticsearchへはログ可視化のため Norikraへはログ解析のため 　解析後はzabbixへ通知します。 Fileは念のため 　
• #35: Norikraの仕組み作りはやれば誰でもできますが、使い物になるかどうかはNorikraルールがどれくらい作りこめているかに比例します。 このルールを作るためには、「ログA+ B =事象Cである」。や「このログがこれだけ出たらおかしい」や、「単体では問題ないログでも、他と組み合わせると異常が発生している。」など、 ルールを作るための大量のデータが必要になります。 ただ作るだけで即実用的かといわれるとそうではない。 如何にしてルールを作るかが重要になります。 我々はE版からの経験で、エラーログリストを持っています。 このエラーは無視できるもの、や、このエラーは絶対に無視できないなど。 これを元にしてルール作りに取り組んでいます。 各バージョン150件ほど。
• #36: 実際に具体例を使ってEFK+NZをご紹介したいと思います。 ・kibanaで表示しているグラフの変動を検知 ・パターン化された障害を検知
• #37: Keystoneはdos攻撃を検知する方法を持っていないのでこれを検知させます。 Kibanaで見るとグラフが変動するので、 この「グラフが変動したら通知する」をやってみます
• #38: Keystoneはdos攻撃を検知する方法を持っていないのでこれを検知させます。 Kibanaで見るとグラフが変動するので、 この「グラフが変動したら通知する」をやってみます
• #39: Norikraのルールに「単位時間当たり同一IPアドレスから401エラーで○回以上アクセスが起きたら」と書いてあげると、 このあとkeystoneへ偽のuser名でtokenを取りに行きます。 辞書攻撃やブルートフォースアタックを受けたと想定してください。 そうするとこのNorikraのルールに一致するので、zabbixへ通知が飛びます
• #40: Zabbixへ通知が飛んでいく。 サーバー監視もzabbixで見るので、ログ監視も同じ画面で監視できます。 運用者は主にこの画面をいていれば良いでしょう
• #41: あるログAとあるログBが同時期に出たら、この障害パターンですと通知してくれます。 手動で解析すると、 たくさんのログファイルを見て、lessやgrepを駆使して解析していると思います。 これには一定のスキルが必要になるので、簡単なエラー事象の解析のためにハイスキルナ人を割り当てるのはナンセンスです。 これの解析通知を自動化します。
• #42: メモリを大量に使うFlavorでVMを起動させます。
• #43: No valid host was found. There are not enough hosts available. 利用可能なホストが見つかりませんでした。 え？何がわるかったの？
• #44: 詳細見ても、原因書いてない。 ログを見ればわかりますけど、利用者はログなんて見れないのでどうしようもない。 電話がかかってきます。 「VMが作れなかった。画面を見ても何がわるのかわからん」と。
• #45: Nova boot error type2 Type2 は flavorのmemoryを満たすホストがなかった。とすれば解析の手間が簡略化されます。 「我々のようにopenstackのログを熟知しているもの」がこのルールを作れば、 　利用者や一部スキル不足な運用者等でもログファイルを読むことなく原因がわ かります。
• #47: ログ監視システムのデモをNTTブースで29日の○時からやります。 もしご興味あればマーケットプレイスのNTTブース(S14)までお越しください。
• #50: ライセンス条項 Elasticsearch logstash Kibana https://www.elastic.co/legal/trademarks OpenStack http://www.openstack.org/brand/openstack-trademark-policy/ Zabbix http://www.zabbix.com/jp/policy.php