Ubuntu Weekly Recipe

第361回Sensuでサーバーのリソースを可視化しよう

(読者がじゃぶじゃぶ可視化したくなるようなメトリクス心を煽りまくるリードテキスト。)

迫り来るクライシスに備えて

Recipeの第359回では水野さんが「Muninでサーバーのリソースを可視化しよう」と題して、継続的なメトリクスの収集と可視化もまた、障害の予防や振り返りにとって重要であることを説いてくれました。

ロードアベレージやメモリ・ディスクの使用量など数値化でき、その時間変化が重要な情報に対して、Muninはとても便利なツールです。しかし世の中にある監視したいものすべてが数値化できるとは限りません。サービスの死活、ファイルのチェックサム、ハードウェアのステータス、うつろいやすい彼女[1]の気持ち。その一瞬の輝きが重要な定性的な情報を、継続的に監視したい場合もあるでしょう[2]⁠。

さらに最近はクラウド上に何台ものインスタンスを立ち上げたり、そのインタンス上でもDockerやLXCで複数の仮想環境を立ち上げることも一般的になってきました。もちろん仮想環境自身も監視対象になり得ますので、モニタリングツールのエージェント・クライアントをインストールすることになるでしょう。しかしクライアントをインストールするたびに、モニタリングサーバーの設定を書き換えるのは不便です。というか忘れてしまいそうです。

そんな方に向けて、今回は「Sensu」を紹介します。

モニタリングフレームワーク「Sensu」

今回紹介するSensu注3はRuby製のモニタリングフレームワークやモニタリングルーターと呼ばれるツールです。情報を収集するSensu Serverと、監視対象のサーバーにインストールするSensu Clientに加えて、収集した情報を保持するRedis、RESTインターフェースを提供するSensu API、これら各コンポーネント間のメッセージ通信を担当するRabbitMQからなり、以下のような特徴を持っています。

  • 設定ファイルはすべてJSONで小分けも可能
  • 監視やメトリクス用のプラグインは好みの言語を利用できる
  • NagiosのNRPEプラグインも流用できる
  • APIやExternal Inputといった機能で外部からの操作が可能
  • 監視結果をIRCやSlackといった外部のサービスへ整形して転送する機能
  • SSLを用いたセキュアな通信
  • スケールアウトや多重化が容易な自由度の高いコンポーネント構成

SensuそのものにはWebブラウザー向けのフロントエンドはありません。以前はSensu Dashboardと言うSinatraを使ったフロントエンドが存在していたのですが、現在はGo言語とAngular JSを使ったUchiwa注4の利用が推奨されています。

また収集したデータをグラフ化するには、各種時系列データベースや可視化ツールを使う必要があります。

Sensuそのものが提供するのは、モニタリングの「コア」の部分だけです。言い換えるとこのコアに、他のツールを組み合わせることで、より自分好みの監視システムを構築できるということです。

図1 結果的に今回はこういう画面になる
図1 結果的に今回はこういう画面になる

Sensuのセットアップ

Sensuには最初からChefのクックブックやPuppetのモジュールが用意されているため、これらの構成管理ツールを使ったインストールが一般的です。ただし今回のRecipeでは、何をどこにインストールするか把握するためにも、手作業でパッケージ一式をインストールする方法を説明します。

ちなみにここではSensu ServerやAPI、Uchiwaなどメトリクスの収集や監視、視覚化を担当するマシンを「サーバー⁠⁠、監視対象のマシンを「クライアント」と呼ぶことにします。またサーバーにもSensu Clientをインストールして自分自身を監視させます。

サーバーの下準備

まずはSensu Server側のセットアップ方法から説明しましょう。クライアントやサーバーとRabbitMQはSSLで通信します。そのためはじめに証明書を作っておきます。

$ cd /tmp
$ wget http://sensuapp.org/docs/0.16/tools/ssl_certs.tar
$ tar -xvf ssl_certs.tar
$ cd ssl_certs
$ ./ssl_certs.sh generate

serverディレクトリにRabbitMQサーバー用の証明書が、clientディレクトリにSensu用の証明書がそれぞれ作成されます。

次にRabbitMQとRedisをインストールします。

$ sudo apt install rabbitmq-server redis-server

さらに先程作成した証明書を使って、RabbitMQのSSLの設定をしましょう。

$ sudo mkdir -p /etc/rabbitmq/ssl
$ sudo cp sensu_ca/cacert.pem server/cert.pem server/key.pem /etc/rabbitmq/ssl

/etc/rabbitmq/rabbitmq.configを作成し次のように編集します。

[
    {rabbit, [
    {ssl_listeners, [5671]},
    {ssl_options, [{cacertfile,"/etc/rabbitmq/ssl/cacert.pem"},
                   {certfile,"/etc/rabbitmq/ssl/cert.pem"},
                   {keyfile,"/etc/rabbitmq/ssl/key.pem"},
                   {verify,verify_peer},
                   {fail_if_no_peer_cert,true}]}
  ]}
].

ここにもあるようにRabbitMQのSSL接続時の待ち受けポート番号を5671に設定しています。このポートのみ、クライアントからアクセスする必要があるため、必要に応じてファイヤーウォールなどの設定を変更しておいてください。SSLではない通常のポートは5672です。こちらは特に設定していなくても最初から待ち受けています。Sensu Serverと同じホストにクライアントも用意する場合は、5672を使うのもありでしょう。また、設定ファイルの最後の「.」をお忘れなく。

RabbitMQを再起動したうえで、Sensu用の設定をいくつか行います。mypassはパスワードです。適宜変更してください。

$ sudo service rabbitmq-server restart
$ sudo rabbitmqctl add_vhost /sensu
$ sudo rabbitmqctl add_user sensu mypass
$ sudo rabbitmqctl set_permissions -p /sensu sensu ".*" ".*" ".*"

Sensuのインストール

今回利用するsensuパッケージは、Sensu Server、Client、APIがすべて一緒になっています。そのためサーバーであってもクライアントであってもインストールするパッケージは同じです。

Sensu本体は公式が提供しているリポジトリを利用します。

$ wget -q http://repos.sensuapp.org/apt/pubkey.gpg -O- | sudo apt-key add -
$ echo "deb     http://repos.sensuapp.org/apt sensu main" | sudo tee /etc/apt/sources.list.d/sensu.list
$ sudo apt update
$ sudo apt install sensu

sensuパッケージは必要なRubyやそのライブラリなどもセットで/opt/sensu以下にインストールします。メトリクス収集用のスクリプトなどでRubyを使う場合は、この/opt/sensu以下にインストールされた組込みRubyを使えたほうが便利です。そこで、/etc/default/sensuの値を変更しておきましょう。

$ sudo sed -i 's/^\(EMBEDDED_RUBY=\)false/\1true/' /etc/default/sensu

Sensu ServerもSensu ClientもRabbitMQから見ると「クライアント」です。先程作った証明書をコピーして、RabbitMQに接続するための設定を行います。別ホストにインストールするクライアントの場合はなんらかの方法で作成した証明書を移動してください。

$ sudo mkdir -p /etc/sensu/ssl
$ sudo cp client/cert.pem client/key.pem /etc/sensu/ssl/

/etc/sensu/conf.d/rabbitmq.jsonファイルを作成して、以下の内容を記述してください。

{
  "rabbitmq": {
    "ssl": {
      "cert_chain_file": "/etc/sensu/ssl/cert.pem",
      "private_key_file": "/etc/sensu/ssl/key.pem"
    },
    "host": "localhost",
    "port": 5671,
    "vhost": "/sensu",
    "user": "sensu",
    "password": "mypass"
  }
}

hostとportはRabbitMQサーバーのアドレスとポート番号を指定します。RabbitMQとSensu Serverが同じホストであれば上記のようにlocalhostでつながりますし、別のホストであればそのアドレスを指定する必要があります。vhost、user、passwordはrabbitmqctlコマンドで指定した値です。

Sensu Serverのセットアップ

ここまででインストールしたSensuがRabbitMQとSSL経由で接続できる設定までは行えました。これはサーバーとクライアント双方に必要な作業です。次にサーバー固有の設定を行います。

まずSensu ServerがRedisに接続するための設定を行います。/etc/sensu/conf.d/redis.jsonを作成してください。

{
  "redis": {
    "host": "localhost",
    "port": 6379
  }
}

次にAPIサーバーの設定です。/etc/sensu/conf.d/api.jsonを作成し、編集します。この設定にもあるように、ポート4567で待ち受けます。外部からAPIを受け付ける場合は、ファイヤーウォールの設定はもちろんのことユーザーやパスワード設定も行っておいたほうが良いでしょう。

