Zabbix в Badoo или о чем не пишут в мануале, Илья Аблеев (Badoo)Badoo Development
Доклад с Zabbix Meetup.
Рассказали про:
• Сколько инстансов используем, зачем, какая конфигурация и нагрузка, какие дополнительные тулзы используем.
• Деплой скриптов/конфигов/обновлении.
• Флоу появления новых сущностей в мониторинге: хостов, проверок, графиков в заббикс. Самописный дискавери (серверов, сервисов): почему свой и что он умеет.
• Штуки для удобства: нотификации на рабочий стол, быстрая навигация по графикам.
Доклад Ильи Аблеева на DevOps Meetup "Мониторинг высоконагруженного проекта".Badoo Development
О чем доклад:
- Как в нашем проекте устроен Zabbix, применяемые нами способы автоматизации, собственные методы "дискавери" серверов и сервисов. Плюс как правильно держать Zabbix под высокой нагрузкой и не упираться в ресурсы серверов.
- Для чего мы используем Pinba, какие именно метрики помогают нам узнать о реальных проблемах пользователей.
- Как мы храним графики в RRD. Мониторинг этих графиков: User activity monitoring.
- Zabbix -> RRD => Capacity Planning.
Как быстро найти слабые места среди кластеров в десятки и сотни нод.
Мониторинг в высоконагруженных (и не только) проектах: сравнительный анализ с...Ontico
Выбор системы мониторинга - это практически holy-war-ная тема среди администраторов и разработчиков. Какая система лучше? Что удобнее? Какая система сможет выдержать большое количество статистики, а какая - лучше собрать и представить данные?
В своем докладе мы попробуем предельно непредвзято рассмотреть существующие решения и понять, что и когда можно использовать.
См. тезисы - http://rootconf.ru/2015/abstracts/1746
Инфраструктура распределенных приложений на nodejs / Станислав Гуменюк (Rambl...Ontico
Мы создаем nodejs приложения, используя различные современные технологии, такие как Docker, Consul, pm2. Современный спектр решений настолько обширен, что сложно не заблудиться. Как же выбрать нужные вашему проекту технологии, чтобы успешно его запустить и поддерживать? Будут рассказаны истории и, конечно же, даны вредные советы :)
Как на nodejs пройти путь от Hello world приложения до распределённого решения, состоящего из микросервисов?
Мы пройдём жизненный цикл продукта, начав с простого приложения на nodejs. Научимся его правильно запускать и будем постепенно добавлять элементы, убирая при этом ненужные. Так к нашему приложению присоединится гипервизор, а само оно будет разделено на части, где каждая сущность будет управлять своей частью приложения.
Построив таким образом архитектуру на чистом nodejs, мы займёмся развитием приложения, добавим современные технологии и применим новые подходы к организации инфраструктуры. Запакуем приложение в Docker, попутно обсудим, зачем он нужен и что может дать. И, наконец, решим проблему поиска запущенных сервисов и отслеживания их статусов, используя Consul.
Zabbix в Badoo или о чем не пишут в мануале, Илья Аблеев (Badoo)Badoo Development
Доклад с Zabbix Meetup.
Рассказали про:
• Сколько инстансов используем, зачем, какая конфигурация и нагрузка, какие дополнительные тулзы используем.
• Деплой скриптов/конфигов/обновлении.
• Флоу появления новых сущностей в мониторинге: хостов, проверок, графиков в заббикс. Самописный дискавери (серверов, сервисов): почему свой и что он умеет.
• Штуки для удобства: нотификации на рабочий стол, быстрая навигация по графикам.
Доклад Ильи Аблеева на DevOps Meetup "Мониторинг высоконагруженного проекта".Badoo Development
О чем доклад:
- Как в нашем проекте устроен Zabbix, применяемые нами способы автоматизации, собственные методы "дискавери" серверов и сервисов. Плюс как правильно держать Zabbix под высокой нагрузкой и не упираться в ресурсы серверов.
- Для чего мы используем Pinba, какие именно метрики помогают нам узнать о реальных проблемах пользователей.
- Как мы храним графики в RRD. Мониторинг этих графиков: User activity monitoring.
- Zabbix -> RRD => Capacity Planning.
Как быстро найти слабые места среди кластеров в десятки и сотни нод.
Мониторинг в высоконагруженных (и не только) проектах: сравнительный анализ с...Ontico
Выбор системы мониторинга - это практически holy-war-ная тема среди администраторов и разработчиков. Какая система лучше? Что удобнее? Какая система сможет выдержать большое количество статистики, а какая - лучше собрать и представить данные?
В своем докладе мы попробуем предельно непредвзято рассмотреть существующие решения и понять, что и когда можно использовать.
См. тезисы - http://rootconf.ru/2015/abstracts/1746
Инфраструктура распределенных приложений на nodejs / Станислав Гуменюк (Rambl...Ontico
Мы создаем nodejs приложения, используя различные современные технологии, такие как Docker, Consul, pm2. Современный спектр решений настолько обширен, что сложно не заблудиться. Как же выбрать нужные вашему проекту технологии, чтобы успешно его запустить и поддерживать? Будут рассказаны истории и, конечно же, даны вредные советы :)
Как на nodejs пройти путь от Hello world приложения до распределённого решения, состоящего из микросервисов?
Мы пройдём жизненный цикл продукта, начав с простого приложения на nodejs. Научимся его правильно запускать и будем постепенно добавлять элементы, убирая при этом ненужные. Так к нашему приложению присоединится гипервизор, а само оно будет разделено на части, где каждая сущность будет управлять своей частью приложения.
Построив таким образом архитектуру на чистом nodejs, мы займёмся развитием приложения, добавим современные технологии и применим новые подходы к организации инфраструктуры. Запакуем приложение в Docker, попутно обсудим, зачем он нужен и что может дать. И, наконец, решим проблему поиска запущенных сервисов и отслеживания их статусов, используя Consul.
мониторинг производительности Web приложений на pythonSlach
как понять где тормозит твое приложение в реальном времени? как не потеряться в океане метрик и собрать на дашборде только нужные? видео https://youtu.be/JgezdgtoNG8
Мастер-класс "Микросервисы: удобно, надежно, серебрянопульно" / Евгений Павло...Ontico
В процессе рефакторинга архитектуры мы начали переделывать часть системы на микросервисы, и вышло настолько клево, что мы просто обязаны этим поделиться.
Микросервисы.
Зачем они вообще:
- В простых сервисах легче разбираться и локализовывать проблемы.
- В микросервисной архитектуре проще добиваться отказоустойчивости.
- Хотим выбирать лучший инструмент для каждой задачи. Получаем зоопарк технологий, которые в монолитные сервисы интегрировать сложнее.
- Независимое обновление компонентов.
- Тестирование частей системы.
Как:
- Docker-образы как основа.
- Rancher как система деплоя и оркестрации Docker-контейнеров. High availability.
- Простота сервиса - ключевой момент.
== Критерий: Разработчик должен иметь возможность быстро понять и переписать сервис при необходимости.
== Забавное следствие: такие сервисы пишутся не на века, а под текущие требования. Получается быстро и agile-но, ведь изменения легко сможет внести любой разработчик.
== PEP8.
- HTTP API и поддержка Swagger. Резко упрощают тестирование.
- RabbitMQ pipelines как отказоустойчивая система взаимодействий между сервисами:
== DLX помогает разбираться со врЕменными проблемами.
== HTTP RPC.
- Метрики, метрики и ещё раз метрики.
== service status API.
== Graphite, Zabbix. Может, к ноябрю еще OKmeter успеем попробовать.
- Структурированые логи: JSON stdout => Fluentd => ELK => счастье. Локализация багов и пр. Об этом подробнее в отдельной презентации.
- В любой непонятной ситуации...
== Сервис должен падать, а не зависать.
== Healthchecks.
- Стабильность архитектуры.
== Осознанная деградация! Любой сервис должен быть готов к падению другого. При этом в первом должно быть явно описано, как будет при этом ограничиваться его функциональность. Это ведет к отсутствию эффекта домино, когда один малозначащий сервис, упав, утягивает за собой всю систему.
- Документация.
== Степень критичности каждого сервиса.
== Краткий обзор функциональности (вспоминаем: сервисы _простые_).
== Конфиги.
== drawback: описание архитектуры обязано быть актуальным и полным, иначе беда.
Трудности: Допишу через пару дней.
Обзор архитектуры и подсистем деплоя и мониторинга.
Как инженеры делают систему прозрачной для разработки.
1) Схема организации репозитория puppet.
Зачем мы сделали репозиторий публичным внутри компании?
Как мы "делим" puppet, и что делать, если все "пропало"?
Собственная реализация механизма puppet kick.
2) Как рассказать всем обо всем и никого не потерять.
"Черный мониторинг" (rbmon). Как мы собираем информацию о серверах и демонах.
Делимся логами с разработчиками. Почему написали "велосипед"?
3) Graphite - система сбора и визуализации данных.
Почему graphite?
1М метрик в минуту?
Какие метрики мы рисуем (nginx-graphite-module, rbmon plugins).
Визуализация работы проекта (Dashboard пульт).
Как не положить тысячи серверов с помощью системы централизованного управлени...Ontico
В 2012 году мы начали внедрение CFEngine в нашу инфраструктуру. Переход на централизованное управление конфигурацией в проектах такого масштаба подобен ремонту - его невозможно закончить, его можно только прекратить. И уже весной 2013 года (в день 404 ошибки и международного дня Интернета) этот "ремонт" превратился в катастрофу и был остановлен. После 3 суток недоступности портала нам пришлось изобрести схему, которая бы физически ограничивала возможность повторения катастрофы. Схема включает в себя тестирование политик на тестовых серверах различной важности и конфигурации. "Маринование" в этой тестовой среде сопровождается автоматизированным контролем характеристик нагрузки этих серверов. Далее происходит обязательный ревью и плавное распространение последовательно по всем датацентрам.
В докладе будет рассказано:
1. почему мы выбрали CFEngine, а не Chief или Puppet;
2. как мы научили CFEngine быть дружелюбным (примеры политик и выдержки из библиотеки);
3. 100500 предпринятых мер, что бы не повторить "день 404" и соблюсти баланс между безопасностью и удобством;
4. как ещё можно использовать системы управления серверами.
Zabbix и миллионы метрик: наилучший опыт масштабного мониторинга / Алексей Вл...Ontico
Управление миллионами метрик таит в себе множество сложностей. Это вопросы автоматизации, масштабируемости, интеграции с другими системами и многое другое. Хочется максимально всё автоматизировать — один раз настроил и забыл. Возможно ли это?
Я подробно расскажу о накопленном практическом опыте использования Zabbix в самых жестоких условиях различных сценариев, расскажу на реальных примерах о том, как справиться с мониторингом тысяч удалённых точек, как не заблудиться в десятках миллионов триггеров и осилить динамические среды. Тут и о производительности нужно серьёзно задуматься.
Zabbix обладает целым набором функциональности, которая позволяет упростить жизнь отдела мониторинга. Конечно, подробности можно найти в документации, только не всегда понятно, как это правильно использовать.
Цель доклада — поделиться практическим опытом, это бесценно!
Архитектура поиска в Avito / Андрей Смирнов (Avito)Ontico
Из доклада вы узнаете о том, как в Avito используется Sphinx search, почему было выбрано это решение, какие подводные камни встретились на пути, и как их преодолеть.
Андрей поделится практическим опытом настройки и оптимизации Sphinx search, который позволяет добиться стабильной работы кластера и высокой скорости индексации и поиска. В Avito Sphinx индексирует 35 млн. объявлений каждые 7 минут!
Дизайн REST API для высокопроизводительных систем / Александр Лебедев (Новые ...Ontico
Доклад осветит вопросы устройства REST API для веб-приложений и мобильных клиентов, от которых требуется высокая производительность.
Проектирование высокопроизводительных REST API.
- Кто должен участвовать в проектировании.
- Как узнать, что оптимизировать.
- Как измерять производительность REST API.
Паттерны и антипаттерны.
- Почему pagination - это плохо, и на что лучше заменить.
- Проблема N+1 и как с ней бороться.
- Бесполезные данные - как обнаружить и уничтожить.
- Как не ломать кэширование на клиенте.
- Эффективная работа с интерфейсами "мастер-детали".
Кэширование.
- Три слоя кэширования.
- Самый быстрый запрос - тот, которого не было. Как увеличить их количество.
- Экономия трафика.
- Исключение ненужных вычислений.
- Подходы к инвалидации кэша.
Приемы оптимизации работы с API на клиенте.
- Параллельные запросы.
- Эффективный разбор данных.
- In-memory DB на клиенте.
- Стратегии кэширования на клиенте.
Преждевременная оптимизация архитектуры / Евгений Потапов, Антон Баранов (ITS...Ontico
Работа в высоконагруженных проектах всегда была такой сферой деятельности, где можно в рамках решения прикладных задач находить и применять сложные и интересные решения.
К сожалению, очень часто во главу угла ставится не надежное решение поставленной задачи, а именно применение сложного и интересного решения, которое даст специалисту новый опыт и удовольствие от сложных архитектур.
В своем докладе я хочу пройтись по тем стандартным "набитым шишкам", которые мы встречаем в своей работе, когда сложное, новое и интересное решение не означает стабильность системы.
1. Когда "интересно" не значит "правильно"?
1.1. Специфика развития высоконагруженного проекта.
1.2. Требования бизнеса и современные технологии.
1.3. Типичные "сомнительные" решения.
2. Проблемы в архитектуре отказоустойчивых систем.
2.1. Ошибки в планировании резервирования.
2.2. Ошибки в планировании системы выкладок.
2.3. Ошибки в архитектурах систем хранения данных.
3. Проблемы в архитектуре систем, рассчитанных на высокую нагрузку.
3.1. Ошибки в планировании мощностей системы.
3.2. Ошибки в планировании возможностей масштабирования системы.
3.3. Ошибки в архитектурах систем хранения данных.
Путь DevOps в «Parallels» / Константин Назаров (Parallels)Ontico
В этом докладе я расскажу вам историю о своих попытках улучшить процессы в компании Parallels. Она будет насыщена "фейлами" и набором неочевидных и спорных ситуаций, с коротыми вы можете столкнуться, если пойдете по "пути инноватора".
Я расскажу:
- чего удалось добиться за 3 года;
- далеко ли могут увести вас чисто инструментальные решения;
- с какими управленческими проблемами приходится столкнуться, если вы "внедряете DevOps";
- какой может быть предел влияния у "DevOps команды";
- типичные ситуации, в которых можно легко "завязнуть", и их корневые причины.
Порядок для скорости. Система структурирования фронтендовой части веб-приложе...Ontico
Расскажем о системе структурирования и версионности фронтендовой части веб-приложений:
• как вести учет поколений и версий дизайна;
• как проводить анализ консистентности фронтенда;
• как построить автоматическую систему документации по элементам;
• насколько такой подход влияет на общую скорость разработки.
Система структурирования фронтенда в Superjob - это более 200 элементов и 2000 представлений.
Стратегия и тактика улучшения производительности BSS систем оператора мобильн...Ontico
В докладе поделимся опытом построения комплексного процесса последовательного улучшения производительности информационных систем мобильного оператора, расскажем об используемых инструментах и компонентах (Oracle, Tarantool, Java, Jmeter и т.д.).
Особенность нашего оператора в том, что основной канал взаимодействия с клиентом - это мобильное приложение или web Личный кабинет, а не USSD команды и СМС, как у основной массы операторов. Данная особенность создает высокие требования к времени отклика и доступности сервисов и ставит перед нами целый ряд вопросов:
- Как достичь приемлемого времени отрисовки страниц (не более 2х секунд) и не "уронить" backend при увеличении кол-ва абонентов в несколько раз за год до 4х миллионов?
- Как обеспечить приемлемую производительность при наличии сложных оркестрирующих процессов на ESB и достаточно медленного, основанного на Oracle биллинга?
- Как контролировать и улучшать производительность и доступность постоянно и на упреждение, а не когда "жареный петух клюнет"?
Мы расскажем о том, как мы отвечаем на выше обозначенные вопросы. В частности, расскажем о внедрении двух БД - inmemory БД на чтение и Oracle на запись с соответствующей синхронизацией, о технике кэширования на нескольких уровнях, оптимизации синхронных и асинхронных процессов, о постоянном выявлении узких мест на тестировании, о кластеризации и других аспектах улучшения общей и частной производительности и доступности при быстро растущей абонентской базе и беспощадной креативности бизнеса.
Сравнение решений по балансировке высоконагруженных систем / Евгений Пивень (...Ontico
+ Функционал разных решений для балансировки.
+ Виды балансировщиков (DNS, hardware, software, облачные решения).
+ Поведение при скачках трафика и возможности скалирования сервиса.
+ Специфика трафика RTB в контексте балансировки.
+ Проблемы, которые возникали у нас, и как мы их решали.
Мониторинг в высоконагруженных (и не только) проектах: сравнительный анализ с...Anton Baranov
Выбор системы мониторинга - это практически holy-war-ная тема среди администраторов и разработчиков. Какая система лучше? Что удобнее? Какая система сможет выдержать большое количество статистики, а какая - лучше собрать и представить данные?
В своем докладе мы попробуем предельно непредвзято рассмотреть существующие решения и понять, что и когда можно использовать.
Прежде всего, мы постараемся сделать доклад не сравнением feature-листов, а рассмотреть особенности практического применения разных систем для конкретной задачи - для сайта, который не должен падать (а точнее - для возможности оперативно отреагировать на аварию, понять что к ней привело, и как можно ее исправить).
Как devops исчерпывает себя, и что будет дальше / Кирилл Вечера (Jetware)Ontico
* Следующее поколение моделей проектирования и эксплуатации серверных приложений в публичных облаках и на классических серверах.
* Сравнение методов эксплуатации: "традиционных" Chef/Salt/Ansible, immutage images/virtual appliances/Docker, и автономных рабочих окружений Jetware/Snappy/Nix/Habitat.
* Самоконфигурация, самоадминистрирование и самовосстановление серверов.
** Управление большими системами Mesos, Kubernetes, Docker Swarm.
** Управление внутри микросервисов.
* Независимость рабочего окружения приложений от операционной системы и ядра, just enough OS.
* Приложение - это не только исходный код, но и операционное окружение. Разработка, тестирование и версионирование всего полностью.
* Сервер как программа - компонентный подход.
OpenResty: превращаем NGINX в полноценный сервер приложений / Владимир Прота...Ontico
Все мы знаем, что NGINX – отличный прокси, который может качественно и эффективно распределять нагрузку между бэкендами и фильтровать запросы по определенным условиям. Но при этом часто на практике возникают задачи, которые не решаются его декларативной моделью описания конфигурации: иногда для принятия решения нам нужно сходить в базу данных (в Redis или даже в MySQL), другой сервис или произвести какую-то более сложную обработку запроса/ответа. Именно здесь к нам на помощь приходит мощь Lua и OpenResty.
Из доклада вы узнаете:
* зачем нам Lua внутри NGINX, и почему из седьмого айфона убрали разъем под наушники;
* в каких ситуациях NGINX в паре с Lua справятся с задачей лучше вашего любимого PHP/NodeJS/Ruby/Python/Visual Basic и о прелестях асинхронного ввода-вывода без callback'ов;
* как залезть к NGINX под капот, используя только высокоуровневый язык;
* при чем здесь Openresty, или как упростить себе жизнь;
* примеры бизнес-кейсов: от "умного" прокси до самостоятельного веб-приложения;
* как оно ведет себя в продакшне под большой нагрузкой.
Эволюция процесса деплоя в проекте / Денис Яковлев (2ГИС)Ontico
Если наш проект — это не коробочный продукт, а, например, веб-сервис, на который постоянно ходят пользователи, их много и они сразу видят изменения, то в жизненном цикле разработки у нас возникает еще одна задача — задача деплоя готового кода в боевое окружение.
В самом начале, когда наш проект маленький и простой, на эту задачу никто может и не обращать внимания, так как все происходит быстро и просто. Процесс деплоя состоит из 2-3 общеизвестных шагов — git pull, yii migrate, etc..., которые легко запомнить и в них сложно ошибиться.
С развитием проекта его сложность возрастает — он уже крутится на нескольких серверах, появляются новые компоненты (утилиты, библиотеки и т.д.), новые сущности (балансеры, кэшы, и т.д.). Держать всю инфраструктуру в голове становится невозможным, ведение документации привносит больше проблем, нежели решений, люди ошибаются чаще и т.д.
В докладе:
— рассмотрим подробно вышеуказанные проблемы, с которыми неизбежно сталкиваются проекты;
— обсудим, какие решения существуют в индустрии (chef, ansible, etc), чем они отличаются, какой выбрать и в чем их задача;
— поговорим про административные вопросы, которые с этим связаны.
Автоматизация нагрузочного тестирования в связке JMeter + TeamСity + Grafana ...Positive Hack Days
1. Описание старого процесса сбора данных о тестах: как было до, что хорошего, что плохого
2. Influxdb, как хранилище time-series данных,
3. Zabbix - мониторинг нагрузочных стендов: windows и linux агенты, активный сбор данных, autodiscovery виртуальных машин в esx
4. Grafana, как способ превратить графики и дашборды в конфетку
5. Автоматизация нагрузки от пользователей через web-UI при помощи Jmeter, отображение статистики в реальном времени, CI в Teamcity
мониторинг производительности Web приложений на pythonSlach
как понять где тормозит твое приложение в реальном времени? как не потеряться в океане метрик и собрать на дашборде только нужные? видео https://youtu.be/JgezdgtoNG8
Мастер-класс "Микросервисы: удобно, надежно, серебрянопульно" / Евгений Павло...Ontico
В процессе рефакторинга архитектуры мы начали переделывать часть системы на микросервисы, и вышло настолько клево, что мы просто обязаны этим поделиться.
Микросервисы.
Зачем они вообще:
- В простых сервисах легче разбираться и локализовывать проблемы.
- В микросервисной архитектуре проще добиваться отказоустойчивости.
- Хотим выбирать лучший инструмент для каждой задачи. Получаем зоопарк технологий, которые в монолитные сервисы интегрировать сложнее.
- Независимое обновление компонентов.
- Тестирование частей системы.
Как:
- Docker-образы как основа.
- Rancher как система деплоя и оркестрации Docker-контейнеров. High availability.
- Простота сервиса - ключевой момент.
== Критерий: Разработчик должен иметь возможность быстро понять и переписать сервис при необходимости.
== Забавное следствие: такие сервисы пишутся не на века, а под текущие требования. Получается быстро и agile-но, ведь изменения легко сможет внести любой разработчик.
== PEP8.
- HTTP API и поддержка Swagger. Резко упрощают тестирование.
- RabbitMQ pipelines как отказоустойчивая система взаимодействий между сервисами:
== DLX помогает разбираться со врЕменными проблемами.
== HTTP RPC.
- Метрики, метрики и ещё раз метрики.
== service status API.
== Graphite, Zabbix. Может, к ноябрю еще OKmeter успеем попробовать.
- Структурированые логи: JSON stdout => Fluentd => ELK => счастье. Локализация багов и пр. Об этом подробнее в отдельной презентации.
- В любой непонятной ситуации...
== Сервис должен падать, а не зависать.
== Healthchecks.
- Стабильность архитектуры.
== Осознанная деградация! Любой сервис должен быть готов к падению другого. При этом в первом должно быть явно описано, как будет при этом ограничиваться его функциональность. Это ведет к отсутствию эффекта домино, когда один малозначащий сервис, упав, утягивает за собой всю систему.
- Документация.
== Степень критичности каждого сервиса.
== Краткий обзор функциональности (вспоминаем: сервисы _простые_).
== Конфиги.
== drawback: описание архитектуры обязано быть актуальным и полным, иначе беда.
Трудности: Допишу через пару дней.
Обзор архитектуры и подсистем деплоя и мониторинга.
Как инженеры делают систему прозрачной для разработки.
1) Схема организации репозитория puppet.
Зачем мы сделали репозиторий публичным внутри компании?
Как мы "делим" puppet, и что делать, если все "пропало"?
Собственная реализация механизма puppet kick.
2) Как рассказать всем обо всем и никого не потерять.
"Черный мониторинг" (rbmon). Как мы собираем информацию о серверах и демонах.
Делимся логами с разработчиками. Почему написали "велосипед"?
3) Graphite - система сбора и визуализации данных.
Почему graphite?
1М метрик в минуту?
Какие метрики мы рисуем (nginx-graphite-module, rbmon plugins).
Визуализация работы проекта (Dashboard пульт).
Как не положить тысячи серверов с помощью системы централизованного управлени...Ontico
В 2012 году мы начали внедрение CFEngine в нашу инфраструктуру. Переход на централизованное управление конфигурацией в проектах такого масштаба подобен ремонту - его невозможно закончить, его можно только прекратить. И уже весной 2013 года (в день 404 ошибки и международного дня Интернета) этот "ремонт" превратился в катастрофу и был остановлен. После 3 суток недоступности портала нам пришлось изобрести схему, которая бы физически ограничивала возможность повторения катастрофы. Схема включает в себя тестирование политик на тестовых серверах различной важности и конфигурации. "Маринование" в этой тестовой среде сопровождается автоматизированным контролем характеристик нагрузки этих серверов. Далее происходит обязательный ревью и плавное распространение последовательно по всем датацентрам.
В докладе будет рассказано:
1. почему мы выбрали CFEngine, а не Chief или Puppet;
2. как мы научили CFEngine быть дружелюбным (примеры политик и выдержки из библиотеки);
3. 100500 предпринятых мер, что бы не повторить "день 404" и соблюсти баланс между безопасностью и удобством;
4. как ещё можно использовать системы управления серверами.
Zabbix и миллионы метрик: наилучший опыт масштабного мониторинга / Алексей Вл...Ontico
Управление миллионами метрик таит в себе множество сложностей. Это вопросы автоматизации, масштабируемости, интеграции с другими системами и многое другое. Хочется максимально всё автоматизировать — один раз настроил и забыл. Возможно ли это?
Я подробно расскажу о накопленном практическом опыте использования Zabbix в самых жестоких условиях различных сценариев, расскажу на реальных примерах о том, как справиться с мониторингом тысяч удалённых точек, как не заблудиться в десятках миллионов триггеров и осилить динамические среды. Тут и о производительности нужно серьёзно задуматься.
Zabbix обладает целым набором функциональности, которая позволяет упростить жизнь отдела мониторинга. Конечно, подробности можно найти в документации, только не всегда понятно, как это правильно использовать.
Цель доклада — поделиться практическим опытом, это бесценно!
Архитектура поиска в Avito / Андрей Смирнов (Avito)Ontico
Из доклада вы узнаете о том, как в Avito используется Sphinx search, почему было выбрано это решение, какие подводные камни встретились на пути, и как их преодолеть.
Андрей поделится практическим опытом настройки и оптимизации Sphinx search, который позволяет добиться стабильной работы кластера и высокой скорости индексации и поиска. В Avito Sphinx индексирует 35 млн. объявлений каждые 7 минут!
Дизайн REST API для высокопроизводительных систем / Александр Лебедев (Новые ...Ontico
Доклад осветит вопросы устройства REST API для веб-приложений и мобильных клиентов, от которых требуется высокая производительность.
Проектирование высокопроизводительных REST API.
- Кто должен участвовать в проектировании.
- Как узнать, что оптимизировать.
- Как измерять производительность REST API.
Паттерны и антипаттерны.
- Почему pagination - это плохо, и на что лучше заменить.
- Проблема N+1 и как с ней бороться.
- Бесполезные данные - как обнаружить и уничтожить.
- Как не ломать кэширование на клиенте.
- Эффективная работа с интерфейсами "мастер-детали".
Кэширование.
- Три слоя кэширования.
- Самый быстрый запрос - тот, которого не было. Как увеличить их количество.
- Экономия трафика.
- Исключение ненужных вычислений.
- Подходы к инвалидации кэша.
Приемы оптимизации работы с API на клиенте.
- Параллельные запросы.
- Эффективный разбор данных.
- In-memory DB на клиенте.
- Стратегии кэширования на клиенте.
Преждевременная оптимизация архитектуры / Евгений Потапов, Антон Баранов (ITS...Ontico
Работа в высоконагруженных проектах всегда была такой сферой деятельности, где можно в рамках решения прикладных задач находить и применять сложные и интересные решения.
К сожалению, очень часто во главу угла ставится не надежное решение поставленной задачи, а именно применение сложного и интересного решения, которое даст специалисту новый опыт и удовольствие от сложных архитектур.
В своем докладе я хочу пройтись по тем стандартным "набитым шишкам", которые мы встречаем в своей работе, когда сложное, новое и интересное решение не означает стабильность системы.
1. Когда "интересно" не значит "правильно"?
1.1. Специфика развития высоконагруженного проекта.
1.2. Требования бизнеса и современные технологии.
1.3. Типичные "сомнительные" решения.
2. Проблемы в архитектуре отказоустойчивых систем.
2.1. Ошибки в планировании резервирования.
2.2. Ошибки в планировании системы выкладок.
2.3. Ошибки в архитектурах систем хранения данных.
3. Проблемы в архитектуре систем, рассчитанных на высокую нагрузку.
3.1. Ошибки в планировании мощностей системы.
3.2. Ошибки в планировании возможностей масштабирования системы.
3.3. Ошибки в архитектурах систем хранения данных.
Путь DevOps в «Parallels» / Константин Назаров (Parallels)Ontico
В этом докладе я расскажу вам историю о своих попытках улучшить процессы в компании Parallels. Она будет насыщена "фейлами" и набором неочевидных и спорных ситуаций, с коротыми вы можете столкнуться, если пойдете по "пути инноватора".
Я расскажу:
- чего удалось добиться за 3 года;
- далеко ли могут увести вас чисто инструментальные решения;
- с какими управленческими проблемами приходится столкнуться, если вы "внедряете DevOps";
- какой может быть предел влияния у "DevOps команды";
- типичные ситуации, в которых можно легко "завязнуть", и их корневые причины.
Порядок для скорости. Система структурирования фронтендовой части веб-приложе...Ontico
Расскажем о системе структурирования и версионности фронтендовой части веб-приложений:
• как вести учет поколений и версий дизайна;
• как проводить анализ консистентности фронтенда;
• как построить автоматическую систему документации по элементам;
• насколько такой подход влияет на общую скорость разработки.
Система структурирования фронтенда в Superjob - это более 200 элементов и 2000 представлений.
Стратегия и тактика улучшения производительности BSS систем оператора мобильн...Ontico
В докладе поделимся опытом построения комплексного процесса последовательного улучшения производительности информационных систем мобильного оператора, расскажем об используемых инструментах и компонентах (Oracle, Tarantool, Java, Jmeter и т.д.).
Особенность нашего оператора в том, что основной канал взаимодействия с клиентом - это мобильное приложение или web Личный кабинет, а не USSD команды и СМС, как у основной массы операторов. Данная особенность создает высокие требования к времени отклика и доступности сервисов и ставит перед нами целый ряд вопросов:
- Как достичь приемлемого времени отрисовки страниц (не более 2х секунд) и не "уронить" backend при увеличении кол-ва абонентов в несколько раз за год до 4х миллионов?
- Как обеспечить приемлемую производительность при наличии сложных оркестрирующих процессов на ESB и достаточно медленного, основанного на Oracle биллинга?
- Как контролировать и улучшать производительность и доступность постоянно и на упреждение, а не когда "жареный петух клюнет"?
Мы расскажем о том, как мы отвечаем на выше обозначенные вопросы. В частности, расскажем о внедрении двух БД - inmemory БД на чтение и Oracle на запись с соответствующей синхронизацией, о технике кэширования на нескольких уровнях, оптимизации синхронных и асинхронных процессов, о постоянном выявлении узких мест на тестировании, о кластеризации и других аспектах улучшения общей и частной производительности и доступности при быстро растущей абонентской базе и беспощадной креативности бизнеса.
Сравнение решений по балансировке высоконагруженных систем / Евгений Пивень (...Ontico
+ Функционал разных решений для балансировки.
+ Виды балансировщиков (DNS, hardware, software, облачные решения).
+ Поведение при скачках трафика и возможности скалирования сервиса.
+ Специфика трафика RTB в контексте балансировки.
+ Проблемы, которые возникали у нас, и как мы их решали.
Мониторинг в высоконагруженных (и не только) проектах: сравнительный анализ с...Anton Baranov
Выбор системы мониторинга - это практически holy-war-ная тема среди администраторов и разработчиков. Какая система лучше? Что удобнее? Какая система сможет выдержать большое количество статистики, а какая - лучше собрать и представить данные?
В своем докладе мы попробуем предельно непредвзято рассмотреть существующие решения и понять, что и когда можно использовать.
Прежде всего, мы постараемся сделать доклад не сравнением feature-листов, а рассмотреть особенности практического применения разных систем для конкретной задачи - для сайта, который не должен падать (а точнее - для возможности оперативно отреагировать на аварию, понять что к ней привело, и как можно ее исправить).
Как devops исчерпывает себя, и что будет дальше / Кирилл Вечера (Jetware)Ontico
* Следующее поколение моделей проектирования и эксплуатации серверных приложений в публичных облаках и на классических серверах.
* Сравнение методов эксплуатации: "традиционных" Chef/Salt/Ansible, immutage images/virtual appliances/Docker, и автономных рабочих окружений Jetware/Snappy/Nix/Habitat.
* Самоконфигурация, самоадминистрирование и самовосстановление серверов.
** Управление большими системами Mesos, Kubernetes, Docker Swarm.
** Управление внутри микросервисов.
* Независимость рабочего окружения приложений от операционной системы и ядра, just enough OS.
* Приложение - это не только исходный код, но и операционное окружение. Разработка, тестирование и версионирование всего полностью.
* Сервер как программа - компонентный подход.
OpenResty: превращаем NGINX в полноценный сервер приложений / Владимир Прота...Ontico
Все мы знаем, что NGINX – отличный прокси, который может качественно и эффективно распределять нагрузку между бэкендами и фильтровать запросы по определенным условиям. Но при этом часто на практике возникают задачи, которые не решаются его декларативной моделью описания конфигурации: иногда для принятия решения нам нужно сходить в базу данных (в Redis или даже в MySQL), другой сервис или произвести какую-то более сложную обработку запроса/ответа. Именно здесь к нам на помощь приходит мощь Lua и OpenResty.
Из доклада вы узнаете:
* зачем нам Lua внутри NGINX, и почему из седьмого айфона убрали разъем под наушники;
* в каких ситуациях NGINX в паре с Lua справятся с задачей лучше вашего любимого PHP/NodeJS/Ruby/Python/Visual Basic и о прелестях асинхронного ввода-вывода без callback'ов;
* как залезть к NGINX под капот, используя только высокоуровневый язык;
* при чем здесь Openresty, или как упростить себе жизнь;
* примеры бизнес-кейсов: от "умного" прокси до самостоятельного веб-приложения;
* как оно ведет себя в продакшне под большой нагрузкой.
Эволюция процесса деплоя в проекте / Денис Яковлев (2ГИС)Ontico
Если наш проект — это не коробочный продукт, а, например, веб-сервис, на который постоянно ходят пользователи, их много и они сразу видят изменения, то в жизненном цикле разработки у нас возникает еще одна задача — задача деплоя готового кода в боевое окружение.
В самом начале, когда наш проект маленький и простой, на эту задачу никто может и не обращать внимания, так как все происходит быстро и просто. Процесс деплоя состоит из 2-3 общеизвестных шагов — git pull, yii migrate, etc..., которые легко запомнить и в них сложно ошибиться.
С развитием проекта его сложность возрастает — он уже крутится на нескольких серверах, появляются новые компоненты (утилиты, библиотеки и т.д.), новые сущности (балансеры, кэшы, и т.д.). Держать всю инфраструктуру в голове становится невозможным, ведение документации привносит больше проблем, нежели решений, люди ошибаются чаще и т.д.
В докладе:
— рассмотрим подробно вышеуказанные проблемы, с которыми неизбежно сталкиваются проекты;
— обсудим, какие решения существуют в индустрии (chef, ansible, etc), чем они отличаются, какой выбрать и в чем их задача;
— поговорим про административные вопросы, которые с этим связаны.
Автоматизация нагрузочного тестирования в связке JMeter + TeamСity + Grafana ...Positive Hack Days
1. Описание старого процесса сбора данных о тестах: как было до, что хорошего, что плохого
2. Influxdb, как хранилище time-series данных,
3. Zabbix - мониторинг нагрузочных стендов: windows и linux агенты, активный сбор данных, autodiscovery виртуальных машин в esx
4. Grafana, как способ превратить графики и дашборды в конфетку
5. Автоматизация нагрузки от пользователей через web-UI при помощи Jmeter, отображение статистики в реальном времени, CI в Teamcity
Реалтайм статистика скорости работы нативных и веб-приложений у реальных поль...Badoo Development
Рассказали как сделана статистика и аналитика скорости работы (UX) приложений Badoo (web, mobile-web, ios, android, windows).
Общие концепции и примеры, что и как измерять.
Как собирать данные со 100% пользователей проекта и выдержать нагрузку.
Как из open-source решений собрать систему сбора и визуализации статистики для своего проекта.
Выложили Jinba в opensource: http://tech.badoo.com/open-source/#os-17
Автоматизация мониторинга распределенной сети подразделенийBadoo Development
Zabbix Moscow Meetup 2016
Доклад Николая Самосвата из Social Discovery Ventures:
"Автоматизация мониторинга распределенной сети подразделений"
В докладе Николай рассказал о своем опыте мониторинга гео-распределенной сети подразделений. О том, каким образом полностью автоматизировали мониторинг в достаточно крупной инсталляции. Также кратко упомянул о другой инсталляции Zabbix (тоже мониторинг распределенной сети), в которой более 13 тысяч подразделений и около двух миллионов хостов.
Introduction to Zabbix - Company, Product, Services and Use CasesZabbix
About Zabbix Software:
Zabbix is an enterprise-class open source distributed monitoring solution designed to monitor and track performance and availability of network servers, devices, services and other IT resources.
Zabbix is an all-in-one monitoring solution that allows users to collect, store, manage and analyze information received from IT infrastructure, as well as display on-screen, and alert by e-mail, SMS or Jabber when thresholds are reached.
Zabbix allows administrators to recognize server and device problems within a short period of time and therefore reduces the system downtime and risk of system failure. The monitoring solution is being actively used by SMBs and large enterprises across all industries and almost in every country of the world.
Jelastic PaaS for DevOps: Hybrid Cloud based on Microsoft AzureDmitry Lazarenko
Гибридное облако PaaS на базе Jelastic и Microsoft Azure. Jelastic позволяет создать гибридное облако с возможностью живой миграции приложений между частным облаком и Microsoft Azure, AWS, SoftLayer
Nagios Conference 2014 - Eric Mislivec - Getting Started With Nagios CoreNagios
Eric Mislivec's presentation on getting started with Nagios Core. The presentation was given during the Nagios World Conference North America held Oct 13th - Oct 16th, 2014 in Saint Paul, MN. For more information on the conference (including photos and videos), visit: http://go.nagios.com/conference.
Zabbix 3.2 - мониторинг качественно нового уровня / Алексей Владышев (Zabbix)Ontico
Вне зависимости от размера инфраструктуры, весьма сложно разобраться в проблемах, обнаруженных системой мониторинга, особенно если их сотни или тысячи. Они могут быть о железе, приложениях, связаны с безопасностью, тестовыми и продакшн средами, различными датацентрами и сервисами. Как эффективно управлять этой сложностью? Как удобно отображать проблемы для коллег, отвечающих за различные куски инфраструктуры?
Новая мажорная версия Zabbix 3.2 революционна и отвечает на эти вопросы!
Модуль корреляции событий на глобальном уровне и уровне одной проблемы, система тагов, новая супер быстрая панель для отображения проблем, вложенные группы устройств, возможность ручного закрытия проблем и многое другое позволяют построить эффективный мониторинг любого размера или качественно улучшить существующий.
Я расскажу о новой функциональности и покажу, как её использовать для построения, в том числе, сервис-ориентированного мониторинга. Многие вещи стали намного проще. Иногда может быть достаточно одного триггера для мониторинга всех сервисов или приложений компании. Фантастика! Как это возможно? Приходите и узнаете.
Внедрение Docker в процесс разработки демонов. Доклад Константина Карпова на ...Badoo Development
Рассказываем о том, как мы жили без Docker'а и зачем его решили использовать. А также описываем процесс внедрения в CI и, в частности, в тесты, плюс с какими проблемами столкнулись и как их побороли.
WebSite Security Day 2016 - Мониторинг e-commerceСергей Обухов
Нашёл одну из первых своих презентаций) 2016 год
WebSite Security Day https://protosecurity.ru/novosti/website-security-day-2016/
С тех пор уровень презентаций и выступлений сильно прокачался
Мониторинг e-commerce проектов
AggreGate Network Manager. Мониторинг IT и управление сетямиTibbo
AggreGate Network Manager - это система мониторинга ИТ-инфраструктуры и управления сетями. Система тесно интегрируется с другими средствами автоматизации зданий и предприятий. AggreGate Network Manager основан на общей архитектуре универсальной системы управления устройствами AggreGate, предоставляя таким образом уникальные возможности по конфигурированию, контролю и мониторингу маршрутизаторов, серверов и рабочих станций, сетевых принтеров, устройств бесперебойного питаний, датчиков состояния окружающей среды и других сетевых устройств.
Кроме запатентованных технологий нормализации, синхронизации и кэширования, возможности по обработке данных включают поиск сетевых устройств, динамические карты сети, сигналы тревоги с различными видами оповещений (визуальные, звуковые, e-mail, SMS и др.), фильтрацию событий, построение графиков в режиме реального времени, отчеты, основанный на SQL запросах, язык выражений, репликацию конфигурации, групповые операции, выполнение задач по расписанию, конструкор графических интерфейсов, импорт/экспорт данных в различные форматы, базу MIB файлов, обработку ловушек (traps) SNMP и многое другое.
Поддерживаются различные способы интеграции с другими системами предприятия (ERP, CRM и др.) при помощи веб-сервисов и API для Java/.NET.
Система может функционировать в автоматическом режиме позволяющем серверу принимать решения и оповещать администраторов только в случае серьезных проблем, а также в интерактивном режиме, который предполагает постоянное наблюдение операторов за сетью при помощи программы-клиента.
AggreGate является многопользовательской средой с гибкой настройкой прав доступа. Поддерживаются все версии протокола SNMP, включая защищенный SNMP v3, что позволяет осуществлять управление гетерогенными сетями включающими оборудование различных производителей. Для наблюдения за любыми устройствами не требуется модификация их программной или аппаратной составляющей.
Основной фокус предлагаемой сессии, это практическое применение технологий Программно Управляемых Сетей (SDN), Виртуализации Сетевых Функции (NFV), и новых платформ оркестрации, обеспечивающие гибкую и модульную сервисную платформу для операторов связи и облачных услуг. Будет подробна рассмотрена бизнес модель и техническая реализация Cisco vMS (Virtual Manaвged Services) решения, которое уже внедрено в коммерческую эксплуатацию ведущими операторами услуг, что позволило им предложить новые персонализированные услуги. Сервисы для корпоративных заказчиков формируются в виде модулей включающих виртуализированные сетевые функции, соглашения об уровне обслуживания (SLA), которые клиенты могут выбрать и активировать на интернет-портале. Будет подробно рассмотрена платформа оркестрации, представляющая собой интегрированную платформу включающую в себя подсистемы создания и обслуживания сервисного каталога, подсистемы кросс доменной оркестрации Cisco NSO (Tail-f NCS) и другие системы обеспечивающие полный цикл автоматизации и сопровождения жизненного цикла услуги.” Сессия будет интересна сетевым и ИТ -специалистам, руководителям отделов развития и эксплуатации сетей операторов связи, партнерам Cisco, интересующимся применением технологий SDN для предоставления современных телекоммуникационных и облачных услуг.
Контроль и управление доступом к корпоративным ресурсам предприятияVERNA
01.05.2015. Семинар во Львове. Кирилл Карнаухов рассказал о преимуществах внедрения контроля сетевого доступа на предприятии и успешном проекте построения Cisco ISE в крупном украинском банке.
Ориентированная на приложения инфраструктура Cisco ACI Cisco Russia
Ориентированная на приложения
инфраструктура Cisco ACI. Решаемые задачи и преимущества.
Запись вебинара можно найти по ссылке: http://ciscoclub.ru/tektorial-po-cod-cisco-aci-arhitektura-preimushchestva-praktika-proektirovaniya-i-vnedreniya
Демонстрация работы интеллектуальной подсистемы управления в многоуровневой сетиCisco Russia
Многоуровневая подсистема управления (aka SDN).
Автоматизация включения сервисов средствами Cisco MATE иGMPLS.
Повышение надежности сети с помощью оптического восстановления.
Оптимизация работы многоуровневой сети.
2. О компании QIWI*
Kazakhstan
177,000+ терминалов и точек
приема платежей
17,3+ млн. виртуальных кошельков
*По данным QIWI plc за 1 квартал 2015 года
3.
4.
5. • Масштабируемость
• Функция discovery
• Инвентаризация
• Простота кастомизации
• Поддержка инфраструктурных
проверок из коробки
• Клонирование элементов
6. С чего начали
1.Установка сервера
2.Добавление хостов и
авторегистрация
3.Работа над ошибками
4.Составление плана
7. План (что сделано)
1.Перенос отдельных метрик
и orabbix
2.Уведомления и jira
3.Настройка авторизации
4.Шаблоны и полезность LLD
8. План (что осталось)
5.Шаблоны по сервисам
6.Перенос специфичных
бизнес метрик
7.Отказоустойчивость
8.Группировка узлов сети по
сервисам
9.Реализация baseline в
триггерах
Как-то перед Новым годом, на собрании нашего подразделения, обсуждали текущие проблемы и планы на будущее.
Одной из тем была "проблемы мониторинга". Текущая система мониторинга (исторически сложившийся нагиос) в текущем его исполнении, уже порядком поднадоел.
Высокое LA, частенько флапающие статусы проверок, тормозащий вэб. А так же желание навести порядок в мониторинге, так как от некоторых костылей можно избавиться, плюс увеличивающееся число заявок на постановку на мониторинг.
Высокое LA, частенько флапающие статусы проверок, тормозащий вэб. А так же желание навести порядок в мониторинге, так как от некоторых костылей можно избавиться, плюс увеличивающееся число заявок на постановку на мониторинг.
Короче говоря пришли к мысли: тут не исправить уже ничего, Господь, жги!
Из очевидных плюсов: масштабируемость (думаю тут и так все понятно), функция discovery (избавляемся от необходимости добавлять все вручную), мониторинг через агентов (избавляемся от необходимости ходить на хосты по ssh), кастомизация (), поддержка инфраструктурных проверок из коробки.
Так же стоит отметить функцию "клонирования" элементов данных и прочего, позволяющая в пару кликов размножить элементы мониторинга. Приходится часто сталкиваться с этим при заведении новых серверов в мониторинг и уже пальцы натерты от ctrl+C/ctrl+V.
Поскольку мы впервые столкнулись с использованием zabbix, мы как непосвященные пошли таким путем.
Про установку сервера, думаю, нет смысла рассказывать, так как проблем тут обычно не бывает.
На виртуалку раскатили заббикс и начали с добавления хостов из нагиос. Вручную. Epic fail.
Потратили на это много времени, и в дальнейшем обнаружили, что существует "Авторегистрация". В общем, ощутимо бы сэкономили время.
После этого добавили правила авторегистрации для unix и windows серверов, а для всего остального правила обнаружения.
Единственная придирка к обнаружению - негде посмотреть прогресс выполнения.
После этого было решено составить план переезда.
Первым пунктом была просьба от одного подразделения, перенести их сенсоры в заббикс. Чтобы уж сильно кардинально не отходить от привычного использования конфигов, для sql запросов мы прикрутили orabbix. Для нас он показался удобнее чем встроенная в заббикс поддержка запросов в базы. Отдельный информативный лог, привычные конфиги. Плюс по принципу работы, orabbix похож на самописную sql шлюз, который мы используем в nagios.
После этого сделали систему уведомлений.
От стандарной функции рассылки писем в заббикс отказался в пользу скрипта, чтобы были возможности кастомизации. По смскам, адаптировали скрипт из нагиос рассылающий через смс-агрегатора. С джирой подружили через перловый модуль JIRA::Client::Automated.
Включили LDAP авторизацию, и скриптом добавили синхронизацию пользователей из AD.
3. Следующим по плану, были шаблоны. Решили разделить на: шаблоны на инфтраструктурные элементы и шаблоны на сервисы.
Так же решили по возможности минимизировать количество проверок которые выполняются с сервера.
В процессе разработки шаблонов, увидели заинтересованность сетевиков, уставших от cacti. Посовещавшись, решили перенести и сетевые хосты, чтобы был единый мониторинг.
В шаблоне для сетевых железок, прониклись идеей LLD. Так же помог snmp-builder входящий в состав Zabbix Extras.
Из оставшегося: шаблоны по отдельным сервисам, перенос специфичных метрик, схема отказоустойчивости, реализация baseline в триггерах, группировка хостов по сферам работы
В нашем случае, мониторинг должен иметь аптайм 24/7 и простои недопустимы. Следовательно должен быть резерв готовый вступить в бой.
Zabbix через peacemaker+corosync. Mysql в режиме master-slave(passive master,с ведением бинарных логов). Переключение БД будет автоматизировано скриптами.
Остановились на такой схеме, правда пока не реализовали ее, потому что нужно будет перевезти заббикс на железный сервер, и согласно нашему плану мы пока не дошли до этого.
Про плюсы ораббикс уже рассказал. Java gateway - отличная вещь для мониторинга jmx, но наши разработчики ее перепишут для поддержки нашего кастома. Zabbix extras: надстройка на фронте, из тех вещей что понравились в ней это: вкладка с неподдерживаемыми элементами (в отличие от стандартного фильтра, показывает еще и текст ошибки), snmp builder - генератор шаблонов из мибов, вкладка показывает стоимость элементов данных.
Про плюсы ораббикс уже рассказал. Java gateway - отличная вещь для мониторинга jmx, но наши разработчики ее перепишут для поддержки нашего кастома. Zabbix extras: надстройка на фронте, из тех вещей что понравились в ней это: вкладка с неподдерживаемыми элементами (в отличие от стандартного фильтра, показывает еще и текст ошибки), snmp builder - генератор шаблонов из мибов, вкладка показывает стоимость элементов данных.