[ English | Indonesia | Deutsch | 日本語 ]

監視

二つの監視のタイプがあります。問題の監視と、利用傾向の監視です。前者は全てのサービスが動作していることを保証するものであり、後者は時間に沿ったリソース利用状況を監視することで、潜在的なボトルネックの発見とアップグレードのための情報を得るものです。

プロセス監視

基本的なアラーム監視は、単に要求されたプロセスが稼働しているかどうかを確認することです。 例えば、 nova-api サービスがクラウドコントローラーで稼働しているかどうかを確認します。

# ps aux | grep nova-api
nova 12786 0.0 0.0 37952 1312 ? Ss Feb11 0:00 su -s /bin/sh -c exec nova-api
--config-file=/etc/nova/nova.conf nova
nova 12787 0.0 0.1 135764 57400 ? S Feb11 0:01 /usr/bin/python
 /usr/bin/nova-api --config-file=/etc/nova/nova.conf
nova 12792 0.0 0.0 96052 22856 ? S Feb11 0:01 /usr/bin/python
/usr/bin/nova-api --config-file=/etc/nova/nova.conf
nova 12793 0.0 0.3 290688 115516 ? S Feb11 1:23 /usr/bin/python
/usr/bin/nova-api --config-file=/etc/nova/nova.conf
nova 12794 0.0 0.2 248636 77068 ? S Feb11 0:04 /usr/bin/python
/usr/bin/nova-api --config-file=/etc/nova/nova.conf
root 24121 0.0 0.0 11688 912 pts/5 S+ 13:07 0:00 grep nova-api

The OpenStack processes that should be monitored depend on the specific configuration of the environment, but can include:

Compute サービス (nova)

  • nova-api

  • nova-scheduler

  • nova-conductor

  • nova-novncproxy

  • nova-compute

Block Storage サービス (cinder)

  • cinder-volume

  • cinder-api

  • cinder-scheduler

Networking サービス (neutron)

  • neutron-server

  • neutron-openvswitch-agent

  • neutron-dhcp-agent

  • neutron-l3-agent

  • neutron-metadata-agent

Image サービス (glance)

  • glance-api

  • glance-registry

Identity サービス (keystone)

keystone プロセスは、WSGI アプリケーションとして Apache の中で動作します。

リソースのアラート

リソースアラート機能は、1 つ以上のリソースが致命的に少なくなった際に通知します。閾値監視がお使いの OpenStack 環境で有効化されているべきですが、リソース使用状況の監視は、まったく OpenStack 固有のことではありません。あらゆる汎用のアラート機能が適切に動作するでしょう。

監視項目に含む幾つかのリソースをあげます。

  • ディスク使用量

  • サーバー負荷

  • メモリー使用量

  • ネットワーク I/O

  • 利用可能な vCPU 数

Telemetry サービス

The Telemetry service (ceilometer) collects metering and event data relating to OpenStack services. Data collected by the Telemetry service could be used for billing. Depending on deployment configuration, collected data may be accessible to users based on the deployment configuration. You can read more about the module in the Ceilometer Administrator Guide or in the Ceilometer Contributor Guide.

OpenStack 固有のリソース

Resources such as memory, disk, and CPU are generic resources that all servers (even non-OpenStack servers) have and are important to the overall health of the server. When dealing with OpenStack specifically, these resources are important for a second reason: ensuring that enough are available to launch instances. There are a few ways you can see OpenStack resource usage. The first is through the openstack command:

# openstack usage list

このコマンドはテナント上で実行されるインスタンスのリストと、インスタンス全体の簡単な利用統計を表示します。クラウドの簡単な概要を得るのに便利なコマンドですが、より詳細な情報については表示しません。

次に nova データベースは 利用情報に関して 3 つのテーブルを持っています。

nova.quotas と``nova.quota_usages`` テーブルはクォータの情報が保管されています。もし、テナントのクォータがデフォルト設定と異なる場合、 nova.quotas テーブルに保管されます。以下に例を示します。

