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 делает записи в syslog.

Затем создайте /etc/rsyslog.d/client.conf с помощью следующей строки:

*.* @192.168.1.10

Это дает указание отсылать все записи в журналы на перечисленные IP. В данном примере IP указывает на контроллер облака.

# 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 работает в настоящее время.

Некоторые из ресурсов, которые вы захотите контролировать:

Например, для мониторинга дисковой емкости на вычислительном узле с использованием 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

Nagios выдает уведомление предостережения (WARNING) когда любой диск в вычислительном узле заполняется на 80 процентов и критично (CRITICAL) при заполнении на 90 процентов.

# nova usage-list

Эта команда выводит список того, как много экземпляров выполняют владельцы и некоторую первичную статистику использования комбинированных экземпляров. Эта команда полезна для быстрого обзора вашего облака, но в действительности не снабжает вас большим количеством деталей.

Далее, база данных nova содержит три таблицы, которые хранят информацию об использовании.

Таблицы nova.quotas и nova.quota_usages хранят информацию о квотах. Если квоты владельца (tenant) отличаются от значений, установленных для квот по умолчанию, тогда их квоты сохраняются в таблице 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      |
+----------------------------------+--------------+--------+

Сравнив жесткие пределы владельца с его текущим использованием ресурсов, вы можете выяснить процент использования. Например, если этот владелец использует 1 плавающий IP из 10, то он использует 10% от своих квот плавающих IP. Вмето выполнения расчетов вручную вы можете воспользоваться 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 % |
+-----------------------------------+------------+------------+---------------+

Но как вы можете определить, что образы были успешно загружены службой образов? Может оказаться, что диск, на который служба образов сохраняет образы заполнен или сервер S3 выключен. Естественно, вы можете проверить это, выполнив быструю загрузку образа: But how can you tell whether images are being successfully uploaded to the Image Service? Maybe the disk that Image Service is storing the images on is full or the S3 backend is down. You could naturally check this by doing a quick image upload:

#!/bin/bash
#
# assumes that reasonable 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), вы теперь получаете автоматизированный способ проверки работоспособности загрузки образов в каталог образов. By taking this script and rolling it into an alert for your monitoring system (such as Nagios), you now have an automated way of ensuring that image uploads to the Image Catalog are working.

	Замечание
	Вы должны удалять образ после каждой проверки. Еще лучше, проверять: можно ли успешно удалить изображение из службы образов.

Интеллектуальные оповещения отнимают значительно больше времени для планирования и реализации по сравнению с другими описанными в этой главе предупреждениями. Хорошей структурой реализации интеллектуального оповещения является:

Некоторые другие примеры интеллектуального оповещения включают в себя:

В качестве примера: запись использования nova-api может позволить вам отслеживать необходимость расширения контроллера облака. Оставляя под наблюдением запросы nova-api, вы можете определить, требуется ли вам порождать больше процессов nova-api или же зайти дальше и запустить совершенно новый сервер nova-api. Чтобы получить приблизительное число запросов, просмотрите стандартные сообщения INFO в /var/log/nova/nova-api.log:

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

Вы можете получить дополнительную статистику, просмотрев количество успешных запросов:

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

Периодически выполняя эту команду и регистрируя результат, вы можете создать отчет анализа тенденции во времени, который показывает: растет ли, уменьшатся ли или поддерживается в устойчивом состоянии использование вашего nova-api.