Владимир, меня при ответе лучше поставить в копию -- 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 <m...@altlinux.ru> ------ Linux.Kiev http://www.linux.kiev.ua/ -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120106151147.gb20...@osdn.org.ua
