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

За получение метрик и их первичную обработку, отвечает компонент OpenStack Ceilometer ^[1].

На протяжении долгого времени он был единственным компонентом OpenStack предоставляющим все базовые возможности телеметрии.

В дальнейшем разработчики разделили функции Ceilometer между несколькими продуктами:

• Aodh ^[2] — сервис оповещений;
• Gnocchi ^[3] — сервис хранения агрегированных измерений;
• Panko ^[4] — сервис хранения информации о событиях;
• Ceilometer ^[1] — сервис сбора измерений.

Aodh и Panko останутся за рамками этой статьи.

Сбор измерений — OpenStack Ceilometer

Ceilometer может собирать измерения об использовании CPU, RAM, сетевых интерфейсов, дисков, значений температуры из различных источников:

• напрямую из гипервизоров (KVM ^[5], Hyper-V ^[6], XEN ^[7], VMware ^[8]);
• из очереди сообщений (RabbitMQ ^[9], ZeroMQ ^[10], Kafka ^[11]);
• посредством опроса других компонентов OpenStack через REST API;
• посредством опроса оборудования по протоколам SNMP или IPMI.

Ранее Ceilometer также предоставлял API для работы с собранными измерениями, метриками и ресурсами. Но начиная с релиза OpenStack Ocata ^[12] соответствующая функциональность была убрана из этого компонента, так как основным бэкендом для Ceilometer стал Gnocchi ^[13], имеющий собственный полнофункциональный API для работы со всеми этими объектами.

Мы пробовали использовать Ceilometer из релиза OpenStack Juno ^[14] несколько лет назад.

Наша первая версия биллинга для проекта VPC ^[15] отправляла в него отчёты, где они были доступны и служебным программам и пользователям, авторизованным с помощью стандартного токена OpenStack Keystone ^[16].

Основными бэкендами для Ceilometer в те времена были SQL база данных и MongoDB ^[17]. К сожалению, оба варианта после полугода использования переставали справляться с нагрузкой. Это происходило из-за того, что структура собираемых данных была слишком свободной, неиндексируемой и излишне подробной.

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

Для преодоления архитектурных проблем в 2014 году команда разработчиков сервисов телеметрии для OpenStack основала новый проект под названием Gnocchi. Подробное описание причин и выбранного способа решения можно прочитать в обзорной заметке в блоге основного разработчика Gnocchi – Жульена Данжу: OpenStack Ceilometer and the Gnocchi experiment ^[18].

Архитектура Ceilometer

Архитектура Ceilometer наглядно показана на схеме:

На каждом хосте, где установлен гипервизор, присутствует компонент Ceilometer Agent Compute ^[19], который собирает данные с виртуальных машин. Собранные данные в таком случае передаются центральному агенту Ceilometer Agent Notification ^[20] через очередь сообщений.

Если нужно собирать данные о загрузке физических хостов, то на них можно установить и использовать SNMP-агент. В таком случае, сбор данных будет осуществляться центральным агентом Ceilometer Agent Central ^[20].

После обработки эти данные будут переданы агенту Ceilometer Agent Notification, который отправит их в выбранный бэкенд для хранения.

Ещё центральный агент Ceilometer Agent Notification может собирать информацию о событиях других компонентов OpenStack, прослушивая очередь сообщений. Это может быть полезно, если требуется отслеживать и сохранять информацию о создании, изменении или удалении серверов, дисков или портов.

До недавних пор (а более точно — до релиза OpenStack Ocata ^[21], который состоялся в феврале этого года) наряду с Ceilometer Agent Notification и Ceilometer Agent Central, на управляющие хосты требовалось устанавливать еще один компонент — Ceilometer Collector.

Сейчас этот компонент уже не используется. Все его функции выполняет Ceilometer Agent Notification.

Настройка Ceilometer

Основными конфигурационными файлами Ceilometer являются:

• ceilometer.conf — файл, описывающий все базовые параметры Ceilometer  (логирование, использование очереди сообщений, аутентификация, координация процессов Ceilometer, и прочее);
• pipeline.yaml — файл, описывающий, какую информацию и откуда необходимо собирать;
• gnocchi_resources.yaml — описание соответствия объектов Ceilometer и Gnocchi (об этом мы поговорим позднее).

