Многие веб-студии не имеют в своем штате системных администраторов. И зачастую узнают о проблемах с запущенными проектами уже после того, как они случились.
В докладе рассмотрим:
- Явные и не очень потери на медленном / недоступном сайте.
- Общие принципы внедрения систем real-time мониторинга.
- Мониторинг нетипичных характеристик (наличие бэкапов, делегирование домена и т.п.).
- Автоматизацию типовых реакций на алерты.
- Зачем нужна аналитика в мониторинге (пробуем предугадать проблемы до того, как они случатся).
- Инструменты и общие подходы быстрого поиска "узких" мест.
4. О чем будем говорить
Явные и не очень потери на медленном / недоступном сайте.
Спасет ли SLA провайдера?
Общие принципы внедрения систем real-time мониторинга.
Мониторинг нетипичных характеристик (наличие бэкапов, делегирование
домена и т.п.).
Автоматизация типовых реакций на алерты.
Зачем нужна аналитика в мониторинге (пробуем предугадать проблемы до
того, как они случатся).
Инструменты и общие подходы быстрого поиска "узких" мест.
Немного про client side.
5. Что теряет медленный сайт?
Прямые потери заказов
Финансовые потери во время
рекламных компаний – вы платите за
«холостые» клики
Стоимость контекстной рекламы
6. Значение поиска невозможно преуменьшить
60% трафика интернет-магазина – поиск
(конверсия этого трафика около 0.5 %)
40% остального трафика – средняя
конверсия 1.1% (исследование
Webprofiters)
Несложная математика: около 40%
заказов – из поиска
7. Медленный сайт опускается в результатах поиска
Факторы ранжирования
время отклика сайта
скорость загрузки страницы
возвраты на SERP и переходы на
другие сайты
количество просмотренных
страниц
общее время сессии
9. Агрегаторы тоже не любят медленные сайты
Яндекс.Маркет ежедневно
отключает на полтора часа более
1000 магазинов из-за таймаутов
10. Если ваш сайт выглядит как живой...
убедитесь, что он еще и здоровый.
11. Спасет ли SLA провайдера?
Ни один SLA не покроет вашу упущенную выгоду (прибыль),
только расходы на хостинг.
Наиболее часто встречается гарантия 99.9% доступности в SLA.
Это – около 9 часов простоя в год.
Небольшие слоты (до 5 минут) никто не считает.
Ребут сервера, скорее всего, не попадает под SLA. А если это
база данных, она может стартовать несколько часов после
аварийного завершения.
12. «Хитрости» SLA
Web 1
Elastic Load Balancing
Web N
…
CloudWatch
+
AutoScaling
Web 1 Web 2 Web N
…
CloudWatch
+
AutoScaling
S3
control cache: memcached
mysqld
mysqld
mysqld
mysqld
mysqld
mysqld
master-master replication
master-master replication
master-master replication
mysqld
mysqld
mysqld
mysqld
mysqld
mysqld
mysqld
mysqld
mysqld
mysqld
mysqld
mysqld
control cache: memcached
control cache: memcached
control cache: memcached
control cache: memcached
control cache: memcached
Web 2
$25 / месяц
$5000 / месяц
13. Недоступность сайта…
Вышел из строя диск
Кончилось место на диске
Не хватило ресурсов CPU
Не хватило памяти
Не хватило производительности диска
Не хватило канала
Вышла из строя оперативная память
Вышла из строя материнская плата
Сгорел блок питания
DDoS
Взлом - целевая атака
Взлом - нецелевая атака
Разделегирование домена
Закончился срок действия SSL сертификата
Выход из строя маршрутизатора провайдера
Авария на канале провайдера
Потери пакетов у upstream провайдера
Авария с электропитанием
Выход из строя вентиляции - перегрев
Ошибки настройки сети
Ошибки настройки веб-сервера
Ошибки настройки базы данных
Ошибка разработки
Преднамеренное вредительство разработчиком
Ошибки на файловой системе
Попадание в реестр Роскомнадзора
Ошибки внешних систем (например, платежная система в интернет-магазине)
Ошибка персонала хостера
Ошибка персонала upstream оператора
Недоступность и авария DNS
Удаленность хостинга от клиентов
Ошибки в системном ПО (segfault)
Ошибки файловой системы после аварийной перезагрузки
Ошибки БД после аварийной перезагрузки
Сброс несохраненных настроек после перезагрузки
Неоплата хостинга
Неоплата лицензий на ПО
Несовместимость с клиентским ПО
Отсутствие ресурсов для масштабирования (не хватило серверов)
Неготовность приложения к масштабированию
Отсутствие кэширования
Взаимодействие с внешними системами (нагрузка импортами)
Нагрузка во время создания бэкапа
Ошибки после установки обновлений
Ошибочная блокировка браузерами (вирусы)
Отсутствие обработки пользовательских данных
Авария на уровне датацентра (пожар, наводнение)
Отсутствие бэкапа для восстановления
«Битый» бэкап (не было учений по восстановлению)
Несвоевременная реакция сисадмина
16. Как при этом не взорвать мозг?
Доступность «Битрикс24» и
облачных сервисов
«1С-Битрикс» - 99.99%
8200+ проверок в трех
регионах в системе
мониторинга
17. Организация системы мониторинга
Лучше – стандартные решения (Nagios, Zabbix и т.п.), а не
самописные.
Дежурная смена и/или мгновенные уведомления.
Мониторить – всё.
Но – аккуратно. Тысячи уведомлений будут бесполезны.
Автоматизация типовых реакций.
Мониторить систему мониторинга.
В идеальном мире – распределенная система мониторинга.
18. Мониторинг «железа»
Рейды
S.M.A.R.T. – диск, возможно, скоро «умрет»
Утилиты вендора – внутренние аппаратные тесты
Периодическое тестирование железа в оффлайне
Имеем «запчасти» (блоки питания, вентиляторы …) или знаем
где их быстро найти
23. Мониторинг нетипичных характеристик
Наличие бэкапов
Срок делегирования доменов
Баланс у провайдера смс-уведомлений
Отсутствие в реестре Роскомнадзора
Срок действия SSL сертификатов
24. SSL сертификаты
Часто по HTTPS работает не весь сайт, а отдельные разделы
Проэкспайрившийся SSL сертификат можно заметить не сразу
При этом закрыты наиболее критичные разделы (корзина,
авторизация и т.п.)
Теряем позиции в поиске (говорят, Google любит HTTPS)
27. Мониторинг веб-приложения, скрипта в кроне и т.п.
Лог работы скрипта (>) – обновился за N часов
Лог ошибок работы скрипта (2>) – должен быть пуст
28. Уведомления – как у нас
Cкрипт, опрашивающий страницу «Problems»
Шлем «дайджест» проблем, а не по одному
сообщению на каждое событие
Несколько уровней критичности событий
Разные списки адресатов на разные события
Повтор (через 15 минут, через 2 часа), чтобы не
«потерять» уведомление
ОК – если все стало хорошо
29. Автоматизация типовых реакций
Рост / падение LA – автоматическое масштабирование вверх / вниз
Автоматический рестарт «сбойных» сервисов
Автоматическое «удаление» проблемных машин
Автоматическое восстановление репликации
Автоматическое переключение трафика в случае аварии на уровне целого ДЦ
30. event handler
# LA on the server
define service{
use local-service
host_name ec2-54-227-28-75.compute-1.amazonaws.com
service_description Current Load
check_command check_nrpe_1arg!check_load!
event_handler restart_phpfpms
}
define command{
command_name restart_phpfpms
command_line /usr/lib64/nagios/plugins/check_nrpe -H $HOSTADDRESS$ -c restart_phpfpm
}
31. Если нет админа… А также для подстраховки
Внешние системы:
http://host-tracker.com/
Яндекс.Метрика
И т.д.
* * * * * user /opt/manage/bin/http_sms.sh
• Зачастую можно найти бесплатные варианты.
• Вы быстро узнаете об отказах, но не будете знать, где они произошли и
почему.
• Вы подстрахуете себя от сбоя мониторинга.
32. Аналитика
Видим, что было
Предвидим, что будет
Улавливаем тренды
Планируем мощности железа
Сравниваем настройки софта
• Веб-система перестает быть черным ящиком, видно ее развитие с
течением времени
34. Аналитика - MySQL
Следите за числом запросов и коннектов в БД, количеством
медленных запросов, прочими характеристиками
35. Если оставить все «по умолчанию»?
По умолчанию MaxClients в Apache 2.x – 256
Если PHP может занять 64 Мб (на самом деле –
см. memory_limit в php.ini) – весь веб-сервер
может занять 16 Гб RAM
256 потенциальных коннектов к MySQL
Память для одного коннекта: read_buffer_size +
read_rnd_buffer_size + sort_buffer_size +
thread_stack + join_buffer_size
• swap, OOM, деградация производительности всей
системы
44. Поиск узких мест и действия
Нужно быстро понять – где и как починить
Смотрим срабатывание тестов – часто единственный источник информации
Смотрим уведомления от системы мониторинга
Смотрим логи. Держим заготовленные скипты-парсеры логов на поиск ошибок.
Смотрим графики
Если получается, запускаем инструменты поиска узких мест
45. Не включил логи?
Статья «уголовного кодекса» веб-
разработчиков и системных
администраторов
Плохо:
display_errors = On
Хорошо:
error.log
access.log
49. Аналитика – со стороны пользователя
Мало знать «среднюю температуру по больнице» и мониторить
только главную страницу сайта
Гистограммы распределения времени хитов, памяти, кодов
ответа и т.п.
50. Поиск «узких» мест
Apache /server-status
Включенные логи медленных запросов php-fpm, nginx, apache, MySQL
52. Инструменты поиска узких мест
Если никаких других инструментов нет
Или надо срочно локализовать проблему на «бою»
Можно просто перезапустить Apache / nginx / PHP-FPM
Но… Вы не найдете суть проблемы, и она повторится
Старые добрые утилиты unix
lsof
strace
gdb
grep, awk, sort, uniq и т.д.
53. Определение процесса
lsof | grep php_sessions
[…]
httpd 29684 bitrix 56u REG 0,19 0 5217392126
/tmp/php_sessions/sess_3m8ulspjvousm6nndmle3ul8s5
httpd 31320 bitrix 57uW REG 0,19 0 5217392033
/tmp/php_sessions/sess_bvgb0oaeq6ilqq8ooneo1j7e61
[…]
top
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
24632 bitrix 16 0 826m 128m 99m S 99.9 0.4 0:40.13 httpd
4006 bitrix 15 0 817m 86m 63m R 9.9 0.3 0:05.61 httpd
24903 bitrix 16 0 823m 121m 94m R 7.9 0.4 0:42.52 httpd
58. Аналитика - MySQL
Одиночные медленные запросы отлавливаются просто.
Сложнее мониторить общее состояние системы с большим
количеством относительно быстрых запросов.
59. Приложение всегда работает в условиях ограниченных ресурсов
Постоянный feedback в две стороны: админам и разработчикам
– в автоматическом и полуавтоматическом режиме
60. Сайт всегда должен быть доступен
для посетителей
Вы должны оперативно узнавать о
любых проблемах и иметь план их
решения
У вас должны быть отлажены
сценарии поиска «узких» мест
Аналитические данные позволят
прогнозировать, где могут
появиться «узкие» места