Владимир,
меня при ответе лучше поставить в копию -- debian-russian@
получаю, но читаю далеко не в первую очередь.
On Fri, Jan 06, 2012 at 09:50:14AM +0400, Vladimir Skubriev wrote:
Что лучше всего использовать для мониторинга подконтрольных
организаций. Занимаюсь ИТ-аутсорсингом, пока 3 организации,
в будущем планирую расширение.
Почти однозначно не стоит изобретать велосипед, т.к. сил
задокументировать и привести в передаваемое состояние при
росте нагрузки и расширении техперсонала (особенно на шагах
от одного до первых нескольких человек и от 5--7 до 10+) не
будет -- либо они будут взяты от внимания к делу и за счёт
повышения риска запятнать заработанное имя при проблемах.
К тому же самописные системы, будучи более подходящими к той
задаче, которая воспринимается сейчас -- обычно менее готовы
к расширению ареала задач, что не так больно на уровне "чуток
дописать", как на уровне "не укладывается, надо переписывать
или отказаться".
Если описать вкратце, то хотел бы получить систему мониторинга вида:
1. Состояние служб записывается, всегда можно обратится к архиву.
2. В случае проблем мне на телефон приходит СМС-уведомление.
Здесь один момент: SMS -- негарантированный транспорт,
по-хорошему надо уметь заказывать подтверждение доставки
и при его отсутствии через заметный таймаут писать ещё.
Может пригодиться gammu-smsd, помнится. Хороший запасной
вариант -- звонить голосом, но это нужен asterisk уже
и GSM-шлюз, что может быть отдельной полезной строкой,
но совсем другая сказка...
Второй момент: надо уметь либо ratelimit с приоритетами,
либо root cause analysis (что сложно) -- иначе может в самый
неподходящий момент завалить сигналами обо всём подряд и тем
дезориентировать. (см. тж. далее по тексту насчёт частоты)
3. Простую и легко настраиваемую систему.
Это достаточно сложно, если ей ещё и что-то уметь надо.
4. Главное, чтобы помимо настройки мониторинга оставалось время на само
обслуживание того, что нужно мониторить, и пользователей с их проблемами.
Помимо первичной настройки (и подстройки на вводе в эксплуатацию)
стоит учитывать вероятность коррекции требований и пожеланий в
будущем -- это ведь тоже время.
Навскидку приходят Zabbix, Nagios, Icinga.
Для такой задачи они, как понимаю, годятся. У нас применяются
или monit+collectd, реализующие активный локальный и пассивный
распределённый мониторинг, или Clustrx Watch в составе системы
управления кластером.
Из того, что в принципе щупал - ZAbbix и Nagios - опять же поверхностно.
Все они позволяют сделать систему мониторинга так, как хотелось бы. Но
увы, на их изучение требуется достаточно много времени. Чует моё сердце,
что придется целиком и полностью погрузится в изучение.
Конечно, потребуется. При этом изучать лучше не на переезде,
а либо на новом внедрении при понимающем ситуацию заказчике,
либо (ещё лучше) у себя на стенде +/- после дозревания стенда до
похожего на бету состояния делать дублирующую систему на наиболее
подходящем клиенте с тем, чтобы потом плавно съехать на неё в
качестве основной.
Может иметь смысл посмотреть доклад Коли Маржана:
http://ftp.linux.kiev.ua/pub/conference/2011/reports/marzhan-monitoring.pdf
http://ftp.linux.kiev.ua/pub/conference/2011/video/s1-3-monitoring.mp4
Имейте в виду, что обобщение своих скриптов будет также занимать
время, причём непредсказуемое в случае непредвиденных заранее задач.
Вообще хотел бы услышать мнение того, кто с такой задачей сталкивался,
желательно сталкивался на фронте "Аутсорсинга". А надо ли вообще?
Мы порой строили клиентам где-то с 2004.
Вот моё мнение : "Мне это нужно, без мониторинга - плохо, но это не есть
моя основная задача и времени на внедрение мониторинга немного".
Значит, следует провести первичный отбор, если останется пара
вариантов -- провести их обкатку на стенде или пилотном внедрении
"сбоку", и по результатам формировать для себя типовое внедрение,
обязательно документируя в такой вид, чтоб можно было воспроизвести
без привлечения тайных знаний в исходной голове -- тогда получится
и в три часа ночи что-то предпринять, и через год-два, и передать
малой кровью своему техперсоналу (hint: когда таким занимается
_один_ человек, а не хотя бы два -- это уже важная точка отказа).
Потому как основных задач с тремя организациями на обслуживании -
вполне хватает на рабочий день.
Может быть, кто-то решает это при помощи самописных скриптов,
или еще как?
Самописные скрипты стоит вписывать как "кончики пальцев".
Проекты-то не на пустом месте родились -- это те же самописные
скрипты, просто прошедшие более длинный путь обобщения и проверки
действительностью. Нередко уже выкинутые и переписанные начисто.
У меня в данный момент есть скрипты, которые каждый день отчитываются о
своей работе по электронной почте. Но увы, это не удобно каждый день
проверять почту и видеть в ней письма с отчетами о "ВЫПОЛНЕННОМ"
Задании. Т.к. по сути меня больше интересуют "НЕ ВЫПОЛНЕННЫЕ" Задания.
Есть ещё одно состояние -- "должно было быть выполнено, отчёта нет".
В то же время я хотел бы быть уверенным в том, что мои задачи
резервного копирования, проверки состояния дисковых массивов и
т.д. проходят в рабочем режиме и готовы доложить о проблеме
немедленно.
Тогда может иметь смысл посмотреть на bacula -- там это учтено:
http://www.mail-archive.com/bacula-users@lists.sourceforge.net/msg50385.html
Правда, это минимум с неделю вечерами посидеть на освоение
базовых концепций и ещё неделю -- на создание и угробливание
первой инсталяции (там есть нюанс -- media в pool'ах следует
организовывать относительно небольшими кусками с ограничением
по размеру/времени с тем, чтобы можно было их автоматом
recycle'ить, т.к. оно только append'ит и не overwrite'ит).
И кстати, тут есть ещё нюанс: если слать _все_ результаты
(а не архивировать все, слать неудачные и сигналить о неожиданном
отсутствии удачных) -- упирается в читающего не только по
количеству площадок, а и по частоте проверок.
И еще вопрос: сколько в среднем потребуется времени на изучение
и внедрение, скажем, если серверов 15 windows/linux-серверов и
где-то около 40 рабочих станций win. Надеюсь, Вы меня поняли.
Сильно зависит от нагрузки, характера остатков времени (по пять
минут за раз или можно выкроить кусками хоть по два-три часа),
имеющихся навыков и т.д. и т.п. Пристреливайтесь на стенде
(хотя бы виртуальном) и пилотном проекте, по ним и получите
свою личную оценку. Совсем на глаз -- около месяца на освоение
и эксперименты, с месяц пробной эксплуатации и только затем уже
масштабировать наработанное решение к другим клиентам.
On Fri, Jan 06, 2012 at 11:58:15AM +0400, Vladimir Skubriev wrote:
Немного оформил мои требования:
1. Текущая доступность серверов и служб на серверах.
2. Архив доступности серверов и служб на серверах.
BTW если он не распределённый, то авария диска или иные события
могут привести к недоступности архива. Если логи, почта, БД
существует _вне_ инфраструктуры объекта мониторинга, то хотя бы
есть шансы на то, что получится восстановить картину происшедшего.
3. Контроль выполнения резервного копирования и свободного
места для резервного копирования.
4. Контроль состояния программных/аппаратных массивов.
5. Контроль состояния дисков по показателям SMART.
Это может быть решаемо существующими средствами общего назначения.
(BTW для разных рейдов и соответствующих вендорских утилит есть
надстройка einarc, может пригодиться на "последней миле")
6. Уведомления по СМС в случае серьезных проблем.
7. Звуковые предупреждения в случае не возможности
уведомления по СМС или электронной почте (отсутствует
связь по интернет, нет денег на счете, другая ошибка).
Это по крайней мере отчасти явно свои скрипты,
дёргающиеся из мониторилки на месте.
8. Проверка успешности задания (скрипта) на удаленном сервере.
Как проверять успешность выполненного задания на удаленном
сервере с помощью различных систем мониторинга будет ЛЕГЧЕ?
А это может быть non-issue, см. обсуждение и ссылку выше.
В свою очередь тот скрипт которого проверяют, если его не
проверили включает свою сирену, например уведомление по email
и звуковой сигнал через динамик PC.
Существенно ли, если он отработал, а связи с Вашей частью
системы мониторинга не было? Если N клиентов будут дёргаться
по причине полуминутного завала линка у Вас, может выйти не очень
красиво. Т.е. может быть и существенно, но для подобных задач
обычно (e.g. в тех же monit и collectd) применяется сбрасываемый
накопитель ошибок -- если за, скажем, десяток циклов произошло
менее восьми ошибок, то это ещё не беда, а вот если больше --
пора сигналить доступными средствами.
PS: набрался нахальства поправить процитированный текст
чуточку насчёт грамматики-орфографии. :) С Рождеством!