Поддержка высоконагруженного проекта: мониторинг,...
-
Upload
ontico -
Category
Engineering
-
view
7.760 -
download
1
Transcript of Поддержка высоконагруженного проекта: мониторинг,...
Евгений Потаповгенеральный директор компании ITSumma
Круглоcуточное удаленное администрирование серверов и техническая поддержка сайтов
100 миллионов уникальных посетителей в сутки
Штат – 50 человек
Более тысячи серверов на поддержке
Содержание• Мониторинг и его специфика
в высоконагруженном проекте• Организация резервирования
и резервного копирования• Организация обслуживания и
поддержки.
Цели мониторинга
• Мониторинг как система оповещения• Мониторинг как средство анализа• Мониторинг как система принятия
решений
Мониторинг как система оповещения
• Оповещение о проблемах на сервере• Оповещение о проблемах, связанных с
логикой приложения• Оповещение о проблемах, связанных с
бизнес-показателями
Мониторинг как система оповещения
Требования к системе оповещения:1. независимость от самого проекта (если
он упадет система должна продолжать работать)
2. максимально быстрое оповещение о достижении критических показателей
3. надежность оповещений о достижении критических показателей
Мониторинг как система оповещения
Три уровня оповещений:1. Проблемы на сервере (проблемы на
серверном железе/серверном ПО)2. Проблемы на уровне приложения
(производительность подсистем, число обращений к подсистемам)
3. Проблемы на уровне бизнес-логики (метрики бизнеса)
Оповещения о проблемах на сервереПроблемы на сервере
1. Статистика по нагрузке на CPU(Оповещения на рост Load Average>числа ядер, CPU idle ниже определенного порога)
2. Статистика по нагрузке на дисковую подсистему (увеличение времени avio, рост дисковых операций iops, рост «busy» диска)
3. Использование оперативной памяти/swap(снижение cached+buffers+free ниже порога, рост использования swap (swap in / swap out)
Оповещения о проблемах на сервере
4. Статистика по серверному софту(падение / всплески числа запросов на веб-сервер, статистика сервера БД, итд)
5. Внешний мониторинг ответа сервисов (время ответа страниц, код ответа страниц, размер ответа страниц, ошибки рендеринга в CasperJS, время рендеринга)
Оповещения о проблемах на сервереПроблемы на уровне приложения
1. Число ошибок уровня приложения (Рост числа ошибок больше заданного, рост/падение числа событий в целом)
2. Число обращений к подсистемам/ «узлам» приложения(Рост/падение таких обращение)
3. Время взаимодействия приложения с внешними сервисами(рост времени запроса к внешним сервисам, корректность ответов внешних сервисов на уровне приложения)
Оповещения о проблемах на сервереПроблемы на уровне бизнес-логики
1. Бизнес данные на «последней миле» технологического стека(Bablo per minute, время с последних действий пользователей, падение числа пользователей)
2. Эмуляция пользовательской логики приложения(оповещения не невозможность выполнить пользовательские действия, оповещения на увеличение времени ответа пользовательских действий)
Оповещения о проблемах на сервере
4. Статистика по серверному софту(падение / всплески числа запросов на веб-сервер, статистика сервера БД, итд)
5. Внешний мониторинг ответа сервисов (время ответа страниц, код ответа страниц, размер ответа страниц, ошибки рендеринга в CasperJS, время рендеринга)
Оповещения о проблемах на сервере
Устанавливать оповещения следует не на фатальные состояния (не осталось места на диске, CPU загружен на 95%), а на «контрольные точки» проекта.
1. На запуске – проект не загружен. После первоначального «шторма», рост будет плавный.
2. Ключевая метрика роста/проблем - достижение контрольных точек (исчерпали 25% ресурсов, исчерпали 50% ресурсов итд).
3. В сложных решениях нужно иметь запас времени для действий связанных с оптимизацией или масштабированием.
Мониторинг как система анализа
Цель – понять причину происходящих проблем
Требования:1. возможность хранить максимально
возможное количество данных в максимально возможной детализации
2. возможность быстро выбрать эти данные за нужный период
3. возможность быстро отобразить выбранные данные и детально их изучить
Мониторинг как система анализа
Необходимая функциональность:
1. Сравнение однотипных данных по разным серверам (на каком сервере происходят отклонения от нормы)
2. Сравнение текущих данных с историческими данными (день назад, неделя назад, месяц назад)(насколько текущие показатели отклоняются от нормы)
3. Быстрая выборка большого диапазона исторических данных (изменение данных в динамике)
Мониторинг как система анализа
Дополнительно:
Сложная агрегация метрик (скользящая средняя, перцентиль, группировка по минимуму, максимум итд).
Мониторинг как система принятия решенийОрганизационный подход:
1. Данные в мониторинге следует использовать не только для анализа причин текущих аварий, но и для понимания что делать дальше
2. Регулярный обзор всех ключевых метрик с целью анализа новых «контрольных точек» («через 6 месяцев мы съедим половину ресурсов»)
3. Данные в мониторинге, как средство избежать повторяющихся ошибок
Мониторинг
Доступные решения:
1. Новый проект на старте: SaaS (Serverdensity, NewRelic, DataDog)
2. Сложный сбор данных, развитие семейство Graphite
3. Извращение и много ресурсов: свои системы
Резервное копирование
Ключевые проблемы:
1. Процесс снятия резервной копии (нагрузка на сервер)
2. Регулярность снятия резервной копии (объем данных, время, необходимое на резервирование)
3. Время восстановления из резервной копии
Резервное копирование
Процесс снятия резервной копии:
1. Сам по себе процесс снятия резервной копии – тяжелая процедура
2. Резервные копии - создавать с резервных машин
3. Понимание того, что нужно резервировать: UGC – база легкая, а статика может весить гигабайты. База без картинок людям не нужна.
4. Бэкап без регулярной процедуры восстановления – не бэкап.
Резервное копированиеРезервные копии - БД:
1. Slave-сервер, как резервная копия на случай аварии (защита от аварий с железом но не от человеческого фактора)
2. Slave-сервер с искусственной задержкой, как резервная копия на случай человеческого фактора
3. Hot-backup-службы – для регулярного внешнего резервного копирования.
Резервное копированиеРезервные копии – БД – хранение:
1. Минимум одна копия – в пределах внутреннего канала площадки (оперативное восстановление при повреждении данных)
2. Минимум одна копия – на внешней площадке (восстановление при глобальной аварии).
Резервное копированиеРезервная копия - контент:
1. Снэпшоты/Rsync (при небольшом количестве изменяемых данных в пределах интервала резервного копирования).
2. Дублирование статики на резервный сервер непосредственно сервером.
Резервное копированиеРезервные копии – процедуры
Регулярная регламентированная процедура восстановления проекта из резервной копииКлючевые показатели:
1. Оценка времени, занятого на восстановление из резервной копии
2. Оценка «отката во времени» на проекте, после восстановление из резервной копии
3. Оценка целостности восстановленной резервной копии
Резервирование
Ключевые вопросы:
1. Выбор площадки для резервирования2. Мощности для резервирования и
бюджеты3. Процедуры переключения на резерв
Резервирование
Выбор площадки для резервирования
1. Резервная площадка не должна быть связана с текущим датацентром (часто видим резервные сервера в той же стойке даже на крупных проектах)
2. Существует риск того, что резервная площадка после переключения останется основной надолго – она не должна быть слишком плохой по качеству или слишком дорогой по стоимости.
Резервирование
Мощности для резервированияНа запуске проекта – простаивающие мощности – лишние затраты.
1. Проект можно разделить на два ДЦ, и переходить на один в случае аварии (тогда возможны тормоза)
2. Гибридное облако – резерв находится в минимальной конфигурации в облаках, достаточной только для того чтобы принимать репликацию. В случае аварии – масштабирование и переключение.
Резервирование
Резервирование – процедуры
Регулярная регламентированная процедура переключения на резерв (все ненавидят)
1. Оценка времени, занятого на переключение2. Оценка целостности данных после
переключения на резерв3. Очень не любит бизнес – риск простоя (но
еще больший риск – если не делать)
Резервирование и резервное копирование
1. Slave – это не бэкап2. Бэкап в том же ДЦ – это не бэкап3. Резерв в том же ДЦ – это не резерв4. Бэкап, который не восстанавливали –
это не бэкап5. Бэкап без статики – это не бэкап6. Если не хватает места – это не отмазка7. Резерв без переключения – это почти не
резерв8. «Я решу про бэкап на днях» – первый
(из двух) шагов к потерянным данным.
Поддержка
Все это – не работает без команды
1. Понимание внутренностей продукта, способность локализовать проблему
2. Вовлеченность в команду (ночные алерты - это боль)
3. Стрессоустойчивость (ночные алерты – это боль)
4. Чаще всего – на старте – разработчики с задатками админа.
5. Должны быть экстраверты (по крайней мере – те кто будут объяснять бизнесу что случилось)
Поддержка
Все это – не работает без организации
1. Исправленная авария, шаги по исправлению которой не документированы - не исправлена
2. Любой инцидент без алертов может случится один раз. Это должен быть единственный раз.
3. Любые повторяющиеся процедуры, повторяющиеся алерты должны быть описаны
4. Минимум бюрократии на этапе борьбы с аварией, формализация – на этапе postmortem-а.
Поддержка
Режим работы
1. Старт – SMS-ки ключевым людям, телефонные звонки
2. Дежурства: двое через двое по 12 часов – отсутствует жизнь.
3. Категорически не должно быть одного человека на sms-ках. Минимум двое (лучше трое)
4. У каждого из людей on-call должно быть минимум 3 телефона критических людей для оповещения
Поддержка
Дополнительные метрики
1. Alerts per hour – для общего понимания увеличения беды.
2. Время проведенное на серверах (рост времени – рост проблем).
3. Запись SSH-сессий как способ просто восстановить сделанные во время аварий операции.
4. У каждого из людей on-call должно быть минимум 3 телефона критических людей для оповещения
Поддержка
Еще про работу
1. Bus factor – если несколько ключевых людей летят на одном рейсе – серверы обязательно упадут
2. On-call с SMS-ками – всегда минимум два способа связи при себе.
3. Идеально: редирект на другого on-call человека при недоступности мобильного телефона.
4. Жизнь on-call людей тяжела – любите и цените их
Вместо выводов
1. Просто сделать и запустить – не работает (человек тоже болеет)
2. Замониторить и больше никогда не упадет – не работает (диспансеризация – тот же мониторинг)
3. Зарезервировать и не проверять – не работает (каждый второй – не проверяет, 9 из 10 не проверяет полноценно)
4. Зарезервировать, замониторить но не организовать службу поддержки – не работает (программисты будут смотреть как «все упало» и не знать что делать)
Евгений Потапов
http://[email protected]://facebook.com/eapotapov