第14章 ロギングと監視

libvirt: /var/log/libvirt/libvirtd.log

VMインスタンスのコンソール (ブートメッセージ): /var/lib/nova/instances/instance-<instance id>/console.log

cinder: /var/log/cinder/cinder-volume.log

まず始めに、全てのOpenStackコンポーネントのログを標準ログに加えてsyslogに出力するように設定します。また、各コンポーネントが異なるsyslogファシリティになるように設定します。これによりログサーバー上で、個々のコンポーネントのログを分離しやすくなります。

nova.conf:

use_syslog=True
syslog_log_facility=LOG_LOCAL0

glance-api.conf および glance-registry.conf:

use_syslog=True
syslog_log_facility=LOG_LOCAL1

cinder.conf:

use_syslog=True
syslog_log_facility=LOG_LOCAL2

keystone.conf:

use_syslog=True
syslog_log_facility=LOG_LOCAL3

Swift

デフォルトでSwiftはsyslogにログを出力します。

次に、 /etc/rsyslog.d/client.confに次の行を作成します。

*.* @192.168.1.10

これは、rsyslogに全てのログを指定したIPアドレスに送るように命令しています。この例では、IPアドレスはクラウドコントローラーを指しています。

集中ログサーバーとして使用するサーバーを決めます。ログ専用のサーバーを利用するのが最も良いです。 /etc/rsyslog.d/server.conf を次のように作成します。

# Enable UDP 
$ModLoad imudp 
# Listen on 192.168.1.10 only 
$UDPServerAddress 192.168.1.10
# Port 514 
$UDPServerRun 514  
      
# Create logging templates for nova
$template NovaFile,"/var/log/rsyslog/%HOSTNAME%/nova.log" 
$template NovaAll,"/var/log/rsyslog/nova.log"
      

      
# Log everything else to syslog.log 
$template DynFile,"/var/log/rsyslog/%HOSTNAME%/syslog.log"
*.* ?DynFile
      

      
# Log various openstack components to their own individual file
local0.* ?NovaFile 
local0.* ?NovaAll 
& ~

この設定例はnovaサービスのみを扱っています。はじめに rsyslog を UDP 514番ポートで動作するサーバーとして設定します。次に一連のログテンプレートを作成します。ログテンプレートは受け取ったログをどこに保管するかを指定します。上記の例を用いると、c01.example.comから送られるnovaのログは次の場所に保管されます。

c02.example.comから送られたログはこちらに保管されます。

全てのノードからのnovaのログを含む集約されたログだけでなく、個々のコンピュートノードのログも持つことになります。

基本的なアラート監視は、単純に必要なプロセスが実行されているかどうかをチェックすることです。例えば、 nova-apiサービスがクラウドコントローラーで動作していることを確認します。

[ root@cloud ~ ] # 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

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は常に一つ以上の nova-computeサービスが動作しているかをチェックします。

リソースのアラートは、一つ以上のリソースが極めて少なくなった場合に通知するものです。監視の閾値はインストールされたOpenStackの環境に合わせて設定すべきですが、リソース監視の利用方法は、OpenStackに固有の話ではありません。一般的なアラートのタイプが利用できます。

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

例として、コンピュートノード上のディスク容量を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を警告します。%i_dummy%f_dummy

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

最初は nova コマンドを利用した例です。

# nova 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      | 
+----------------------------------+--------------+--------+

リソース利用をテナントのクォータと結合することで、利用率を求めることが出来ます。例えば、テナントが、10個のうち1つのFloating IPを利用しているとすると、10%のFloating IP クォータを利用することになります。これを行なうことで、レポートを作ることができます。

+-----------------------------------+------------+-------------+---------------+ 
| 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 (https://github.com/cybera/novac/blob/dev/libexec/novac-quota-report) にあるカスタムスクリプトを用いて作成しました。

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

インテリジェントなアラートは運用における継続的インテグレーションの要素の一つです。例えば、以下のような方法で簡単にGlanceが起動しているかを簡単に確認できます。glance-apiとglance-registryプロセスが起動していることを確認する、もしくはglace-apiが9292ポートに応答するといった方法です。

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

#!/bin/bash 
# 
# assumes that resonable credentials have been stored at 
# /root/auth 
 
      
. /root/openrc 
wget https://launchpad.net/cirros/trunk/0.3.0/+download/cirros-0.3.0-x86_64-disk.img  
glance image-create --name='cirros image' --is-public=true --container-format=bare --disk-format=qcow2 < cirros-0.3.0-x8
6_64-disk.img

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

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

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

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

トレンドはどのようにクラウドが実行されているかの素晴しい見通しを与えてくれます。例えば、負荷の高い日がたまたま発生したのか、新しいコンピュートノードを追加すべきか、などです。

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

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

例として、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のドキュメント (https://collectd.org/wiki/index.php/Data_source)を参照してください。