С 1991 года на компьютерном рынке России 		e-mail

т.: 676 0965, 676 0396
Москва, Сосинская ул. 43,
м. Волгоградский проспект
Руководство по эксплуатации OpenStack

ГЛАВА 13

Ведение журналов и мониторинг

Пользуйтесь переводом существенно переработанной и дополенной 2й редакции (12-дек-2014),
находящейся теперь и в режиме постоянно обновляемой документации
(последняя пока доступна только на англ.яз.).

Поскольку OpenStack состоит из очень большого количества служб, существует много файлов журналов. Цель данного раздела заключается в том, чтобы помочь вам в поиске журналов и работе с ними, а также в других способах отслеживания состояния вашего проекта.

Где находятся журналы?

В Ubuntu большинство служб использует соглашение о том, чтобы записывать свои файлы журналов в подкаталоги /var/log directory.

Контроллер облака

Служба
 		 Местоположение журнала
 
nova-* /var/log/nova
glance-* /var/log/glance
cinder-* /var/log/cinder
keystone /var/log/keystone
horizon /var/log/apache2/
различные (Swift, dnsmasq) /var/log/syslog

Вычислительные узлы

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

Консоль (загрузки сообщений) для экземпляров виртуальных машин: /var/lib/nova/instances/instance-<instance id>/console.log

Узлы блочных хранилищ

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

Как читать журналы

Службы OpenStack используют стандартные уровни ведения журналов по мере повышения степени важности: DEBUG, INFO, AUDIT, WARNING, ERROR, CRITICAL и TRACE. Таким образом, сообщения появляются в журналах только если они более "серьезные", чем определенный уровень журнала, причем DEBUG позволяет протоколировать все возникающие сообщения. Например, TRACE регистрируется только если программное обеспечение имеет стек трассировки, в то время как INFO регистрируется для каждого сообщения, включая те, которые предназначены только для информирования.

Чтобы запретить уровень ведения журналов DEBUG, отредактируйте /etc/nova/nova.conf:
debug=false

Keystone обрабатывается немного по-другому. Чтобы изменить уровень ведения журнала, отредактируйте файл /etc/keystone/logging.conf и найдите разделы logger_root и handler_file.

