#bitrix

Цели
Научиться видеть сложную веб-систему целиком в простом ракурсе
Понять, почему веб-проекты после запуска нередко становятся сложными и слабоуправляемыми
Рассмотреть несколько инструментов, метрик и цифр, научиться их трактовать. Понять принцип отбора метрик для мониторинга и анализа
Выстроить бизнес-процесс управления, обеспечивающий порядок и прозрачность веб-проекта

Запуск веб-проекта
Проектирование. Не всегда достаточно времени. Требования меняются до самого конца.
Сжатые сроки на развертывание веб-проекта на хостинге
Мало кто проводит и умеет делать нагрузочное тестирование
Система запускается «как есть» и по инерции может «поработать» год-два «без вмешательства»
Не все задумываются над организацией мониторинга, резервного копирования, обновления софта на серверах и т.п.

Вроде работает…
Веб-проект «вроде работает»
В случае торможения пинают сисадмина перезапустить apache или MySQL ☺
Программисты что-то дописывают «на боевых серверах» - так быстрее
Менеджеры проекта меняются
Кто отвечает за порядок, прозрачность и мониторинг??
Веб-проект начинает разрушаться и деградировать изнутри…

Как должно быть
Сервера «стерильны», код выкладывается через систему контроля версий
Доступ на сервера строго ограничен кругом квалифицированных администраторов
ПО на серверах постоянно обновляется, «дырки» закрываются, предварительно тестируется всё
Вся система «покрыта датчиками» и мониторится. SMS. Хорошо, если есть дежурные 24/7.
Перед попаданием «на бой» код попадает на testing, stage сервера для функционального и нагрузочного тестирования

Мифы о стабильности
Миф 1. Весь веб-проект покрыть unit и другими тестами на 100%
Миф 2. Проводится тщательное нагрузочное тестирование на реальных данных
Миф 3. При изменении настроек/обновлении серверов все тщательно тестируется
Миф 4. Если установлены все патчи безопасности, система безопасна.
Миф 5. Мы знаем, что может случиться, и ждем этого.

Взять контроль над веб-системой
Прозрачное поле боя (nagios)
Дисциплина и регламент
Анализ трендов (munin)

Мониторинг «железа»
Рейды
S.M.A.R.T. – диск возможно скоро «умрет»
Утилиты вендора – внутренние аппаратные тесты
Имеем «запчасти» (блоки питания, вентиляторы …) или знаем где их быстро найти
Периодическое тестирование железа в оффлайне

Мониторинг операционной системы
Место на дисках
Периодическая проверка файловой системы - fsck
Регулярно пробуем прочитать записанные (в архив) файлы ☺
iostat

Мониторинг операционной системы
Очередь выполнения
vmstat
Размер и использование swap

Мониторинг операционной системы
Сеть. netstat, -o -p
Полезные утилиты: atop, ps, pstree, apachetop, innotop

Мониторинг MySQL
Ключевые тесты

Мониторинг MySQL
Гистограмма времени обработки запросов (Percona)

Мониторинг веб-приложения
Лог работы скрипта (>) – обновился за N часов
Лог ошибок работы скрипта (2>) – должен быть пуст
Обязательно ротируем логи - logrotate

Мониторинг веб-приложения
Число ошибок в хитах за 15 минут - меньше L (из pinba)
Макс. время хита (тэга) – меньше M сек.
Макс. использование памяти хитом – меньше N МБ
Графики рисует простой плагин для munin

Мониторинг веб-приложения
Гистограммы распределения времени хитов, памяти, кодам ответа – из логов (awk-скрипт) или pinba
Общая температура «по палате»

Аналитика - munin
Дисковая подсистема

Аналитика - munin
Сеть

Аналитика - munin
Память
Apache MaxClients
MySQL buffers …
Нужно «прикинуть» максимальный расход памяти в приложениях и следить за ней

Аналитика - munin
swap
Скорость работы с диском на неск. порядков ниже. Нужно стараться избегать своппинга.

Аналитика - munin
Нагрузка

Аналитика - munin
Нагрузка

Аналитика - memcached
Ключевые графики

Аналитика - MySQL
Ключевые графики

Аналитика - MySQL
Ключевые графики

Аналитика - MySQL
Ключевые графики

Поиск узких мест
XHProf, pinba, XDebug

Поиск узких мест
Apache /server-status
Включенные логи медленных запросов php-fpm, nginx, apache, mysql

Да пребудет с нами сила! ☺