{
  "api": {
    "host": "localhost",
    "port": 4567
  }
}

これらは/etc/sensu/config.json.exampleにもあるように、/etc/sensu/config.jsonにまとめて書いてしまってもかまいません。

最後にSensu ServerとSensu APIを起動します。

$ sudo service sensu-server start
$ sudo service sensu-api start

/var/log/sensu/以下にsensu-server.logとsensu-api.logが作成されますので、うまく動かない場合はそちらを確認してください。ちゃんと起動するようなら、サーバー起動時に自動起動するように設定しておきましょう[5]⁠。

$ sudo update-rc.d sensu-server defaults
$ sudo update-rc.d sensu-api defaults

Sensu Clientのセットアップ

次にSensu Clientの設定です。Sensu ClientはRabbitMQと通信できれば問題ありません。よってSensuのインストールと以前に作った証明書のうちクライアント関連の証明書のコピー、rabbitmq.jsonファイルの作成部分はサーバーと同じになります。

クライアント特有の設定として/etc/sensu/conf.d/client.jsonのファイルを作成します。最初のクライアントはサーバー上で動かすことにしましょう。

{
  "client": {
    "name": "sensu-server",
    "address": "localhost",
    "subscriptions": [ "all" ]
  }
}

nameはクライアントマシンを識別するための名前で、addressはクライアントのアドレスです。subscriptionsには任意の文字列のグループ名を指定します。

Sensu Clientは起動すると上記設定ファイルの内容をRabbitMQで通知します。Sensu Serverはこの通知を受けてクライアントを登録し、定期的に死活監視を行います。このためクライアントを追加しても、サーバー側で何がしかの設定を行う必要はありません。

Sensu Serverは監視やメトリクスの収集を行う際の対象をsubscriptionsで指定されたグループで決定します。これについては後ほど説明します。

クライアントを起動してみましょう。

$ sudo service sensu-client start

ログは/var/log/sensu/sensu-client.logです。なおClientはExternal Inputのために3030ポートをlistenしています。自動起動する場合は次のコマンドを実行しておきましょう。

$ sudo update-rc.d sensu-client defaults

ClientはServerに登録されたら、定期的にKeepAliveイベントを送ります。これにより一定期間イベントがこなかったClientに対してはエラーイベントが発生するようになっています。ClientをServerの監視対象から外したい場合は、SensuのFAQにある「How do I delete a client?」を参照してください。

Uchiwaのインストール

冒頭でも説明したようにUchiwaは、Sensu API用いたWebフロントエンドです。Sensu用にリポジトリを追加した環境であれば、そこからパッケージをインストールできます

$ sudo apt install uchiwa

設定ファイルは/etc/sensu/uchiwa.jsonです。既存の設定ファイルを次のように変更してください。

{
  "sensu": [
    {
      "name": "Sensu",
      "host": "127.0.0.1",
      "ssl": false,
      "port": 4567,
      "user": "",
      "pass": "",
      "path": "",
      "timeout": 5
    }
  ],
  "uchiwa": {
    "host": "0.0.0.0",
    "port": 3000,
    "user": "admin",
    "pass": "secret",
    "interval": 5
  }
}

なお、最初の設定ファイルにもあるように、複数のSensu Serverを1つのUchiwaで表示することも可能です。sensu配列のほうにSensu APIの設定を、uchiwaのほうはWebサービスとしてのポート番号やBASIC認証のユーザー名などを設定します。設定ファイルはこれだけですので、実際に起動してみましょう。

$ sudo service uchiwa start

ログファイルは/var/log/uchiwa.logです。自動起動設定は同じようにupdate-rc.dを使います。

$ sudo update-rc.d sensu-client defaults

実際に「http://アドレス:3000/」にアクセスするとBASIC認証後に以下のページが表示されるはずです。

図2 Uchiwaのトップページには発生したイベントリストが表示される
図2 Uchiwaのトップページには発生したイベントリストが表示される
図3 Clientsには登録済のクライアントが表示される
図3 Clientsには登録済のクライアントが表示される

試しに別のマシンにSensu Clientをインストールし、起動してみてください。Sensu ServerやUchiwaのほうは特に何も設定しなくても自動的にクライアント画面に新しいクライアントが追加されるはずです。

Sensuのモニタリングシステム

Sensuではクライアントごとに確認しなければならない単位項目を「Check」と呼びます。Checkで取得した結果を「Event Data」と呼び、成功ステータス以外のEvent Dataが返ってきたときに行う処理を「Handler」と呼びます。Handlerそのものが何かをする場合もありますし、⁠Mutator」と呼ばれる整形スクリプトを介してEvent Dataが他のツールに渡されることもあります。

では監視やメトリクスの収集を行う際の基本となるCheckを追加してみましょう。行わなければならない作業は次のとおりです。

  • クライアントにCheckスクリプトをインストールする
  • サーバーにCheckスクリプトを呼び出す設定(Check)を追加する
  • クライアントを追加したCheckに登録する

Checkスクリプトとは実際にデータを収集したり、監視コマンドを実行するスクリプトです。スクリプトで使用する言語に制約はありませんが、出力結果はNagiosと同様に「exitステータスコードと標準出力や標準エラー出力」を用いたフォーマットである必要があります。

Sensuではコミュニティで開発しているプラグインをGitHubで公開しています。そこで今回は「check-file-exist」を使って、再起動が必要なマシンにアラートを出すようにしてみましょう。まず「クライアント側」にCheckスクリプトをダウンロードします。

$ sudo wget -O /etc/sensu/plugins/check-file-exists.rb \
    https://raw.github.com/sensu/sensu-community-plugins/master/plugins/files/check-file-exists.rb
$ sudo chmod 755 /etc/sensu/plugins/check-file-exists.rb

このRubyスクリプトは指定したファイルが存在するときにオプションのステータスを返すシンプルなスクリプトです。APTシステムでアップグレードした時、再起動が必要な場合は「/var/run/reboot-required」ファイルを作成します。そこでこのファイルが存在した場合は、CRITICAL状態と通知することにしましょう。

スクリプトそのものはクライアント側のローカルで次のようにテストできます。

$ /opt/sensu/embedded/bin/ruby /etc/sensu/plugins/check-file-exists.rb -c /var/run/reboot-required
CheckFileExists OK: No test files exist

次にサーバー側で、このCheckスクリプトを定期的に実行する設定ファイルを用意します。設定ファイルとして「/etc/sensu/conf.d/check_reboot.json」を作成しましょう。

{
  "checks": {
    "check_reboot": {
      "handlers": ["default"],
      "command": "/etc/sensu/plugins/check-file-exists.rb -c /var/run/reboot-required ",
      "interval": 10,
      "subscribers": [ "reboot" ]
    }
  }
}

commandにクライアント側で実行して欲しいコマンドを記述します。intervalは実行間隔です。テスト目的で10秒間隔としていますが、再起動が必要になるのはアップデートしたタイミングなので、大抵は1日単位ぐらいで良いはずです。subscribersは、このCheckを実行するグループを列挙します。

Sensu Serverの設定を変更したので再起動しておきましょう。ちなみにSensu Serverを再起動する場合は、APIのほうも再起動しないとUchiwaが追随してくれないようです。

$ sudo service sensu-server restart
$ sudo service sensu-api restart

再びクライアント側に戻り、このクライアントをrebootグループに参加させます。クライアントの設定ファイル/etc/sensu/conf.d/client.jsonのsubscriptionsに「reboot」を追加するだけです。

{
  "client": {
    "name": "sensu-server",
    "address": "localhost",
    "subscriptions": [ "all", "reboot" ]
  }
}

最後にclient.jsonを変更したので、クライアントも再起動しておきます。

$ sudo service sensu-client restart

これで、次のようにUchiwaにCheckが表示されます。

図4 Checks画面にCheckの詳細が表示される
図4 Checks画面にCheckの詳細が表示される
図5 試しに/var/run/reboot-requiredを作ると、アラートが表示される
図5 試しに/var/run/reboot-requiredを作ると、アラートが表示される

Standalone Checkと呼ばれる特別なタイプのCheckが存在します。これはクライアント側でスクリプトの実行タイミングを制御するタイプのCheckで、設定もすべてクライアント側だけで完結します。特定のマシンでのみ実行すれば良かったり、マシン上の何らかのの契機でCheckを実行したい場合に有用です。

InfluxDBとGrafanaでグラフ作成

冒頭で、Sensuには「グラフ機能はない」とお伝えしました。でもそれでは「可視化」という意味で力不足です。そこでグラフ作成ツールであるInfluxDBとGrafanaにSensuが収集したデータを渡して、グラフ化してもらうことにします。

