Опус о том как не нужно выбирать и имплементировать систему мониторинга
Здравствуйте уважаемыее.
Позвольте рассказать вам о длинной истории одной компании, с весьма небольшим штатом команды , которой вдруг захотелось проапгрейдить свою систему мониторинга. Речь пойдет о пути долгом и тернистом. Пути который только сейчас, спустя почти два года, подходит к этому замечатльному и неоднозначному понятию как 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 ибо именно тогда ему заплатят полностью, да и консультанты тоже имеют свою выгоду если всё пройдёт хорошо. Если вендор говорит что это займет месяцы с их персоналом, это значит что так скорее всего и есть. Если в бюджете нет денег на это — остановитесь, ибо всё равно заплатите, но уже больше.
Автор: Roto