Регистрация для Horizon настроена в /etc/openstack_dashboard/local_settings.py. Поскольку Horizon является веб-приложением Django, он следует рамочным соглашениям Django Logging (https://docs.djangoproject.com/en/dev/topics/logging/).

Первый шаг при поиске источника ошибки обычно начинается с просмотра сообщений в журналах CRITICAL, TRACE или ERROR в конце файла журнала.

Пример сообщения журнала CRITICAL с непосредственно за ним следующими соответствующими TRACE (отслеживание Phyton):
2013-02-25 21:05:51 17409 CRITICAL cinder [-] Bad or unexpected response from the storage volume backend API: volume group cinder-volumes doesn't exist
2013-02-25 21:05:51 17409 TRACE cinder Traceback (most recent call last):
2013-02-25 21:05:51 17409 TRACE cinder File "/usr/bin/cinder-volume", line 48, in <module>
2013-02-25 21:05:51 17409 TRACE cinder service.wait()
2013-02-25 21:05:51 17409 TRACE cinder File "/usr/lib/python2.7/dist-packages/cinder/service.py", line 422, in wait
2013-02-25 21:05:51 17409 TRACE cinder _launcher.wait()
2013-02-25 21:05:51 17409 TRACE cinder File "/usr/lib/python2.7/dist-packages/cinder/service.py", line 127, in wait
2013-02-25 21:05:51 17409 TRACE cinder service.wait()
2013-02-25 21:05:51 17409 TRACE cinder File "/usr/lib/python2.7/dist-packages/eventlet/greenthread.py", line 166, in wait
2013-02-25 21:05:51 17409 TRACE cinder return self._exit_event.wait()
2013-02-25 21:05:51 17409 TRACE cinder File "/usr/lib/python2.7/dist-packages/eventlet/event.py", line 116, in wait
2013-02-25 21:05:51 17409 TRACE cinder return hubs.get_hub().switch()
2013-02-25 21:05:51 17409 TRACE cinder File "/usr/lib/python2.7/dist-packages/eventlet/hubs/hub.py", line 177, in switch
2013-02-25 21:05:51 17409 TRACE cinder return self.greenlet.switch()
2013-02-25 21:05:51 17409 TRACE cinder File "/usr/lib/python2.7/dist-packages/eventlet/greenthread.py", line 192, in main
2013-02-25 21:05:51 17409 TRACE cinder result = function(*args, **kwargs)
2013-02-25 21:05:51 17409 TRACE cinder File "/usr/lib/python2.7/dist-packages/cinder/service.py", line 88, in run_server
2013-02-25 21:05:51 17409 TRACE cinder server.start()
2013-02-25 21:05:51 17409 TRACE cinder File "/usr/lib/python2.7/dist-packages/cinder/service.py", line 159, in start
2013-02-25 21:05:51 17409 TRACE cinder self.manager.init_host()
2013-02-25 21:05:51 17409 TRACE cinder File "/usr/lib/python2.7/dist-packages/cinder/volume/manager.py", line 95,
in init_host
2013-02-25 21:05:51 17409 TRACE cinder self.driver.check_for_setup_error()
2013-02-25 21:05:51 17409 TRACE cinder File "/usr/lib/python2.7/dist-packages/cinder/volume/driver.py", line 116,
in check_for_setup_error
2013-02-25 21:05:51 17409 TRACE cinder raise exception.VolumeBackendAPIException(data=exception_message)
2013-02-25 21:05:51 17409 TRACE cinder VolumeBackendAPIException: Bad or unexpected response from the storage volume
backend API: volume group cinder-volumes doesn't exist
2013-02-25 21:05:51 17409 TRACE cinder

В данном примере cinder-volumes не смогли стартовать и была проведена трассировка стека, так как их сервер томов не смог установить том системы хранения - вероятно потому, что том LVM, который предполагается в конфигурации не существует.

Пример журнала ошибок:
2013-02-25 20:26:33 6619 ERROR nova.openstack.common.rpc.common [-] AMQP server on localhost:5672 is unreachable:
[Errno 111] ECONNREFUSED. Trying again in 23 seconds.

В данной ошибке служба nova не смогла подключиться к серверу RabbitMQ, поскольку получила сообщение об ошибке отказа в соединении.

Трассировка запросов экземпляра

Когда экземпляр отказывает работать должным образом, вам обычно приходится отслеживать активность, связанную с этим экземпляром в лог-файлах различных служб nova-*, причем и в контроллере облака, и в вычислительных узлах.

Обычный способ заключается в отслеживании UUID, связанного с экземпляром в журналах служб.

Рассмотрим следующий пример:
ubuntu@initial:~$ nova list
+--------------------------------+--------+--------+--------------------------+
| ID                             | Name   | Status | Networks                 |
+--------------------------------+--------+--------+--------------------------+
| fafed8-4a46-413b-b113-f1959ffe | cirros | ACTIVE | novanetwork=192.168.100.3|
+--------------------------------+--------+--------+--------------------------+

Здесь faf7ded8-4a46-413b-b113-f19590746ffe - ID, связанный с экземпляром. Если вы выполните поиск этой строки в контроллере облака в файлах /var/log/nova-*.log, она обнаружится в nova-api.log и в nova-scheduler.log. Если вы выполните поиск этой строки в вычислительных узлах в /var/log/nova-*.log, она обнаружится в novanetwork.log и в nova-compute.log. Если не возникло сообщений об ошибках ERROR или CRITICAL, самая последняя выведенная запись журнала может обеспечит подсказку о том, что пошло не так.

Добавление настраиваемых пользователем операторов ведения журналов

Если в существующих журналах не достаточно информации, возможно вам потребуется добавить свои собственные операторы для служб nova-*services.

Исходные файлы расположены в /usr/lib/python2.7/dist-packages/nova

Чтобы добавить операторы ведения журналов, в верней части файла должна присутствовать следующая строка. Для большинства файлов она уже присутствует на своем месте.
from nova.openstack.common import log as logging
LOG = logging.getLogger(__name__)

Чтобы добавить оператор ведения журналов DEBUG, вы должны выполнить:
LOG.debug("This is a custom debugging statement")

Вы могли заметить, что все существующие сообщения в журналах имеют предшествующий символ подчеркивания и заключены в круглые скобки, например:
LOG.debug(_("Logging statement appears here"))

Это используется для поддержки перевода сообщений ведения журналов на различные языки, используя библиотеку интернационализации gettext (http://docs.python.org/2/library/gettext.html). Вам не нужно делать это для ваших собственных сообщений пользовательских журналов. Однако, если вы хотите внести свой вклад в код проекта OpenStack, который включает операторы протоколирования, вы должны окружить ваши сообщения журнала подчеркиванием и круглыми скобками.

Интерфейс веб- управления RabbitMQ или rabbitmqctl

За исключением отказов в соединениях, файлы журналов RabbitMQ, как правило, бесполезны для отладки проблем, связанных с OpenStack. Вместо этого, мы рекомендуем вам использовать интерфейс веб управления RabbitMQ. Включите его в контроллере облака:
# /usr/lib/rabbitmq/bin/rabbitmq-plugins enable rabbitmq_management
# service rabbitmq-server restart

Веб- управляемый интерфейс RabbitMQ доступен в вашем контроллере облака по ссылке http://localhost:55672.

TipUbuntu 12.04 устанавливает версию RabbitMQ 2.7.1, которая использует порт 55672. RabbitMQ версии 3.0 и выше использует порт 15672. Вы можете проверить, с какой версия RabbitMQ вы работаете на локальном компьютере Ubuntu, выполнив:
$ dpkg -s rabbitmq-server | grep "Version:" Version: 2.7.1-0ubuntu4

Альтернативой разрешению интерфейса веб- управления RabbitMQ является использование команд rabbitmqctl. Например, rabbitmqctl list_queues| grep cinder отобразит все оставшиеся в очереди сообщения. Если они существуют, то это возможный признак того, что службы cinder не соединились должным образом с RabbitMQ и, возможно, должны быть запущены повторно.

Элементы для наблюдения за RabbitMQ включают ряд элементов в каждой из очередей и статистики времени обработки для сервера.

Централизованно управляемые журналы

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

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

Настройка клиента rsyslog

Для начала настройте все компоненты OpenStack на ведение системных журналов дополнительно к их стандартному месторасположению файлов журналов. Также настройте каждый компонент для регистрации в различных системных журналах. Это сделает более простым разделение журналов по индивидуальным компонентам на центральном сервере.
nova.conf:
  use_syslog=True
  syslog_log_facility=LOG_LOCAL0
glance-api.confand 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

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

Настройка сервера rsyslog

Назначьте сервер для централизованного ведения журналов. Лучше всего выбрать сервер, который будет посвящен исключительно этой задаче. Создайте файл /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 на работу в качестве сервера, который обслуживает порт 514. Далее, он создает ряд шаблонов для записи в журнал. Шаблоны записей в журнал управляют местоположением, в котором хранятся получаемые журналы. При использовании приведенного выше примера, журнал nova из c01.example.com размещается в следующих местах:

  • /var/log/rsyslog/c01.example.com/nova.log
  • /var/log/rsyslog/nova.log

Также полезно журналы из c02.example.com разместить по адресам:

  • /var/log/rsyslog/c02.example.com/nova.log
  • /var/log/rsyslog/nova.log

Таким образом вы имеете индивидуальный файл журнала для каждого вычислительного узла и агрегированный журнал, который содержит записи журналов для всех узлов.

StackTach

StackTach является инструментом, созданным Rackspace для сбора и представления уведомлений, отправляемых nova. Уведомления, по существу, те же записи в журнал, однако могут быть гораздо более детальными. Хороший обзор уведомлений можно найти в System Usage Data (https://wiki.openstack.org/wiki/SystemUsageData).

Чтобы разрешить nova отправлять уведомления, добавьте следующие строки в nova.conf:
notification_topics=monitor notification_driver=nova.openstack.common.notifier.rabbit_notifier

Раз уж nova отправляет уведомления, установите и настройте StackTach. Поскольку StackTach является относительно новым продуктом и постоянно меняется, инструкции по установке будут быстро устаревать. Пожалуйста, обращайтесь к ресурсу StackTach GitHub repo ( https://github.com/rackerlabs/ stacktach ) для получения инструкций и демонстрационных видео.

Мониторинг

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

Мониторинг процессов

Основной вид оповещающего мониторинга является простой проверкой и удостоверения в том, что требуемый процесс запущен. Например, убедитесь, что в контроллере облака запущена служба 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/novaapi --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/novaapi --config-file=/etc/nova/nova.conf
nova 12794 0.0 0.2 248636 77068 ? S Feb11 0:04 /usr/bin/python /usr/bin/novaapi --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 novacompute

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

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

Специфичные для OpenStack ресурсы

Такие ресурсы как память, диск и процессор являются общими для всех серверов (даже для не OpenStack серверов) и имеют важное значение для общего состояния работоспособности сервера. Когда имеешь дело конкретно с OpenStack, эти ресурсы важны по другой причине: достаточной обеспеченности доступной для запуска экземпляров. Существует несколько способов, которыми вы можете увидеть использование ресурсов OpenStack.

Первый обеспечивается командой nova:
# 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. Вы можете применить эту процедуру и развернуть ее в форматированный отчет:
+-----------------------------------+------------+------------+---------------+
| 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)

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

Интеллектуальные оповещения

Интеллектуальные оповещения можно рассматривать как одну из форм непрерывной интеграции для работы. Например, вы можете легко проверить что Glance запущен и работает, удостоверившись, что процессы glance-api и glance-registry запущены, или убедившись, что glance-api отвечает по порту 9292.

Но как вы можете определить, что образы были успешно загружены службой образов? Может оказаться, что диск, на который служба образов сохраняет образы заполнен или сервер S3 выключен. Естественно, вы можете проверить это, выполнив быструю загрузку образа:
#!/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 --containerformat=bare --disk-format=qcow2 < cirros-0.3.0-x86_64-disk.img

Выполняя этот сценарий и прокручивая его в оповещениях для вашей системы мониторинга (например, в Nagios), вы теперь получаете автоматизированный способ проверки работоспособности загрузки образов в каталог образов.

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

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

  • Анализ общих действий в вашем облаке
  • Создание способов автоматической проверки этих действий
  • Свертывание этих тестов в систему предупреждений

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

  • Могут ли экземпляры быть запущены и уничтожены?
  • Можно ли создавать пользователей?
  • Могут ли сохраняться и удаляться объекты?
  • Можно ли создавать и уничтожать тома?

Анализ тенденций

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

Анализ тенденций имеет несколько иной подход, чем оповещения. В то время, как оповещения интересуются двузначным результатом (удастся ли проверка или нет), анализ тенденций записывает текущее состояние в определенный момент времени. Как только необходимое количество временных отметок было записано, вы можете увидеть, как значение изменяется с течением времени.

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

  • Число экземпляров в каждом вычислительном узле
  • Типы используемых особенностей
  • Количество используемых томов
  • Почасовое количество запросов к хранилищам объектов
  • Почасовое количество nova-api запросов
  • Статистика ввода/ вывода из ваших служб хранения

В качестве примера: запись использования 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.

Такой инструмент, как collectd, может быть использован для хранения подобной информации. Поскольку collectd выходит за рамки данной книги, хорошей отправной точкой будет использование collectd для хранения результатов в виде типа данных счетчика (COUNTER). Более подробную информацию можно найти в документации collectd (https://collectd.org/wiki/index.php/Data_source).

Глава 12 Оглавление Глава 14
 
Перевод: Copyright © 2014  .
All rights reserved.
Ссылки обязательны (Refs and links obligatory).		 http://www.mdl.ru