Шаблон файла ceilometer.conf со всеми доступными опциями можно скачать или сгенерировать, используя официальную документацию: Ceilometer Configuration Options ^[22].

Файл pipeline.yaml требуется заполнить самостоятельно.
Пример:

---
sources:                        #Источники данных
  - interval: 600               # Интервал получения данных (секунды)
    meters:                     # Список метрик
      - memory.usage            # Используемая память внутри виртуальной машины (МБ)
      - memory.resident         # Память, используемая виртуальной машиной на хосте (МБ)
    name: memory_meters         # Имя источника измерений
    sinks:                      # Список получателей данных
     
 - memory.sink                  # Имя получателя данных
  - interval: 600               # Интервал получения данных (секунды)
    meters:                     # Список метрик
      - disk.device.read.bytes  # Суммарное количество прочитанных байт на диске
      - disk.device.write.bytes # Суммарное количество записанных байт на диске
    name: disk_meters           # Имя источника измерений
    sinks:                      # Список потребителей измерений
      - disk_sink               # Имя потребителя измерений

sinks:                          # Потребители измерений 
  - name: memory_sink           # Имя получателя данных  (используется источником "memory_meters")
    publishers:                 # Список бэкендов хранения, в которые будут записаны измерения
      - gnocchi://              # Используется только бэкенд Gnocchi

  - name: disk_sink             # Имя получателя данных (используется источником "memory_meters")
    publishers:                 # Список бэкендов для хранения измерений
      - gnocchi://              # Используется только бэкенд Gnocchi (об этом речь пойдёт ниже)

В этом файле мы можем дополнительно указать трансформации для собираемых данных. К примеру, мы можем преобразовать все полученные значения метрик memory.usage и memory.resident из мегабайт в килобайты. Заодно переименуем эти метрики и добавим им единицы измерения.

Для этого нам потребуется отредактировать потребителя memory_sink таким образом:

sinks:
  - name: memory_sink
    transformers:
      - name: "unit_conversion"                 # Используем встроенный метод unit_conversion
        parameters:
          source:
            map_from:
              name: "memory\.(usage|resident)" # Что переименовать
          target:
            map_to:
              name: "memory.\1.kilobytes"      # Как переименовать
            scale: "volume * 1024.0"            # Как преобразовать значения
            unit: "KB"                          # Добавление единицы измерения
    publishers:
      - gnocchi://

Подробную информацию о формате данного файла и применении других преобразований можно узнать в официальной документации: Data processing and pipelines ^[23].

Далее мы рассмотрим проект Gnocchi, который позволяет хранить собираемые измерения в агрегированном виде и предоставляет API для работы с ними.

Хранение данных — Gnocchi

Проект Gnocchi представляет из себя базу данных временных рядов (time-series database).
Следует отметить, что, в начале мая 2017г., разработчики Gnocchi решили вывести ^[24] этот проект из инфраструктуры OpenStack.

Кодовая база была перенесена в GitHub ^[25], а в качестве багтрекера используется механизм GitHub Issues ^[26]. Одна из основных причин — желание позиционировать Gnocchi не только как бэкенд к Ceilometer, но как более универсальный продукт, подходящий под другие решения. К примеру, в репозитории Gnocchi уже сейчас имеется плагин ^[27] для сохранения данных из Collectd ^[28] и плагин ^[29] для построения графиков в Grafana ^[30].

Рассмотрим устройство и особенности работы Gnocchi более подробно.

Архитектура Gnocchi

Gnocchi состоит из 2х основных компонентов:

• API, через который происходит сохранение и обновление данных (например от Ceilometer, или вручную), а также получение агрегированных данных;
• Metricd — демон, который обрабатывает только-что полученные и еще не отсортированные данные, и сохраняет их в нужном виде в выбранное хранилище (Ceph ^[31], Redis ^[32], OpenStack Swift ^[33] или на локальную файловую систему).

Начиная с версии 3.1 в Gnocchi появилась поддержка разных типов хранилищ для обработанных и необработанных данных. Такое разделение позволяет размещать «горячие» неагрегированные данные на быстром хранилище (например, Redis, поддержка которого появилась в Gnocchi версии 4.0), а данные в агрегированном виде сохранять уже в более надежный, масштабируемый бэкенд (например, Ceph, поддержка которого была еще в самой первой версии Gnocchi).

