http://habrahabr.ru/company/centosadmin/blog/243843/


Небольшое резюме: статья про успешное внедрение 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*.

Итого: Получили рабочую, напичканную функционалом и автоматизированную систему мониторинга. Задачи создаются так активно и чувствительно к проблемам, что мы уже сами не рады все счастливы. Общее впечатление от Zabbix более чем положительное. Кто говорил, что Zabbix совершенно не поворотлив, думаю просто не с той стороны его настраивал. Создается ощущение, что можно бесконечно наращивать и допиливать под себя его возможности. Чем и будем заниматься, ведь лучшее конечно впереди… Всем спасибо!

Автор: Бурнашев Роман, главный системный администратор компании centos-admin.ru