監視¶

プロセス監視¶

基本的なアラーム監視は、単に要求されたプロセスが稼働しているかどうかを確認することです。 例えば、 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-api
• 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 サービス¶

Telemetry サービス (ceilometer) は、OpenStack のサービスに関連するメータリングとイベントデータを収集します。Telemetry サービスにより収集されるデータは、課金のために使用できます。環境の設定によっては、ユーザーが設定に基づいて収集したデータにアクセスできるかもしれません。Telemetry サービスは ceilometer V2 Web API にドキュメント化されている REST API を提供します。このモジュールの詳細は、 OpenStack Administrator Guide や developer documentation にあります。

OpenStack 固有のリソース¶

メモリ、ディスク、CPUのような一般的なリソースは、全てのサーバー(OpenStackに関連しないサーバーにも)に存在するため、サーバーの状態監視において重要です。OpenStackの場合、インスタンスを起動するために必要なリソースが確実に存在するかの確認という点でも重要です。OpenStackのリソースを見るためには幾つかの方法が存在します。 1 番目は nova コマンド経由です。

# 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 にあるカスタムスクリプトを使用して生成されました。

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

Intelligent alerting can be thought of as a form of continuous integration for operations. For example, you can easily check to see whether the Image service is up and running by ensuring that the glance-api and glance-registry processes are running or by seeing whether glance-api is responding on port 9292.

しかし、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のような)監視システムに組込むことで、イメージカタログのアップロードが動作していることを自動的に確認することができます。

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

• 構築したクラウドにおいて一般的なアクションをレビューする
• それらのアクションに対して自動テストを作成する
• それらのテストをアラートシステムに組み込む

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

• インスタンスの起動と削除が可能か?
• ユーザの作成は可能か?
• オブジェクトの保存と削除は可能か?
• ボリュームの作成と削除は可能か?

トレンド¶

傾向は、あなたのクラウドが日々どのように動作しているかについて、素晴らしい洞察を与えられます。例えば、忙しい日が単純にほとんど発生していないかどうか、新しいコンピュートノードを追加しはじめるべきかどうかを学習できます。

トレンドはアラートとは全く異なったアプローチです。アラートは0か1かの結果(チェックが成功するか失敗するか)に注目しているのに対して、トレンドはある時点での状態を定期的に記録します。十分な量が記録されれば、時系列でどのように値が変化するかを確認できます。

これまでに示した全てのアラートタイプは、トレンドレポートに利用可能です。その他のトレンドの例は以下の通りです。

• 各コンピュートノード上のインスタンス数
• 使用中のフレーバー
• 使用中のボリューム数
• 1時間あたりの Object Storage リクエスト数
• 1時間あたりの nova-api リクエスト数
• ストレージサービスの I/O の統計

例として、 nova-api の使用を記録することでクラウドコントローラーをスケールする必要があるかを追跡できます。 nova-api のリクエスト数に注目することにより、 nova-api プロセスを追加するか、もしくは、 nova-api を実行するための新しいサーバーを導入することまで行なうかを決定することができます。リクエストの概数を取得するには /var/log/nova/nova-api.log の INFO メッセージを検索します。

# grep INFO /var/log/nova/nova-api.log | wc

成功したリクエストを検索することで、更なる情報を取得できます。

# grep " 200 " /var/log/nova/nova-api.log | wc

このコマンドを定期的に実行し結果を記録することで、トレンドレポートを作ることができます。これにより /var/log/nova/nova-api.log の使用量が増えているのか、減っているのか、安定しているのか、を知ることができます。

collectd のようなツールはこのような情報を保管することに利用できます。 collectd はこの本のスコープから外れますが、 collectd で COUNTER データ形として結果を保存するのがよい出発点になります。より詳しい情報は collectd のドキュメント を参照してください。

モニタリングツール¶

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
}

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

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
}

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

notification_topics=monitor
notification_driver=messagingv2

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.