mysql> select project_id, resource, hard_limit from quotas;
+----------------------------------+-----------------------------+------------+
| project_id                       | resource                    | hard_limit |
+----------------------------------+-----------------------------+------------+
| 628df59f091142399e0689a2696f5baa | metadata_items              | 128        |
| 628df59f091142399e0689a2696f5baa | injected_file_content_bytes | 10240      |
| 628df59f091142399e0689a2696f5baa | injected_files              | 5          |
| 628df59f091142399e0689a2696f5baa | gigabytes                   | 1000       |
| 628df59f091142399e0689a2696f5baa | ram                         | 51200      |
| 628df59f091142399e0689a2696f5baa | floating_ips                | 10         |
| 628df59f091142399e0689a2696f5baa | instances                   | 10         |
| 628df59f091142399e0689a2696f5baa | volumes                     | 10         |
| 628df59f091142399e0689a2696f5baa | cores                       | 20         |
+----------------------------------+-----------------------------+------------+

nova.quota_usages テーブルはどのくらいリソースをテナントが利用しているかを記録しています。

mysql> select project_id, resource, in_use from quota_usages where project_id like '628%';
+----------------------------------+--------------+--------+
| project_id                       | resource     | in_use |
+----------------------------------+--------------+--------+
| 628df59f091142399e0689a2696f5baa | instances    | 1      |
| 628df59f091142399e0689a2696f5baa | ram          | 512    |
| 628df59f091142399e0689a2696f5baa | cores        | 1      |
| 628df59f091142399e0689a2696f5baa | floating_ips | 1      |
| 628df59f091142399e0689a2696f5baa | volumes      | 2      |
| 628df59f091142399e0689a2696f5baa | gigabytes    | 12     |
| 628df59f091142399e0689a2696f5baa | images       | 1      |
+----------------------------------+--------------+--------+

テナントのハード制限と現在の使用量を比較することにより、それらの使用割合を確認できます。例えば、このテナントが Floating IP を 10 個中 1 個使用している場合、Floating IP クォータの 10% を使用していることになります。手動で計算するより、SQL やお好きなスクリプト言語を使用して、定型化されたレポートを作成できます。

+----------------------------------+------------+-------------+---------------+
| some_tenant                                                                 |
+-----------------------------------+------------+------------+---------------+
| Resource                          | Used       | Limit      |               |
+-----------------------------------+------------+------------+---------------+
| cores                             | 1          | 20         |           5 % |
| floating_ips                      | 1          | 10         |          10 % |
| gigabytes                         | 12         | 1000       |           1 % |
| images                            | 1          | 4          |          25 % |
| injected_file_content_bytes       | 0          | 10240      |           0 % |
| injected_file_path_bytes          | 0          | 255        |           0 % |
| injected_files                    | 0          | 5          |           0 % |
| instances                         | 1          | 10         |          10 % |
| key_pairs                         | 0          | 100        |           0 % |
| metadata_items                    | 0          | 128        |           0 % |
| ram                               | 512        | 51200      |           1 % |
| reservation_expire                | 0          | 86400      |           0 % |
| security_group_rules              | 0          | 20         |           0 % |
| security_groups                   | 0          | 10         |           0 % |
| volumes                           | 2          | 10         |          20 % |
+-----------------------------------+------------+------------+---------------+

前の情報は GitHub にあるカスタムスクリプトを使用して生成されました。

注釈

このスクリプトは特定のOpenStackインストール環境向けなので、自身の環境に適用する際には変更しなくてはいけませんが、ロジックは簡単に変更できるでしょう。

インテリジェントなアラート

インテリジェントなアラート機能により、ある種の運用の継続的インテグレーションと考えることができます。例えば、 glance-api プロセスと glance-registry プロセスが動作していること、または glance-api が 9292 ポートで応答していることを確認することにより、Image サービスが起動して動作していることを簡単に確認できます。

しかし、Image service にイメージが正しくアップロードされたことをどのように知ればいいのでしょうか? もしかしたら、Image service が保管しているイメージのディスクが満杯、もしくは S3 のバックエンドがダウンしているかもしれません。簡易的なイメージアップロードを行なうことでこれをチェックすることができます。

#!/bin/bash
#
# assumes that reasonable credentials have been stored at
# /root/auth


. /root/openrc
wget http://download.cirros-cloud.net/0.3.5/cirros-0.3.5-x86_64-disk.img
openstack image create --name='cirros image' --public \
--container-format=bare --disk-format=qcow2 \
--file cirros-0.3.5-x86_64-disk.img

このスクリプトを(Nagiosのような)監視システムに組込むことで、イメージカタログのアップロードが動作していることを自動的に確認することができます。

注釈

毎回テスト後にイメージを削除する必要があります。 Image サービスからイメージが削除できるかのテストにしてしまえば、さらによいです。

