Re: мониторинг нескольких организаций - как можно проще, чем?
Владимир,
меня при ответе лучше поставить в копию -- 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: набрался нахальства поправить процитированный текст
чуточку насчёт грамматики-орфографии. :) С Рождеством!
--
---- WBR, Michael Shigorin <mike@altlinux.ru>
------ Linux.Kiev http://www.linux.kiev.ua/
Reply to: