Огромная часть работы службы эксплуатации, так или иначе, связана с мониторингом существующей инфраструктуры.
Если система мониторинга настроена хорошо, она позволяет сократить время простоя, какие-то проблемы показать на ранней стадии, формализовать рабочие процессы команды админов.
То есть она является носителем знания о нашей инфраструктуре и о том, как именно работают админы.
Можно ли извлечь дополнительную пользу из этого?
В hh.ru мы используем систему мониторинга ещё и как check list для повседневных задач админов (алерты в данном случае являются задачами для человека: сделал задачу - триггер проверил результат и погас), идея взята из TDD.
Также расскажу, как мы работаем с внештатными ситуациями: реагируем на алерты, чиним, разбираем и классифицируем.
Еще на основе разобранных инцидентов мы считаем показатели работы службы эксплуатации, из этих показателей высчитываются наши премии (данный KPI получился удачным: с ним согласен и бизнес и админы).
Сетевые аномалии – рано или поздно с ними сталкиваются все, кто так или иначе связан с созданием и эксплуатацией сетевых сервисов.
Природа сетевых аномалий и их проявления могут значительно варьироваться: потери пакетов, увеличение задержек, разрывы TCP-соединений. Но вне зависимости от своей природы сетевые аномалии требуют корректной и зачастую крайне оперативной диагностики.
В рамках доклада будут рассмотрены стандартные утилиты, такие как ping, traceroute, mtr, hping, а также области их применения. Самым значительным ограничением при использовании данных утилит является невозможность определения обратного пути пакета, что может значительно усложнить диагностику.
Также в докладе будут рассмотрены активные методы диагностики сетевых аномалий (Looking glass, RIPE Atlas, NLNOG RING, PlanetLab) и разработанный командой Qrator механизм определения обратного маршрута от любой заданной сети с использованием математического моделирования.
Мониторинг в высоконагруженных (и не только) проектах: сравнительный анализ с...Ontico
Выбор системы мониторинга - это практически holy-war-ная тема среди администраторов и разработчиков. Какая система лучше? Что удобнее? Какая система сможет выдержать большое количество статистики, а какая - лучше собрать и представить данные?
В своем докладе мы попробуем предельно непредвзято рассмотреть существующие решения и понять, что и когда можно использовать.
См. тезисы - http://rootconf.ru/2015/abstracts/1746
Сетевые аномалии – рано или поздно с ними сталкиваются все, кто так или иначе связан с созданием и эксплуатацией сетевых сервисов.
Природа сетевых аномалий и их проявления могут значительно варьироваться: потери пакетов, увеличение задержек, разрывы TCP-соединений. Но вне зависимости от своей природы сетевые аномалии требуют корректной и зачастую крайне оперативной диагностики.
В рамках доклада будут рассмотрены стандартные утилиты, такие как ping, traceroute, mtr, hping, а также области их применения. Самым значительным ограничением при использовании данных утилит является невозможность определения обратного пути пакета, что может значительно усложнить диагностику.
Также в докладе будут рассмотрены активные методы диагностики сетевых аномалий (Looking glass, RIPE Atlas, NLNOG RING, PlanetLab) и разработанный командой Qrator механизм определения обратного маршрута от любой заданной сети с использованием математического моделирования.
Мониторинг в высоконагруженных (и не только) проектах: сравнительный анализ с...Ontico
Выбор системы мониторинга - это практически holy-war-ная тема среди администраторов и разработчиков. Какая система лучше? Что удобнее? Какая система сможет выдержать большое количество статистики, а какая - лучше собрать и представить данные?
В своем докладе мы попробуем предельно непредвзято рассмотреть существующие решения и понять, что и когда можно использовать.
См. тезисы - http://rootconf.ru/2015/abstracts/1746
Поддержка высоконагруженного проекта: мониторинг, резервирование, обслуживани...Ontico
1. Мониторинг высоконагруженного проекта.
1.1. Специфика мониторинга высоконагруженного проекта: гранулярность мониторинга, надежность системы мониторинга, система оповещений.
1.2. Мониторинг и контроль распределенных систем.
1.3. Специфика организации оповещений в высоконагруженном проекте. Превентивный мониторинг.
2. Резервирование и резервное копирование в высоконагруженном проекте.
2.1. Резервирование и резервное копирование - разные вещи.
2.2. Резервирование: на уровне сервера, дата-центра, географически распределенных площадок.
2.1. Организация резервного копирования. Сохранность часто обновляемых данных.
3. Обслуживание высоконагруженного проекта.
3.1. Организация поддержки высоконагруженного проекта: опыт, специфика работы.
3.2. Организация дежурств, эскалация оповещений.
3.3. Аварии в высоконагруженных проектах: примеры из жизни.
Принципы и приёмы обработки очередей / Константин Осипов (Mail.ru)Ontico
Насколько повысится среднее время обработки одного запроса если увеличить нагрузку вдвое? Почему производительность базы данных может снизиться при росте числа клиентов? Как добиться эффективного распределения большого числа задач на весь кластер? О практике и о теории обработки очередей на которой основана практика в моём докладе.
Open Source SQL-базы данных вступили в эру миллионов запросов в секунду / Фед...Ontico
Широко распространено мнение, что SQL СУБД обречены быть медлительными и неповоротливыми, поскольку несут груз совместимости с предыдущими версиями. Это расхожее мнение широко эксплуатируется маркетингом NoSQL СУБД. Однако, это не всегда действительно так.
Разработка в Open Source сообществе позволяет продукту развиваться достаточно гибко, чтобы отвечать требованиям времени. В MySQL и PostgreSQL – самых популярных Open Source СУБД – недавно были проведены оптимизации для работы на больших серверах, что позволило им выполнять более миллиона SQL-запросов в секунду на одном экземпляре БД.
В данном докладе будут рассмотрены конкретные оптимизации, которые позволили добиться таких результатов, которые раньше могли бы показаться фантастическими. И можно сказать, что Open Source СУБД вошли в эру миллионов запросов в секунду.
NodeJS в HighLoad проекте / Акрицкий Владимир (iAge Engineering)Ontico
NodeJS — достаточно молодой фреймворк, и пока не каждый решается использовать его в продакшене, а тем более в highload.
В течение последнего года мы разрабатывали проект DMP (Data Management Platform), используя NodeJS для прототипирования. На данный момент проект в большей степени все еще остался на JS и без труда справляется с текущими нагрузками в 10 000 запросов в секунду.
В докладе я расскажу, почему остановились именно на NodeJS и совсем не жалеем об этом.
К сожалению, никакое дело не обходится без граблей и костылей. Я расскажу обо всех встретившихся проблемах и уделю особое внимание проблемам со спагетти-кодом, утечками и нехваткой памяти. Как мы убили немало времени, тщетно ища источник проблем, и какие правила мы составили для себя на будущее, чтобы не повторить своих ошибок.
Расскажу немного о применении микросервисов для решения проблемы спагетти-кода.
И, как итог, опишу ряд рекомендаций, которые помогут избежать большой траты времени при использовании NodeJS.
NAS, Predictions, Preloading, Presudo-Isomorphism / Охрименко Алексей (Acronis)Ontico
На примере фреймворка COD.js ( c React as View Layer ) и топовых продуктов фирмы Acronis мы увидим, каких удивительных результатов можно добиться используя:
1) NAS — неблокирующее состояние приложения;
2) Predictions — дизайн-паттерн, позволяющий предсказывать состояния системы и производить так называемую "latency conpensation" — технику, которую очень любят в Game Dev;
3) Preloading — стандартную и всем знакомую технику, у которой есть пара интересных способов применения, заслуживающих внимания;
4) Presudo-Isomorphism — очень хитрую технику, которую так активно использует Facebook.
Все это будет показано на примере реальных продуктов. С простыми и понятными примерами, которые можно будет применить в любом продукте.
Zabbix в Badoo или о чем не пишут в мануале, Илья Аблеев (Badoo)Badoo Development
Доклад с Zabbix Meetup.
Рассказали про:
• Сколько инстансов используем, зачем, какая конфигурация и нагрузка, какие дополнительные тулзы используем.
• Деплой скриптов/конфигов/обновлении.
• Флоу появления новых сущностей в мониторинге: хостов, проверок, графиков в заббикс. Самописный дискавери (серверов, сервисов): почему свой и что он умеет.
• Штуки для удобства: нотификации на рабочий стол, быстрая навигация по графикам.
Доклад о том, как мы добились идеально ровной балансировки нагрузки по кластеру из 200+ серверов, реализовали автоматический подбор весов и получили разброс CPU usage в 2,5% в пике трафика. Это позволило сэкономить нам около 40-50 серверов и улучшить время отклика мобильного сайта в пике нагрузки. Реализацию приведенного алгоритма мы выложим в open-sourсe. Доклад Юрия Насретдинова на Highload 2015.
Веб-разработка без наркотиков с помощью PostgreSQL, Nginx и c2h5oh / Миша Кир...Ontico
Разговор в докладе пойдёт о веб-программировании.
При изготовлении веб-проектов то и дело пользуются широко распространёнными фреймворками на базе языков программирования — PHP, Python, Perl, Ruby, Go, Rust, Java и т.п.
Я предлагаю отказаться от употребления оных и использовать для разработки веб-приложений только c2h5oh — расширение для высокопроизводительного сервера nginx. Данное расширение позволяет эффективно использовать PostgreSQL в качестве сервера веб-приложений.
Хочу поделиться со слушателями своим личным опытом разработки с использованием подобной связки. Планирую рассказать о плюсах и минусах такого подхода.
«Секретные» технологии инвестиционных банков / Алексей Рагозин (Дойче Банк)Ontico
Как правило, такое базовое ПО, как языки программирования, системы управления базами данных, брокеры сообщений, используется в разных индустриях и не имеет ярко выраженной бизнес-специализации. Java, Python, MySQL и не только находят применение повсюду, начиная с больших корпораций, заканчивая стратапами и видеоиграми.
Тем не менее, встречаются исключения. В докладе пойдёт речь о технологиях, получивших распространение в инвестиционных банках и не слишком известных за их пределами. Хотя прямого отношения к торговле финансовыми инструментами сами по себе эти технологии не имеют.
Тезисы - http://www.highload.ru/2015/abstracts/1888.html
Tempesta FW: challenges, internals, use cases / Александр Крижановский (Tempe...Ontico
Tempesta FW — это Open Source гибрид Web-акселератора и файервола, специально разработанный для высокопроизводительной доставки контента вне зависимости от DDoS или наплыва посетителей.
В докладе будет рассказано про задачи, которые ставились при разработке проекта и пути их решения. Рассмотрим проблемы современных операционных систем в приложении к Web-стеку (система фильтрации, Web-сервер, application слой, БД), и как они решаются в Tempesta — некоторые уже решены, некоторые еще в процессе работы.
И самое главное — у нас появился рабочий прототип, и я расскажу про типовые примеры инсталляции, фичи и конфигурацию, а также покажу бенчмарки.
Жизнь проекта на production советы по эксплуатации / Николай Сивко (okmeter.io)Ontico
Ваш сайт или другой проект приносит деньги только тогда, когда он работает.
Нельзя просто выложить код на серверы, залить схему в базу данных и делегировать домен.
Будем говорить о планировании отказоустойчивости и мониторинге проектов:
- оцениваем риски отказа различных компонентов;
- какие-то из вероятных проблем просто мониторим и планируем действия при сбоях;
- проблемы, которых можно избежать легко и дешево, закрываем сразу.
Расскажу на примерах о том, что всё всегда ломается, но с этим можно жить.
10 способов достижения HighLoad'а и BigData на ровном месте / Илья Космодемья...Ontico
Веб-сайт нужно делать так, чтобы о перипетиях его разработки и поддержки бессонными ночами через пару лет можно было рассказать на конференции Highload++, а тамошнюю аудиторию сложно удивить велосипедом с треугольными каменными колесами. Большинство разработчиков свято следуют этому принципу то ли в силу природной любознательности и трудолюбия, то ли по причине отсутствия конференции LowLoad--.
Примерно такие мысли приходят в голову практически любому специалисту по хранилищам данных, когда он видит успешный веб-проект, испытывающий стандартные проблемы с базой данных.
В этом докладе я расскажу о 10-ти очень распространенных ошибках проектирования и эксплуатации хранилища в веб-проекте — от преждевременного шардирования базы и непродуманной системы архивации ненужных данных до особенностей работы всеми любимых фреймворков. Про каждую из них я расскажу подробно и поделюсь рецептами, как такие ошибки исправлять.
Обзор архитектуры и подсистем деплоя и мониторинга.
Как инженеры делают систему прозрачной для разработки.
1) Схема организации репозитория puppet.
Зачем мы сделали репозиторий публичным внутри компании?
Как мы "делим" puppet, и что делать, если все "пропало"?
Собственная реализация механизма puppet kick.
2) Как рассказать всем обо всем и никого не потерять.
"Черный мониторинг" (rbmon). Как мы собираем информацию о серверах и демонах.
Делимся логами с разработчиками. Почему написали "велосипед"?
3) Graphite - система сбора и визуализации данных.
Почему graphite?
1М метрик в минуту?
Какие метрики мы рисуем (nginx-graphite-module, rbmon plugins).
Визуализация работы проекта (Dashboard пульт).
Кластеры баз данных делаем сложные вещи просто / Андрей Тихонов (Avito)Ontico
Порой в процессе развития высоконагруженного проекта наступает момент, когда необходимо масштабирование. Возможно, ваш проект впервые упёрся в производительность железа (и таким образом перешёл в разряд высоконагруженных); возможно, это уже не первое масштабирование — не важно. Какие же проблемы могут возникнуть?
Во-первых, если вы увеличиваете количество бэкенд-серверов, и, соответственно, количество рабочих процессов, то с ростом количества одновременных клиентских подключений вырастают и накладные расходы на базах данных.
Во-вторых, достаточно быстро может кончиться ресурс in-memory баз данных. Потребуется создать (либо увеличить) кластер, а это каждый раз влечёт за собой необходимость модифицировать логику приложения.
В-третьих, чем больше серверов, тем больше вероятность, что один из них выйдет из строя. Поэтому неплохо задуматься о том, как обеспечить отказоустойчивость, а это, опять же, потребует модифицировать логику приложения.
В этом докладе я расскажу, как и какими инструментами можно легко решить все вышеперечисленные проблемы: уменьшить накладные расходы от большого количества подключений к базам данных, создать/модифицировать кластер БД прозрачно для приложения, а также прозрачно добавить устойчивость к падениям серверов БД.
План доклада:
- Введение. Методы масштабирования БД: репликация, шардирование.
- Создаём шардированные кластеры in-memory БД прозрачно для приложений: Twemproxy, Redis-proxy, Mcrouter.
- Уменьшаем накладные расходы от большого количества одновременных подключений на PostgreSQL с помощью PgBouncer.
- Создаём шардированный кластер PostgreSQL с помощью PL/Proxy.
- Добавляем прозрачную для приложения отказо�
Что нового и полезного в PostgreSQL 9.5 / Илья Космодемьянский (PostgreSQL-Co...Ontico
Доклад о новинках нового релиза PostgreSQL можно сделать экстремально скучным: взять release-notes и зачитать вслух. Но 9.5 обещает быть очень интересным релизом как с точки зрения улучшения производительности, так и функциональности - было бы жалко сделать о нем плохой доклад. Поэтому я выбрал несколько важных и нужных фич и расскажу про каждую - как она устроена, на что влияет и, главное, как ей разумно воспользоваться - максимум практических аспектов, минимум маркетинга. Без этого минимума нельзя, иначе мне никак не поделиться своим взглядом на то, как сейчас развивается PostgreSQL, и как жить пользователям Postgres'а при такой стратегии развития.
Эволюция процесса деплоя в проекте / Денис Яковлев (2ГИС)Ontico
Если наш проект — это не коробочный продукт, а, например, веб-сервис, на который постоянно ходят пользователи, их много и они сразу видят изменения, то в жизненном цикле разработки у нас возникает еще одна задача — задача деплоя готового кода в боевое окружение.
В самом начале, когда наш проект маленький и простой, на эту задачу никто может и не обращать внимания, так как все происходит быстро и просто. Процесс деплоя состоит из 2-3 общеизвестных шагов — git pull, yii migrate, etc..., которые легко запомнить и в них сложно ошибиться.
С развитием проекта его сложность возрастает — он уже крутится на нескольких серверах, появляются новые компоненты (утилиты, библиотеки и т.д.), новые сущности (балансеры, кэшы, и т.д.). Держать всю инфраструктуру в голове становится невозможным, ведение документации привносит больше проблем, нежели решений, люди ошибаются чаще и т.д.
В докладе:
— рассмотрим подробно вышеуказанные проблемы, с которыми неизбежно сталкиваются проекты;
— обсудим, какие решения существуют в индустрии (chef, ansible, etc), чем они отличаются, какой выбрать и в чем их задача;
— поговорим про административные вопросы, которые с этим связаны.
Внутреннее устройство PostgreSQL: временные таблицы и фрагментация памяти / Г...Ontico
Всем известно о существовании временных таблиц в PostgreSQL, но как они устроены, и чем грозит их некорректное использование - не столь очевидно.
На примере одного известного приложения, активно и некорректно использующего временные таблицы, мы расскажем о создаваемой ими проблеме фрагментации памяти.
Что такое фрагментация памяти, по каким признакам можно определить ее наличие, чем она грозит, почему она возникает при активном использовании временных таблиц, и как мы пропатчили PostgreSQL, чтобы ее избежать - обо всем этом можно узнать из нашего доклада.
Обзор архитектуры и подсистем деплоя и мониторинга. Как инженеры делают систе...Ontico
1) Схема организации репозитория puppet.
Зачем мы сделали репозиторий публичным внутри компании?
Как мы "делим" puppet, и что делать, если все "пропало"?
Собственная реализация механизма puppet kick.
2) Как рассказать всем обо всем и никого не потерять.
"Черный мониторинг" (rbmon). Как мы собираем информацию о серверах и демонах.
Делимся логами с разработчиками. Почему написали "велосипед"?
3) Graphite - система сбора и визуализации данных.
Почему graphite?
1М метрик в минуту?
Какие метрики мы рисуем (nginx-graphite-module, rbmon plugins).
Визуализация работы проекта (Dashboard пульт).
Путь DevOps в «Parallels» / Константин Назаров (Parallels)Ontico
В этом докладе я расскажу вам историю о своих попытках улучшить процессы в компании Parallels. Она будет насыщена "фейлами" и набором неочевидных и спорных ситуаций, с коротыми вы можете столкнуться, если пойдете по "пути инноватора".
Я расскажу:
- чего удалось добиться за 3 года;
- далеко ли могут увести вас чисто инструментальные решения;
- с какими управленческими проблемами приходится столкнуться, если вы "внедряете DevOps";
- какой может быть предел влияния у "DevOps команды";
- типичные ситуации, в которых можно легко "завязнуть", и их корневые причины.
Лучшие практики Continuous Delivery с Docker / Дмитрий Столяров (Флант)Ontico
Потребность в отстроенном процессе Continuous Delivery встает перед каждым развивающимся highload-проектом. Чем больше серверов и составных приложений, чем выше динамика релизов, тем раньше проект сталкивается с данной потребностью, и тем острее она стоит.
Многие команды эксплуатации смогли отстроить этот процесс, некоторые добились впечатляющих результатов, а некоторые — потерпели неудачу. Но все из них знают, что их процесс можно улучшить: сделать быстрее, надежнее, предсказуемее и удобнее.
В этом докладе я хочу обобщить и систематизировать лучшие практики построения процесса Continuous Delivery с использованием актуальных Open Source технологий (Docker, Chef, Gitlab, Kubernetes), а также обозначить известные проблемы и потенциальные пути их решения.
Будет предпринята попытка однозначно ответить на следующие практические вопросы:
- Почему пора всем переходить на Docker? Как лучше собирать Docker-образы? Как лучше доставлять и хранить Docker-образы?
- Как правильно построить процесс разработки Infrastructure as Code (IaC)?
- Как оптимально интегрировать автоматическое и ручное тестирование в процесс Continuous Delivery?
- Как перестать бояться регулярных выкатов новых версий и сделать этот процесс надежным?
- Почему Continuous Delivery не заканчивается релизом новой версии и зачем нужен Kubernetes?
Поддержка высоконагруженного проекта: мониторинг, резервирование, обслуживани...Ontico
1. Мониторинг высоконагруженного проекта.
1.1. Специфика мониторинга высоконагруженного проекта: гранулярность мониторинга, надежность системы мониторинга, система оповещений.
1.2. Мониторинг и контроль распределенных систем.
1.3. Специфика организации оповещений в высоконагруженном проекте. Превентивный мониторинг.
2. Резервирование и резервное копирование в высоконагруженном проекте.
2.1. Резервирование и резервное копирование - разные вещи.
2.2. Резервирование: на уровне сервера, дата-центра, географически распределенных площадок.
2.1. Организация резервного копирования. Сохранность часто обновляемых данных.
3. Обслуживание высоконагруженного проекта.
3.1. Организация поддержки высоконагруженного проекта: опыт, специфика работы.
3.2. Организация дежурств, эскалация оповещений.
3.3. Аварии в высоконагруженных проектах: примеры из жизни.
Принципы и приёмы обработки очередей / Константин Осипов (Mail.ru)Ontico
Насколько повысится среднее время обработки одного запроса если увеличить нагрузку вдвое? Почему производительность базы данных может снизиться при росте числа клиентов? Как добиться эффективного распределения большого числа задач на весь кластер? О практике и о теории обработки очередей на которой основана практика в моём докладе.
Open Source SQL-базы данных вступили в эру миллионов запросов в секунду / Фед...Ontico
Широко распространено мнение, что SQL СУБД обречены быть медлительными и неповоротливыми, поскольку несут груз совместимости с предыдущими версиями. Это расхожее мнение широко эксплуатируется маркетингом NoSQL СУБД. Однако, это не всегда действительно так.
Разработка в Open Source сообществе позволяет продукту развиваться достаточно гибко, чтобы отвечать требованиям времени. В MySQL и PostgreSQL – самых популярных Open Source СУБД – недавно были проведены оптимизации для работы на больших серверах, что позволило им выполнять более миллиона SQL-запросов в секунду на одном экземпляре БД.
В данном докладе будут рассмотрены конкретные оптимизации, которые позволили добиться таких результатов, которые раньше могли бы показаться фантастическими. И можно сказать, что Open Source СУБД вошли в эру миллионов запросов в секунду.
NodeJS в HighLoad проекте / Акрицкий Владимир (iAge Engineering)Ontico
NodeJS — достаточно молодой фреймворк, и пока не каждый решается использовать его в продакшене, а тем более в highload.
В течение последнего года мы разрабатывали проект DMP (Data Management Platform), используя NodeJS для прототипирования. На данный момент проект в большей степени все еще остался на JS и без труда справляется с текущими нагрузками в 10 000 запросов в секунду.
В докладе я расскажу, почему остановились именно на NodeJS и совсем не жалеем об этом.
К сожалению, никакое дело не обходится без граблей и костылей. Я расскажу обо всех встретившихся проблемах и уделю особое внимание проблемам со спагетти-кодом, утечками и нехваткой памяти. Как мы убили немало времени, тщетно ища источник проблем, и какие правила мы составили для себя на будущее, чтобы не повторить своих ошибок.
Расскажу немного о применении микросервисов для решения проблемы спагетти-кода.
И, как итог, опишу ряд рекомендаций, которые помогут избежать большой траты времени при использовании NodeJS.
NAS, Predictions, Preloading, Presudo-Isomorphism / Охрименко Алексей (Acronis)Ontico
На примере фреймворка COD.js ( c React as View Layer ) и топовых продуктов фирмы Acronis мы увидим, каких удивительных результатов можно добиться используя:
1) NAS — неблокирующее состояние приложения;
2) Predictions — дизайн-паттерн, позволяющий предсказывать состояния системы и производить так называемую "latency conpensation" — технику, которую очень любят в Game Dev;
3) Preloading — стандартную и всем знакомую технику, у которой есть пара интересных способов применения, заслуживающих внимания;
4) Presudo-Isomorphism — очень хитрую технику, которую так активно использует Facebook.
Все это будет показано на примере реальных продуктов. С простыми и понятными примерами, которые можно будет применить в любом продукте.
Zabbix в Badoo или о чем не пишут в мануале, Илья Аблеев (Badoo)Badoo Development
Доклад с Zabbix Meetup.
Рассказали про:
• Сколько инстансов используем, зачем, какая конфигурация и нагрузка, какие дополнительные тулзы используем.
• Деплой скриптов/конфигов/обновлении.
• Флоу появления новых сущностей в мониторинге: хостов, проверок, графиков в заббикс. Самописный дискавери (серверов, сервисов): почему свой и что он умеет.
• Штуки для удобства: нотификации на рабочий стол, быстрая навигация по графикам.
Доклад о том, как мы добились идеально ровной балансировки нагрузки по кластеру из 200+ серверов, реализовали автоматический подбор весов и получили разброс CPU usage в 2,5% в пике трафика. Это позволило сэкономить нам около 40-50 серверов и улучшить время отклика мобильного сайта в пике нагрузки. Реализацию приведенного алгоритма мы выложим в open-sourсe. Доклад Юрия Насретдинова на Highload 2015.
Веб-разработка без наркотиков с помощью PostgreSQL, Nginx и c2h5oh / Миша Кир...Ontico
Разговор в докладе пойдёт о веб-программировании.
При изготовлении веб-проектов то и дело пользуются широко распространёнными фреймворками на базе языков программирования — PHP, Python, Perl, Ruby, Go, Rust, Java и т.п.
Я предлагаю отказаться от употребления оных и использовать для разработки веб-приложений только c2h5oh — расширение для высокопроизводительного сервера nginx. Данное расширение позволяет эффективно использовать PostgreSQL в качестве сервера веб-приложений.
Хочу поделиться со слушателями своим личным опытом разработки с использованием подобной связки. Планирую рассказать о плюсах и минусах такого подхода.
«Секретные» технологии инвестиционных банков / Алексей Рагозин (Дойче Банк)Ontico
Как правило, такое базовое ПО, как языки программирования, системы управления базами данных, брокеры сообщений, используется в разных индустриях и не имеет ярко выраженной бизнес-специализации. Java, Python, MySQL и не только находят применение повсюду, начиная с больших корпораций, заканчивая стратапами и видеоиграми.
Тем не менее, встречаются исключения. В докладе пойдёт речь о технологиях, получивших распространение в инвестиционных банках и не слишком известных за их пределами. Хотя прямого отношения к торговле финансовыми инструментами сами по себе эти технологии не имеют.
Тезисы - http://www.highload.ru/2015/abstracts/1888.html
Tempesta FW: challenges, internals, use cases / Александр Крижановский (Tempe...Ontico
Tempesta FW — это Open Source гибрид Web-акселератора и файервола, специально разработанный для высокопроизводительной доставки контента вне зависимости от DDoS или наплыва посетителей.
В докладе будет рассказано про задачи, которые ставились при разработке проекта и пути их решения. Рассмотрим проблемы современных операционных систем в приложении к Web-стеку (система фильтрации, Web-сервер, application слой, БД), и как они решаются в Tempesta — некоторые уже решены, некоторые еще в процессе работы.
И самое главное — у нас появился рабочий прототип, и я расскажу про типовые примеры инсталляции, фичи и конфигурацию, а также покажу бенчмарки.
Жизнь проекта на production советы по эксплуатации / Николай Сивко (okmeter.io)Ontico
Ваш сайт или другой проект приносит деньги только тогда, когда он работает.
Нельзя просто выложить код на серверы, залить схему в базу данных и делегировать домен.
Будем говорить о планировании отказоустойчивости и мониторинге проектов:
- оцениваем риски отказа различных компонентов;
- какие-то из вероятных проблем просто мониторим и планируем действия при сбоях;
- проблемы, которых можно избежать легко и дешево, закрываем сразу.
Расскажу на примерах о том, что всё всегда ломается, но с этим можно жить.
10 способов достижения HighLoad'а и BigData на ровном месте / Илья Космодемья...Ontico
Веб-сайт нужно делать так, чтобы о перипетиях его разработки и поддержки бессонными ночами через пару лет можно было рассказать на конференции Highload++, а тамошнюю аудиторию сложно удивить велосипедом с треугольными каменными колесами. Большинство разработчиков свято следуют этому принципу то ли в силу природной любознательности и трудолюбия, то ли по причине отсутствия конференции LowLoad--.
Примерно такие мысли приходят в голову практически любому специалисту по хранилищам данных, когда он видит успешный веб-проект, испытывающий стандартные проблемы с базой данных.
В этом докладе я расскажу о 10-ти очень распространенных ошибках проектирования и эксплуатации хранилища в веб-проекте — от преждевременного шардирования базы и непродуманной системы архивации ненужных данных до особенностей работы всеми любимых фреймворков. Про каждую из них я расскажу подробно и поделюсь рецептами, как такие ошибки исправлять.
Обзор архитектуры и подсистем деплоя и мониторинга.
Как инженеры делают систему прозрачной для разработки.
1) Схема организации репозитория puppet.
Зачем мы сделали репозиторий публичным внутри компании?
Как мы "делим" puppet, и что делать, если все "пропало"?
Собственная реализация механизма puppet kick.
2) Как рассказать всем обо всем и никого не потерять.
"Черный мониторинг" (rbmon). Как мы собираем информацию о серверах и демонах.
Делимся логами с разработчиками. Почему написали "велосипед"?
3) Graphite - система сбора и визуализации данных.
Почему graphite?
1М метрик в минуту?
Какие метрики мы рисуем (nginx-graphite-module, rbmon plugins).
Визуализация работы проекта (Dashboard пульт).
Кластеры баз данных делаем сложные вещи просто / Андрей Тихонов (Avito)Ontico
Порой в процессе развития высоконагруженного проекта наступает момент, когда необходимо масштабирование. Возможно, ваш проект впервые упёрся в производительность железа (и таким образом перешёл в разряд высоконагруженных); возможно, это уже не первое масштабирование — не важно. Какие же проблемы могут возникнуть?
Во-первых, если вы увеличиваете количество бэкенд-серверов, и, соответственно, количество рабочих процессов, то с ростом количества одновременных клиентских подключений вырастают и накладные расходы на базах данных.
Во-вторых, достаточно быстро может кончиться ресурс in-memory баз данных. Потребуется создать (либо увеличить) кластер, а это каждый раз влечёт за собой необходимость модифицировать логику приложения.
В-третьих, чем больше серверов, тем больше вероятность, что один из них выйдет из строя. Поэтому неплохо задуматься о том, как обеспечить отказоустойчивость, а это, опять же, потребует модифицировать логику приложения.
В этом докладе я расскажу, как и какими инструментами можно легко решить все вышеперечисленные проблемы: уменьшить накладные расходы от большого количества подключений к базам данных, создать/модифицировать кластер БД прозрачно для приложения, а также прозрачно добавить устойчивость к падениям серверов БД.
План доклада:
- Введение. Методы масштабирования БД: репликация, шардирование.
- Создаём шардированные кластеры in-memory БД прозрачно для приложений: Twemproxy, Redis-proxy, Mcrouter.
- Уменьшаем накладные расходы от большого количества одновременных подключений на PostgreSQL с помощью PgBouncer.
- Создаём шардированный кластер PostgreSQL с помощью PL/Proxy.
- Добавляем прозрачную для приложения отказо�
Что нового и полезного в PostgreSQL 9.5 / Илья Космодемьянский (PostgreSQL-Co...Ontico
Доклад о новинках нового релиза PostgreSQL можно сделать экстремально скучным: взять release-notes и зачитать вслух. Но 9.5 обещает быть очень интересным релизом как с точки зрения улучшения производительности, так и функциональности - было бы жалко сделать о нем плохой доклад. Поэтому я выбрал несколько важных и нужных фич и расскажу про каждую - как она устроена, на что влияет и, главное, как ей разумно воспользоваться - максимум практических аспектов, минимум маркетинга. Без этого минимума нельзя, иначе мне никак не поделиться своим взглядом на то, как сейчас развивается PostgreSQL, и как жить пользователям Postgres'а при такой стратегии развития.
Эволюция процесса деплоя в проекте / Денис Яковлев (2ГИС)Ontico
Если наш проект — это не коробочный продукт, а, например, веб-сервис, на который постоянно ходят пользователи, их много и они сразу видят изменения, то в жизненном цикле разработки у нас возникает еще одна задача — задача деплоя готового кода в боевое окружение.
В самом начале, когда наш проект маленький и простой, на эту задачу никто может и не обращать внимания, так как все происходит быстро и просто. Процесс деплоя состоит из 2-3 общеизвестных шагов — git pull, yii migrate, etc..., которые легко запомнить и в них сложно ошибиться.
С развитием проекта его сложность возрастает — он уже крутится на нескольких серверах, появляются новые компоненты (утилиты, библиотеки и т.д.), новые сущности (балансеры, кэшы, и т.д.). Держать всю инфраструктуру в голове становится невозможным, ведение документации привносит больше проблем, нежели решений, люди ошибаются чаще и т.д.
В докладе:
— рассмотрим подробно вышеуказанные проблемы, с которыми неизбежно сталкиваются проекты;
— обсудим, какие решения существуют в индустрии (chef, ansible, etc), чем они отличаются, какой выбрать и в чем их задача;
— поговорим про административные вопросы, которые с этим связаны.
Внутреннее устройство PostgreSQL: временные таблицы и фрагментация памяти / Г...Ontico
Всем известно о существовании временных таблиц в PostgreSQL, но как они устроены, и чем грозит их некорректное использование - не столь очевидно.
На примере одного известного приложения, активно и некорректно использующего временные таблицы, мы расскажем о создаваемой ими проблеме фрагментации памяти.
Что такое фрагментация памяти, по каким признакам можно определить ее наличие, чем она грозит, почему она возникает при активном использовании временных таблиц, и как мы пропатчили PostgreSQL, чтобы ее избежать - обо всем этом можно узнать из нашего доклада.
Обзор архитектуры и подсистем деплоя и мониторинга. Как инженеры делают систе...Ontico
1) Схема организации репозитория puppet.
Зачем мы сделали репозиторий публичным внутри компании?
Как мы "делим" puppet, и что делать, если все "пропало"?
Собственная реализация механизма puppet kick.
2) Как рассказать всем обо всем и никого не потерять.
"Черный мониторинг" (rbmon). Как мы собираем информацию о серверах и демонах.
Делимся логами с разработчиками. Почему написали "велосипед"?
3) Graphite - система сбора и визуализации данных.
Почему graphite?
1М метрик в минуту?
Какие метрики мы рисуем (nginx-graphite-module, rbmon plugins).
Визуализация работы проекта (Dashboard пульт).
Путь DevOps в «Parallels» / Константин Назаров (Parallels)Ontico
В этом докладе я расскажу вам историю о своих попытках улучшить процессы в компании Parallels. Она будет насыщена "фейлами" и набором неочевидных и спорных ситуаций, с коротыми вы можете столкнуться, если пойдете по "пути инноватора".
Я расскажу:
- чего удалось добиться за 3 года;
- далеко ли могут увести вас чисто инструментальные решения;
- с какими управленческими проблемами приходится столкнуться, если вы "внедряете DevOps";
- какой может быть предел влияния у "DevOps команды";
- типичные ситуации, в которых можно легко "завязнуть", и их корневые причины.
Лучшие практики Continuous Delivery с Docker / Дмитрий Столяров (Флант)Ontico
Потребность в отстроенном процессе Continuous Delivery встает перед каждым развивающимся highload-проектом. Чем больше серверов и составных приложений, чем выше динамика релизов, тем раньше проект сталкивается с данной потребностью, и тем острее она стоит.
Многие команды эксплуатации смогли отстроить этот процесс, некоторые добились впечатляющих результатов, а некоторые — потерпели неудачу. Но все из них знают, что их процесс можно улучшить: сделать быстрее, надежнее, предсказуемее и удобнее.
В этом докладе я хочу обобщить и систематизировать лучшие практики построения процесса Continuous Delivery с использованием актуальных Open Source технологий (Docker, Chef, Gitlab, Kubernetes), а также обозначить известные проблемы и потенциальные пути их решения.
Будет предпринята попытка однозначно ответить на следующие практические вопросы:
- Почему пора всем переходить на Docker? Как лучше собирать Docker-образы? Как лучше доставлять и хранить Docker-образы?
- Как правильно построить процесс разработки Infrastructure as Code (IaC)?
- Как оптимально интегрировать автоматическое и ручное тестирование в процесс Continuous Delivery?
- Как перестать бояться регулярных выкатов новых версий и сделать этот процесс надежным?
- Почему Continuous Delivery не заканчивается релизом новой версии и зачем нужен Kubernetes?
Опыт построения и эксплуатации большого файлового хранилища / Даниил Подольск...Ontico
1. Введение в проблематику: файловые хранилища, их классификация и ключевые характеристики - по версии докладчика.
1.1. Термины и определения: файл, хранилище, POSIX file system, документ-ориентированное хранилище, области применимости и условия эксплуатации.
1.2. Классификация по размеру: количество записей, количество байт, количество запросов, количество обновлений и сочетание этих параметров, позволяющее назвать хранилище “большим”.
далее см. - http://rootconf.ru/2015/abstracts/1747
Использование haproxy/iptables+etcd+confd для автоматического service discove...Ontico
* Сервис-ориентированная архитектура - что это такое и зачем это нужно?
* Поиск сервисов: стандартные пути:
1) Хардкод endpoint'ов (IP:port).
+ работает
+ просто и топорно
- при росте числа сервисов начинается ад
- появляется документация, странички в вики, которые неактуальны, ночью изменения не внесешь
- при миграции серверов часто меняются эндпоинты, много лишней сопутствующей работы
далее см. - http://rootconf.ru/2015/abstracts/1779
smart balancing with nginx+lua / Андрей Кононов (IPONWEB)Ontico
В этом докладе я планирую осветить следующие проблемы:
- Почему стандартных механизмов балансировки бывает недостаточно.
- Как выбирать фундамент для решения, и какие принципы проектирования использовались.
- Как формировались требования для решения, которое работает сейчас в продакшне и пропускает через себя ощутимое количество.
Расскажу, как без помощи сторонних сессионных хранилищ и довольно за дёшево организовать "sticky balancing", и как это работает с точки зрения науки. Покажу пример отказоустойчивой геораспределённой системы, расскажу, что мониторить и как правильно это делать при помощи специального расширения для nginx и не только. Расскажу о том, как было организовано нагрузочное и функциональное тестирование конечного продукта. Также расскажу про полный жизненный цикл этого весьма критичного для инфраструктуры приложения.
Поскольку мы живём в публичных облаках, я по ходу доклада расскажу, как мы тестировали и сравнивали AWS и GCP, а также про некоторые сугубо практические особенности организации in-house балансировки внутри публичного облака.
Использование Tarantool в качестве платформы виртуализации данных / Константи...Ontico
Инфраструктура хранения данных современного предприятия отражает историю развития бизнеса и индустрии и зачастую разнородна: проприетарные системы хранения и обработки данных, кэширующие системы, системы хранения данных для Интернет-сервисов.
Всё большее проникновение цифровых технологий в бизнес бросает вызов существующей IТ-инфраструктуре. Для сохранения имеющихся позиций на рынке необходимо обрабатывать всё большие объёмы всё быстрее меняющихся данных.
Проприетарные решения не отвечают этому вызову не только в технологической, но и в экономической составляющей: лицензионная политика, общая стоимость владения часто линейно зависят от объёма обрабатываемых данных, что является недопустимым в условиях шквального роста цифровой составляющей бизнеса.
Облачные решения недостаточно сформировались, с одной стороны, и ограничены в применении, с другой, особенно если речь идёт об обработке персональных данных, либо данных, имеющих жизненно
важное значение для бизнеса.
Единственным возможным на сегодняшний день ответом на вызов digital трансформации является внедрение решений с открытым исходным кодом.
В данном докладе будет изложен опыт такого внедрения в крупную компанию телекоммуникационной индустрии. Речь пойдёт о построении платформы виртуализации данных на основе решения Tarantool.
Преимуществами подхода виртуализации данных являются:
- безболезненная интеграция с существующей IТ-инфраструктурой, платформа может выступать в качестве высокопроизводительного "фасада" к существующим источникам данных;
- чрезвычайно высокая скорость работы с данными;
- возможность работать с данными, а не с ис
В нашей большой компании мы столкнулись с задачей выкладывания релизов наших проектов на несколько групп серверов по нескольким сотням машин.
Мы решили разработать свой софт для удобного деплоя, поскольку задача, на мой взгляд, достаточно сложная, потому что каждая секунда при выкатке решает очень многое.
Почему именно разработать что-то свое, а не использовать что-то готовое, например, Fabric или Capistrano?
Все просто:
1. Система должна быть написана на языке, на котором принято разрабатывать в компании.
2. Все возникающие трудности и проблемы должны быть решены в кратчайшие сроки, нет времени ждать пока чья-то техподдержка прилетит на помощь на голубом вертолете :)
3. Система должна быть безопасна, полностью с открытыми кодами для безопасников.
4. Минимизированы зависимости от внешних модулей.
Вкратце расскажу о том, как мы раскладываем front-end для наших проектов в Mail.ru Group в продакшн и на тестовые сервера.
В частности, расскажу, как мы собираем версточный релиз.
Расскажу о том, как его запаковать и как аккуратно раздать на несколько сотен серверов.
Расскажу об архитектуре мониторинга системы обновлений, а также покажу, как выглядит наш дашборд, по которому мы понимаем, что все хорошо.
Отвечу на все интересующие вас вопросы и дам несколько рекомендаций, которые помогут вам обойти подводные грабли, на которые наступали мы.
Мониторинг всех слоев web проекта / Сивко Николай (hh.ru)Ontico
Когда вы узнаете, что ваш сервис не работает, вы идете в мониторинг, видите много алертов про CPU/load average/diskIO/и т.д., пускаете слезу и идете читать логи. Сначала на фронтенды, потом дальше по стеку.
У многих уже есть grafana и подобные дашборды, но почти всегда там есть только метрики про приложение и пользователей, но нет ничего про сеть, базу и другие подсистемы, от которых зависит работа сервиса.
Мониторинг должен помочь быстро понять, в каком сервисе проблема, а, может, даже показать причину проблемы.
Я расскажу и покажу на примере hh.ru, как покрыть мониторингом все слои инфраструктуры:
- client-side метрики;
- метрики с фронтендов (логи nginx);
- сеть (что можно добыть из TCP);
- приложение (логи);
- метрики базы данных (postgresql в нашем случае);
- операционная система (cpu usage тоже может пригодиться:).
Классические архитектуры во фронтенде / Александра Шинкевич (LOVATA)Ontico
Responsive web design, HTML5, CSS3, IDE, API, React, Angular, веб-компоненты, БЭМ... Опытным фронтендерам эти слова давно знакомы. А как насчет таких классических архитектур как MVC, MVP или MVVM? Знаете ли вы, что такое MVP, и почему Angular.js построен на паттерне MVVM, а не MVC, хотя в этом фреймворке активно используется понятие "контроллер"? Чем эти три архитектуры отличаются друг от друга, и зачем, вообще, о них нужно знать фронтендеру?
В своем докладе я хочу рассмотреть эти три понятия как с теоретической (история, концепция, назначение), так и с практической точки зрения. На простых примерах я покажу, как можно организовать ту или иную архитектуру во фронтендовой части веб-приложения, а также рассмотрю некоторые архитектурные паттерны, которые позволяют увеличить читабельность и добавить модульность и переносимость кода.
Как не положить тысячи серверов с помощью системы централизованного управлени...Ontico
В 2012 году мы начали внедрение CFEngine в нашу инфраструктуру. Переход на централизованное управление конфигурацией в проектах такого масштаба подобен ремонту - его невозможно закончить, его можно только прекратить. И уже весной 2013 года (в день 404 ошибки и международного дня Интернета) этот "ремонт" превратился в катастрофу и был остановлен. После 3 суток недоступности портала нам пришлось изобрести схему, которая бы физически ограничивала возможность повторения катастрофы. Схема включает в себя тестирование политик на тестовых серверах различной важности и конфигурации. "Маринование" в этой тестовой среде сопровождается автоматизированным контролем характеристик нагрузки этих серверов. Далее происходит обязательный ревью и плавное распространение последовательно по всем датацентрам.
В докладе будет рассказано:
1. почему мы выбрали CFEngine, а не Chief или Puppet;
2. как мы научили CFEngine быть дружелюбным (примеры политик и выдержки из библиотеки);
3. 100500 предпринятых мер, что бы не повторить "день 404" и соблюсти баланс между безопасностью и удобством;
4. как ещё можно использовать системы управления серверами.
Сравнение решений по балансировке высоконагруженных систем / Евгений Пивень (...Ontico
+ Функционал разных решений для балансировки.
+ Виды балансировщиков (DNS, hardware, software, облачные решения).
+ Поведение при скачках трафика и возможности скалирования сервиса.
+ Специфика трафика RTB в контексте балансировки.
+ Проблемы, которые возникали у нас, и как мы их решали.
Кит на службе у человека microPaaS Deis / Алексей Медведчиков (2ГИС)Ontico
Всем, кто сталкивался с запуском веб-сервисов, хорошо знакомы вопросы, возникающие при выпуске нового продукта:
- нужно создать вируталки/залить сервера;
- нужно обеспечить мониторинг сервиса;
- обеспечить zero-downtime обновление приложения;
- ... ещё 100500 разных задач.
Зачастую эти задачи решаются либо руками, либо различными связками систем управления конфигурацией и деплойментом.
Мы нашли способ, значительно сокративший время на запуск новых приложений — веб-платформа Deis. Она построена на Docker и CoreOS и представляет собой легковесный PaaS, похожий на Heroku. Подходы, используемые при работе с Deis, облегчают внедрение CD/CI, уменьшают разрыв между dev/stage и production окружениями, уменьшают время на поддержку приложений.
Мы поговорим о проблемах, перечисленных выше, о том, какой путь пройден нами до продакшна, и о том, какие проблемы Deis не решает.
Доклад будет полезен как для Ops, которым хочется автоматизировать типичные задачи вокруг деплоя/обновления веб-сервиса, так и для Dev, которые могут увидеть потенциальную возможность ускорения доставки багфиксов/фич на бой.
Применяем стандарты кодирования NASA к JavaScript / Денис Радин (Liberty Global)Ontico
Jet Propulsion Laboratory – научная организация, производящая большое количество исследований и разрабатывающая ПО для большинства беспилотных программ NASA в области исследования дальнего космоса. В портфолио JPL такие проекты как марсоход Curiosity и зонд Voyager, покинувший солнечную систему после 25 лет полета и до сих пор поставляющий научную информацию. Высокий уровень автоматизации миссий и продолжительность явились основанием для беспримерных требований к качеству ПО, следствием которых стали недавно опубликованные рекомендации по написанию кода для проектов JPL.
Так как требования к веб-приложениям постоянно растут, а задачи, доверяемые им, становятся все более критическими, давайте применим стандарты кодирования NASA/JPL к JavaScript для повышения надежности, производительности и во имя лучшего мира.
Современная операционная система: что надо знать разработчику / Александр Кри...Ontico
Мы проговорим про связь приложения и ОС, какие компоненты есть в современной ОС на примере Linux, как настройки этих компонент могут повлиять на приложение.
Я расскажу про планировщик процессов, дисковый и сетевой ввод-вывод и соответствующие планировщики, управление памятью - как это все в общих чертах работает и как его потюнить.
Путь мониторинга 2.0 всё стало другим / Всеволод Поляков (Grammarly)Ontico
Обзор мониторинга в Grammarly, о котором я докладывал на прошлом RootConf'е.
Почему мы опять решили всё изменить после перехода на докер, и как мы пришли к zipper-stack, go-carbon, carbon-c-relay (в том числе и бенчмарки альтернативных решений), как получать миллион уникальных метрик в секунду, как мы пришли к тому, что теги в условии безымянных инстансов необходимы, и как мы их сделали, как работает zipper-stack и, вообще, архитектура нашего текущего убер мониторинга.
PostgreSQL: практические примеры оптимизации SQL-запросов / Иван Фролков (Po...Ontico
Довольно часто как адинистраторы, так и разработчики жалуются на низкую производительность приложений, работающих с базой данных, и нередко при этом ищут решения возникших проблем с помощью различных настроек как СУБД, так и операционной системы, пренебрегая при этом самым действенным способом - оптимизацией запросов к собственно БД.
Тому, как понимать, где же узкие места, и как их можно попробовать избежать на примере PostgreSQL и посвящен этот доклад.
Производительность запросов в PostgreSQL - шаг за шагом / Илья Космодемьянски...Ontico
Вы взяли ваш любимый фреймворк™ и быстро запустили крутой проект, который раскручивается, приносит деньги и требует быстрого развития, чтобы оставить конкурентов далеко позади.
В один далеко не прекрасный момент вы понимаете, что корень всех зол - медленное время ответа базы данных, а ваш админ зло смотрит на разработчиков красными от бессонницы глазами и ругается на безумные запросы, которые генерирует ORM. Тот самый ORM, который позволил вам так быстро запустить ваш замечательный проект.
Знакомо? Тогда вам будет интересно послушать, как заставить вашу базу данных работать прямо сейчас. А именно:
- какое место в общей производительности базы данных занимает оптимизация запросов?
- когда прекращать “крутить гайки” и заниматься медленными запросами?
- что такое медленный запрос и когда их надо начинать оптимизировать?
- как оптимизировать?
- EXPLAIN, EXPLAIN ANALYZE - как читать и на что обращать внимание?
- как работает оптимизатор запросов PostgreSQL и где могут быть узкие места?
- для чего нужны и для чего не нужны индексы, методики индексирования, и как быть уверенным, что ваш индекс правильно используется?
- какие запросы не будут работать быстро никогда, и как с этим жить?
- ошибается ли оптимизатор и, если да, то почему и как его в таком случае призвать к порядку?
Highload в ВУЗе идеализм, расчётливый менеджмент или пустые надежды / Артем К...Ontico
Highload — тот ещё секс в нашей жизни. Можно ли научить сексу заранее тех, кто не нюхал пороха?
В своей работе я часто сталкиваюсь с бойцами от разработки, управления проектами, информационной безопасности и даже эксплуатации, возможно даже опытными, с медалями первой степени, но из другого рода продуктов, из "обычного софта" что ли... Эти ребята действительно уверены, что база данных всегда ответит их приложению быстро. Они с пеной у рта доказывают, что точки интеграции с elastic'ом защищать не нужно и можно делать синхронные вызовы к нему на входе в приложение. Они обижаются, когда их приложение падает. Недоумевают, почему разбираться с этим нужно вместе — ведь на тестовой все работало, а на машине у программера, вообще, все летало!!!
И только с кровью и потом приходит понимание. Поскольку кровь и пот не только их, но и мои, я задумался: а можно ли ещё на этапе грудного вскармливания подмешать этих знаний в молодые умы? Чтоб уж, если не писали сразу с учётом боевой нагрузки, то хотя бы чтоб быстро понимали, как исправлять приложение.
Как итог: новый спецкурс на Факультете информационных технологий в НГУ.
Два года, два потока.
Переписанная два раза программа, мысли переписать снова.
Трудности с лабораторными стендами. Пошёл через облака — отдал своих кровных 5 000 за время, пока настраивал, и две пары лабораторной работы в Azure.
Отказался от идеи показать для сравнения мир Microsoft с его release manager и desired state config.
С удивлением включил в программу вопросы непрерывной интеграции, а думал говорить только про поставку.
Мясо, нужно больше мяса, но нужны помощники, где взять опытных волонтеров со сбитыми костяшками.
Мучения с погружением в кух�
Доклад является обобщением моего опыт по работе с системами мониторинга серверных приложений в Qiwi.
Цель доклада:
- Получить общее представление о подходах к мониторингу серверных приложений
- Разобраться с популярными средствами для мониторинга серверных приложений
Оглавление:
- Мотивация
- Теория
---- Определение
---- Модель системы с точки зрения мониторинга
---- Классификация систем мониторинга
---- Уровни мониторинга
---- Инструменты мониторинга
- Практика
---- Системы мониторинга и сбора логов
---- Интерфейсы мониторинга
---- Инструменты мониторинга в JVM-based приложениях
Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)Ontico
Исторически сложилось так, что одни люди разрабатывают приложения (Dev), а другие эксплуатируют их в продакшне (Ops). И у последних есть немало проблем с тем, что невозможно понять, что происходит.
Причем это касается как собственных разработок, так и популярных open source решений.
Я расскажу, как устроена диагностика у некоторых популярных софтин:
- nginx
- postgresql
- mongodb
Мы попробуем разобраться, что там сделано хорошо, и чего не хватает для полного счастья.
Во второй части доклада мы поговорим про то, как нужно инструментировать собственное приложение для прозрачной работы в продакшне:
- что считать и зачем: ошибки, тайминги, разные состояния приложения,
- инструментарий: your_lang-metrics, your_lang-statsd-client, логи,
- как не перемудрить и не убить прод диагностикой.
Может показаться, что этот доклад про DevOps, но нет - про docker не будет ни слова :)
Xp days 2019 - Why startups need SRE practicesAlexey Andreev
In Prisma we process more than 500k photos per day on the server. I would like to present why SRE practices are needed in a small company, how to implement them without pain, why it pays off, and how we reduced the number of incidents.
Автоматизация нагрузочного тестирования в связке 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
Мониторинг в высоконагруженных (и не только) проектах: сравнительный анализ с...Anton Baranov
Выбор системы мониторинга - это практически holy-war-ная тема среди администраторов и разработчиков. Какая система лучше? Что удобнее? Какая система сможет выдержать большое количество статистики, а какая - лучше собрать и представить данные?
В своем докладе мы попробуем предельно непредвзято рассмотреть существующие решения и понять, что и когда можно использовать.
Прежде всего, мы постараемся сделать доклад не сравнением feature-листов, а рассмотреть особенности практического применения разных систем для конкретной задачи - для сайта, который не должен падать (а точнее - для возможности оперативно отреагировать на аварию, понять что к ней привело, и как можно ее исправить).
Доклад от Parallels:
Методики тестировния производительности database-centric приложений
Описание: При работе над сложными продуктами в database-centric приложениях изменения в коде и тем более в SQL запросах к базе данных могут приводить к неожиданным падениям производительности или же деградации производительности приложения с ростом размера базы данных. Поэтому важно уметь как можно быстрее отлавливать и исправлять причины таких деградаций.
Доклад о том, как устроен процесс мониторинга производительности продукта автоматизации хостинга и облачных сервисов Parallels Automation, для которого определяющим фактором является производительность базы данных.
Компания покажет, как анализирует планы исполнения SQL запросов внутри PostgreSQL, как проверяет насколько быстро и эффективно в целом работают SQL запросы, как определяет стратегию дальнейшей оптимизации.
Near-realtime аналитика событий в высоконагруженном проекте / Александр Краше...Ontico
Типовой задачей аналитики для любого проекта является получение ответов на вопросы: "сколько у нас регистраций за последний день?", "сколько сообщений было отправлено (товаров добавлено в корзину и пр.) в стране N, мужчинами/женщинами из приложения/сайта?". Поиском ответов на эти вопросы в компании обычно занимается отдел BI.
Инструментарием могут служить различные технологии: файлы Excel, старые-добрые РСУБД (MySQL, PosgtreSQL, MS SQL, Oracle etc.), специализированные аналитические базы данных (Vertica, Exasol, etc.), вычисления на Hadoop-кластере. Естественно, любое решение обладает своими достоинствами и недостатками — что-то ограничено по объему обрабатываемой информации, что-то — по скорости, что-то — по realtime.
Перед нами стояла задача сделать систему аналитики:
+ Горизонтально масштабируемой — уже не хватает ресурсов SQL.
+ Близкой к реальному времени — аналитические базы и Hadoop не дают нам желаемого эффекта.
+ Легкой в конфигурировании — любой новый отчет требует минимума затрат от разработчика.
Мы можем рассказать о том, как мы построили систему, которая прямо сейчас обрабатывает 200к событий в секунду, строит 12М метрик и может еще расти и расти.
Под капотом: Apache Spark для near-realtime обработки событий, Hadoop — как фундамент для масштабирования.
One-cloud — система управления дата-центром в Одноклассниках / Олег Анастасье...Ontico
HighLoad++ 2017
Зал «Калининград», 8 ноября, 15:00
Тезисы:
http://www.highload.ru/2017/abstracts/2964.html
Одноклассники состоят из более чем восьми тысяч железных серверов, расположенных в нескольких дата-центрах. Каждая из этих машин была специализированной под конкретную задачу - как для обеспечения изоляции отказов, так и для обеспечения автоматизированного управления инфраструктурой.
...
Масштабируя DNS / Артем Гавриченков (Qrator Labs)Ontico
HighLoad++ 2017
Зал «Калининград», 8 ноября, 16:00
Тезисы:
http://www.highload.ru/2017/abstracts/3032.html
Протокол DNS на семь лет старше, чем Всемирная паутина. Стандарты RFC 882 и 883, определяющие основную функциональность системы доменных имён, появились в конце 1983 года, а первая реализация последовала уже годом позже. Естественно, что у технологии столь старой и при этом по сей день активнейшим образом используемой просто не могли не накопиться особенности, неочевидные обыкновенным пользователям.
...
Создание BigData-платформы для ФГУП Почта России / Андрей Бащенко (Luxoft)Ontico
HighLoad++ 2017
Зал «Калининград», 8 ноября, 13:00
Тезисы:
http://www.highload.ru/2017/abstracts/3010.html
В этом докладе я расскажу, как BigData-платформа помогает трансформировать Почту России, как мы управляем построением и развитием платформы. Расскажу про найденные удачные решения, например, как разбиение на продукты с понятными SLA и интерфейсами между ними помогло нам сохранять управляемость с ростом масштабов проекта.
...
Готовим тестовое окружение, или сколько тестовых инстансов вам нужно / Алекса...Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 10:00
Тезисы:
http://www.highload.ru/2017/abstracts/2914.html
Казалось бы, что нужно для организации тестового окружения? Тестовая железка и копия боевого окружения - и тестовый сервер готов. Но как быть, когда проект сложный? А когда большой? А если нужно тестировать одновременно много версий? А если все это вместе?
Организация тестирования большого развивающегося проекта, где одновременно в разработке и тестировании около полусотни фич - достаточно непростая задача. Ситуация обычно осложняется тем, что иногда есть желание потрогать еще не полностью готовый функционал. В таких ситуациях часто возникает вопрос: "А куда это можно накатить и где покликать?"
...
Новые технологии репликации данных в PostgreSQL / Александр Алексеев (Postgre...Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 18:00
Тезисы:
http://www.highload.ru/2017/abstracts/2854.html
Из этого доклада вы узнаете о возможностях репликации и автофейловера PostgreSQL, в том числе о возможностях, ставших доступных в PostgreSQL 10.
Среди прочих, будет затронуты следующие темы:
* Виды репликации и решаемые с ее помощью проблемы.
* Настройка потоковой репликации.
* Настройка логической репликации.
* Настройка автофейловера / HA средствами Stolon и Consul.
После прослушивания доклада вы сможете самостоятельно настраивать репликацию и автофейловер PostgreSQL.
PostgreSQL Configuration for Humans / Alvaro Hernandez (OnGres)Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 17:00
Тезисы:
http://www.highload.ru/2017/abstracts/3096.html
PostgreSQL is the world’s most advanced open source database. Indeed! With around 270 configuration parameters in postgresql.conf, plus all the knobs in pg_hba.conf, it is definitely ADVANCED!
How many parameters do you tune? 1? 8? 32? Anyone ever tuned more than 64?
No tuning means below par performance. But how to start? Which parameters to tune? What are the appropriate values? Is there a tool --not just an editor like vim or emacs-- to help users manage the 700-line postgresql.conf file?
Join this talk to understand the performance advantages of appropriately tuning your postgresql.conf file, showcase a new free tool to make PostgreSQL configuration possible for HUMANS, and learn the best practices for tuning several relevant postgresql.conf parameters.
Inexpensive Datamasking for MySQL with ProxySQL — Data Anonymization for Deve...Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 16:00
Тезисы:
http://www.highload.ru/2017/abstracts/3115.html
During this session we will cover the last development in ProxySQL to support regular expressions (RE2 and PCRE) and how we can use this strong technique in correlation with ProxySQL's query rules to anonymize live data quickly and transparently. We will explain the mechanism and how to generate these rules quickly. We show live demo with all challenges we got from the Community and we finish the session by an interactive brainstorm testing queries from the audience.
Опыт разработки модуля межсетевого экранирования для MySQL / Олег Брославский...Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 15:00
Тезисы:
http://www.highload.ru/2017/abstracts/2957.html
Расскажем о нашем опыте разработки модуля межсетевого экрана для MySQL с использованием генератора парсеров ANTLR и языка Kotlin.
Подробно рассмотрим следующие вопросы:
— когда и почему целесообразно использовать ANTLR;
— особенности разработки ANTLR-грамматики для MySQL;
— сравнение производительности рантаймов для ANTLR в рамках задачи синтаксического анализа MySQL (C#, Java, Kotlin, Go, Python, PyPy, C++);
— вспомогательные DSL;
— микросервисная архитектура модуля экранирования SQL;
— полученные результаты.
ProxySQL Use Case Scenarios / Alkin Tezuysal (Percona)Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 14:00
Тезисы:
http://www.highload.ru/2017/abstracts/3114.html
ProxySQL aims to be the most powerful proxy in the MySQL ecosystem. It is protocol-aware and able to provide high availability (HA) and high performance with no changes in the application, using several built-in features and integration with clustering software. During this session we will quickly introduce its main features, so to better understand how it works. We will then describe multiple use case scenarios in which ProxySQL empowers large MySQL installations to provide HA with zero downtime, read/write split, query rewrite, sharding, query caching, and multiplexing using SSL across data centers.
MySQL Replication — Advanced Features / Петр Зайцев (Percona)Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 13:00
Тезисы:
http://www.highload.ru/2017/abstracts/2954.html
MySQL Replication is powerful and has added a lot of advanced features through the years. In this presentation we will look into replication technology in MySQL 5.7 and variants focusing on advanced features, what do they mean, when to use them and when not, Including.
When should you use STATEMENT, ROW or MIXED binary log format?
What is GTID in MySQL and MariaDB and why do you want to use them?
What is semi-sync replication and how is it different from lossless semi-sync?
...
Внутренний open-source. Как разрабатывать мобильное приложение большим количе...Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 12:00
Тезисы:
http://www.highload.ru/2017/abstracts/3120.html
Количество разработчиков мобильных приложений Сбербанк Онлайн с начала 2016 года выросло на порядок. Для того чтобы продолжать выпускать качественный продукт, мы кардинально перестраиваем процесс разработки.
Количество внутренних заказчиков тех или иных доработок в какой-то момент выросло настолько, что разработчики стали узким местом. Мы внедрили культуру разработки, которую можно условно назвать "внутренним open-source", сохранив за собой контроль над архитектурой и качеством проекта, но позволив разрабатывать новые фичи всем желающим.
...
Подробно о том, как Causal Consistency реализовано в MongoDB / Михаил Тюленев...Ontico
HighLoad++ 2017
Зал «Мумбай», 8 ноября, 18:00
Тезисы:
http://www.highload.ru/2017/abstracts/2836.html
При использовании Eventually Consistent распределенных баз данных нет гарантий, что чтение возвращает результаты последних изменений данных, если чтение и запись производятся на разных узлах. Это ограничивает пропускную способность системы. Поддержка свойства Causal Consistency снимает это ограничение, что позволяет улучшить масштабируемость, не требуя изменений в коде приложения.
...
Балансировка на скорости проводов. Без ASIC, без ограничений. Решения NFWare ...Ontico
HighLoad++ 2017
Зал «Мумбай», 8 ноября, 16:00
Тезисы:
http://www.highload.ru/2017/abstracts/2858.html
Аудитория Одноклассников превышает 73 миллиона человек в России, СНГ и странах дальнего зарубежья. При этом ОК.ru - первая социальная сеть по просмотрам видео в рунете и крупнейшая сервисная платформа.
Качественный и количественный рост DDoS-атак за последние годы превращает их в одну из первоочередных проблем для крупнейших интернет-ресурсов. В зависимости от вектора атаки “узким” местом становится та или иная часть инфраструктуры. В частности, при SYN-flood первый удар приходится на систему балансировки трафика. От ее производительности зависит успех в противостоянии атаке.
...
Перехват трафика — мифы и реальность / Евгений Усков (Qrator Labs)Ontico
HighLoad++ 2017
Зал «Мумбай», 8 ноября, 15:00
Тезисы:
http://www.highload.ru/2017/abstracts/3008.html
Никогда не было и вот снова случилось! Компания Google в результате перенаправления трафика сделала недостпуными в Японии несколько тысяч различных сервисов, большинство из которых никак не связано с самой компанией Google. Однако, подобные инциденты происходят с завидной регулярностью, вот только не всегда попадают в большие СМИ. У таких инцидентов могут быть разные причины, начиная от ошибок сетевых инженеров и заканчивая государственным регулированием.
...
И тогда наверняка вдруг запляшут облака! / Алексей Сушков (ПЕТЕР-СЕРВИС)Ontico
HighLoad++ 2017
Зал «Мумбай», 8 ноября, 14:00
Тезисы:
http://www.highload.ru/2017/abstracts/2925.html
Облака и виртуализация – современные тренды развития IT-технологий. Операторы связи строят свои TelcoClouds на стандартах NFV (Network Functions Virtualization) и SDN (Software-Defined Networking). В докладе начнем с основ виртуализации, далее разберемся, для чего используются NFV и SDN, потом полетим к облакам и вернемся на землю для решения практических задач!
...
Как мы заставили Druid работать в Одноклассниках / Юрий Невиницин (OK.RU)Ontico
HighLoad++ 2017
Зал «Мумбай», 8 ноября, 10:00
Тезисы:
http://www.highload.ru/2017/abstracts/3045.html
Как мы заставили Druid работать в Одноклассниках.
«Druid is a high-performance, column-oriented, distributed data store» http://druid.io.
Мы расскажем о том, как, внедрив Druid, мы справились с ситуацией, когда MSSQL-based система статистики на 50 терабайт стала:
- медленной: средняя скорость ответа была в разы меньше требуемой (и увеличилась в 20 раз);
- нестабильной: в час пик статистика отставала до получаса (теперь ничего не отстает);
- дорогой: изменилась политика лицензирования Microsoft, расходы на лицензии могли составить миллионы долларов.
...
Разгоняем ASP.NET Core / Илья Вербицкий (WebStoating s.r.o.)Ontico
HighLoad++ 2017
Зал «Рио-де-Жанейро», 8 ноября, 18:00
Тезисы:
http://www.highload.ru/2017/abstracts/2905.html
Прошло более года с того момента, как Microsoft выпустила первую версию своего нового фреймворка для разработки web-приложений ASP.NET Core, и с каждым днем он находит все больше поклонников. ASP.NET Core базируется на платформе .NET Core, кроссплатформенной версии платформы .NET c открытым исходным кодом. Теперь у С#-разработчиков появилась возможность использовать Mac в качестве среды разработки, и запускать приложения на Linux или внутри Docker-контейнеров.
...
100500 способов кэширования в Oracle Database или как достичь максимальной ск...Ontico
HighLoad++ 2017
Зал «Рио-де-Жанейро», 8 ноября, 14:00
Тезисы:
http://www.highload.ru/2017/abstracts/2913.html
Изначально будут раскрыты базовые причины, которые заставили появиться такой части механизма СУБД, как кэш результатов, и почему в ряде СУБД он есть или отсутствует.
Будут рассмотрены различные варианты кэширования результатов как sql-запросов, так и результатов хранимой в БД бизнес-логики. Произведено сравнение способов кэширования (программируемые вручную кэши, стандартный функционал) и даны рекомендации, когда и в каких случаях данные способы оптимальны, а порой опасны.
...
Apache Ignite Persistence: зачем Persistence для In-Memory, и как он работает...Ontico
HighLoad++ 2017
Зал «Рио-де-Жанейро», 8 ноября, 13:00
Тезисы:
http://www.highload.ru/2017/abstracts/2947.html
Apache Ignite — Open Source платформа для высокопроизводительной распределенной работы с большими данными с применением SQL или Java/.NET/C++ API. Ignite используют в самых разных отраслях. Сбербанк, ING, RingCentral, Microsoft, e-Therapeutics — все эти компании применяют решения на основе Ignite. Размеры кластеров разнятся от всего одного узла до нескольких сотен, узлы могут быть расположены в одном ЦОД-е или в нескольких геораспределенных.
...
HighLoad++ 2017
Зал «Рио-де-Жанейро», 8 ноября, 12:00
Тезисы:
http://www.highload.ru/2017/abstracts/3005.html
Когда мы говорим о нагруженных системах и базах данных с большим числом параллельных коннектов, особый интерес представляет практика эксплуатации и сопровождения таких проектов. В том числе инструменты и механизмы СУБД, которые могут быть использованы DBA и DevOps-инженерами для решения задач мониторинга жизнедеятельности базы данных и ранней диагностики возможных проблем.
...
2. План
• Взгляд на службу эксплуатации с точки зрения бизнеса
• Договариваемся про KPI
• Как жить с KPI
• Мониторинг: требования
• Мониторинг: метрики
• Мониторинг: триггеры
• Мониторинг: инцидент
3. План
• Взгляд на службу эксплуатации с точки зрения бизнеса
• Договариваемся про KPI
• Как жить с KPI
• Мониторинг: требования
• Мониторинг: метрики
• Мониторинг: триггеры
• Мониторинг: инцидент
4. Требования бизнеса
• Сайт должен работать
• Есть ответственный за работоспособность сайта
• Сайт должен работать быстро (говорят, это влияет на
разные важные коверсии :)
• Минимальные операционные и капитальные затраты
5. Сайт работает (было)
• Раз в минуту проходят основные пользовательские
сценарии
• Время ответа укладывается в нужные рамки
6. Сайт работает (сейчас)
• количество ошибок < 20/s
• 95-я персентить времени ответа < 4s (на самом деле
обычно ~500ms)
• внешние чеки на случай проблем с каналами
7. Сайт работает (хотим)
• количество ошибок < 20/s
• 95-я персентить времени ответа < 4s
• количество запросов не упало
• пользовательская активность на нужном уровне (в
нашем случае: активность по резюме, вакансиям,
откликам)
8. Кто отвечает за аптайм
• На практике: админы И разработчики
• На инциденты всегда реагируют админы
9. План
• Взгляд на службу эксплуатации с точки зрения бизнеса
• Договариваемся про KPI
• Как жить с KPI
• Мониторинг: требования
• Мониторинг: метрики
• Мониторинг: триггеры
• Мониторинг: инцидент
10. Попытка #1
• Нужно, чтобы админы просыпались по SMS, чинили
сайт, если не могут починить, будили кого-то из
девелоперов и чинили вместе
• Выходит, что KPI админов - это время реакции на
инцидент!
11. Попытка #1
“Время простоя за квартал 5 часов,
максимальные время реакции 2 минуты,
мы молодцы, сделали всё, что можем,
хотим премию!”
12. Попытка #2
• Админы должны отвечать за аптайм
• Но приложение сайта для админов black box
• Мы вложимся в QA, все проблемы включая
производительность будем ловить на стендах (утопия)
• Человек должен отвечать только за то, на что может
влиять!
13. Попытка #3
• Давайте поделим аптайм на зоны ответственности
• Админы будут отвечать только за свое
• Что делать со всем остальным решим потом
14. Формализуем
• любой выход за пределы SLA - считаем , что сайт лежит
(даже если что-то работает)
• на любой инцидент реагируют админы (дежурные или
все сразу)
• по каждому инциденту обязательный разбор, поиск
причины, классификация
• считаем суммарный downtime
• делим по зонам ответственности
15. Классы проблем
• Проблема с релизом (взорвалось или были ошибки при
деплое)
• Ошибка в приложении (утекло, тяжелый запрос убил
базу, не отработал таймаут до удаленного сервиса, итд)
• Железо + сеть + каналы + ДЦ
• Ошибка админа
• Проблемы с БД
• Плановый downtime (иногда нужно)
• Ошибка мониторинга (чтобы не удалять инциденты
никогда)
16. Зона ответственности СЭ
• Проблема с релизом
• Ошибка в приложении
• Железо + сеть + каналы + ДЦ
• Ошибка админа
• Проблемы с БД
• Плановый downtime
• Ошибка мониторинга
17. Премия = f(аптайм)
Простой за квартал Аптайм, % % оклада в премию
<= 12 минут >= 99.99 120
<= 40 минут >= 99.97 100
<= 1 часа >= 99.95 80
<= 2 часов >= 99.90 60
<= 3 часов >= 99.85 50
> 3 часов < 99.85 0
18. План
• Взгляд на службу эксплуатации с точки зрения бизнеса
• Договариваемся про KPI
• Как жить с KPI
• Мониторинг: требования
• Мониторинг: метрики
• Мониторинг: триггеры
• Мониторинг: инцидент
19. Первый квартал c KPI
• Оказывается, нужно работать :)
• Надо привыкать думать над каждым действием
• Многие операции перевели в разряд “рискованных”, их
выполнять стали в часы минимальной нагрузки,
объявляя плановый downtime
• Начали проводить учения, тестировать сценарии
деградации системы (выключать rabbitmq, memcached,
свои сервисы, без которых все должно жить)
20. Первый квартал c KPI
• Мониторинг начал ловить очень много всего нового
• Logrotate, разные cron’ы давали 500ки, на которые
раньше не реагировали
• Начали вдумчиво настраивать таймауты, ретраи итд
• Где-то пересмотрели архитектуру и запланировали
переделку
• Самое сложное: выяснять причины ВСЕХ инцидентов
• Перестал устраивать существующий мониторинг
21. План
• Взгляд на службу эксплуатации с точки зрения бизнеса
• Договариваемся про KPI
• Как жить с KPI
• Мониторинг: требования
• Мониторинг: метрики
• Мониторинг: триггеры
• Мониторинг: инцидент
22. Требования
• Узнать, что есть проблема
• Видеть, что происходит: насколько проблема масштабна,
какие компоненты затронуты
• Иметь достаточно метрик, чтобы копаться “задним
числом”
• Ускорять выявление проблем, все важное из логов
вынести на графики
• Простота расширения
23. Что у нас было
• Nagios + centreon (+ патчи)
• Nagios + своя штука для графиков + свой poller SNMP
• У разработчиков всегда были свои cacti, graphite итд
• Свое решение - monik (был выделенный разработчик
мониторинга)
24. Проблемы
• У нас нет цели разрабатывать мониторинг
• Зато есть много другой работы
• Всё, что мы разрабатывали устаревает, появляются
новые требования
• Взять и попробовать что-то новое – тоже время
• В opensource практически нет full-stack решений, есть
отдельно хранилища, собиралки, алертилки,
дашбордилки
• Практически всё нужно доделывать под себя
25. SaaS мониторинг
• Не нужно писать код
• У нас нет супер-секретных метрик
• Специализированная компания: они могут себе
позволить тесты, мониторинг мониторинга,
отказоустойчивость (у нас всегда мониторинг жил на 1
сервере)
• Мы “большой” клиент, можем договориться о доработках
под нас
• Ценник сравним с выделенным разработчиком у нас
• Мы работаем с okmeter.io
26. План
• Взгляд на службу эксплуатации с точки зрения бизнеса
• Договариваемся про KPI
• Как жить с KPI
• Мониторинг: требования
• Мониторинг: метрики
• Мониторинг: триггеры
• Мониторинг: инцидент
27. Проблемы
• Как правило мониторингом покрывают только самые
критичные подсистемы
• Мы пробовали включать покрытие мониторингом в
процедуру выпуска новых сервисов – не работает
• Часто снимают не всё (где-то забыли включить jmx, где-
то пустить мониторинг в postgresql)
• Инфраструктура меняется: запускаются новые jvm, pg,
nginx, haproxy итд
• Метрики сильно обобщены, видно, что есть проблема, но
не видно, где конкретно
28. Подход
• Все что можно снять без конфига, снимаем всегда и со
всех машин
• Если агенту нужны права или донастройка, это алерт в
мониторинге
• Метрики максимально детальные в пределах разумного,
агрегаты можно сделать на лету
• Ждем: алерт, если поймали TCP соединения с хостов, на
котором не стоит агент
30. Про каждый процесс
• CPU time (user/system)
• Memory (RSS)
• Disk I/O (read/write bytes, ops)
• Swap Usage -> Swap Rate
• Thread count
• Open FDs count
• Open files limit
31. Про каждый TCP LISTEN
• Если remote IP из той же сети – все метрики для каждого
IP отдельно
• Количество соединений в разных состояниях
(ESTABLISHED, TIME_WAIT, …)
• 95я персентиль TCP RTT (с учетом SACK не является
реальным RTT в сети, но для сравнения было-стало
работает хорошо)
• Количество соединений в backlog и лимит
• Похожие метрики для исходящих TCP соединений
32. Nginx
• Если есть работающий процесс nginx, находится и
парсится конфиг
• Парсится log_format и access_log
• Если лог нельзя распарсить – алерт
• Если в логе нет $request_time, $upstream_response_time -
алерт
• RPS в разрезе status, top urls, cache_status, method
• Персентили и гистограммы для таймингов в тех же
разрезах
33. Jvm
• Если есть работающий процесс jvm, парсятся аргументы
запуска
• Определяем параметры JMX, если выключено – алерт
• Снимаем heap, GC, memory pools, threads
• Если есть mbeans cassandra – снимаем детальные
метрики
• Так же планируем снимать метрики jetty, grizzly, c3p0,
hibernate,…
34. Postgresql
• Пробуем с predefined паролем
• Если не пускает - алерт с просьбой настроить пароль или
загрантить
• Если не настроено pg_stat_statements - алерт с просьбой
включить
• Если не хватает прав – алерт
• Снимаем всё про top запросов/таблиц/индексов, bgwriter,
текущие соединения, локи итд (pg_stat_*)
38. Метрики из SQL
plugin: postgresql_query
config:
…
query: SELECT count(*) as value, COALESCE(old_value,
'NULL') as old_status, new_value new_status from
resume_field_change_history where change_date >=
now() - INTERVAL '60 seconds' and change_date <
now() and field_name='status' group by old_value,
new_value
metric_name: resume.changes.count
40. План
• Взгляд на службу эксплуатации с точки зрения бизнеса
• Договариваемся про KPI
• Как жить с KPI
• Мониторинг: требования
• Мониторинг: метрики
• Мониторинг: триггеры
• Мониторинг: инцидент
41. Принципы
• Проактивного мониторинга не существует (disk usage
если только)
• В нагруженной системе всё меняется за доли секунды,
понять последовательность событий нереально даже при
секундном разрешении (как правило достаточно
минутного)
• зависимости между алертами хорошо сделать
невозможно
• в нормальном состоянии не должно быть активных
алертов
42. Принципы
• Critical событие – это то, на что нужно срочно
среагировать и починить (CPU usage > 90% не нужно
срочно чинить)
• У нас 3 critical триггера (HTTP-5xx, Q95, ext http check)
• Все остальные Warning, Info – всего лишь подсказки, у
большинства нет нотификаций вообще
• Лучше зажечь много warning-ов и выбрать глазами
причину проблемы, чем пытаться автоматически
определить, где причина, а где следствие
43. Принципы
• Чтобы после SMS не ждать recovery, а сразу чинить - есть
отложенная нотификация (notify after 2 min)
• Идеально - увидеть проблему в списке алертов
• Если нет, нужно смотреть на дашборды, где нужно
глазами исключать возможные причины
• В следующий раз такая же проблема должна быть в
списке алертов
44. Принципы
• Если есть алерт, который вы не собираетесь чинить -
выключайте
• Если есть постоянный поток писем от мониторинга, он
заруливается в отдельную папку в почте и не читается,
проще выключить
• Если вас не интересует CPU usage на hadoop машине –
настройте исключение
45. Наши триггеры
• Про все внутренние сервисы – warning по http-5xx+499,
q95
• Про все процессы: open files usage > 90%
• Про все LISTEN сокеты: TCP ack backlog usage > 90%
• Про диски: usage > 95%, IO usage > 99% в течении 10
минут
• Про raid: status, bbu, operations (если идет проверка
mdraid может просесть i/o, если на железке идет
профилактика батарейки – может отключиться write
cache)
46. Наши триггеры
• Живы все nginx, haproxy, … – там где они были хоть раз
запущены (если загорается лишний – закрываем руками)
• Давно нет данных от агента на каком-то сервере
• Нет данных от JVM/pg/….
• Jvm heap usage > 99% на протяжении 2 минут (ловим
OOM, не везде настроена автоперезапускалка)
• Time offset > 10 seconds
• В важных очередях > N сообщений
47. План
• Взгляд на службу эксплуатации с точки зрения бизнеса
• Договариваемся про KPI
• Как жить с KPI
• Мониторинг: требования
• Мониторинг: метрики
• Мониторинг: триггеры
• Мониторинг: инцидент
48. Сайт лёг - инцидент
• SMS/еmail уведомление
• Мониторинг создает задачу в JIRA (начало инцидента)
• Админ реагирует, подтверждает это переводом задачи в
статус “Проблемой занимаются” (любой сотрудник в
компании это видит)
49. Чиним
• Смотрим текущие алерты
• Синхронизируемся в чате
• Основной график – “Светофор” + рядом ~10 графиков
52. После восстановления
• Починили, мониторинг меняет статус задачи на
“Инцидент исчерпан”
• Поиск причины, общение в JIRA
• Заполняем класс проблемы в задаче, перевод в статус
“Закрыто”
• Если по результатам нужна разработка, есть
продолжение workflow
54. По результатам
• Человеческая ошибка: обсудить, почему
произошло, как избежать (может
автоматизировать что-то)
• Проблемы с релизом: доработка автотестов,
процедуры выкладки
• Проблема в приложении: задача в разработку
• Железо/сеть/каналы/ДЦ: задача для админов
(починить/уменьшить вероятность/обеспечить
самовосстановление/уменьшить downtime в
будущем)
55. По результатам
• Добавить метрик в мониторинг?
• Детализировать метрики ?
• Новый триггер ?
• Новый “говорящий” график на дашборд?