InfluxDBとGrafanaのインストール

「InfluxDB」はGo言語で作られた時系列データベースの一種です。ここでは深入りせずに、公式ドキュメントにしたがってインストールします。

$ wget http://s3.amazonaws.com/influxdb/influxdb_latest_amd64.deb
$ less influxdb_latest_amd64.deb
$ sudo dpkg -i influxdb_latest_amd64.deb
$ sudo service start influxdb
$ curl -X POST 'http://localhost:8086/db?u=root&p=root' -d '{"name": "stats"}'

設定ファイルは/opt/influxdb/shared/config.tomlです。管理画面用にポート8083を、HTTP API用にポート8086を使用します。

GrafanaはInfluxDBやGraphite、OpenTSDBなどのダッシュボードの見た目を「いい感じ」にしてくれる、Webアプリです。別途Webサーバーが必要なのでここではNginxをインストールします。

$ sudo apt install nginx
$ sudo rm /etc/nginx/sites-enabled/default
$ sudo mkdir -p /var/www/html
$ cat <<EOF | sudo tee /etc/nginx/sites-available/grafana
server {
        listen 80 default_server;
        listen [::]:80 default_server ipv6only=on;

        root /var/www/html/;
        index index.html index.htm;

        server_name localhost;

        location /grafana {
                index index.html index.htm;
        }
}
EOF
$ sudo ln -s /etc/nginx/sites-available/grafana /etc/nginx/sites-enabled/
$ sudo service nginx configtest
$ sudo service nginx restart
$ wget http://grafanarel.s3.amazonaws.com/grafana-1.9.1.tar.gz
$ tar xvf grafana-1.9.1.tar.gz
$ sudo mv grafana-1.9.1 /var/www/html/grafana
$ sudo chown -R www-data: /var/www/html/grafana

また/var/www/html/grafana/config.sample.jsをconfig.jsに書き換えて、以下の内容を追加しておいてください。

datasources: {
  influxdb: {
    type: 'influxdb',
    url: "http://(InfluxDBのアドレス):8086/db/stats",
    username: 'root',
    password: 'root',
  },
  grafana: {
    type: 'influxdb',
    url: "http://(InfluxDBのアドレス):8086/db/grafana",
    username: 'root',
    password: 'root',
    grafanaDB: true
  },
},

なお、GrafanaはJavaScriptの中で上記のInfluxDBのアドレスへとアクセスします。うまく動かない時は、CORSのポリシーなども確認してください。

Metricの追加

次はSensu側の設定です。まずはデータの収集から。Checkのタイプに「Metric」と呼ばれるものが存在します。これはCheckスクリプトが成功した時、標準出力に構造化されたデータ(つまりは計量したデータ)が表示されるタイプのCheckです。Sensu ServerはこのCheckを実行した時、Event Dataとしてこのデータを保存します。

コミュニティで開発しているプラグインにvmstatの出力結果を取得するMetricスクリプトがありますのでそれを利用します。クライアント側で次のように実行します。

$ sudo wget -O /etc/sensu/plugins/vmstat-metrics.rb \
    https://raw.github.com/sensu/sensu-community-plugins/master/plugins/system/vmstat-metrics.rb
$ sudo chmod 755 /etc/sensu/plugins/vmstat-metrics.rb
$ /opt/sensu/embedded/bin/ruby /etc/sensu/plugins/vmstat-metrics.rb
sensu-client.vmstat.procs.waiting 0 1423466090
sensu-client.vmstat.procs.uninterruptible 0 1423466090
sensu-client.vmstat.memory.swap_used 0 1423466090
(以下略)

クライアントの設定ファイル/etc/sensu/conf.d/client.jsonのsubscriptionsに「vmstat」を追加します。

{
  "client": {
    "name": "sensu-server",
    "address": "localhost",
    "subscriptions": [ "all", "reboot", "vmstat" ]
  }
}

最後にclient.jsonを変更したので、クライアントも再起動しておきます。

$ sudo service sensu-client restart

サーバー側に/etc/sensu/conf.d/vmstat_metrics.jsonという名前でMetricを追加します。

{
  "checks": {
    "vmstat_metrics": {
      "type": "metric",
      "handlers": [ "influxdb" ],
      "command": "/etc/sensu/plugins/vmstat-metrics.rb",
      "interval": 60,
      "subscribers": [ "vmstat" ]
    }
  }
}

