検索
連載

今、話題の監視ツール「Sensu」とは？――基本的な構成、監視の仕組みを理解する：Sensuで始めるクラウド時代のシステム監視（1）

新たなクラウド監視ツールとして注目され始めている「Sensu」の活用方法を解説する本連載。今回は、Sensuの基本的な構成や監視の仕組み、利用するメリットなどを紹介します。

Share
Tweet
LINE
Hatena
「Sensuで始めるクラウド時代のシステム監視」のインデックス

連載目次

監視プラットフォーム「Sensu」とは？

　「Sensu」は、Sensu,Inc.（※）が開発している、「Ruby」製のオープンソース監視プラットフォームです。「Nagios（ナギオス）」の問題点を解決する目的で、2011年にSean Porter氏らを中心に開発が開始されました。

　「Sensu（扇子）」という名前は、竹を活用する日本文化と、単機能をうまく組み合わせるUNIX哲学から影響を受けたそうです。ちなみに、現在の最新バージョンは「v0.27.0」で、現在も活発に開発が進められています。


【※】2017年1月30日にHeavy Water Operationsから社名を変更。



Sensuの設計思想

　そもそも、Sensuが誕生するきっかけとなったNagiosの問題点とは何でしょうか。Nagiosは、監視サーバが監視対象となるクライアントの情報を持っている必要があります。新たなクライアントを監視するには、設定ファイルに追記し、サービスをリロードする必要があるため、クラウドのように頻繁にシステム構成が変更されるような環境には不向きだったのです。

　そこで、Sensuは最初からクラウド環境での利用を想定して設計されました。下記のような機能がコンセプトになっており、サーバ数が頻繁に増減したり、サーバが自動でデプロイされたりするような環境にも柔軟に対応することが可能になっています。

監視クライアント（エージェント）を自動で監視サーバに登録、削除できる

  • 監視サーバ側の設定変更やリロードは不要
  • 監視クライアントにエージェントをインストールするのみ

設定ファイルはJSON形式で、自由に分割することができる

  • 「Chef」などの構成管理ツールと親和性が高い
  • 「sensu-chef」や「sensu-puppet」を標準で提供

Nagiosの監視プラグイン「Nagios Plugins」と互換性がある

  • Nagiosから移行する際、既存の資源を活用することが可能

監視サーバやミドルウェアをスケールアウトできる

  • 冗長化や大規模な環境での導入が可能

標準でRESTful APIを備え、ドキュメントも充実している

  • フロントエンドやツールなどとの連携が可能

Sensuの仕組みと基本的な構成

　Sensuは「sensu-server」（監視サーバ）、「sensu-client」（エージェント）、「sensu-api」（RESTful API）の3つのコンポーネントで構成されています（図1）。sensu-serverとsensu-clientの通信には、メッセージ指向ミドルウェアの「RabbitMQ」、監視対象や監視結果の保存にはKey-Valueストアの「Redis」を使用しています。なお、Sensu v0.19.0からは、Redisを通信にも使用できるようになりました。

図1
図1　Sensuは監視サーバ、エージェント、APIの3つのコンポーネントで構成されている（出典：Sensu, a monitoring framework | PorterTech）

　ここで、Sensuにおける監視の流れを簡単に説明しておきましょう。Sensuにおける監視の流れは以下のようになり、データのやりとりはほとんどがJSON形式で行われます。

（1）sensu-serverからsensu-clientに対して監視の実行が指示

  • 指示は、RabbitMQの各sensu-clientのキューにキューイングされる

（2）sensu-clientはキューイングされた監視を実行し、結果をsensu-serverに送信

  • sensu-client上でコマンドやスクリプトを実行し、出力と終了ステータスを取得する
  • 監視結果はRabbitMQを通じてsensu-serverに送信する

（3）sensu-serverは受信した監視結果に応じて、通知などの処理を実施

  • 終了ステータスは「0：OK」「1：WARNING」「2：CRITICAL」の3つに分類される

