Сервис спроектирован как расширяемый за счет подключаемых агентов сбора информации и легко маштабируемый горизонтально. Ceilometer поддерживает два способа сбора данных. Предпочтительный метод сбора при помощи очереди сообщений. Реализуется сервисом ceilometer-collector. Данный сервис запускается на одном или более управляющих узлах и отслеживает очередь сообщений. Сборщик получает уведомления от инфраструктурных сервисов (Nova, Glance, Cinder, Neutron, Swift, Keystone, Heat), затем преобразует их в сообщения телеметрии и отправляет обратно в очередь сообщений. Сообщения телеметрии записываются в хранилище без преобразований. Второй, менее предпочтительный способ - через опрашивающие инфраструктуру агенты. При помощи вызовов API или других инструментов агенты периодически запрашивают у сервисов необходимую информацию.
В веб-интерфейсе OpenStack за отображение информации Ceilometer отвечают две вкладки на странице Admin->System->Resource Usage (на рисунке). Намного больше возможностей предоставляет клиент командной строки ceilometer который использует RESTful API.
Попробуем запросить метрики телеметрии для которых уже есть записи в базе данных:
$ ceilometer meter-list
+---------------------+-------+----------+-------------+---------+------------+
| Name | Type | Unit | Resource ID | User ID | Project ID |
+---------------------+-------+----------+-------------+---------+------------+
| disk.ephemeral.size | gauge | GB | 66746d4a-.. | f3aab.. | 9c1c71f2.. |
| disk.root.size | gauge | GB | 66746d4a-.. | f3aab.. | 9c1c71f2.. |
| instance | gauge | instance | 66746d4a-.. | f3aab.. | 9c1c71f2.. |
| instance:m2.tiny | gauge | instance | 66746d4a-.. | f3aab.. | 9c1c71f2.. |
| memory | gauge | MB | 66746d4a-.. | f3aab.. | 9c1c71f2.. |
| vcpus | gauge | vcpu | 66746d4a-.. | f3aab.. | 9c1c71f2.. |
+---------------------+-------+----------+-------------+---------+------------+
Нужно обратить внимание, что данная команда выведет данные, только если они были предварительно собраны, поэтому если вы запускаете команду ceilometer первый раз после установки сервиса, запустите при помощи nova boot хотя бы одну виртуальную машину. Ограничить вывод по конкретному ресурсу, например по определенному экземпляру виртуальной машины можно добавив опции --query resource=
Можно также попробовать вывести все измерения для заданной метрики:
$ ceilometer sample-list -m instance
+-------------+----------+-------+--------+----------+----------------------------+
| Resource ID | Name | Type | Volume | Unit | Timestamp |
+-------------+----------+-------+--------+----------+----------------------------+
| 66746d4a-.. | instance | gauge | 1.0 | instance | 2015-05-31T18:51:36.981000 |
| 66746d4a-.. | instance | gauge | 1.0 | instance | 2015-05-31T18:51:23.358000 |
+-------------+----------+-------+--------+----------+----------------------------+
Или получить статистику, опять же в разрезе заданной метрики:
$ ceilometer statistics -m instance
+--------+--------------+-------------+-----+-----+-----+------+-------+----------+----------------+--------------+
| Period | Period Start | Period End | Max | Min | Avg | Sum | Count | Duration | Duration Start | Duration End |
+--------+--------------+-------------+-----+-----+-----+------+-------+----------+----------------+--------------+
| 0 | 2015-05-16.. | 2015-05-1.. | 1.0 | 1.0 | 1.0 | 46.0 | 46 | 1316727 | 2015-05-16T1.. | 2015-05-31.. |
+--------+--------------+-------------+-----+-----+-----+------+-------+----------+----------------+--------------+
Более сложные запросы можно создавать при помощи команды ceilometer query-samples используя опции --filter, --orderby и —limit.
Данные собранные сервисом ceilometer-collector также можно отправлять в различные внешние сервисы и системы при помощи механизма публикаций. За эти настройки отвечает файл pipeline.yaml, находящийся в директории /etc/ceilometer. Для дальнейших экспериментов поправим в этом файле периодичность снятия метрик по процессору с десяти минут до одной минуты. Соответствующая часть файла должна выглядеть:
- name: cpu_source
interval: 60
Попробуем познакомиться с триггерами или сигналами оповещения (alarms). Триггер может быть в трех состояниях: «Ok», «Тревога» и «Не достаточно данных». Правила триггеров могут объединяться при помощи операторов AND и OR. К триггеру можно привязать определенное правило, которое чаще всего HTTP-команда POST для заданного URL. Можно также в качестве действия выбрать запись в файл журнала, но это используется только для отладки, поскольку необходим доступ с правами администратора облака.
Попробуем создать простой триггер для виртуальной машины. Для начала запустим экземпляр:
$ source keystonerc_demo
$ nova boot --flavor m2.tiny --image cirros-0.3.3-x86_64 --key-name demokey1 --security-groups demo-sgroup mytest1
$ nova add-floating-ip mytest1 10.100.1.101
$ nova list
+-------+---------+--------+------------+-------------+-----------------------+
| ID | Name | Status | Task State | Power State | Networks |
+-------+---------+--------+------------+-------------+-----------------------+
| b99.. | mytest1 | ACTIVE | - | Running | demo-net=172.16.0.21, |
| | | | | | 10.100.1.101 |
+-------+---------+--------+------------+-------------+-----------------------+
В выводе последней команды нас интересует ID экземпляра (в таблице для экономии места первый столбец сокращен). Создадим триггер используя этот ID:
$ source keystonerc_admin
$ ceilometer alarm-threshold-create --name myalarm1 --meter-name cpu_util --threshold 60.0 --comparison-operator gt --statistic avg --period 60 --evaluation-periods 3 --alarm-action 'log://' --query resource_id=b99e45af-95d2-436f-bfc6-64e5bfa999de
+---------------------------+--------------------------------------+
| Property | Value |
+---------------------------+--------------------------------------+
| alarm_actions | [u'log://'] |
| alarm_id | c33000db-a4eb-41ea-9742-96e5d7b4d034 |
| comparison_operator | gt |
| description | Alarm when cpu_util is gt a avg of |
| | 60.0 over 60 seconds |
| enabled | True |
| evaluation_periods | 3 |
| exclude_outliers | False |
| insufficient_data_actions | [] |
| meter_name | cpu_util |
| name | myalarm1 |
| ok_actions | [] |
| period | 60 |
| project_id | |
| query | resource_id == b99e45af-95d2-436f-.. |
| repeat_actions | False |
| state | insufficient data |
| statistic | avg |
| threshold | 90.0 |
| type | threshold |
| user_id | 595c7da34b8e41bb812a0f3ecd6e7260 |
+---------------------------+--------------------------------------+
Мы создали триггер с именем myalarm1, который сработает если средняя загрузка процессора виртуальной машины превысит 60% для трех измерений подряд через каждые 60 секунд. Как видно из вывода команды, сразу после создания триггер находится в состоянии «недостаточно данных» (insufficient data). Подождем несколько минут и выполним команду:
$ ceilometer alarm-list
+-----------+----------+-------+---------+------------+--------------------------------+------------------+
| Alarm ID | Name | State | Enabled | Continuous | Alarm condition | Time constraints |
+-----------+----------+-------+---------+------------+--------------------------------+------------------+
| c33000d.. | myalarm1 | ok | True | False | cpu_util > 60.0 during 3 x 60s | None |
+-----------+----------+-------+---------+------------+--------------------------------+------------------+
Состояние триггера изменилось на «Ok». Это значит, что данные собираются, но заданное условие не наступило. Проверим загрузку процессора:
$ ceilometer sample-list --meter cpu_util -q 'resource_id=b99e45af-95d2-436f-bfc6-64e5bfa999de'
+--------------------------------------+----------+-------+---------------+------+---------------------+
| Resource ID | Name | Type | Volume | Unit | Timestamp |
+--------------------------------------+----------+-------+---------------+------+---------------------+
| b99e45af-95d2-436f-bfc6-64e5bfa999de | cpu_util | gauge | 10.868852459 | % | 2015-06-02T19:05:09 |
| b99e45af-95d2-436f-bfc6-64e5bfa999de | cpu_util | gauge | 9.81632653061 | % | 2015-06-02T19:04:08 |
| b99e45af-95d2-436f-bfc6-64e5bfa999de | cpu_util | gauge | 6.875 | % | 2015-06-02T19:03:19 |
+--------------------------------------+----------+-------+---------------+------+---------------------+
или суммарную статистику:
$ ceilometer statistics -m cpu_util -q 'resource_id=b99e45af-95d2-436f-bfc6-64e5bfa999de'
+--------+-------------+------------+-------+------+------+-------+-------+----------+---------------+--------------+
| Period | Period Start| Period End | Max | Min | Avg | Sum | Count | Duration | Duration Start| Duration End |
+--------+-------------+------------+-------+------+------+-------+-------+----------+---------------+--------------+
| 0 | 2015-06-02T1| 2015-06-02T| 14.35 | 6.87 | 11.9 | 250.6 | 21 | 1189.0 | 2015-06-02T19 | 2015-06-02T1 |
+--------+-------------+------------+-------+------+------+-------+-------+----------+---------------+--------------+
Действительно, значение около десяти процентов. Исправим это, подключившись к виртуальной машине:
$ ssh -i demokey1 cirros@10.100.1.101
$ md5sum /dev/zero
Проверим что команда md5sum действительно загрузила процессор более чем на шестьдесят процентов:
$ ceilometer sample-list --meter cpu_util -q 'resource_id=b99e45af-95d2-436f-bfc6-64e5bfa999de'
+--------------------------------------+----------+-------+---------------+------+---------------------+
| Resource ID | Name | Type | Volume | Unit | Timestamp |
+--------------------------------------+----------+-------+---------------+------+---------------------+
| b99e45af-95d2-436f-bfc6-64e5bfa999de | cpu_util | gauge | 69.7666666667 | % | 2015-06-02T20:20:37 |
| b99e45af-95d2-436f-bfc6-64e5bfa999de | cpu_util | gauge | 88.7627118644 | % | 2015-06-02T20:19:37 |
| b99e45af-95d2-436f-bfc6-64e5bfa999de | cpu_util | gauge | 82.6 | % | 2015-06-02T20:18:38 |
+--------------------------------------+----------+-------+---------------+------+---------------------+
и триггер сработал:
$ ceilometer alarm-list
+-----------+----------+-------+---------+------------+--------------------------------+------------------+
| Alarm ID | Name | State | Enabled | Continuous | Alarm condition | Time constraints |
+-----------+----------+-------+---------+------------+--------------------------------+------------------+
| c33000d.. | myalarm1 | alarm | True | False | cpu_util > 60.0 during 3 x 60s | None |
+-----------+----------+-------+---------+------------+--------------------------------+------------------+
При необходимости можно также обновить триггер, например задать границу срабатывания в 75 процентов:
$ ceilometer alarm-threshold-update --threshold 75.0 c33000db-a4eb-41ea-9742-96e5d7b4d034
Наконец, можно просмотреть историю по триггеру:
$ ceilometer alarm-history -a c33000db-a4eb-41ea-9742-96e5d7b4d034
+------------------+----------------------------+----------------------+
| Type | Timestamp | Detail |
+------------------+----------------------------+----------------------+
| rule change | 2015-06-.. | rule: cpu_util > 75.0 during 3 x 60s |
| state transition | 2015-06-.. | state: ok |
| state transition | 2015-06-.. | state: alarm |
| creation | 2015-06-.. | name: myalarm1 |
| | | description: Alarm when cpu_util is |
| | | gt a avg of 60.0 over 60 seconds |
| | | type: threshold |
| | | rule: cpu_util > 60.0 during 3 x 60s |
| | | time_constraints: None |
+------------------+----------------------------+----------------------+
Когда триггер нам больше не нужен, его можно удалить командой ceilometer alarm-delete.
Комментариев нет:
Отправить комментарий