Помимо непосредственного хранилища данных, для Gnocchi дополнительно требуется SQL-база данных, где хранятся индексы метрик и их метаданные. Для этого можно использовать MySQL или PostgreSQL. Gnocchi использует собственных подход к сохранению измерений, так как все перечисленные технологии не предоставляют возможность хранить данные в виде временных рядов.

Сохранение данных в Gnocchi

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

Мы можем создать архивную политику при помощи консольного клиента python-gnocchiclient ^[34]. Для примера создадим политику с именем memory_policy, которая содержит 3 метода агрегации — минимум, максимум и среднее, и 2 определения того, как данные будут храниться. Первое определение говорит о том, что мы будем хранить данные с точностью 1 час на протяжении 7 дней. Второе говорит о том, что мы будем хранить данные с точностью 1 день на протяжении 1 года.

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

controller:~# gnocchi archive-policy create memory_policy 
> -b 72 
> -m min -m max -m mean 
> -d 'granularity:1h,timespan:7d' 
> -d 'granularity:1d,timespan:365d'

В ответ мы получим описание созданной политики:

.rce lang=«python»>
+---------------------+-------------------------------------------------------------------------+
| Field | Value |
+---------------------+-------------------------------------------------------------------------+
| aggregation_methods | max, min, mean |
| back_window | 72 |
| definition | — points: 168, granularity: 1:00:00, timespan: 7 days, 0:00:00 |
| | — points: 365, granularity: 1 day, 0:00:00, timespan: 365 days, 0:00:00 |
| name | memory_policy |
+---------------------+-------------------------------------------------------------------------+

Обратите внимание на то, что для определений также было автоматически рассчитано значение points. Эта величина считается по формуле:
Points = Timespan / Granularity

Она требуется для расчета места, которое будут занимать значения сохраняемых метрик.
Разработчики Gnocchi предлагают ^[35] использовать следующую формулу для расчета требуемого места:
Size (in bytes) = 8 * points * aggregation methods

Указанная формула является расчетом места для худшего случая, так как информация всегда хранится в сжатом виде. Используя эту формулу, мы можем рассчитать объем места для архивной политики memory_policy. Для первого определения (точность 1 час в течение 7 дней) мы получаем 4032 байта:
4032 (байт) = 8 * 168 * 3

А для второго определения (точность 1 день на протяжении года) получаем 8760 байт:
8760 (байт) = 8 * 365 * 3

Полученные значения отображают используемое место для одной метрики, хранимой согласно политике memory_policy.
Если мы, к примеру, начнем собирать 2 метрики — memory.usage и memory.resident для 2000 виртуальных машин, то нам потребуется:
2000 * 2 * 4032 (байт) = 16.128 Мбайт (для 7 дней)
2000 * 2 * 8760 (байт) = 35.04 Мбайт (для 1 года)

Ресурсы Gnocchi

Все метрики, сохраняемые в Gnocchi, относятся к каким либо ресурсам. Ресурс — это абстрактный объект, который может содержать несколько метрик и также может иметь дополнительные поля, описанные в типе этого ресурса.
Взаимоотношение объектов метрика — ресурс — тип ресурса выглядит так:

К примеру, мы имеем набор ресурсов типа instance_memory. Каждый ресурс этого типа будет содержать метрики memory.usage и memory.resident.
Если мы собираем метрики с 2000 виртуальных машин, то число ресурсов instance_memory также будет равно 2000.
Для таких ресурсов может быть полезно сохранять дополнительную информацию, например, имя хоста гипервизора, на котором запущена виртуальная машина или идентификатор образа операционной системы (хранящегося в сервисе OpenStack Glance ^[36]), из которого виртуальная машина была создана.

Создадим тип ресурса instance_memory при помощи консольной команды. Укажем описанные дополнительные поля host, image_ref, для хранения имени хоста и идентификатора образа, сделаем при этом поле host обязательным:

controller:~# gnocchi resource-type create instance_memory 
> -a host:string:true:min_length=0:max_length=255 
> -a image_ref:string:false:min_length=0:max_length=255

