6.6.4 Подключение внешних систем мониторинга

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

Построение системы мониторинга облачной инфраструктуры должно быть основано на владении подробной информацией о внутренних процессах взаимодействия между отдельными компонентами ПО, а также подсистемами обслуживания (Control, Network, Compute).

Большинство служб OpenStack и ключевые модули TIONIX реализуют модель сетевого взаимодействия, основанную на использовании (сетевых) протоколов, в частности – REST [1]. Этот протокол может быть использован для seamless-интеграции системы мониторинга, формирющей запросы, отправляемые к тем или иным службам/модулям (Раздел 6.6.2).

Обмен данными в REST происходит с помощью методов HTTP: GET, POST, PUT, DELETE.

Ниже приведена информация, позволяющая организовать «сторонний» мониторинг подсистем, образующих:

– кластер, состоящий из одного и более управляющих узлов (контроллеров OpenStack);

– вычислительный пул, состоящий из нескольких вычислительных узлов, управляемых при помощи кластера.

6.6.4.1 Сервисы управляющих узлов

В каждом из контроллеров OpenStack – управляющих узлов кластера – должны работать определенные системные службы (сервисы). Полный список (перечень) приведен ниже (Таблица 6.2).

Таблица 6.2 Перечень сервисов облачного контроллера
Название системной службы
1 corosync
4 haproxy
5 Httpd [2]
6 memcached
7 neutron-dhcp-agent
8 neutron-l3-agent
9 neutron-metadata-agent
10 neutron-openvswitch-agent
11 neutron-server
14 openstack-cinder-api
15 openstack-cinder-scheduler
16 openstack-cinder-volume
17 openstack-glance-api
18 openstack-glance-registry
19 openstack-nova-api
20 openstack-nova-conductor
21 openstack-nova-consoleauth
22 openstack-nova-novncproxy
23 openstack-nova-scheduler
24 pacemaker
25 pcsd
26 rabbitmq-server
27 tionix-journal-api
28 tionix-journal-keystone-listener
29 tionix-journal-listener
30 tionix-journal-nova-listener
31 tionix-monitor-api
32 tionix-monitor-nova-listener
33 tionix-monitor-tionix-listener
34 tionix-node-control-agent
35 tionix-node-control-api
36 tionix-node-control-drs-trigger
37 tionix-node-control-node-syncer
38 tionix-node-control-node-tracker
39 tionix-node-control-nova-listener
40 tionix-node-control-worker
41 tionix-scheduler-beat
42 tionix-scheduler-worker
43 tionix-vdi-broker-api
44 tionix-vdi-keystone-listener
45 tionix-vdi-neutron-listener
46 tionix-vdi-nova-listener
47 tionix-vdi-project-syncer
48 tionix-vdi-server-api
49 tionix-vdi-worker

6.6.4.2 Сервисы вычислительных узлов

В каждом вычислительном узле облачной инфраструктуры должны работать системные службы, обеспечивающие нормальное функционирование и доступность гипервизора. Перечень сервисов приведен ниже (Таблица 6.3).

Таблица 6.3 Перечень сервисов вычислительных узлов облачной инфраструктуры
Название программного пакета
1 libvirtd
2 neutron-openvswitch-agent
3 openstack-ceilometer-compute
4 openstack-nova-compute
5 tionix-agent

6.6.4.3 Инфраструктурный сервер (Cobbler)

Инфраструктурный сервер с установленным ПО Сobbler [3] не принимает прямого участия в работе ПО OpenStack, однако предоставляет сервисы DNS и зеркало репозитория для остальных серверов.

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

Для мониторинга ИС может быть использован протокол HTTP, предоставляющий (фейковый) образ носителя данных – ISO.

6.6.4.4 Перечень портов для мониторинга

C целью обнаружения потенциально аварийных ситуаций необходимо регулярно проводить проверку доступности сетевых портов контроллера. Перечень представлен ниже (Таблица 6.4).

Таблица 6.4 Перечень сетевых портов контроллера
Название порта Номер порта
mysql 3306
memcached 11211
rabbitmq 5672
keystone 5000
keystone 35357
glance-api 9292
glance-registry 9191
neutron-server 9696
nova-api 8775
nova-api 8774
nova-placement 8778
cinder-api 8776
gnocchi-api 8041
tionix-journal-api 9360
tionix-monitor-api 9363
tionix-node-control-api 9362
tionix-scheduler-beat 10001
tionix-vdi-broker-api 9365
tionix-vdi-server-api 9364

Регулярность проверки (доступности) сетевых портов не регламентирована. Если не указано иного, то частота проверки «один раз в час» будет достаточной для того, чтобы организовать оперативное реагирование.

Внимание.

Чрезмерно частая проверка сетевых портов может повлечь за собой неустойчивость работы зависимых служб!

6.6.4.5 Проверка статусов служб

Некоторые службы OpenStack позволяют выполнение HTTP-запроса, осуществляющего так называемую «проверку здоровья» [4]:

– Keystone: http://manage.tionix.loc:35357/healthcheck;

– Gnocchi: http://internal.tionix.loc:8041/healthcheck;

– Glance API: http://internal.tionix.loc:9292/healthcheck;

– Glance Registry: http://internal.tionix.loc:9191/healthcheck.

При успешной работе службы возвращается HTTP-код – 200.

6.6.4.6 Извлечение данных телеметрии

Служба телеметрии (Ceilometer) архитектурно реализована агентами [5]. Некоторые модули телеметрии совмещают функциональность сбора данных, хранения сэмплов в БД, или предоставляют службу API, обрабатывающую входящие запросы.

Принципы работы службы изложены в официальной документации.

Агент вычислений (ceilometer-agent-compute) выполняется на каждом ВУ облачной инфраструктуры и отрабатывает (polls) статистику использования ресурсов. Фактически, ceilometer-polling – the polling agent – запускается с параметром --polling-namespace compute.

Центральный агент (ceilometer-agent-central) выполняется на центральном сервере обслуживания, чтобы отрабатывать (poll) статистику использования ресурсов для тех ресурсов, которые не связаны с инстансами или ВУ. Множество агентов может запускаться с целью горизонтального масштабирования (телеметрической) службы. Фактически, таким агентом является ceilometer-polling, запускаемый с параметром --polling-namespace central.

Агент уведомлений (ceilometer-agent-notification) выполняется на одном или нескольких центральных серверах обслуживания и потребляет сообщения, помещенные в очередь(и) сообщений, чтобы создавать (to build) данные событий и метрик. После чего данные публикуются в определенных (целевых) местах. По умолчанию, данные отправляются в Gnocchi (базу данных временных рядов), рекомендуемую для эффективного хранения и статистического анализа телеметрических данных.

Все перечисленные выше агенты взаимодуйствуют посредством шины сообщений OpenStack. Данные телеметрии спроектированы таким образом, чтобы они могли публиковаться в различные конечные точки (endpoints), а уже там накапливаться и анализироваться.

Для извлечения данных телеметрии программным способом может использоваться телеметрическое API [6], реализованное в виде стандартного протокола обмена REST API. Собранные сэмплы и связанная информация извлекается в виде списка метрик, определений тревог и т.д.

Ссылка на телеметрическое API URL может быть получена из сервисного каталога, предоставленного службой идентификации (OpenStack Identity), доступной (which is populated) втечение процесса инсталляции. Доступ к API для получения метрических данных требует предоставления действующего токена и подходящих прав [7].

Кроме того, поддерживаются бэкэнды тревог:

  • MySQL;
  • PostgreSQL.

Для получения событий поддерживаются следующие бэкэнды:

  • ElasticSearch;
  • MongoDB;
  • MySQL;
  • PostgreSQL;
  • HBase.

Сноски

[1]https://docs.openstack.org/keystone/victoria/admin/health-check-middleware.html
[2]keystone, gnocchi, horizon, nova-placement-api, tionix-scheduler-api, tionix-vdi-web
[3]https://cobbler.github.io/
[4]https://docs.openstack.org/keystone/victoria/admin/health-check-middleware.html
[5]https://docs.openstack.org/ocata/admin-guide/telemetry-system-architecture.html
[6]https://docs.openstack.org/ocata/admin-guide/telemetry-data-retrieval.html#telemetry-v2-api
[7]https://docs.openstack.org/ocata/admin-guide/telemetry-system-architecture.html#telemetry-users-roles-projects