Небольшое резюме: статья про успешное внедрение Zabbix с автоматизацией большинства процессов, не претендует на tutorial, но если нужны будут подробности, то могу предоставить.
Вот уже много лет наша компания использовала проверенный и наработанный мониторинг monit + cacti. Но все течет — все меняется. И выросли мы настолько, что monit перестал справляться. Цикл проверки вырос с минуту до 10-20 минут, что просто неприемлимо! Так как разработчики monit нам помочь не смогли, было решено добавить (мониторинга много не бывает) новую систему мониторинга. Принцип “работает — не трожь” тут больше не работает. Долго ли, коротко ли, но выбор пал на Zabbix. Почему? Почитали, поспорили, подумали и исполнитель решил. У каждой системы есть плюсы и минусы, информации об этом более чем достаточно и каждый выбирает то, что ему удобно. Я, например, уже умел мониторить OracleDB в Zabbix. Возможно эта статья кого-либо подвинет на сторону Zabbix — буду рад.
Итак, главная цель, которую я преследовал: надежно, быстро, удобно и без лишних телодвижений ( лень — двигатель всего ). По железу не заморачивались, взяли старенький сервер ex6 от hetzner и подселили туда контейнер, характеристика:
- CPU: Intel Corporation Xeon E3-1200 Processor
- RAM: 16 GB
- HDD: SATA software RAID 1
В общем и в целом не впечатляет, но сойдет, как минимум на этап внедрения.
Zabbix-server установлен и настроен по оф. инструкции + пару раз тюнинговал БД. Использовал CentOS 6.5 nginx+apache+mysql.
Теперь нужно понять, что будем автоматизировать (всё?). Для этого расcкажу какие мы используем основные инструменты: система управления конфигурациями и Redmine. Значит нужно брать список хостов и подключаемых темплейтов из системы управления конфигурациями ( не стал сокращать в аббревиатуру) и делать автоматически задачки в Redmine.
Пример как у нас хранятся списки хостов, напримере клиента domain.ru. Есть файл domain.ru.conf, и в нем список серверов по следующему принципу:
d1.domain.ru:
nginx.domain.d1
mysql.domain.d1
zabbix.domain.d1
role4.domain.d1
и тд.
Добавляем серверы в Zabbix-server.
Для этого будем использовать Actions — Auto registration. Штука очень полезная. Через систему управления конфигурациями на серверы где есть роль Zabbix устанавливаем zabbix-agent и прописываем в конфиг HostMetadata=d.domain.ru. можно было обойтись просто доменом, но у нас от d. или v. зависит нода это или контейнер. Прописываем все остальные настройки (server host), рестартим zabbix-agent и всего делов.
Теперь махинации на сервере. Для каждого домена нужно сделать host groups и собственно правило Auto registration. А их много, да еще и прибывают. Тут к нам на помощь спешит ZabbixApi. Документация по нему хорошая, осваивается довольно легко. Есть конечно несколько моментов которые напрягают, например не возможность добавить к хосту шаблон, не затерев старые шаблоны… И так, кому нужны будут примеры моей работы с api ( я написал отдельную либу на python для себя) могу выложить куда-нибудь.
Освоив ZabbixApi, просто берем текущее состояние проектов (у нас это файлы domain.ru.conf) и создаем/удаляем группы и правила авторегистрации согласно изменениям.
Приведу пример правила авторегистрации для ноды:
Отлично, вот у нас пошли добавляться сервера со стандартными шаблонами. Теперь нужно добавлять дополнительный шаблоны согласно ролям сервера в системе управления конфигурациями. Пишем парсер, который берет свежую информацию, сравнивает с эталоном, что-то делает или не делает и перезаписывает эталон. Вот тут я столкнулся с проблемой, что в ZabbixApi нельзя просто добавить шаблон, остальные затираются и нельзя его просто “не добавить” — не удаляется история и триггеры. В этом же скрипте удаляем хосты которые есть в шаблоне, но которых нет в системе управления конфигурациями. Не буду грузить статью листингом этих скриптов, строчек там много, опиши принципы:
Самое простое это удаление хоста, удаляем если в эталоне он есть, а по новым данным его нет. С добавлением хуже, то есть если в эталоне нет а по новым данным есть — игнорируем хост. ведь добавляем мы их через правила авторегистрации. Основная работа идет по списку шаблонов. Если у хоста добавилась новая роль, то мы добавляем к нему одним запросом все старые шаблоны + новый. Если удалили одну роль, то во первых проверяем был ли такой шаблон и если был, то чистим его и отвязываем от хоста.
На этом с добавлением хостов и шаблонов все! От нас теперь только требуется добавить сервер в систему управления конфигурациями, прописать ему нужные роли и можно радоваться жизни.
Теперь второй момент, уведомления по почте это интересно, но мы привыкли к задачам в Redmine. Да и Redmine нам уже всякие смс шлет и клиенты видят активность по задачам. В Redmine так же есть API. Что мы делаем: настраиваем в Zabbix actions, которое на определенные условия выполняет Remote command на Zabbix сервере. Например наши проверки клиентских сайтов на правильную подстроку в ответе, команда выглядит так:
/srv/scripts/redmine_api_content.py {TRIGGER.DESCRIPTION} {TRIGGER.STATUS} {TRIGGER.SEVERITY} '{TRIGGER.NAME}' '{ITEM.NAME2} {ITEM.KEY2}: {ITEM.VALUE2}' >> /var/log/zabbix/redmine_api_content.log 2>&1
В скрипте {TRIGGER.DESCRIPTION} — это проект в котором будет создана задача, в обычных проверках ( ping и тд) тут передается {HOST.NAME} из которого формируется идентификатор проекта. {TRIGGER.STATUS} — если PROBLEM и задачи с таким именем нет, то создаем, если задача есть то коментарий добавляем к ней. Если OK и задача есть — то комментарий добавляем иначе ничего не делаем. {TRIGGER.SEVERITY} — важность триггера, преобразуется в статус задачи (высокий, Авария!). {TRIGGER.NAME} — собственно что происходит :) это будет имя задачи. {ITEM.NAME2} {ITEM.KEY2}: {ITEM.VALUE2} тут я добавляю информацию о причине срабатывания веб проверки (web.test.error).
Листинг этого скрипта я приведу, в нем используется пакет python-redmine:
#!/usr/bin/python
import sys, time
from redmine import Redmine
from datetime import datetime, timedelta, date, time as dt_time
if len (sys.argv) != 6:
print "use params: project, status, priority, trigger_name, item_value."
print sys.argv
sys.exit("Erorr! Wrong arguments!")
else:
PROJECT_NAME = sys.argv[1]
TRIGGER_STATUS = sys.argv[2]
TRIGGER_PRIORITY = sys.argv[3]
TRIGGER_NAME = sys.argv[4]
ITEM_VALUE = sys.argv[5]
REDMINE_URL = 'https://factory.example.com'
REDMINE_KEY = 'API_KEY'
# Идентификатор пользователя группы в Redmine на которого назначать задачу
ADMINS_ID = 33
#Идентификатор приоритета задачи
priority = 4
if TRIGGER_PRIORITY == "Disaster":
priority = 14
if TRIGGER_PRIORITY == "High":
priority = 5
#подключаемся к Redmine
redmine = Redmine(REDMINE_URL, key=REDMINE_KEY)
#проверяем наличие такой задачи
issueExist = redmine.issue.filter(
project_id = PROJECT_NAME,
subject = "PROBLEM: "+ TRIGGER_NAME
)
#это используется для файлового лога (избытки привычек)
print datetime.now()
print TRIGGER_STATUS +": "+ TRIGGER_NAME + "\n" + ITEM_VALUE
#Создание задач/комментариев в зависимости от условий
if TRIGGER_STATUS == "PROBLEM":
if issueExist:
print "Issue already exist. Create comment"
issue = redmine.issue.update(
issueExist[0].id,
notes = TRIGGER_STATUS +": "+ TRIGGER_NAME + "\n" + ITEM_VALUE
)
else:
print "Issue not exist. Create issue"
issue = redmine.issue.create(
project_id = PROJECT_NAME,
subject = TRIGGER_STATUS +": "+ TRIGGER_NAME,
tracker_id = 3,
description = TRIGGER_STATUS +": "+ TRIGGER_NAME + "\n" + ITEM_VALUE,
status_id = 1,
priority_id = priority,
assigned_to_id = ADMINS_ID
)
if TRIGGER_STATUS == "OK":
if issueExist:
print "Add comments"
issue = redmine.issue.update(
issueExist[0].id,
notes = TRIGGER_STATUS +": "+ TRIGGER_NAME + "\n" + ITEM_VALUE
)
Что у нас получилось с нагрузкой, не зря же я привел конфигурацию железа. При таких данных:
Нагрузка на сервере держится в районе 2-3 la, то есть вполне достойно. Больше всего страдают диски, потому что RAM маловат. Конечно система сейчас будет обрастать новыми шаблонами и проверками, нагрузка будет расти и придется переехать на новое железо. Кстати, небольшой совет,.исключайте из бэкапа все таблицы history*.
Итого: Получили рабочую, напичканную функционалом и автоматизированную систему мониторинга. Задачи создаются так активно и чувствительно к проблемам, что
Автор: Бурнашев Роман, главный системный администратор компании centos-admin.ru