В ответ мы получим описание созданного типа ресурса:

+----------------------+-----------------------------------------------------------+
| Field                | Value                                                     |
+----------------------+-----------------------------------------------------------+
| attributes/host      | max_length=255, min_length=0, required=True, type=string  |
| attributes/image_ref | max_length=255, min_length=0, required=False, type=string |
| name                 | instance_memory                                           |
| state                | active                                                    |
+----------------------+-----------------------------------------------------------+

Аналогичным образом создадим типы ресурсов instance_cpu и instance_disk. Первый будет иметь такие же дополнительные поля, как и instance_memory, а второй будет иметь поле instance_id, указывающий идентификатор сервера, к которому подключен диск:

controller:~# gnocchi resource-type create instance_cpu 
> -a host:string:true:min_length=0:max_length=255 
> -a image_ref:string:false:min_length=0:max_length=255

+----------------------+-----------------------------------------------------------+
| Field                | Value                                                     |
+----------------------+-----------------------------------------------------------+
| attributes/host      | max_length=255, min_length=0, required=True, type=string  |
| attributes/image_ref | max_length=255, min_length=0, required=False, type=string |
| name                 | instance_cpu                                              |
| state                | active                                                    |
+----------------------+-----------------------------------------------------------+

controller:~# gnocchi resource-type create instance_disk 
> -a instance_id:uuid:true

+------------------------+--------------------------+
| Field                  | Value                    |
+------------------------+--------------------------+
| attributes/instance_id | required=True, type=uuid |
| name                   | instance_disk            |
| state                  | active                   |
+------------------------+--------------------------+

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

Конфигурация Ceilometer + Gnocchi

Для того, чтобы Ceilometer начал использовать Gnocchi в качестве бэкенда, требуется:

1. Добавить опцию meter_dispatchers в файл ceilometer.conf:

[DEFAULT]
meter_dispatchers = gnocchi

2. Создать файл gnocchi_resources.yaml, который описывает соответствия метрик Ceilometer и типов ресурсов Gnocchi, а также указывает дополнительные поля типов ресурсов:

---
resources:                                  
  - resource_type: instance_memory           # Тип ресурса для выбранных метрик
    metrics:
      - 'memory.usage'                       # Метрика используемой памяти внутри виртуальной машины
      - 'memory.resident'                    # Метрика используемой памяти виртуальной машиной на хосте
    attributes:
      host: resource_metadata.instance_host  # Метаданные о хосте виртуальной машины
      image_ref: resource_metadata.image_ref # Метаданные об образе виртуальной машины

  - resource_type: instance_disk             # Тип ресурса для выбранных метрик
    metrics:
      - 'disk.device.read.bytes'             # Метрика суммарного количества прочитанных байт на диске
      - 'disk.device.write.bytes'            # Метрика суммарного количества записанных байт на диске
    attributes:
      instance_id: resource_metadata.instance_id      # Метаданные с id виртуальной машины

  - resource_type: instance_cpu              # Тип ресурса для выбранной метрики
    metrics:
      - 'cpu_util'                           # Метрика утилизации процессора внутри виртуальной машины
    attributes:
      host: resource_metadata.instance_host  # Метаданные о хосте виртуальной машины
      image_ref: resource_metadata.image_ref # Метаданные об образе виртуальной машины

После запуска Ceilometer, начнется сбор данных и их отправка в Gnocchi (при условии что он был настроен согласно документации ^[37]).

Вы можете следить за статусом обработки новых данных и сохранением их в агрегированном виде в выбранное хранилище при помощи команды:

controller:~# gnocchi status
+-----------------------------------------------------+-------+
| Field                                               | Value |
+-----------------------------------------------------+-------+
| storage/number of metric having measures to process | 93    |
| storage/total number of measures to process         | 93    |
+-----------------------------------------------------+-------+

В приведенном выводе можно увидеть, что сейчас процессы Gnocchi-metricd обрабатывают 93 измерения, распределенные по 93 метрикам.
При помощи этой команды можно следить, справляется ли компонент Gnocchi-metricd с поступающими метриками.
Скорость обработки будет напрямую зависеть от количества процессов Gnocchi-metricd и производительности выбранного хранилища данных.

Вывод агрегированной информации

