Мы продолжаем цикл публикаций о внедрении инструментов и практик DevOps в нашей компании. Недавно мы рассказывали о том, как анализируем уязвимости с помощью нейронных сетей и нечеткой логики, а сегодня поговорим о внедрении системы мониторинга Zabbix в процессы разработки и тестирования.
Типичные проблемы тестирования
Одной из серьезных проблем, которую мы хотели решить с помощью внедрения практик DevOps была организация мониторинга ИТ-систем. До этого он осуществлялся недостаточно активно. Это приводило к целому ряду сложностей. Например, мы могли поздно заметить, что на диске нужной машины кончилось место, о проблемах сигнализировали перебои в работе сервисов и приложений. Все это острые проблемы для процесса разработки и тестирования, поскольку из-за таких ошибок продукт может быть нестабильным, а отловить в нем баги становится сложнее.
При тестировании продукта необходимо анализировать множество показателей: логи, загруженность сервера, доступность внутренних и внешних сервисов и т.д. Кроме того, от версии к версии список наблюдаемых параметров может изменяться.
Для решениях всех этих проблем мы решили интегрировать в процессы разработки и тестирования систему мониторинга Zabbix. Вот, как мы это сделали, и что получилось в итоге.
Как мы внедряли Zabbix
Вообще, системы мониторинга делятся по функциям и по типам. Разделение по функциям можно описать так:
- Мониторинг ситуации — оповещение о критических событиях и ошибках (классическая ситуация «SMS в 2 ночи»).
- Мониторинг трендов — информация собирается для дальнейшего анализа.
- Performance-мониторинг — отслеживание быстродействия системы.
Мониторинг по типам делится на:
- Системный мониторинг — анализируется состояние ОС и системных служб.
- Мониторинг приложений — реализуется внутри приложения.
- Бизнес-метрики — реализуется внутри приложения.
Применяемый нами механизм позволяет «закрывать» все эти функции и осуществлять системный мониторинг полностью, а мониторинг приложений — частично.
Для оптимизации процесса тестирования мы решили разграничить зоны ответственности между командой DevOps, разработчиками и тестировщиками, написали собственные инструменты для взаимодействия с Zabbix (zabbixtools) и перешли к использованию подхода “monitoring as code”.
Разграничение ответственности выглядит так — если у нас есть хост, который нужно мониторить, то тестировщик назначает ему определенную роль. У каждого хоста может быть только одна роль, в которой может быть несколько профилей — их предоставляет команда DevOps. Профили могут быть разные — для мониторинга процессов, служб, API и т.д.
В пакет zabbixtools входят скрипты Python и Powershell (репозиторий проекта на GitHub), которые расширяют функциональность системы Zabbix в части:
- кастомных проверок на Zabbix-агентах и внешних проверок на сервере;
- кастомизации оповещений — интеграции с различными сервисами и workflow;
- работы через API — например, массовое редактирование хостов и других сущностей;
- Конфигурировании мониторинга при развертывании продукта или тестов.
Система мониторинга должна быть гибкой и легко конфигурируемой, чего не скажешь о веб-интерфейсе Zabbix. Поэтому для упрощения конфигурирования решено было реализовать систему, при которой как можно больше данных о наблюдаемых показателях Zabbix должен был забирать с целевого сервера. Для упрощения настройки, в zabbixtools используется функциональность Low Level Discovery (LLD).
Это позволяет вносить любые настройки мониторинга на самом отслеживаемом сервере, а не в «админке» Zabbix.
Примерная схема реализации данной функции представлена на схеме:
Вот как это работает:
- LLD запрашивает у Zabbix-агента конфигурацию мониторинга (с требуемыми параметрами). Например, списки служб, доступных сайтов или дисков с необходимым количеством места
- Zabbix-агент предоставляет параметры, фактически, берет их из файла yaml-формата.
- LLD создает необходимые Item и Trigger на хосте. При этом условия срабатывания триггера тоже могут задаваться на стороне агента.
Таким образом, для настройки нового хоста с определенными правилами командам нет необходимости изучать административный интерфейс, достаточно лишь добавить нужный набор профилей в роль, которая будет привязана к данному серверу. Веб-интерфейс будет использоваться только для просмотра текущего состояния/исторической информации.
Пример встраивания системы мониторинга в процессы разработки/тестирования
Проблема мониторинга при разработке и тестировании продукта — меняющийся от версии к версии список наблюдаемых параметров.
Например, возможна ситуация, когда для двух релизова нам необходимо мониторить следующие показатели:
1. Release N.0
- Мониторим доступность ресурса А по протоколу HTTP
- Мониторим сервис В
- Мониторим сервис С
- Для ресурса X выставляем критическое значение Y
2. Release N+1.0
- Мониторим доступность ресурса А по протоколу HTTPS
- Мониторим сервис С (но его имя изменилось)
- Мониторим сервис D
- Для ресурса Х выставляем критическое значение Z
Причем сегодня на стенде SERVER-1 будет развернута одна версия продукта, а завтра — нужно разворачивать другую. В системах мониторинга любые изменения делаются вручную в веб-интерфейсе со статическими заданными параметрами.
zabbixtools вместе с LLD позволяет решить эту проблему, двумя возможными способами:
1. Конфигурация мониторинга (yaml-файлы) разворачиваются при деплое продукта (файлы берутся из того же репозитория, что и исходный код продукта).
- Поддержка актуальности конфигурации мониторинга остается задачей разработчиков.
- Конфигурация мониторинга различается от ветке к ветке/от фиче к фиче.
- Проводится SMOKE-тестирование уже при деплое продукта, даже если нет нужды запускать тесты.
2. Конфигурация мониторинга (yaml-файлы) разворачиваются при тестировании продукта (файлы берутся из того же репозитория, что и код для теста).
- Поддержка актуальности конфигурации мониторинга — задача тестировщиков.
- SMOKE-тесты могут быть выполнены системой мониторинга.
Эта схема позволяет настраивать мониторинг в зависимости от релиза продукта и держать его под версионным контролем. Также мы можем реализовывать SMOKE-тестирование средствами самой системы мониторинга. Кроме того, такая конфигурация позволяет разграничить ответственность между командами DevOps, разработки и тестирования — в частности, программистам и тестировщикам не нужно разбираться с работой Zabbix и его API.
В итоге участие разных команд требуется лишь в определенные промежутки времени. Например, при развертывании продукта разработчики отвечают за поддержку актуальности конфигурации мониторинга, конфигурация мониторинга различается от ветки к ветке и от фичи к фиче, а SMOKE-тестирование осуществляется при деплое даже без запуска тестов.
При тестировании продукта за поддержку актуальности конфигурации мониторинга отвечают тестировщики, SMOKE-тесты могут быть выполнены системой мониторинга.
Примеры работы
Ниже представлены примеры конфигураций для мониторинга сайтов, служб, процессов и размера папок.
Рассмотрим ситуацию, в которой нам нужно мониторить доступность внутренних и внешних сайтов — от них мы должны получать ответ HTTP 200 OK. Для этого надо просто добавить строки в файл
websites.yaml
. Если же требуется осуществлять мониторинг работы служб (службы должны быть включены), то их следует добавить в services.yaml
.В том случае, если необходимо наблюдать за потреблениями памяти определенных процессов, сделать это можно с помощью нескольких строк в process.yaml.
Еще одно полезное свойство этого инструмента — возможность установки разных пороговых значений для метрик. Если, к примеру, нам важно, чтобы размер папки Cache был небольшим, а логи могут разрастаться в размере, то можно просто добавить разные
CriticalSize
у папок в foldersize.yaml
.P.S. Рассказ о нашем опыте интеграции мониторинга с помощью Zabbix в процессы разработки и тестирования был представлен в рамках DevOps-митапа, который состоялся осенью 2016 года в Москве.
Видео:
Слайды:
По ссылке представлены презентации 16 докладов, представленных в ходе мероприятия. Все презентации и видео выступлений добавлены в таблицу в конце этого топика.
Автор: Алексей Буров