　監視やその結果に応じた処理を行うプラグイン（スクリプトなど）の設定はsensu-server上で定義し、実際に実行するスクリプトはsensu-client上に配置します。監視の設定には「どの役割のsensu-clientで実行するか」が定義されており、sensu-clientは自分の役割（Webサーバ、メールサーバなど）に応じた監視を実行します（役割は複数定義、設定できるため、n対nの関係になっています）。

　また、sensu-client上で設定を行い、独立して監視を実行できるスタンドアロン機能もあります。クライアント独自の監視を行うことができ、結果はsensu-serverに集約されるため便利です。

　Sensuはこのような構成になっているため、新たなsensu-clientを追加した場合でも、sensu-serverの設定を変更することなく監視を開始することができます（監視項目の追加など、設定を変更した場合はサービスのリロードが必要）。

Sensuのダッシュボード「Uchiwa」

　Sensuのダッシュボードには「Uchiwa」というしゃれた名前が付けられています。UchiwaはSensuとは別のプロダクトですが、両者を組み合わせて使うことが一般的です（2014年末までは「sensu-dashboard」がありましたが、既にサポートが終了しています）。

　Uchiwaでは、発生中のアラートやクライアントと監視項目の一覧など、Sensuの情報を一元的に閲覧することができます（設定の変更などはできません）（画面1）。複数のSensu環境にも対応しており、大量の情報をフィルタリングして見やすくすることも可能です。また、メンテナンスなどの際にアラートを一時的にサイレントにしたり、監視クライアントを削除したり、アラートを停止したりするなど、管理者向けの機能も備えています。

画面1
画面1　Sensuの情報を一元的に閲覧できる「Uchiwa」（出典：Uchiwa | Simple Dashboard for Sensu）

Sensuを使うメリットとデメリット

　最後に、Sensuを利用する際のメリット／デメリットを整理しておきます。Sensuの利用で得られるメリットには、以下のようなものがあります。


クラウド環境において、監視に関わるメンテナンスコストを少なくできる

  • インスタンスの追加、削除に合わせて、自動的に監視を開始、停止できる
  • 監視項目などの設定はsensu-serverに集約されており、管理しやすい

ドキュメントやプラグインが充実しており、比較的容易に導入できる


　一方、Sensuには以下のようなデメリットがあることも覚えておいてください。


使用するミドルウェアの知識が必要になる

  • Sensuだけでなく、RabbitMQとRedisを構築、運用する必要がある
  • ミドルウェアを冗長化したり、スケールアウトしたりする場合、比較的高度な技術を求められる

リソースなどのメトリクスを収集できるが、保存したり、可視化したりする機能を備えていない

  • 死活監視だけでなく、メトリクスの収集も可能だが、別途保存先が必要である
  • InfluxDB＋GrafanaやElasticsearch＋Kibanaの組み合わせが一般的である

終わりに

　今回はSensuの概要と基本的な構成、監視の仕組みを説明しました。監視クライアントの自動登録や構成管理ツールとの親和性の高さなど、他の監視プラットフォームと比較して、クラウド環境に適していることがご理解いただけたと思います。

　次回以降は、Sensuのインストールや設定、メトリクスの収集と可視化、スケールアウトと冗長化など、より具体的な内容を説明していきます。実際の運用で得られたノウハウの紹介なども行う予定ですので、ご期待ください。

参考文献

　本稿の執筆に際し、Sensu開発者のSean Porter氏のブログや講演資料、Sensuのソースコードを参考にさせていただきました。



筆者紹介

堀内 晨彦（ほりうち あきひこ）

生まれも育ちも香川県。香川大学大学院 情報科出身。学生時代は研究の傍ら、勉強会やコミュニティー活動に積極的に参加し、「Sensu Deep Talks」などを主催。2016年4月からは上京し、ICT企業でベアメタルクラウドの開発に従事。趣味は料理とカメラ。

Webサイト：https://hico-horiuchi.github.io/


Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る