ポイントはtypeがmetricになっていることと、handlersがinfluxdbになっていることです。このhandlersについては次のページで説明します。

HandlerとMutator

HandlerはEvent Dataを受け取ったときに、何か特別なことをさせたいときに使用します。メールアラートを送信したり、Twitterに書き込んだり、データを他のプログラムに渡したり、特定のコマンドを実行したり……といった具合です。今回の例では「influxdb」Handlerを指定しています。

さらに他のプログラムにデータを渡す前に、Event Dataを整形したいことがあります。それを行うのがMutatorです。

今回はMutatorは使わずHandlerだけ必要です。influxdb-metrics用のスクリプトをダウンロードします。

$ sudo wget -O /etc/sensu/handlers/influxdb-metrics.rb \
    https://raw.github.com/sensu/sensu-community-plugins/master/handlers/metrics/influxdb-metrics.rb
$ sudo chmod 755 /etc/sensu/handlers/influxdb-metrics.rb
$ sudo /opt/sensu/embedded/bin/gem install influxdb
$ sudo sed -i "s/each/each_line/" /etc/sensu/handlers/influxdb-metrics.rb

最後のsedは、vmstatのCheckのoutputが配列ではなく文字列として返されることに対する回避策です[6]⁠。ダウンロードしたスクリプトをHandlerとして設定します。/etc/sensu/conf.d/handler_influxdb.jsonを作成してください。

{
  "handlers": {
    "influxdb": {
      "type": "pipe",
      "command": "/etc/sensu/handlers/influxdb-metrics.rb"
    }
  },
  "influxdb": {
    "server": "localhost",
    "port": "8086",
    "username": "root",
    "password": "root",
    "database": "stats"
  }
}

最後にサーバーを再起動します。

$ sudo service sensu-server restart
$ sudo service sensu-api restart

これで定期的にvmstatの結果がInfluxDBに保存されます。実際にデータが保存されているかどうかは、次のようなコマンドで確認できます。

$ curl -G 'http://localhost:8086/db/stats/series?u=root&p=root' \
    --data-urlencode "q=select value from vmstat_memory_free;"

うまく保存されてないようなら、まずはSensu Serverのログで何かエラーが出ていないかというところから確認すると良いでしょう。

Grafanaの確認

最後にGrafanaのページをブラウザで表示してみましょう。最初は何も選択されていないため、まずはInfluxDBのどのデータをグラフ化するかを指定する必要があります。

Dashboardにあるグラフの「no tilte (click here)」と書いてある部分を素直にクリックして「edit」を選択します。あとは「Metrics」タブにクエリー入力欄が現れますので、⁠series name」と書いてあるところにvmstatの出力名を入力すると自動的にグラフが表示されます。

図6 冒頭と同じ画面、操作はかなりインタラクティブなのでいじっているだけでも楽しい
図6 冒頭と同じ画面、操作はかなりインタラクティブなのでいじっているだけでも楽しい

Grafanaの操作についての詳しいことは公式のチュートリアルを参照してください。

Sensu of Wonder

いかがでしたでしょうか。導入までがすごく面倒で、これだったらMuninのほうがお手軽で良いグラフが出せるじゃないか、と感じたのではないでしょうか。少なくともこの記事を書いている当の筆者本人は途中からすごくそう思いました。

ただし今回はなるべく手作業でいろいろなものをインストールしています。これらの煩雑に見える部分も、本来であればChefやPuppetである程度自動化されていますし、InfluxDBやGrafanaも構成管理ツールで簡単に自動化できそうです。特に台数が多くなりがちな監視対象であるクライアント側は、cloud-initなどで「インストール後に必ず行うもの」リストに入れてしまえば、⁠面倒」な部分はほぼなくなります。

Sensuはあくまでフレームワークであり、何を監視・取得するかだけでなく、監視・取得した結果をどう加工するか、次に誰にデータを渡すのかまで自由に組み合わせられるようになっています。今回のように時系列データベースに保存すればMuninのようなグラフになりますし、ElasticSearchとKibanaを組み合わせて、何らかの攻撃のようなアクセスが発生したタイミングでイベントを発生させ、アクセス元のIPアドレスを地図上にマッピングするといった処理も可能になります。たぶん。

ぜひSensuを使って、皆さんが心に秘めているであろう監視の創造性や可視化の未来性を遺憾なく発揮してください。

おすすめ記事

記事・ニュース一覧