インテリジェントなアラートは、この章で述べられているの他のアラートよりも計画、実装にかなり時間を要します。インテリジェントなアラートを実装する流れは次のようになります。

  • 構築したクラウドにおいて一般的なアクションをレビューする

  • それらのアクションに対して自動テストを作成する

  • それらのテストをアラートシステムに組み込む

インテリジェントなアラートのその他の例としては以下があります。

  • インスタンスの起動と削除が可能か?

  • ユーザの作成は可能か?

  • オブジェクトの保存と削除は可能か?

  • ボリュームの作成と削除は可能か?

モニタリングツール

Nagios

Nagios は、オープンソースソフトウェアの監視サービスです。任意のコマンドを実行して、サーバーやネットワークサービスの状態を確認できます。また、任意のコマンドをリモートのサーバーで直接実行できます。サーバーが受動的な監視形態で通知を送信することもできます。Nagios は 1999 年ごろにできました。より当たらし監視サービスがありますが、Nagios は実績豊富なシステム管理ツールです。

Nagios と NRPE を使って、クリティカルなプロセスの自動化されたアラートを作成することが可能です。 nova-compute プロセスがコンピュートノードで動作していることを保証するために、Nagios サーバー上で次のようなアラートを作成します。

define service {
    host_name c01.example.com
    check_command check_nrpe_1arg!check_nova-compute
    use generic-service
    notification_period 24x7
    contact_groups sysadmins
    service_description nova-compute
}

コンピュートノードにおいて、次のような NRPE 設定を作成します。

command[check_nova-compute]=/usr/lib/nagios/plugins/check_procs -c 1: -a nova-compute

Nagiosは常に 1 つ以上の nova-compute サービスが動作しているかをチェックします。

たとえば、リソースのアラートとして、コンピュートノード上のディスク容量を Nagios を使って監視する場合、次のような Nagios 設定を追加します。

define service {
    host_name c01.example.com
    check_command check_nrpe!check_all_disks!20% 10%
    use generic-service
    contact_groups sysadmins
    service_description Disk
}

コンピュートノード上では、次のようなNRPE設定を追加します。

command[check_all_disks]=/usr/lib/nagios/plugins/check_disk -w $ARG1$ -c $ARG2$ -e

Naigos は、80% のディスク使用率で WARNING、90% で CRITICAL を警告します。

StackTach

StackTach is a tool that collects and reports the notifications sent by nova. Notifications are essentially the same as logs but can be much more detailed. Nearly all OpenStack components are capable of generating notifications when significant events occur. Notifications are messages placed on the OpenStack queue (generally RabbitMQ) for consumption by downstream systems. An overview of notifications can be found at System Usage Data.

以下を nova.conf 設定ファイルに追加して、nova で通知の送信を有効化します。

notification_topics=monitor
notification_driver=messagingv2

Once nova is sending notifications, install and configure StackTach. StackTach works for queue consumption and pipeline processing are configured to read these notifications from RabbitMQ servers and store them in a database. Users can inquire on instances, requests, and servers by using the browser interface or command-line tool, Stacky. Since StackTach is relatively new and constantly changing, installation instructions quickly become outdated. Refer to the StackTach Git repository for instructions as well as a demostration video. Additional details on the latest developments can be discovered at the official page

Logstash

Logstash is a high performance indexing and search engine for logs. Logs from Jenkins test runs are sent to logstash where they are indexed and stored. Logstash facilitates reviewing logs from multiple sources in a single test run, searching for errors or particular events within a test run, and searching for log event trends across test runs.

Logstash は 4 つのおもなレイヤーがあります。

  • Log Pusher

  • Log Indexer

  • ElasticSearch

  • Kibana

Each layer scales horizontally. As the number of logs grows you can add more log pushers, more Logstash indexers, and more ElasticSearch nodes.

Logpusher is a pair of Python scripts that first listens to Jenkins build events, then converts them into Gearman jobs. Gearman provides a generic application framework to farm out work to other machines or processes that are better suited to do the work. It allows you to do work in parallel, to load balance processing, and to call functions between languages. Later, Logpusher performs Gearman jobs to push log files into logstash. Logstash indexer reads these log events, filters them to remove unwanted lines, collapse multiple events together, and parses useful information before shipping them to ElasticSearch for storage and indexing. Kibana is a logstash oriented web client for ElasticSearch.