В этой компании до внедрения сервиса мониторинга никогда аварий не происходило? Или их не решали никак?
Сомневаюсь.
Вот "самые умные" должны сесть и оформить в виде регламентов свое видение того, кто и что должен делать в случае, если мониторинг зафиксировал аварию (с учетом опыта решения проблем, которые были до...). А потом эти регламенты дорабатывать на основе ситуаций, когда в процессах взаимодействия произошёл сбой.
Вопрос регламентов очень сильно завязан на специфику и орг структуру конкретной компании. Не существует универсальных рецептов. В 7 пункте я лишь хочу подчеркнуть, что правила, регламенты, инструкции и прочее должны существовать к моменту начала работы системы. Любые, пусть даже не оптимальные регламенты лучше, чем их их полное отсутствие.
Для описания организации процесса все довольно конкретно. Считаю, что рекомендации применимы для любой компании, которая хочет организовать мониторинг, приносящий реальную пользу.
Не правильно заставлять. Не правильно. Если создать такие условия, что подразделениям будет выгодно пользоваться системой мониторинга, они сами начнут ее использовать. Самый банальный пример. Поставьте в kpi подразделения целевой показатель по количеству критических аварий. И аварии эти считайте по системе мониторинга. В этом случае подразделения очень быстро сами, добровольно запросят оповещения, которые предвещают критические аварии. Это и есть мотивация в моем понимании.
С системой инвентаризации ничего не делали, кроме изменения названия полей в инвентарных данных. Любые изменения на уровне хранения в данном случае повлекут за собой проблемы с обновлением.
Кое каким лайфхаком является то, что в одном из полей инвентаризации в Zabbix мы храним ID КЭ этого сервера из CMDB так что при необходимости, мы по этому ID можем всегда обратиться в систему учета (Service Manager). Думаю, при необходимости аналогичным образом можно поступать и с другими системами инвентаризации.
После обновления сервера приложений, при первом старте, сервер проверяет версию базы. В случае, если база старой версии, начинает ее обновлять… Вот это обновление у нас и затянулось. Поискать скрипты можно либо внутри патчей, которыми обновляется Zabbix, либо запросить непосредственно в Zabbix.
Мы уже давно прошли этот этап, поэтому точного файла, в котором храняться эти патчи и запросы по памяти не подскажу.
скрипт получает на вход этот словарь и шаблон html письма. В этом шаблоне он заменяет значения по словарю и готовит из него body для почтового сообщения, которое затем отправляет.
Я бы выразился немного по-другому: Сберу хватило ума перестать прикладывать усилия к тому, чтобы заставить работать SCOM и он обратил внимание на другие, более отзывчивые и простые в настройке инструменты мониторинга. Я совсем не хочу обидеть ни SCOM, ни тех, кто его использует. Просто по моему мнению, этот инструмент не очень подходит для нашей компании.
А не приходила мысль на 1500 тестовых сред создавать 1500 инстансов заббиксов
Можно привести очень много причин того, почему это делать не стоит. Приведу лишь некоторые:
Появится полторы тысячи виртуалок/контейнеров Zabbix (по крайней мере у нас в компании, на тестовом стенде нельзя держать никакой сторонний софт, так что под каждый инстанс Zabbix придется резервировать отдельные ресурсы)
Каждой команде придется держать экспертизу по мониторингу.
Каждая команда неизбежно будет тратить ресурсы на разработку примерно одних и тех же метрик мониторинга. В рамках компании это КОЛОССАЛЬНОЕ КОЛИЧЕСТВО ресурсов. Одним из плюсов нашего сервиса является то, что в моем подразделении сосредоточена подавляющая часть экспертизы мониторинга компании (мы так или иначе в курсе всех активностей, связанных с мониторингом в Сбертехе и банке). И сейчас, спустя 4 года, если к нам обращаются с просьбой о разработке того или иного функционала, мы можем ответить, что «это уже было в Симсонах». Если же это действительно что-то новое, мы сразу ведем разработку так, чтобы новый инструмент затем можно было тиражировать на все среды тестирования, где это возможно. Мы также сразу информируем потенциальных потребителей о появлении нового функционала и т.д.
Мы не избавляемся от централизованного инстанса, иначе не получим целостной картины состояния инфраструктуры.
И еще много много всего.
Я бы рассмотрел возможность подобной идеологии (инструментом, скорее всего, был бы не Zabbix) только в том случае, если каждая АС поддерживается совершенно независимой командой от начала и до конца (и нет каких то сервисных подразделений, которые занимаются администрированием всей инфраструктуры в целом). — Об этом я уже написал в одном из комментариев.
Нам удалось добиться от ODBC более менее стабильной работы. Сильно помогли в этом мастер-метрики. Так что сейчас мы продолжаем использовать именно ODBC, благо процесс постановки на мониторинг баз почти полностью автоматизирован.
Самой большой проблемой на данный момент является то, что невозможно в прототипах элементов данных (далее ЭД) разведки использовать в качестве мастер-метрики использовать обычный ЭД из шаблона. Такой функционал значительно снизил бы количество сессий, который мониторинг создает к базе. Но и использование мастер-метрики внутри разведки по каждому Tablespace уже снизило количество создаваемых сессий примерно в 3 раза.
У нас запланировано основательное тестирование инструментария DBforBIX, но руки до этого пока что не дошли. Решающим при окончательном выборе будет возможность полной автоматизации процесса постановки на мониторинг, так как баз, которые нужно мониторить у нас очень много.
Сложно сказать, так как активное развитие сервиса продолжается все время и сейчас его даже больше, чем было год или два назад и надеюсь. Не уверен, что для сервиса мониторинга вообще возможно такое понятие, как «окончание внедрения».
На что потратили больше всего времени?
Опять же, в связи со спецификой нашей инфраструктуры и в частности инфраструктуры, на которой работает наш сервис, много времени за последние четыре года приходилось тратить оптимизацию производительности (если в о технических моментах). Наверное, чуть позже я опишу мощности, которые задействованы в нашем сервисе. К примеру, 19000 НВПС нам удалось достичь на 8 ядрах (на основном сервере приложений), без SSD, High-End или чего-либо в этом роде.
Если говорить об организационных моментах, самым сложным было добиться популярности нашего сервиса в компании, так как наших заказчиков никто не заставлял работать именно с нашим сервисом.
Как я уже писал выше, у нас работает три инстанса Zabbix.
Один из них как раз и дублирует мониторинг критически важных для компании сервисов (в том числе, на нем развернут и «мониторинг мониторинга»). Этот инстанс намного меньше чем инстанс мониторинга тестовых сред, а потому работает он значительно стабильнее (нагрузка на нем порядка 200 НВПС).
Если вам интересно, я могу попробовать описать наш внутренний мониторинг (графики и метрики, по которым мы диагностируем проблемы на Zabbix) в отдельном посте.
В условиях нашей компании такая выборка по всей инфраструктуре это уже BigData. И решать такую задачу нужно соответствующими средствами. Кстати, у нас реализованы инструменты экспорта данных из базы Zabbix в NoSQL. Там эти данные специалисты Capacity Management могут крутить так как им нужно. IMHO это не задача сервиса мониторинга.
а ведь еще есть динамическое создание, для которых нужны шаблоны, без которых совсем все плохо и все равно придется их настраивать, но все это больно и неудобно
Звучит как-то по Prometheus-овски. Zabbix в том числе устраивает нас потому, что хотя у меня и есть претензии к его ролевой модели, с помощью неё удается поддерживать сервис на 1000+ пользователей. И именно эта ролевая модель не дает грузить в базу все подряд (как это происходит в некоторых других инструментах мониторинга. Но опять же, это мое личное мнение.
Еще раз повторюсь, в любой компании есть своя специфика. Прежде всего, подход к мониторингу зависит от того, как в принципе в компании реализован цикл разработки, тестирования и сопровождения в проме систем. Скажем так, если бы каждую систему на протяжении всего жизненного цикла (в том числе в ПРОМ-е) сопровождала бы одна независимая от других команда, то инструментом мониторинга точно был бы не Zabbix.
Собственно, у нас как раз такая интеграция с CMDB и реализована. См. Предыдущую статью.
В этой компании до внедрения сервиса мониторинга никогда аварий не происходило? Или их не решали никак?
Сомневаюсь.
Вот "самые умные" должны сесть и оформить в виде регламентов свое видение того, кто и что должен делать в случае, если мониторинг зафиксировал аварию (с учетом опыта решения проблем, которые были до...). А потом эти регламенты дорабатывать на основе ситуаций, когда в процессах взаимодействия произошёл сбой.
Да, конечно. В том числе к этих регламентных должно быть зафиксировано порядок и периодичность их пересмотра.
См. Седьмое НЕ из моей статьи. Там как раз про это.
Для описания организации процесса все довольно конкретно. Считаю, что рекомендации применимы для любой компании, которая хочет организовать мониторинг, приносящий реальную пользу.
Не правильно заставлять. Не правильно. Если создать такие условия, что подразделениям будет выгодно пользоваться системой мониторинга, они сами начнут ее использовать. Самый банальный пример. Поставьте в kpi подразделения целевой показатель по количеству критических аварий. И аварии эти считайте по системе мониторинга. В этом случае подразделения очень быстро сами, добровольно запросят оповещения, которые предвещают критические аварии. Это и есть мотивация в моем понимании.
Кое каким лайфхаком является то, что в одном из полей инвентаризации в Zabbix мы храним ID КЭ этого сервера из CMDB так что при необходимости, мы по этому ID можем всегда обратиться в систему учета (Service Manager). Думаю, при необходимости аналогичным образом можно поступать и с другими системами инвентаризации.
После обновления сервера приложений, при первом старте, сервер проверяет версию базы. В случае, если база старой версии, начинает ее обновлять… Вот это обновление у нас и затянулось. Поискать скрипты можно либо внутри патчей, которыми обновляется Zabbix, либо запросить непосредственно в Zabbix.
Мы уже давно прошли этот этап, поэтому точного файла, в котором храняться эти патчи и запросы по памяти не подскажу.
[TRIGGER.STATUS]:{TRIGGER.STATUS}
[INVENTORY.LOCATION]:{INVENTORY.LOCATION}
[TRIGGER.NAME]:{TRIGGER.NAME}
[TRIGGER.SEVERITY]:{TRIGGER.SEVERITY}
[HOST.NAME1]:{HOST.NAME1}
[IPADDRESS1]:{IPADDRESS1}
[INVENTORY.TAG1]:{INVENTORY.TAG1}
[ITEM.NAME1]:{ITEM.NAME1}
[ITEM.VALUE1]:{ITEM.VALUE1}
[TRIGGER.ID]:{TRIGGER.ID}
[EVENT.ID]:{EVENT.ID}
[TRIGGER.URL]:{TRIGGER.URL}
[ITEM.ID]:{ITEM.ID}
[DATE]:{DATE}
[TIME]:{TIME}
[TRIGGER.DESCRIPTION]:{TRIGGER.DESCRIPTION}
[EVENT.TAGS]:{EVENT.TAGS}
скрипт получает на вход этот словарь и шаблон html письма. В этом шаблоне он заменяет значения по словарю и готовит из него body для почтового сообщения, которое затем отправляет.
Я бы рассмотрел возможность подобной идеологии (инструментом, скорее всего, был бы не Zabbix) только в том случае, если каждая АС поддерживается совершенно независимой командой от начала и до конца (и нет каких то сервисных подразделений, которые занимаются администрированием всей инфраструктуры в целом). — Об этом я уже написал в одном из комментариев.
Самой большой проблемой на данный момент является то, что невозможно в прототипах элементов данных (далее ЭД) разведки использовать в качестве мастер-метрики использовать обычный ЭД из шаблона. Такой функционал значительно снизил бы количество сессий, который мониторинг создает к базе. Но и использование мастер-метрики внутри разведки по каждому Tablespace уже снизило количество создаваемых сессий примерно в 3 раза.
У нас запланировано основательное тестирование инструментария DBforBIX, но руки до этого пока что не дошли. Решающим при окончательном выборе будет возможность полной автоматизации процесса постановки на мониторинг, так как баз, которые нужно мониторить у нас очень много.
Опять же, в связи со спецификой нашей инфраструктуры и в частности инфраструктуры, на которой работает наш сервис, много времени за последние четыре года приходилось тратить оптимизацию производительности (если в о технических моментах). Наверное, чуть позже я опишу мощности, которые задействованы в нашем сервисе. К примеру, 19000 НВПС нам удалось достичь на 8 ядрах (на основном сервере приложений), без SSD, High-End или чего-либо в этом роде.
Если говорить об организационных моментах, самым сложным было добиться популярности нашего сервиса в компании, так как наших заказчиков никто не заставлял работать именно с нашим сервисом.
Один из них как раз и дублирует мониторинг критически важных для компании сервисов (в том числе, на нем развернут и «мониторинг мониторинга»). Этот инстанс намного меньше чем инстанс мониторинга тестовых сред, а потому работает он значительно стабильнее (нагрузка на нем порядка 200 НВПС).
Если вам интересно, я могу попробовать описать наш внутренний мониторинг (графики и метрики, по которым мы диагностируем проблемы на Zabbix) в отдельном посте.
Звучит как-то по Prometheus-овски. Zabbix в том числе устраивает нас потому, что хотя у меня и есть претензии к его ролевой модели, с помощью неё удается поддерживать сервис на 1000+ пользователей. И именно эта ролевая модель не дает грузить в базу все подряд (как это происходит в некоторых других инструментах мониторинга. Но опять же, это мое личное мнение.
Еще раз повторюсь, в любой компании есть своя специфика. Прежде всего, подход к мониторингу зависит от того, как в принципе в компании реализован цикл разработки, тестирования и сопровождения в проме систем. Скажем так, если бы каждую систему на протяжении всего жизненного цикла (в том числе в ПРОМ-е) сопровождала бы одна независимая от других команда, то инструментом мониторинга точно был бы не Zabbix.
Предлагаю дальнейшую дискуссию по этому поводу вести за рамками комментариев к данной статье.