Опус о том как не нужно выбирать и имплементировать систему мониторинга
Здравствуйте уважаемые хабровчане.
Позвольте рассказать вам о длинной истории одной компании, с весьма небольшим штатом команды хостинга, которой вдруг захотелось проапгрейдить свою систему мониторинга. Речь пойдет о пути долгом и тернистом. Пути который только сейчас, спустя почти два года, подходит к этому замечатльному и неоднозначному понятию как maintenance mode. Коль сия история покажется вам интересной — добро пожаловать под кат.
Итак, два года назад было решено что SolarWinds ipMonitor, которым мы успешно пользовались довольно много лет, исчерпал свои возможности. Компания росла, количество серверов в клетках росло, количество самих клеток так же росло и было решено что ping, telnet и поиск слова в source это весьма недостаточно. Помимо этой системы так же было великое множество скриптов написанных разными инженерами и естественно без документации. Регулярно скрипты ломались, иногда не очевидно, и в итоге страдало качество предоставляемого сервиса.
На одной из vmWare презентаций моим начальником была замечена мониторинговая система с «огромным потенциалом». Куча индикаоров, кнопочек. графиков, инструментов анализа, вобщем очень много красивого и сладкого для неизбалованного начальника отдела хостинга из пяти человек. Звался сей чудо инструмент Quest Foglight Monitoring System (FMS далее). Не откладывая в долгий ящик, старшему инженеру было предложено связаться с вендором и сделать тестовый деплоймент. После нескольких недель «тяжкого труда» инженер дал добро. Конечно же начальник предложил всем нам ознакомиться с системой перед покупкой и попросил выразить своё мнение. Итак настала точка невозврата — мы согласились с доводами старшего вслепую, так-как от основной работы никто нас не освобождал и тратить время на что-то где старший сказал «зер гут» как бы не имеет особого смысла. Итак была озвучена цена, естественно мы захотели абсолютно весь функционал который только можно и цена довольно сильно кусалась. Вендор уговаривал нас купить несколько месяцев времени их professional services, но их услуги показались кому-то слишком дорогими. В конце-концов ведь справлялись мы как-то с тем что уже было, справимся и с этим, ведь так? О Великий Вишну, насколько же это мнение оказалось ошибочным. Был куплен пакет трейнинга длинной в три дня для всей группы, а так же неделя PS и были так же заказаны «некоторые кастомизации». Опытные айтишники немаленького среднего бизнеса наверняка уже хихикают и крутят пальцем у виска. Хостеры наверняка просто вздыхают и возможно удивляются безмерной недальновидности всего выше изложеного.
Проблемы начались через минуту после того как исчерпалось время консультанта и нас передали отделу поддержки клиентов. Началось всё с того что вендору наш старший предоставил план деплоймента в котором указывался его тестовый sandbox. Вендор наверняка был счастлив продать людям с тремя десятками виртуалок и одной базой данных систему мониторинга в топовой комплектации, но ведь речь на самом деле шла о нескольких сотнях виртуалок на нескольких шасси, с несколькими кластерами серверов баз данных, да ещё и географически на разных концах континента. В тот момент мы представить не могла насколько прожорливой окажется FMS в плане ресурсов. После создания всех агентов баз данных, vCenter, и инфраструктуры мы вдруг поняли что оно висит намертво. Заонок в поддержку, нас тыкают носом в план деплоймента и заявляют что если бы мы сообщили заранее о размере наших нужд то и речь шла бы о других требованиях. Через два дня уволился старший инженер. Так на сцене появляюсь я — в принципе всё ещё далеко не senior и слова в выборе проектов для себя не имеющий.
Первой мыслью было «А не уволиться ли мне сейчас». Но ведь русские не сдаются, правда? Сначала я выбил выделеные сервера под это веселье. Два старичка Dell 2950 с ESXi на них. Выбить отдельный сервер под базу данных я не смог и потому пришлось использовать виртуалку на них же ещё и под это.
Небольшое описание архитектуры FMS
FMS состоит из:
1. Management Server. Этих серверов может быть несколько в active/passive кластере собственной имплементации, это центральная точка которая всем командует.
2. Foglight Agent Manager. Диспетчер агентов это windows service (daemon если Вы умеете и хотите) которых может быть установлено несколько для разных нужд. Мы таким образом разделили vmWare, SQL staging, SQL production и OS чтобы при проблеме с каким-то одним типом агента не приходилось прерывать все наблюдения.
3. Foglight Agent. Агенты могут быть на все случаи жизни: как купленные у вендора, так и написанные самостоятельно.
4. Database. Тут всё ясно — у нас SQL Server 2008.
Довольно быстро я понял что работать с тем что есть просто невозможно. Во-первых система тормозила даже при адекватных ресурсах. Страничка с менеджером правил могла грузить список правил произвольное количество времени от пяти до пятнадцати минут. Звонок в поддержку имел неожиданный результат — о проблеме знали и обещали починить в следующей версии… через квартал. Тем временем начальство требовало результатов и никакие обоснования о том, что наша версия тормозит не принимались — ведь потрачена весьма немалая сумма денег. Скрипя зубами и изобретая окольные пути всё более-менее заработало через ещё шесть недель и тут перевели часы. При чем тут DST, справедливо спросите вы? Дело в том что в этой довольно давно разработанной системе был баг.
Попользовавшись системой некоторое время мы начали понимать что заказаные нами кастомизации во-первых просто не работают, а во вторых они просто были не нужны. Нужны другие, но вот незадача — вендора купил Dell и ценовая политика несколько изменилась. Начальство требует чтобы я срочно сам написал требуемые кастомизации. Мысль о том что неплохо бы уволиться посетила меня снова, ибо я ни разу не программист. Вот не лежит душа у меня к этому и всё тут. Но ведь русские не сдаются, правда? Осваиваю groovy script на котором всё это работает. В процессе обучания понимаю, что практически половина купленного нами функционала может работать лучше, если я просто перепишу это под наши конкретные нужды. Переписываю и попутно прекращаю говорить начальству, что я ненавижу этот продукт потому-как это уже на 30% мой собственный продукт: ведь за всё время имплементации кроме меня ни один инженер к нему вообще не прикоснулся, хоть я и просил о помощи.
И вот настал заветный час — вышла новая версия в которой, о Великий Вишну, были исправлены как проблема с загрузкой многих страниц, так и ненавистный баг с DST. Признаюсь — в этот день я праздновал. Конец постоянному нервному тику и походами за кофе «пока загрузится страница». Именно это событие наконец приблизило наступление заветного maintenance mode. Теперь, я только иногда, по просьбам трудящихся, меняю пороги срабатывания оповещений и изредка пишу новые агенты, которые не имеют ничего общего с инфраструктурой, а просто оповещают о уже вполне клиентских проблемах: таких как блокировка учеток пользователей нашего продукта. Теперь я — lead и теперь я точно знаю как нельзя выбирать и имплементировать ПО.
Попробую изложить свои, вроде бы очевидные, выводы.
1. Нельзя покупать сразу полный функционал без твердой уверенности, что он нужен. Убедиться что он действительно нужен несложно, ведь можно нанять консультанта имеющего опыт работы с именно этим ПО. Поверьте — это намного дешевле чам заплатили мы за картриджи которые теперь не используются.
2. Нельзя спешить. Ничего страшного не случилось бы если мы ещё пол года посидели на том что уже было. Несколько старых серверов можно найти всегда и никто, кроме менеджера по продажам от вендора, вас не гонит заплатить здесь и сейчас.
3. Нужно понимать специфику персонала который имеется в наличии. Не стоит поручать анализ всего одному человеку, особенно если человек плохо мотивирован.
4. Не стоит экономить на цене имплементации. Правда, не стоит. Вендор обычно действительно хочет вас как можно скорее привести к production ибо именно тогда ему заплатят полностью, да и консультанты тоже имеют свою выгоду если всё пройдёт хорошо. Если вендор говорит что это займет месяцы с их персоналом, это значит что так скорее всего и есть. Если в бюджете нет денег на это — остановитесь, ибо всё равно заплатите, но уже больше.