現在位置: ホーム / みらくるブログ / OpenStack Summit Tokyo 2015 聴講レポート ~ユーザ事例でHatoholが紹介されました!~

OpenStack Summit Tokyo 2015 聴講レポート ~ユーザ事例でHatoholが紹介されました!~

今秋、東京 品川で開催されたOpenStack Summitにて、モニタリングを主体に聴講した内容をレポートします。OpenStack運用では、ログマネジメントが喫緊の課題か。

みなさま、はじめまして or こんにちは。テクニカルアライアンス部の佐藤剛春です。近年は監視システム関連の仕事に携わっております。今年2月に開催されたOpenStack Days Tokyo 2015では、OpenStack運用管理についてお話させていただく機会をいただきました。

さて、今秋のOpenStack Summitは、品川にあるグランドプリンスホテル新高輪で開催されました。会場は日本ですが(日本語枠を除く)セッションは英語のみで実施され、非常に英語を苦手としている私は苦闘する羽目に陥りました。

今回のOpenStack Summitはモニタリングを主体に聴講しました。内容は様々でしたが、ログ管理について多く言及されていました。OpenStackを運用すると数多くのソフトウェアから出力される大量のログを相手にすることとなり、これらのマネジメントが課題となることが分かります。

 

■ログマネジメント手法

ログ管理にあたり、多く取り上げられていたのがELKです。ELKはElasticsearch, Logstash, Kibanaの頭文字をとったものです(ヘラジカではないのでした)。Logstashで各サーバからログを収集し、Elasticsearch + Kibanaで解析を行います。

29日のセッション『Monitoring Swift With Elastic Search』では、ELK + Swiftの障害追及の実演が行われました。Swift管理下のオブジェクトを人為的に削除して「障害」を発生させ、その原因をログから調べるという内容です。Kibanaのインターフェースで検索対象を絞りこみ、最終的に「いつ」「どのIPアドレスから」該当オブジェクトが削除されたのかを特定しました。障害解析にあたっての使用イメージを明確にすることのできるデモでした。なお、セッションの様子はYouTubeにて確認可能です(執筆時、以下同様)。


ログ収集にLogstashではなく、Fluentdを使用するパターンも示されました。29日のセッション『Fluentd vs. Logstash for OpenStack Log Management』では、Fluentdのforward機能を使用し、複数のデータ送出先Fluentdを用意することで、Active-Standby構成(フォルトトレラント向け)のみならずActive-Active構成(ロードバランス)をとれることが説明されました。

Logstashを使用した場合はlumberjackを使用したActive-Standby構成に限られ、高速化に際してFluentdにアドバンテージがあるようです。なお、ログは最終的にInfluxDB, Elasticsearchに集積されるように図示されていました(プラグインと設定が必要です)。したがって、Kibanaからの検索も行えることになります。

また、ログをFlulentdへ送る際にrsyslogを経由する方法と、機能提案(ブループリント)が提示されたoslo_logを使用する方法が説明されました。oslo_logを使えばログのパースが不要となり、使い勝手が非常に良くなるようです。説明資料は次のURLで参照可能です。

 

■モニタリング関連OpenStackプロジェクト

もちろん監視はログに限ったものではありません。monitoring-as-a-service、Monascaの開発が活発に進められており、2つのセッションで機能やアーキテクチャに関して解説されました。スケールアウト可能、マルチテナント対応RESTful API実装済で、高い拡張性と相互運用性を持っているとのこと。また、監視システムが停止して障害検出ができなくなることのないよう、フォルトトレラント機能(資料上はHigh Availabilityと記載されています)も実装されているとのことです。セッションの様子はYouTubeにて確認可能です。


モニタリング関連OpenStackプロジェクト001


モニタリング関連OpenStackプロジェクト002

また、さらに強化したモニタリング実装も紹介されました。MonascaとCeilometerとの組み合わせで実現するもので、Ceiloscaと命名されているものです。高可用性、パフォーマンス向上、データ統合等を目的としたもので、検索速度は最大でCeilometer単体の18倍速と発表されていました。また、データ量によってはCeilometerでの検索では失敗する場合でも、Ceiloscaであれば実行可能なパターンもあるそうです。

CeilometerからMonascaへのデータ送信にはCeilometer Publishing Agentを、CeilometerからMonascaに対する検索にはCeilometer Monasca Storage Driverを使用するとのこと。セッションの様子はYouTubeにて確認可能です。


モニタリング関連OpenStackプロジェクト003

ただし、ここまで取り上げた実装を使用するためには複数種のデータベースを扱わなければならないなど、少々ハードルが上がってしまう印象を受けました。

 

■OpenStackシステム管理ユーザー事例

NTTソフトウェア様による日本語セッション『OSSで作るOpenStackの監視システム(英訳: Monitoring system for OpenStack, using a OSS products)』では、実例としての監視システムが語られました。構成ソフトウェアはELK + Nokra + Zabbix + Hatoholです。

重要な点として、ハードウェアの監視と仮想マシンの監視を分けて考えることが挙げられました。確かに監視対象が全く異なりますから、少なくとも適用テンプレートは分割することは行われることになるでしょう。

加えて、監視対象ホスト(仮想マシン)がシャットダウンされた場合の対処として、network discoveryを使用する方法が挙げられました。監視対象ホストと通信が途絶したことを検知した際に、ホストの登録を削除するアクションを設定することになります(アクションのイベントソースとして「ディスカバリ」を選択する必要があります)。

OpenStack環境のログ監視には、ELKとNorikraの2本立てで使用しているとのこと。ELKではnortificationに不自由するため、Norikraでログの出現パターンによりZabbixに通知を出し、それを起点としてZabbixのイベント生成を行わせるそうです。

また、数多くのZabbixサーバで生成されるイベントをまとめるため、Hatoholを活用されるとのことでした。説明資料は次のURLで参照可能です。

network discoveryを使用したホストの自動削除を設定した場合、多くの場合は一時的に「Agent is unavailable.」状態となります。加えてイベント「Zabbix agent on {HOST.NAME} is unreachable for 5 minutes」が発生すると思われます(これらはディスカバリルールの間隔との関係によります)。このイベント生成が許容される環境であれば、説明された手法が活用できると感じました。

 

■OpenStack監視用MIRACLE ZBXテンプレート

ミラクル・リナックスは日本仮想化技術株式会社様(以下VTJ様)と協業し、VTJ様が公開されているOpenStack構築手順書に監視環境構築手順を寄稿しています。この中で使用しているOpenStack環境を監視するためのMIRACLE ZBX用テンプレートも公開しています(Zabbixでも全く同様に使用可能です)。

こちらのテンプレート、執筆時点ではIcehouseからKiloまで対応しています。そろそろ、先日リリースされたLiberty向けにアップデートしなければならないなと感じているところです。しばしお待ちを!