Как я Quest (нынче Dell) Foglight имплементировал

Опус о том как не нужно выбирать и имплементировать систему мониторинга

Здравствуйте уважаемые хабровчане.

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

Комментарии 11

    0
    Хорошо, что все закончилось хорошо :)
      +1
      Почему-то в списке не было ничего из стандартных инструментов мониторинга. Даже в режиме сравнения. Ни shinken, ни nagios, ни zabbix…
        0
        Сейчас объясню почему так вышло. Мы не использовали ничего из стандартных инструментов. До очень недавнего времени команда представляла из себя разрозненную кучку очень узкопрофильных спецов которых нанимали не заботясь о конечном результате. 10 лет компания вообще просуществовала без отдела хостинга как такового, а хостингом занимался корпоративный хелпдеск. Это весьма печально на самом деле. Так-что инструменты которые мы использовали (я забыл упомянуть SiteScope) это то что скорее всего выпадало в топе результатов поиска на момент актуализации проблемы. Я-же лично не упоминал другие инструменты потому как я ими пользовался очень ограничено, а писать о том чего не знаю я не стану.
        0
        Любопытно, по каким критериям не подошел Microsoft Operations Managers? Мониторинг каких систем вы производите?
          0
          EMC VNX и CX, vCenter разных версий, Cisco коммутаторы и Juniper маршрутизаторы (по SNMP), APC UPS, ATS, PDU (опять таки по SNMP), Cisco UCS и HP C7000 шасси, кучу старых Dell PE2950, из ОСей всё как обычно — Windows 2003-2012 и RHEL, ну и наверняка я забыл что еще именно мы скармливаем этому инструменту, НО что-бы правильно ответить на Ваш вопрос… Operations Manager не рассматривался вообще. Я не знаю по каким причинам. Когда этот вопрос задавался одним из наших свежих инжинеров — внятного ответа получено не было.
          0
          Тоже хотел написать пропитанный желчью пост про знакомство с настоящим корпоративным софтом, но в ходе знакомства ненавится угасла и пришло смирение.
            –1
            Простите, но англицизмы просто вырви глаза. Вроде и по русски написано, а вроде и не очень.
              0
              Вы меня простите пожалуйста за сие. Я вырос, обучался и работал исключительно в США. Поверьте, за многими русскими терминами мне приходиться обращаться к гуглу, а о существовании других я даже не догадываюсь. Собственно на хабр я пришел именно для того что-бы подучиться тому что я уже довольно давно делаю, но на русском языке. Даже прожив почти год в Киеве на меня бывает оглядываются именно по этой причине — проскакивают всякие олрайты и вотсапы.
                0
                Хм. Тогда очень даже неплохо ) Просто выглядит, как будто кто-то за работой сильно увлекся англоязычной документацией. Но для чисто англоязычного человека очень даже неплохо!
                Было бы тогда еще интересно послушать и о том как вы попали в Киев. Как уезжают в США это все наслышаны, а вот что бы обратно — не часто такое бывает.
                  0
                  Не уверен что этот рассказ актуален даже в комментариях :) Всё невероятно просто на самом деле и сводится к одному слову — жена. Но Вы несколько неправы говоря что это бывает не часто. Просто вы не услышите об этих историях, ведь эти люди не выставляют это на показ и не жалуются на жизнь «в этой стране где всё плохо». В моем окружении очень много людей вернувшихся получив обучение и опыт, а есть и коренные иностранцы которым просто нравится в России и на Украине. Я в Киеве регулярно встречаю новых знакомых которым просто здесь интереснее чем в каком-то Брунзвике или Атланте.
              +1
              Как человек, к которому приходят проблемы не решённые группой поддержки, (не foglight но тоже продукт quest\dell) могу сказать следующее:
              1) professional service решает 99% проблем, которые возникают при развёртывание проблем если PSO обращается в поддержку то это в 9 случаях из 10 действительно баг. И конечно количество граблей на которые Вы наступили было бы значительно меньше, хотя да, это дорого.
              2) есть клиенты, которые экономят на PSO и как ваша компания решает всё своими силами и силами службы поддержки. В этом случае успех предприятия зависит от того к какому инженеру вы попали. Конечно инженеры поддержки не жаждут выполнять функции PSO, в любом случае этот путь болезненный и долгий.

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое