Comments 50
Можете ли вы рассказать подробнее о методике/алгоритме отнесения серверов к категории недозагруженный/загруженный оптимально/ перегруженный?
Базовый интервал сбора метрик в нашем сервисе принят в 60 секунд.
В Zabbix для каждого сервера вычисляются метрики 15-ти минутного скользящего среднего (далее MA15) и 90% перцентиля* (далее PCT90) для каждого из трех параметров: CPU Utilization, RAM Utilization, Disk Utilization — по каждому разделу.
Для MA15 базовый интервал сбора — 60 секунд (на то оно и скользящее)
Для PCT90 интервал сбора — 15 минут, данная метрика менее ресурсоёмкая.
Далее отдельными метриками в Zabbix же вычисляем суточные максимумы для MA15 и PCT90: MA15_1DMAX и PCT90_1DMAX
В итоге, получаем 30 значений в месяц для каждой из метрик.
Анализ мы ведем на промежутке 3-х месяцев: анализируем по 90 значений каждой метрики MA15_1DMAX и PCT90_1DMAX.
Из этих 90 значений отбрасываем одно наибольшее:
1) Пытаемся избежать попадания в выборку случайного повышения нагрузки
2) Не берем в расчет нагрузку, которая за три месяца возникала всего один раз
Из оставшихся 89 значений выбираем наибольшее по обеим метрикам. Назовем полученные два значения MA15_90DMAX и PCT90_90DMAX (не забываем, что на самом деле это не максимум, а «второй» максимум — первый мы исключили из выборки).
Для нашей инфраструктуры тестовых сред** мы определили следующие целевые показатели:
оптимальная загруженность: 60-80%
недозагруженность: < 60%
перегруженность: > 80%
Далее сравниваем MA15_90DMAX и PCT90_90DMAX с целевыми показателями и категоризируем каждый сервер по каждому из ресурсов (CPU, RAM, HDD).
Теперь пару слов о том, почему используем оба параметра MA15 и PCT90, а не какой то один. Если говорить очень кратко, то каждый сервер использует ресурсы по-разному и тестирование на серверах проходят разные. Некоторые могут быть стабильно утилизированы — для таких серверов более показательна MA15. Другие сервера интенсивно работают лишь небольшой промежуток времени, а остальное время простаивают.
Базовой для нас является все-таки MA15, но если показания MA15 и PCT 90 сильно различаются, то приходится проводить более детальный анализ.
Ближайшим развитием этой методики мы видим профилирование серверов по типу нагрузки. Считаю, что в перспективе это позволит серьезно оптимизировать распределение виртуалок по гипервизорам и обеспечить стабильность работы даже в условиях значительной переподписки. Но до реализации данной методики руки пока что не дошли, хотя из полученных данных уже ясно, что эта работа принесет положительные результаты.
* все приведенные в данном описании метрики определены именно для нашей инфраструктуры и для нашей компании. Далеко не факт, что для вас подойдет именно 15-ти минутное усреднение или именно 90% перцентиль. Мы, например, делали пилотный проект и выбирали примерно из 20 комбинацией перцентиля и разных интервалов усреднения
** для ПРОМ-а эта методика требует доработок, так как специфика работы и нагрузки ПРОМ систем отличается от тестовых сред кардинально.
В Zabbix для каждого сервера вычисляются метрики 15-ти минутного скользящего среднего (далее MA15) и 90% перцентиля* (далее PCT90) для каждого из трех параметров: CPU Utilization, RAM Utilization, Disk Utilization — по каждому разделу.
Для MA15 базовый интервал сбора — 60 секунд (на то оно и скользящее)
Для PCT90 интервал сбора — 15 минут, данная метрика менее ресурсоёмкая.
Далее отдельными метриками в Zabbix же вычисляем суточные максимумы для MA15 и PCT90: MA15_1DMAX и PCT90_1DMAX
В итоге, получаем 30 значений в месяц для каждой из метрик.
Анализ мы ведем на промежутке 3-х месяцев: анализируем по 90 значений каждой метрики MA15_1DMAX и PCT90_1DMAX.
Из этих 90 значений отбрасываем одно наибольшее:
1) Пытаемся избежать попадания в выборку случайного повышения нагрузки
2) Не берем в расчет нагрузку, которая за три месяца возникала всего один раз
Из оставшихся 89 значений выбираем наибольшее по обеим метрикам. Назовем полученные два значения MA15_90DMAX и PCT90_90DMAX (не забываем, что на самом деле это не максимум, а «второй» максимум — первый мы исключили из выборки).
Для нашей инфраструктуры тестовых сред** мы определили следующие целевые показатели:
оптимальная загруженность: 60-80%
недозагруженность: < 60%
перегруженность: > 80%
Далее сравниваем MA15_90DMAX и PCT90_90DMAX с целевыми показателями и категоризируем каждый сервер по каждому из ресурсов (CPU, RAM, HDD).
Теперь пару слов о том, почему используем оба параметра MA15 и PCT90, а не какой то один. Если говорить очень кратко, то каждый сервер использует ресурсы по-разному и тестирование на серверах проходят разные. Некоторые могут быть стабильно утилизированы — для таких серверов более показательна MA15. Другие сервера интенсивно работают лишь небольшой промежуток времени, а остальное время простаивают.
Базовой для нас является все-таки MA15, но если показания MA15 и PCT 90 сильно различаются, то приходится проводить более детальный анализ.
Ближайшим развитием этой методики мы видим профилирование серверов по типу нагрузки. Считаю, что в перспективе это позволит серьезно оптимизировать распределение виртуалок по гипервизорам и обеспечить стабильность работы даже в условиях значительной переподписки. Но до реализации данной методики руки пока что не дошли, хотя из полученных данных уже ясно, что эта работа принесет положительные результаты.
* все приведенные в данном описании метрики определены именно для нашей инфраструктуры и для нашей компании. Далеко не факт, что для вас подойдет именно 15-ти минутное усреднение или именно 90% перцентиль. Мы, например, делали пилотный проект и выбирали примерно из 20 комбинацией перцентиля и разных интервалов усреднения
** для ПРОМ-а эта методика требует доработок, так как специфика работы и нагрузки ПРОМ систем отличается от тестовых сред кардинально.
Как вы делали интеграцию с HP SM и Jira? Какие проблемы при этом решали?
Мы думали сделать, но отказались от этой идеи и тикеты об авариях проходят через человека.
Мы думали сделать, но отказались от этой идеи и тикеты об авариях проходят через человека.
Для интеграции с JIRA использовали питоновский модуль JIRA. В нем создавали тикет. Проблемы могут появиться из за составления тикета для отправки внутри скрипта. Формат зависит от workflow в Jira, который использует проект (переход тикетов из одного статуса в другой и т.д.) при изменении этого workflow, скрипт отправки нужно корректировать.
Да, еще проблема была с автоматическим закрытием тикета в JIRA, так как где-то нужно было хранить соответствия номера тикета и события в Zabbix, на основании которого этот тикет был создан. Для этого использовали небольшую базу SQLite.
Для интеграции с HP SM, для нас сделали Web сервис (WSDL). В скрипте мы готовили XML c с описанием инцидента и подавали на вход этому сервису.
В скрипте использовали библиотеку suds.
Проблемы были, в основном, организационного характера и были связаны с коммуникациями.
Да, еще проблема была с автоматическим закрытием тикета в JIRA, так как где-то нужно было хранить соответствия номера тикета и события в Zabbix, на основании которого этот тикет был создан. Для этого использовали небольшую базу SQLite.
Для интеграции с HP SM, для нас сделали Web сервис (WSDL). В скрипте мы готовили XML c с описанием инцидента и подавали на вход этому сервису.
В скрипте использовали библиотеку suds.
Проблемы были, в основном, организационного характера и были связаны с коммуникациями.
По Jira интеграции очень интересно, да. И еще вопрос — вы не собирали с помощью Zabbix данные по установленному софту и его версиям? Если данные не закрытые — какое у вас приблизительное соотношение Linux/Windows на серверах, которые мониторятся Zabbix?
Скажем так, Linux на 14% больше, чем Windows.
Я думаю, если сообщество проявит интерес к тому, как организован мониторинг ИТ-инфраструктуры у нас в компании, я продолжу публиковать статьи, где буду описывать наиболее интересные моменты относительно того, как работает наш сервис.
Я думаю, если сообщество проявит интерес к тому, как организован мониторинг ИТ-инфраструктуры у нас в компании, я продолжу публиковать статьи, где буду описывать наиболее интересные моменты относительно того, как работает наш сервис.
И еще вопрос — вы не собирали с помощью Zabbix данные по установленному софту и его версиям?
Да, конечно собираем. Если почитать внимательнее основные цели проекта, то там присутствует: «Аудит соответствия окружений тестовых сред и промышленных АСМ». Это как раз в том числе про соответствие версий софта в проме и тестовых средах. Кроме того, в разделе отчетность я явно указал наличие отчета «о соответствии версий ППО в стенде для сравнения с конфигурацией промышленных сред».
Да, конечно собираем. Если почитать внимательнее основные цели проекта, то там присутствует: «Аудит соответствия окружений тестовых сред и промышленных АСМ». Это как раз в том числе про соответствие версий софта в проме и тестовых средах. Кроме того, в разделе отчетность я явно указал наличие отчета «о соответствии версий ППО в стенде для сравнения с конфигурацией промышленных сред».
В целом интересно было почитать, спасибо за статью.
Но некоторые моменты меня смутили, вроде восьмичасового простоя при обновлении при полной недоступности мониторинга.
Восемь часов простоя при обновлении выглядит как фатальный неустранимый недостаток и повод отказаться от подобной системы и уехать на что-нибудь другое.
Почему это вообще не стало причиной отказа от использования Zabbix?
Есть же, к примеру, Sensu как мониторинг, есть специальные стораджи для метрик вроде InfluxDB и Graphite (даже он прекрасно выдержит 20krps на современном железе с SSD), которые, кроме на порядок большей нагрузки, умеют еще и в различные выборки, запросы и агрегирование гибкое (в Graphite можно еще и свои функции написать, благо python).
Для inventory тоже множество решений различных, даже в рамках configuration management утилит. Не знаю есть ли что-то подобное для Ansible, но для Puppet есть специальный модуль который все собирает.
Но некоторые моменты меня смутили, вроде восьмичасового простоя при обновлении при полной недоступности мониторинга.
Восемь часов простоя при обновлении выглядит как фатальный неустранимый недостаток и повод отказаться от подобной системы и уехать на что-нибудь другое.
Почему это вообще не стало причиной отказа от использования Zabbix?
Есть же, к примеру, Sensu как мониторинг, есть специальные стораджи для метрик вроде InfluxDB и Graphite (даже он прекрасно выдержит 20krps на современном железе с SSD), которые, кроме на порядок большей нагрузки, умеют еще и в различные выборки, запросы и агрегирование гибкое (в Graphite можно еще и свои функции написать, благо python).
Для inventory тоже множество решений различных, даже в рамках configuration management утилит. Не знаю есть ли что-то подобное для Ansible, но для Puppet есть специальный модуль который все собирает.
Восьмичасовой простой возник лишь один раз. Кроме того, как я уже сказал, мы нашли решение для этой проблемы в будущем (обновление базы напрямую SQL скриптами, не через сервер приложений), поэтому это не стало причиной отказа. Если бы это был мониторинг ПРОМ-а, такой проблемы у нас не возникло бы (протестировали бы обновление на полноценном клоне базы и выявили бы все проблемы на этапе тестирования).
По поводу вопроса выбора альтернативы — считаю этот вопрос риторическим. Существует огромное количество разных инструментов мониторинга, каждый со своими болезнями. Какие то чуть лучше мониторят одну часть инфраструктуры, другие чуть лучше другую. Zabbix вполне сбалансированный инструмент, который пригоден для мониторинга большой инфраструктуры и я пока что не вижу причин от него отказываться. Во всяком случае, лично для меня сейчас проблема долгого обновления больших шаблонов — проблема намного более серьезная, нежели проблема времени обновления базы.
Кроме того, я считаю, что 80% успеха мониторинга лежит в организационной плоскости и создании эффективного процесса, а не в выборе инструмента.
На следующей неделе я планирую опубликовать статью, в которой опишу основные моменты организации процесса мониторинга.
По поводу вопроса выбора альтернативы — считаю этот вопрос риторическим. Существует огромное количество разных инструментов мониторинга, каждый со своими болезнями. Какие то чуть лучше мониторят одну часть инфраструктуры, другие чуть лучше другую. Zabbix вполне сбалансированный инструмент, который пригоден для мониторинга большой инфраструктуры и я пока что не вижу причин от него отказываться. Во всяком случае, лично для меня сейчас проблема долгого обновления больших шаблонов — проблема намного более серьезная, нежели проблема времени обновления базы.
Кроме того, я считаю, что 80% успеха мониторинга лежит в организационной плоскости и создании эффективного процесса, а не в выборе инструмента.
На следующей неделе я планирую опубликовать статью, в которой опишу основные моменты организации процесса мониторинга.
Если не секрет, то что на что обновляли? И про какие sql-скрипты пишете? Где их можно поискать?
Если не ошибаюсь, то обновлялись с 2.2 до 3.0.х.
После обновления сервера приложений, при первом старте, сервер проверяет версию базы. В случае, если база старой версии, начинает ее обновлять… Вот это обновление у нас и затянулось. Поискать скрипты можно либо внутри патчей, которыми обновляется Zabbix, либо запросить непосредственно в Zabbix.
Мы уже давно прошли этот этап, поэтому точного файла, в котором храняться эти патчи и запросы по памяти не подскажу.
После обновления сервера приложений, при первом старте, сервер проверяет версию базы. В случае, если база старой версии, начинает ее обновлять… Вот это обновление у нас и затянулось. Поискать скрипты можно либо внутри патчей, которыми обновляется Zabbix, либо запросить непосредственно в Zabbix.
Мы уже давно прошли этот этап, поэтому точного файла, в котором храняться эти патчи и запросы по памяти не подскажу.
Основные проблемы, которые возникали перед нами за последние 4 года работы с Zabbix, мы так или иначе успешно решали. Причем, несмотря на шестилетний опыт работы с Enterprice решениями для мониторинга от HP (ныне MicroFocus), я сомневаюсь, что я смог бы так же успешно справиться с этими проблемами на стеке их мониторинга.
Кроме того, я считаю, что 80% успеха мониторинга лежит в организационной плоскости и создании эффективного процесса, а не в выборе инструмента.
Это безусловно, тут я с вами совершенно согласен.
Основные проблемы, которые возникали перед нами за последние 4 года работы с Zabbix, мы так или иначе успешно решали. Причем, несмотря на шестилетний опыт работы с Enterprice решениями для мониторинга от HP...
Я понимаю, что вы сравниваете с другим Enterprise решением и наверно в сравнении с ним Zabbix действительно лучше.
Я все это написал просто к тому, что сталкивался с ним неоднократно и он на столько со скрипом решает некоторые задачки: банальная годовая выборка с агрегацией, чтобы посмотреть глобальные тенденции дается его базе очень тяжело, а ведь еще есть динамическое создание, для которых нужны шаблоны, без которых совсем все плохо и все равно придется их настраивать, но все это больно и неудобно (вы это уже упоминали как раз), реализация многих концепций вроде динамической балансировки приложений по доступным нодам тоже малореальна и т.п.
Да, мне кажется просто наши инфраструктуры выглядят совсем по-разному и именно поэтому я Zabbix последние лет 7 воспринимаю как что-то, от чего все равно придется избавляться.
Кстати, а на проде тоже Zabbix, или вы поддерживаете разные системы мониторинга для разных сред?
банальная годовая выборка с агрегациейВ условиях нашей компании такая выборка по всей инфраструктуре это уже BigData. И решать такую задачу нужно соответствующими средствами. Кстати, у нас реализованы инструменты экспорта данных из базы Zabbix в NoSQL. Там эти данные специалисты Capacity Management могут крутить так как им нужно. IMHO это не задача сервиса мониторинга.
а ведь еще есть динамическое создание, для которых нужны шаблоны, без которых совсем все плохо и все равно придется их настраивать, но все это больно и неудобноЗвучит как-то по Prometheus-овски. Zabbix в том числе устраивает нас потому, что хотя у меня и есть претензии к его ролевой модели, с помощью неё удается поддерживать сервис на 1000+ пользователей. И именно эта ролевая модель не дает грузить в базу все подряд (как это происходит в некоторых других инструментах мониторинга. Но опять же, это мое личное мнение.
Еще раз повторюсь, в любой компании есть своя специфика. Прежде всего, подход к мониторингу зависит от того, как в принципе в компании реализован цикл разработки, тестирования и сопровождения в проме систем. Скажем так, если бы каждую систему на протяжении всего жизненного цикла (в том числе в ПРОМ-е) сопровождала бы одна независимая от других команда, то инструментом мониторинга точно был бы не Zabbix.
UFO just landed and posted this here
Оперативное информирование специалистов о неполадках в работе тестовых сред;
Чистая правда, вот только мне приходила вся инфа о неполадках всех тестовых контуров, а я хотел только мои сервера. Сказали, что так нельзя и junk забивался очень быстро.
Я так понимаю Заббикс единый инструмент технического мониторинга? Бизнес события у нас выгребал Splunk
Сказали, что так нельзя и junk забивался очень быстро: Что — то мне подсказывает, что вы общаетесь с командой мониторинга банка, а не с нашей командой. Мы вам такого сказать не могли. Всем, кто озаботился настройкой оповещений, мы помогли сделать их максимально полезными.
Наш сервис — единственный централизованный сервис мониторинга тестовых сред. Насколько мне известно, других централизованных инструментов мониторинга в СБТ нет.
Наш сервис — единственный централизованный сервис мониторинга тестовых сред. Насколько мне известно, других централизованных инструментов мониторинга в СБТ нет.
Что — то мне подсказывает, что вы общаетесь с командой мониторинга банка, а не с нашей командой
Да, вполне возможно, настраивали давно
Наш сервис — единственный централизованный сервис мониторинга тестовых сред
В ЕФС было распоряжение от ЦСПС с приемкой бизнес событий мониторинга через Splunk. НТ тоже производили с подключением этого добра, там даже команда отдельная есть, которая спланк сопровождает.
UFO just landed and posted this here
SCOM использовался в банке, но насколько я знаю, сейчас обсуждается уход от SCOM в связи с его низкой производительностью. Наша команда никаких других инструментов, кроме Zabbix не поддерживает.
UFO just landed and posted this here
Я бы выразился немного по-другому: Сберу хватило ума перестать прикладывать усилия к тому, чтобы заставить работать SCOM и он обратил внимание на другие, более отзывчивые и простые в настройке инструменты мониторинга. Я совсем не хочу обидеть ни SCOM, ни тех, кто его использует. Просто по моему мнению, этот инструмент не очень подходит для нашей компании.
SCOM стоит денег. Тяжело найти высоквалифицированных специалистов (их мало) на сапорт и написание пакетов, запрашиваемые ими ставки также высоки. Zabbix при всех его не достатках, достаточно прос в эксплуатации, расширении функционала и не имеет проблем с агентами.
Спасибо за за статью и что делитесь опытом.
Вы как-то дублируете сбор критически важных метрик (доступность, целостность сети) на уровне сервисов? Второй/отдельный Zabbix? Возможно, полностью автономная параллельная система на другом софте? Следите ли (и если да — то с помощью чего) за работоспособностью самого сервиса сбора метрик?
Вы как-то дублируете сбор критически важных метрик (доступность, целостность сети) на уровне сервисов? Второй/отдельный Zabbix? Возможно, полностью автономная параллельная система на другом софте? Следите ли (и если да — то с помощью чего) за работоспособностью самого сервиса сбора метрик?
Как я уже писал выше, у нас работает три инстанса Zabbix.
Один из них как раз и дублирует мониторинг критически важных для компании сервисов (в том числе, на нем развернут и «мониторинг мониторинга»). Этот инстанс намного меньше чем инстанс мониторинга тестовых сред, а потому работает он значительно стабильнее (нагрузка на нем порядка 200 НВПС).
Если вам интересно, я могу попробовать описать наш внутренний мониторинг (графики и метрики, по которым мы диагностируем проблемы на Zabbix) в отдельном посте.
Один из них как раз и дублирует мониторинг критически важных для компании сервисов (в том числе, на нем развернут и «мониторинг мониторинга»). Этот инстанс намного меньше чем инстанс мониторинга тестовых сред, а потому работает он значительно стабильнее (нагрузка на нем порядка 200 НВПС).
Если вам интересно, я могу попробовать описать наш внутренний мониторинг (графики и метрики, по которым мы диагностируем проблемы на Zabbix) в отдельном посте.
Да, было бы интересно как именно мониторите сам Zabbix (нагруженный) — жизнеспособность агентов на целевых хостах, работоспособность внутренностей сервера сборки данных и прочее. Какие с этим были проблемы, как разрешались. Спасибо.
+1к интересующимся, расскажите пожалуйста про проблемы Zabbix и их анализ
А что используете в качестве конфигурационной базы данных? Интеграцию делали самостоятельно или использовали что-то готовое?
Как много времени заняло внедрение? На что потратили больше всего времени?
Как много времени заняло внедрение?Сложно сказать, так как активное развитие сервиса продолжается все время и сейчас его даже больше, чем было год или два назад и надеюсь. Не уверен, что для сервиса мониторинга вообще возможно такое понятие, как «окончание внедрения».
На что потратили больше всего времени?Опять же, в связи со спецификой нашей инфраструктуры и в частности инфраструктуры, на которой работает наш сервис, много времени за последние четыре года приходилось тратить оптимизацию производительности (если в о технических моментах). Наверное, чуть позже я опишу мощности, которые задействованы в нашем сервисе. К примеру, 19000 НВПС нам удалось достичь на 8 ядрах (на основном сервере приложений), без SSD, High-End или чего-либо в этом роде.
Если говорить об организационных моментах, самым сложным было добиться популярности нашего сервиса в компании, так как наших заказчиков никто не заставлял работать именно с нашим сервисом.
Спасибо за интересную статью.
Расскажите пожалуйста как вы осуществляете мониторинг базы данных в забиксе? Ведь из коробки он совершенно не предназначен для этого. Мониторить базы через ODBC — это смерти подобно. Другие наколенные решения (скрипты, доп. программы и z-модули), например для Oracle — это zbxora, для Pg — libzbxpgsql, для MySQL (думаю у вас нет его) — нет ничего достойного.
Спасибо.
Расскажите пожалуйста как вы осуществляете мониторинг базы данных в забиксе? Ведь из коробки он совершенно не предназначен для этого. Мониторить базы через ODBC — это смерти подобно. Другие наколенные решения (скрипты, доп. программы и z-модули), например для Oracle — это zbxora, для Pg — libzbxpgsql, для MySQL (думаю у вас нет его) — нет ничего достойного.
Спасибо.
Нам удалось добиться от ODBC более менее стабильной работы. Сильно помогли в этом мастер-метрики. Так что сейчас мы продолжаем использовать именно ODBC, благо процесс постановки на мониторинг баз почти полностью автоматизирован.
Самой большой проблемой на данный момент является то, что невозможно в прототипах элементов данных (далее ЭД) разведки использовать в качестве мастер-метрики использовать обычный ЭД из шаблона. Такой функционал значительно снизил бы количество сессий, который мониторинг создает к базе. Но и использование мастер-метрики внутри разведки по каждому Tablespace уже снизило количество создаваемых сессий примерно в 3 раза.
У нас запланировано основательное тестирование инструментария DBforBIX, но руки до этого пока что не дошли. Решающим при окончательном выборе будет возможность полной автоматизации процесса постановки на мониторинг, так как баз, которые нужно мониторить у нас очень много.
Самой большой проблемой на данный момент является то, что невозможно в прототипах элементов данных (далее ЭД) разведки использовать в качестве мастер-метрики использовать обычный ЭД из шаблона. Такой функционал значительно снизил бы количество сессий, который мониторинг создает к базе. Но и использование мастер-метрики внутри разведки по каждому Tablespace уже снизило количество создаваемых сессий примерно в 3 раза.
У нас запланировано основательное тестирование инструментария DBforBIX, но руки до этого пока что не дошли. Решающим при окончательном выборе будет возможность полной автоматизации процесса постановки на мониторинг, так как баз, которые нужно мониторить у нас очень много.
Самой большой проблемой на данный момент является то, что невозможно в прототипах элементов данных (далее ЭД) разведки использовать в качестве мастер-метрики использовать обычный ЭД из шаблона
В Zabbix 4.0, начиная с 9 альфы, такую возможность уже включили.
Вот про ODBC www.youtube.com/watch?v=VSl1mqoDaqg&feature=youtu.be
Другой вопрос, а Вы не пробовали ставить Haproxy перед Oracle, чтобы он немного коннекты кешировал до Oracle?
Другой вопрос, а Вы не пробовали ставить Haproxy перед Oracle, чтобы он немного коннекты кешировал до Oracle?
Вот про один запрос и много метрик blog.zabbix.com/zabbix-3-4-mass-data-collection-using-mercury-and-smartmontools-as-an-example/5784
Спасибо, интересно
Но вот такой вопрос, навеянный цифрой 1500 тестовых сред и затем слайдом с Магнитом, в котором указано 11К прокси:
А не приходила мысль на 1500 тестовых сред создавать 1500 инстансов заббиксов, локальных для каждой тестовой среды? Так же как вы раскатываете zabbix-агентов, тем же ансиблом можно автоконфигурить и раскатывать и zabbix-server-а
В каждом таком инстансе будут свои пользователи со своими метриками от своей тестовой среды. Требования по производительности инстанса минимальны. Можно развернуть на виртуалке или даже в докере.
Конечно, главный Zabbix для мониторинга непосредственно железа и крутых отчетов останется, но нагрузка и количество пользователей радикально уменьшится. А насколько проще будет чистить базу от разобранных тестовых сред
Но вот такой вопрос, навеянный цифрой 1500 тестовых сред и затем слайдом с Магнитом, в котором указано 11К прокси:
А не приходила мысль на 1500 тестовых сред создавать 1500 инстансов заббиксов, локальных для каждой тестовой среды? Так же как вы раскатываете zabbix-агентов, тем же ансиблом можно автоконфигурить и раскатывать и zabbix-server-а
В каждом таком инстансе будут свои пользователи со своими метриками от своей тестовой среды. Требования по производительности инстанса минимальны. Можно развернуть на виртуалке или даже в докере.
Конечно, главный Zabbix для мониторинга непосредственно железа и крутых отчетов останется, но нагрузка и количество пользователей радикально уменьшится. А насколько проще будет чистить базу от разобранных тестовых сред
А не приходила мысль на 1500 тестовых сред создавать 1500 инстансов заббиксовМожно привести очень много причин того, почему это делать не стоит. Приведу лишь некоторые:
- Появится полторы тысячи виртуалок/контейнеров Zabbix (по крайней мере у нас в компании, на тестовом стенде нельзя держать никакой сторонний софт, так что под каждый инстанс Zabbix придется резервировать отдельные ресурсы)
- Каждой команде придется держать экспертизу по мониторингу.
- Каждая команда неизбежно будет тратить ресурсы на разработку примерно одних и тех же метрик мониторинга. В рамках компании это КОЛОССАЛЬНОЕ КОЛИЧЕСТВО ресурсов. Одним из плюсов нашего сервиса является то, что в моем подразделении сосредоточена подавляющая часть экспертизы мониторинга компании (мы так или иначе в курсе всех активностей, связанных с мониторингом в Сбертехе и банке). И сейчас, спустя 4 года, если к нам обращаются с просьбой о разработке того или иного функционала, мы можем ответить, что «это уже было в Симсонах». Если же это действительно что-то новое, мы сразу ведем разработку так, чтобы новый инструмент затем можно было тиражировать на все среды тестирования, где это возможно. Мы также сразу информируем потенциальных потребителей о появлении нового функционала и т.д.
- Мы не избавляемся от централизованного инстанса, иначе не получим целостной картины состояния инфраструктуры.
- И еще много много всего.
Я бы рассмотрел возможность подобной идеологии (инструментом, скорее всего, был бы не Zabbix) только в том случае, если каждая АС поддерживается совершенно независимой командой от начала и до конца (и нет каких то сервисных подразделений, которые занимаются администрированием всей инфраструктуры в целом). — Об этом я уже написал в одном из комментариев.
1. серверный истанс не обязан стоять именно на тех же серверах, что и тестовые среды. можно все инстансы собрать на отдельную ферму и в отдельную подсеть и в облако, да куда угодно. А в zabbix-agent-ы разных сред добавить к параметру ServerName, кроме вашего центрального сервера, FQDN инстанса соответствующего среде
2. А кто же те 1000 пользователей вашего централизованного забикса. Они если сейчас не эксперты, то для них мало что изменится. Ну url будут другой писать.
3. Администровать все инстансы будет по прежнему ваше подразделение
4. Конечно его необходимо оставить. Я об этом прямо написал
5. Вот тут согласен :)
И это… я не настаиваю, просто в последнее время начал смотреть на различные ИТ решения под углом: «А насколько это решение масштабируется?»
2. А кто же те 1000 пользователей вашего централизованного забикса. Они если сейчас не эксперты, то для них мало что изменится. Ну url будут другой писать.
3. Администровать все инстансы будет по прежнему ваше подразделение
4. Конечно его необходимо оставить. Я об этом прямо написал
5. Вот тут согласен :)
И это… я не настаиваю, просто в последнее время начал смотреть на различные ИТ решения под углом: «А насколько это решение масштабируется?»
Как вы сделали такие оповещения, там же plain text из коробки?
Полностью переписали оповещения на Python.
На вход скрипту в форме действия передается словарь такого вида:
скрипт получает на вход этот словарь и шаблон html письма. В этом шаблоне он заменяет значения по словарю и готовит из него body для почтового сообщения, которое затем отправляет.
[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 мы храним ID КЭ этого сервера из CMDB так что при необходимости, мы по этому ID можем всегда обратиться в систему учета (Service Manager). Думаю, при необходимости аналогичным образом можно поступать и с другими системами инвентаризации.
Кое каким лайфхаком является то, что в одном из полей инвентаризации в Zabbix мы храним ID КЭ этого сервера из CMDB так что при необходимости, мы по этому ID можем всегда обратиться в систему учета (Service Manager). Думаю, при необходимости аналогичным образом можно поступать и с другими системами инвентаризации.
Спасибо, да я наступал на эти грабли =) добавлял новые поля в базу и проводил их везде по гуи чтоб работали. Включая добавление выбора полей для показа из гуи, но это очень сложно обновлять.
Конечно хотелось бы не собирать одни и те же данные 2жды и иметь все в одном месте но похоже да, писать просто ид и собирать другой системой единственный выход, либо выгружать через API
Спасибо за информацию.
Конечно хотелось бы не собирать одни и те же данные 2жды и иметь все в одном месте но похоже да, писать просто ид и собирать другой системой единственный выход, либо выгружать через API
Спасибо за информацию.
Я в свое время использовал поля не по назначению (например запихивая туда JSON) и прикручивал самописную страницу-морду. Но все это разбилось в момент когда эту «CMDB» нужно было расширять (например для статистики). В итоге создал отдельные таблицы, а скрипты через zAPI получали списки машин и обходили их для сбора нужных данных (через итемы агента или через ssh). С задачей сбора версий ПО этот костыль стравлялся на ура.
PS: Может кто подскажет более красивое/рассово верное решение с учетом того что не весь софт был из реп и многое ставилось в /opt (т.е. кастомные, хотя и стандартизирование, пути)? :)
PS: Может кто подскажет более красивое/рассово верное решение с учетом того что не весь софт был из реп и многое ставилось в /opt (т.е. кастомные, хотя и стандартизирование, пути)? :)
Sign up to leave a comment.
Zabbix на стероидах: как устроена единая платформа мониторинга Сбертеха