После того, как полученные измерения будут обработаны и сохранены, можно будет получить доступ к ресурсам и измерениям Gnocchi.
Выведем ресурсы с типом instance_memory, ограничим вывод тремя ресурсами, и отобразим только 4 колонки — идентификатор самого ресурса его тип, имя хоста виртуальной машины и идентификатор ее образа:

controller:~# gnocchi resource list --type instance_memory --limit 3 --column id --column type --column host --column image_ref
+--------------------------------------+-----------------+-----------+--------------------------------------+
| id                                   | type            | host      | image_ref                            |
+--------------------------------------+-----------------+-----------+--------------------------------------+
| 945ad3cc-2617-4b19-a681-5a1cb96d71e1 | instance_memory | compute00 | 3456e843-b7fe-42be-8c4c-0c7d1c2d09c7 |
| e33c895f-e38a-4f8e-be07-8fe0d7c8275f | instance_memory | compute02 | 27bbfeb7-0706-4d11-bb59-f98d6b08dc1c |
| 023fed66-3fdd-43b6-b02e-325da55b62cc | instance_memory | compute04 | f0f5e0aa-4615-462e-8340-b8258aae90e2 |
+--------------------------------------+-----------------+-----------+--------------------------------------+

Отобразим колонки с метриками и типом для ресурса 945ad3cc-2617-4b19-a681-5a1cb96d71e1:

controller:~# gnocchi resource show --column metrics --column type 945ad3cc-2617-4b19-a681-5a1cb96d71e1
+---------+-------------------------------------------------------+
| Field   | Value                                                 |
+---------+-------------------------------------------------------+
| metrics | memory.resident: f56b76ad-5ce8-49fe-975f-6e5da412df31 |
|         | memory.usage: aa757f46-52b9-40de-898c-524dfe29b7bc    |
| type    | sel_instance                                          |
+---------+-------------------------------------------------------+

Посмотрим на средние значения для измерений метрики aa757f46-52b9-40de-898c-524dfe29b7bc, в интервале 12:00 — 18:00 для даты 25.08.2017, и точностью равной одному часу:

controller:~# gnocchi measures show --aggregation mean --granularity 3600 --start 2017-08-25T12:00 --stop 2017-08-25T18:00 aa757f46-52b9-40de-898c-524dfe29b7bc

+---------------------------+-------------+---------------+
| timestamp | granularity   | value       |               |
+---------------------------+-------------+---------------+
| 2017-08-25T12:00:00+00:00 | 3600.0      | 2231.75       |
| 2017-08-25T13:00:00+00:00 | 3600.0      | 2238.66666667 |
| 2017-08-25T14:00:00+00:00 | 3600.0      | 2248.58333333 |
| 2017-08-25T15:00:00+00:00 | 3600.0      | 2259.08333333 |
| 2017-08-25T16:00:00+00:00 | 3600.0      | 2240.41666667 |
| 2017-08-25T17:00:00+00:00 | 3600.0      | 2249.66666667 |
+---------------------------+-------------+---------------+

Агрегированную информацию можно получать не только с помощью консольной утилиты, но и через REST API. Рассмотрим несколько примеров:

Получение значений метрики memory.usage для ресурса типа instance_memory, с точностью 24 часа, начиная с даты 28.08.2017:

controller:~# curl -XGET 
> -H 'Content-Type: application/json' 
> -H 'X-Auth-Token: KEYSTONE_TOKEN' 
> 'controller:8041/v1/resource/instance_memory/684f5b56-2c06-485a-ae1a-66ab5c4175fb/metric/memory.usage/measures?start=2017-08-28&granularity=86400' 
> | python -m json.tool

[
    [
        "2017-08-28T00:00:00+00:00",
        86400.0,
        2645.9444444444443
    ],
    [
        "2017-08-29T00:00:00+00:00",
        86400.0,
        2671.625
    ],
    [
        "2017-08-30T00:00:00+00:00",
        86400.0,
        2681.5438596491226
    ]
]

Поиск ресурса с типом instance_memory, созданного после 29.08.2017, со значением «compute19» в поле host:

controller:~# curl -XPOST 
> -H 'Content-Type: application/json' 
> -H 'X-Auth-Token: KEYSTONE_TOKEN' 
> 'controller:8041/v1/search/resource/instance_memory 
> -d '{
>   "and": [
>     {
>       "=": {
>         "host": "compute19"
>       }
>     },
>     {
>       ">": {
>         "started_at": "2017-08-29"
>       }
>     }
>   ]
> }' 
> | python -m json.tool
[
    {
        "created_by_project_id": "99288fd3d178459f808c1e8bc2cf9e49",
        "created_by_user_id": "7dd0582d38aa471bbe8995f63a1293a9",
        "creator": "7dd0582d38aa471bbe8995f63a1293a9:99288fd3d178459f808c1e8bc2cf9e49",
        "ended_at": null,
        "host": "compute19",
        "id": "9052e237-ad17-47be-8aa5-10aacbf6717f",
        "image_ref": "e12ef13d-783c-4030-9251-ad2c8e270453",
        "metrics": {
            "memory.resident": "365db8ce-f4f7-4e59-ac9f-03dcdfe81195",
            "memory.usage": "084157b7-09d3-45e7-a869-fad62062025a"
        },
        "original_resource_id": "9052e237-ad17-47be-8aa5-10aacbf6717f",
        "project_id": "99288fd3d178459f808c1e8bc2cf9e49",
        "revision_end": null,
        "revision_start": "2017-08-30T20:35:19.214598+00:00",
        "started_at": "2017-08-30T20:35:19.214577+00:00",
        "type": "instance_memory",
        "user_id": "7dd0582d38aa471bbe8995f63a1293a9"
    }
]

Получение агрегации по максимальным значениям метрик memory.resident с точность до одного часа для виртуальных машин, запущенных на хосте compute19; метрики систематизированы по идентификаторам проектов:

controller:~# curl -XPOST 
> -H 'Content-Type: application/json' 
> -H 'X-Auth-Token: KEYSTONE_TOKEN' 
> 'controller:8041/v1/aggregation/resource/instance_memory/metric/memory.resident&aggregation=max&granularity=3600&groupby=project_id' 
> -d '{
>   "=": {
>     "host": "compute19"
>   }
> }' 
> | python -m json.tool
[
  {
    "group": {
      "project_id": "eef577b17cfe4432b7769d0078dbb625"
    },
    "measures": [
      [
        "2017-08-29T09:00:00+00:00",
        3600,
        735
      ],
      [
        "2017-08-30T11:00:00+00:00",
        3600,
        949
      ]
    ]
  },
  {
    "group": {
      "project_id": "b998dbbb9b02474c9dc49ffc289eae8c"
    },
    "measures": [
      [
        "2017-08-29T09:00:00+00:00",
        3600,
        612
      ],
      [
        "2017-08-30T11:00:00+00:00",
        3600,
        642
      ]
    ]
  }
]

Другие примеры использования REST API доступны в официальной документации ^[38].

Статистика в сервисе VPC

В настоящее время мы используем описанные компоненты в сервисе VPC ^[15].
Пользователям доступны следующие метрики для виртуальных машин:

• утилизация процессора, в % (cpu_util);
• использование оперативной памяти, в МБ (memory.usage).

Метрики для дисков:

• количество байт/c на чтение и запись (disk.device.read.bytes, disk.device.write.bytes);
• количество запросов на чтение и запись в секунду (disk.device.read.requests, disk.device.write.requests).

И метрики для сетевых интерфейсов:

• количество бит/c входящего и исходящего трафика (network.incoming.bits, network.outgoing.bits);
• количество пакетов входящего и исходящего трафика в секунду (network.incoming.packets, network.outgoing.packets).

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

Графики использования процессора

Графики использования оперативной памяти

Графики нагрузки дисков

Графики нагрузки сетевых интерфейсов

Заключение

В этой статье мы рассмотрели два компонента для сбора, хранения и отображения статистики об объектах OpenStack.

Если у вас возникли вопросы, добро пожаловать в комментарии.

Если вам интересно было бы попробовать gnocchi в качестве сервиса, в который вы смогли бы писать собственные данные — напишите нам об этом.

Также будем рады, если вы поделитесь собственным опытом использования Ceilometer или Gnocchi.

Автор: aozerov

Источник ^[39]