Мониторинг сайта

Мониторинг сайта

Мониторинг сайта на этапе программирования сокращает производственный цикл и предотвращает выпуск медленного, сырого продукта

Специалисты техподдержки сайтов хорошо знакомы с инструментами мониторинга сайтов и аналитики показателей, измеряемых в режиме реального времени. Часто это системные утилиты, запускаемые из консоли, либо веб-приложения, собирающие данные в таблицы и отображающие их в виде красивых графиков.

Однако не всегда программисты знают об их существовании и той пользе, которую они могут принести в процессе отладки кода на сервере разработки. Такие утилиты позволяют на всех этапах, в том числе самых ранних, отслеживать эффективность выбранных алгоритмов и работу программного кода в контексте адекватного потребления ресурсов сервера, влияющих на скорость сайта.

В этой статье мы последовательно рассмотрим:

• Часть 1: внутренние инструменты мониторинга
• Часть 2: внешние инструменты мониторинга
• Часть 3: нагрузочное тестирование на этапе разработки

Итак, различают внешние инструменты и внутренние. Внешние могут собирать очень много данных и показать симптомы проблемы, которая себя еще не проявила. Но все они работают снаружи.

Полноценные данные с пониманием всех происходящих процессов может дать только само веб-приложение, в частности 1С-Битрикс: Управление сайтом. Если сайт работает на платформе 1С-Битрикс, полезно понимать, как провести мониторинг и аналитику сайта – встроенными инструментами.

Инструменты мониторинга сайта и отладки

1. снаружи
• Nagios – проверка доступности и работоспособности
• Munin – графики для аналитики
2. изнутри
• монитор производительности 1С-Битрикс
1. конфигурация (железо + веб-окружение)
2. настройки 1С-Битрикс (опции платформы)
3. качество разработки
• нагрузочное тестирование (упрощенное)
• режим отладки: страница, компоненты, запросы к БД

Часть 1

Монитор производительности 1С-Битрикс

Отдельный модуль, который позволяет оценить очень много метрик системы, платформы и качества разработки. У него несколько вкладок.

Конфигурация

Оценивает характеристики системы. Казалось бы, зачем она нужна, есть всякие системные утилиты, тем же iostat’ом можно посмотреть происходящее с дисками vmstat’ом, top’ом – загрузку процессора, памяти и всего остального. Но все они показывают цифры по железу. Что можно считать показателем производительности системы? Например, скорость загрузки сайта.

Даже при самом мощном сервере можно неудачно сконфигурировать сайт и он будет открываться очень медленно. Наверное, единственный показатель, который для клиента наиболее важен.

Но разные страницы одного сайта могут открываться с разной скоростью. Да и Главная страница одного сайта может весить 2Мб, а у другого 10Кб.

Что же означают цифры, абстрактные «попугаи», в закладке Конфигурация? Не попугаи – измеряется скорость загрузки пустой страницы, к которой подключается только ядро продукта. То есть, без шаблона, без компонентов, без всего остального, подключается ядро и измеряется скорость загрузки такой эталонной страницы.

Отчасти получается синтетический тест, но он показывает не только характеристики физического сервера, но и корректность настроек системного ПО. Если эта цифра большая (равна единице, деленной на количество выдаваемых хитов за 1 секунду), то все хорошо, если маленькая, то наверное что-то не так.

Цифры, выводимые ниже никак не участвуют в формуле расчета параметра «Конфигурация», они просто показывают администратору системы, где могут быть узкие места – на диске, процессоре или еще где-то. Если со всеми показателями все в порядке, значит что-то неправильно сконфигурировано.

Битрикс

Вкладка «Битрикс» позволяет увидеть все метрики, которые влияют на производительность непосредственно в платформе 1С-Битрикс. Если например не включили кеширование в продукте, будет медленно. Или не подключили php-ускоритель, тоже будет медленно.

Разработка

Пожалуй, ключевая вкладка «Разработка» позволяет оценить качество разработки – изнутри померить скорость загрузки страниц и понять, какие страницы потребляют больше всего ресурсов. Позволяет проводить мониторинг в режиме реального времени – можно включить аналитику на 5 минут, на 1 час или более, собрать данные о всех хитах, получить сводную таблицу, какие страницы грузились медленнее всего, какие страницы потребили больше всего ресурсов в PHP, памяти, в запросах к базе, и позволяют администратору очень просто и быстро понять, где, например, на этой странице забыли включить кеширование или сделали слишком много запросов. Позволяет мониторить изнутри и получать актуальные данные.

Масштабируемость

Встроенный инструмент «Масштабируемость» не является альтернативой полноценного нагрузочного тестирования. Однако если нужно быстро оценить именно не производительность железа, а пик, сколько сможет выдержать система на группе серверов, то можно запустить такое подобие нагрузочного тестирования из админки 1С-Битрикс и оценить скорость генерации страниц и время отдачи контента.

Отладка

Также можно для каждой страницы построить отладочную информацию, которая собирается в процессе мониторинга, и посмотреть время выполнения заголовка, самого тела скрипта, всех компонентов, время работы скрипта, сколько выполнено запросов, какие данные получили.

Если заранее такие инструменты отладки используем в платформе 1С-Битрикс, то получаем удобный инструмент, который позволяет быстро и находить узкие места в системе и быстро их исправлять.

Используя подобные механизмы построения систем, можно получить очень быструю и надежную систему, выдерживать любое количество посетителей на сайте.

Часть 2

Внешний проактивный мониторинг сайта и анализ трендов

Задачи:

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

Запуск веб-проекта

Как вообще живет веб-проект и почему возникают с ним проблемы?

Проектирование: не всегда достаточно времени, требования меняются до самого конца

По-хорошему, надо проектировать, но не всегда дается достаточно времени, возникает вопрос зачем? Давайте скорее код писать, заказчик уже деньги перевел, давайте скорее запускаться. Проект совсем не проектируется, либо плохо проектируется. И еще, суровая правда жизни, постоянно меняются требования, до самого конца, как бы менеджеры не защищали программистов от заказчика, требования будут меняться.

Сжатые сроки на развертывание веб-проекта на хостинге

Всегда сроков не хватает, нужно запускаться раньше конкурентов, поэтому часто нервничаем и бежим, ошибаемся, но никуда не деться.

Мало кто проводит и умеет делать нагрузочное тестирование

К сожалению, мало кто умеет организовывать и проводить нагрузочные тестирования. Инструменты есть, но для этого нужен опыт – надо провалить десять проектов, чтобы понять, как правильно делать нагрузочные тестирования, какие параметры определять и мониторить.

Не все задумываются над организацией мониторинга, резервного копирования, обновления софта на серверах и т.п.

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

Часто бывает, ставят какую-нибудь экспериментальную FreeBSD или Fedora (Linux), у которой заканчивается срок поддержки через полгода. Это может стать известно через год после запуска проекта, когда понадобится обновить софт, установить баг-фиксы, и вдруг выясняется – поддержка уже закончилась, и нужно устанавливать новую версию операционной системы из новой поддерживаемой ветки, а для этого надо все заново перетестировать, все конфигурационные файлы перенести, и вообще надо искать системного администратора, который в этом разбирается. Такое бывает очень часто.

Система запускается «как есть» и по инерции может «поработать» год-два «без вмешательства»

В конце концов система запускается, идут клиенты, принимаются заказы, менеджеры довольны. Система живет, но на самом деле она начинает уже деградировать. Она медленно превращается в хаос. Она может проработать год-два, но потом, если не принять меры, может разрушиться.

Вроде работает...

В случае торможения пинают сисадмина перезапустить apache или MySQL

Может проявиться следующим образом: система «вроде работает». Если что-то зависло, просим сисадмина перезапустить веб-сервер Apache, систему управления базами данных MySQL.

Программисты что-то дописывают «на боевых серверах» – так быстрее

Идет «ленивая» эксплуатация проекта, программисты что-то дописывают на «боевых серверах» – так быстрее. Подключаются к ним с максимальными правами доступа от root’а.

Менеджеры проекта меняются

Часто бывает, менеджеры проекта меняются – пришел один менеджер, потом второй, проект «пошел по рукам» – у одного, у второго. Программисты увольняются, техническая документация не ведется, как правило. Проект начинает деградировать и разрушаться.

Веб-проект начинает разрушаться и деградировать изнутри…

Обидно, когда наблюдаешь. Ведь сколько было вложено сил в разработку, тестирование, запуск. И потом видишь, как эта штука через два-три года превращается в ужасный «свинарник» кода, нет ответственных, душа болит за проект, потому что ты знаешь, он может работать хорошо, он может развиваться. Менеджер начинает понимать: куча денег потрачена, а проект стало сложно развивать. Говорят, чтобы что-то добавить, нужно все переписать, это «говно-код», надо все убрать. Вообще, сервера старые, надо все менять, «железо» неправильно подобрано и т.п.

Правильный процесс разработки сайта

Сервера «стерильны», код выкладывается через систему контроля версий

Сервера должны быть «стерильны», код должен выкладываться через систему контроля версия (Git, SVN), никаких разработчиков на боевых серверах быть не должно. Эксплуатацией боевого проекта должна заниматься отдельная команда высококвалифицированных людей, не разработчиков, разработчики могут их консультировать.

Доступ на сервера строго ограничен кругом квалифицированных администраторов

Доступ на сервера должен быть ограничен. Не дай бог, кто-нибудь залезет на сервер, начнет в Unix’е играться, изучать консольку. Unix – отдельный мир, не PHP, вообще другая жизнь, она требует отдельных книжек, знаний, кармы и т.д. Программирование – это другая история, больше романтики, больше творчества. Система администрирования – это “кровь”, “мозги на стенах”, здесь жестче все. Некоторые люди работают лучше там, некоторые – там.

ПО на серверах постоянно обновляется, «дырки» закрываются, предварительно тестируется всё

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

На «взрослых проектах» на серверах постоянно обновляется ПО и устанавливаются баг-фиксы. Они тестируются. Правильная практика, так и должно быть. Если связаться с «несерьезной» системой со сроком поддержки год-два, то столкнетесь с проблемами обновлений. Поэтому мы у себя в проектах используем операционную систему Cent OS, либо RedHat можно использовать, систему, у которой пятилетний срок поддержки. Вы ставите и знаете: все обновления, которые будут выходить в течение пяти лет, они вам систему не сломают, с вероятностью 99,9%. Но это лучше, чем поставить систему и через год переезжать на другую, и при этом вам говорят: «нет механизма переноса, надо все руками переносить и перетестировать».

Перед попаданием «на бой» код попадает на testing, stage сервера для функционального и нагрузочного тестирования

Должна быть «цепочка» серверов:

• боевые сервера
• stage-сервера
• testing-сервера
• development- сервера

Такой подход – не прихоть разработчиков, а суровая правда жизни. Почему? Потому что вы сможете максимально полно протестировать функционал перед выкладкой на «бой». На самом деле, вы до конца не протестируете, это не возможно. Но вы должны тестировать. Нельзя говорить, мы не будем тестировать. Нет, вы должны сделать все, максимально, но потом все равно не нескольких серверах погонять нагрузку, пользователей загнать, тестировщиков, программистов и потом выложить на бой. Это нужная практика, она доказала свое право на существование.

Вся система «покрыта датчиками» и мониторится. SMS. Хорошо, если есть дежурные 24/7.

Ну и конечно, всю систему нужно мониторить. Надо мониторить все, что мониторится и не мониторится. Вы никогда не знаете, что случится. Вы не знаете, какое обновление выйдет в операционной системе Linux, и какой модуль оно может сломать, именно в вашем проекте. То есть, весь мир Linux’а будет работать, а ваш сайт начнет работать неправильно, такое бывает. Бывает несовместимость пакетов, бывает один пакет глючит с другим, и разработчики дистрибутива еще не увидели, только вы это увидите первым, и ваши клиенты.

Поэтому система должна быть покрыта датчиками и мониториться. Очень хорошо, если есть дежурные администраторы. Если вы запустили один сервер, вы знаете - проклятье на всю жизнь, за ним надо следить. Либо администратор, либо группа. Очень хорошо работают СМС-уведомления, когда администратор знает о проблеме раньше, чем вы, и не надо его «пинать».

Мифы о гарантиях стабильности работы сайта

Теперь развеем мифы.

Миф 1. Весь веб-проект покрыть unit и другими тестами на 100%

Первый миф: весь веб-проект можно покрыть unit-тестами и другими тестами и работать по continuos integration. Это не так. Можно покрыть проект тестами? Да. Но гарантировать, что он будет работать при внесении изменений, нельзя. Вы все никогда не протестируете. И даже если вы все покроете тестами, рынок устроен так, требования меняются очень быстро. Вы будете тратить огромное количество денег на написание unit-тестов.

Поэтому мы рекомендуем тесты писать, но в ограниченном количестве, на какие-то критические вещи, на системные библиотеки, какой-то функционал. Важно понимать, тестами все не покроешь. Это миф. Должны быть и тестировщики, и unit-тесты.

Миф 2. Проводится тщательное нагрузочное тестирование на реальных данных

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

Поэтому не бойтесь, проводите нагрузку, но знайте - «лучшее нагрузочное тестирование» впереди.

Миф 3. При изменении настроек/обновлении серверов все тщательно тестируется

Если сервер обновить из репозитория, например, RedHut, Cent OS, все будет продолжать работать – в репозитории все тестируется. Неправда, бывает официально обновляешь операционную систему и, например, отваливается Munin, плагины все слетают. Либо затирается какой-то конфиг.

Можно, конечно, ругаться с разработчиками, но перед нами Open Source, они скажут: «извините». Поэтому это миф, это тоже нужно проверять. Чуть позже рассмотрим, как.

Миф 4. Если установлены все патчи безопасности, система безопасна

Еще один миф: если все патчи безопасности установлены, систему взломать нельзя. Неправда. Патчи безопасности выпускаются тогда, когда дыра найдена. Но на самом деле есть хакерские тусовки, где дыр значительно больше найдено, они об этих дырах знают, больше о них никто не знает.

Может даже есть рутовый доступ на сервера Linux’овые, и никто об этом не знает. А они этим доступом пользуются. Спецслужбы и хакеры. Откроют, они следующую «дырку» найдут. Поэтому с точки зрения безопасности используйте все возможные средства защиты серверов: ограничьте доступ по IP, побольше сделайте палок в колеса хакерам, и тогда скорее всего вас не взломают.

Миф 5. Мы знаем, что может случиться, и ждем этого

На самом деле мы не знаем, что может случиться. Каждый день происходит что-то новое :) Но не отчаивайтесь, дальше будет рецепт.

Как обеспечить стабильность работы сайта

Надо взять все под контроль. Но как?

1. Прозрачное поле боя (nagios)
2. Дисциплина и регламент
3. Анализ трендов (munin)

Прозрачное поле боя (nagios)

Сначала нужно организовать прозрачное поле боя, у вас система должна быть полностью прозрачна, вы должны видеть всех врагов в лицо. Если вы допустите, когда у вас будет какая-то куча вещей, коробки, все, вы потеряете контроль. Надо покрыть систему датчиками на 100%, тогда вы сразу увидите, в чем проблема, где и что случилось.

Дисциплина и регламент

Далее нужно ввести регламент и дисциплину с программистами, с администраторами. Имеем дело с людьми творческими, креативными, они увлекаются. Но должна быть дисциплина. В системе администрирования особенно. Случайно не там поставишь точку с запятой – голову оторвет, у клиента, заказы посыпятся. Поэтому регламент и дисциплина – условия выживания высоко нагруженных проектов.

Анализ трендов

Датчиков не достаточно, регламентов тоже не достаточно. Нужна аналитика. Вы должны знать, что может случиться завтра, после завтра, в течение месяца. Для этого нужны графики. О них дальше немного поговорим.

Мониторинг «железа»

Рейды (RAID)

С помощью Nagios можно мониторить аппаратный рейд (raid). Тест зеленый, значит все в порядке, все диски в рейде работают, и рейд не деградировал – очень важно.

Бывают аппаратные тесты, вендорские тесты для рейдов, но их надо мониторить.

Жесткие диски

Диски иногда могут «умирать». Вы же не хотите, чтобы это случилось внезапно. Поэтому рекомендуют использовать S.M.A.R.T. утилиты, задачей которых является предупредить заранее – диск возможно скоро «умрет». Точность таких инструментов не гарантирована, но лучше ими пользоваться, иногда они помогают.

Есть утилиты вендора, например, в сервер можно купить недорогую плату, которая будет мониторить сервер. Ее можно не покупать, но лучше купить, если у вас свой выделенный сервер. Побольше разных тестов, тогда вы увидите систему лучше

Память

Память тоже желательно тестировать.

Кроме того, нужно иметь запасные вентиляторы, блоки питания и пр., то есть все то, что часто может выйти из строя, а допустить длительный простой нельзя.

Мониторинг операционной системы

Место на дисках

Нужно мониторить место на дисках. Банально, но на практике бывает, вдруг магазин останавливается, так как закончилось место на диске. А почему закончилось место? Потому что дисков много, за всеми не уследишь. Можно, есть плагин для Nagios простой, который позволяет мониторить место на всех дисках автоматически. Поставьте и забудьте об этой проблеме. Сначала он пожелтеет, когда место будет заканчиваться, потом он покраснеет.

На самом деле, мы постоянно в это упираемся, у нас постоянно какие-то эксперименты на серверах, кто-то x-debug включил и т.д. и место вдруг закончилось.

Периодическая проверка файловой системы – fsck

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

Регулярно пробуем прочитать записанные (в архив) файлы

Ну и конечно, важно читать бэкапы, если она сохраняются не в облако, а на диск. Сделали бэкап на сервер, все хорошо. А вы знаете, что можете его не прочитать? Просто не прочитать. Например, диск разрушился, и вы об этом узнаете тогда, когда вы начнете читать бэкап.

В облачных хранилищах обычно автоматически сканируются все диски в фоновом режиме и проверяются на читаемость, и если диск не читается, его заменяют. То есть если у вас свои сервера, вы должны также свои диски сканировать, чтобы иметь возможность поднять бэкап в нужный момент. Особенно касается дисков бэкапных серверов. Их тоже надо проверять, постоянно считывать, например, раз в месяц, раз в полгода. Данные считываются, значит все нормально, диски не посыпались – очень важно.

iostat

Параметры мониторинга по дискам: команда iostat позволяет отслеживать «процент утилизации», показывающий на сколько устройство загружено. Если около 100%, значит все, диск не тянет. Может вы всего 10Мб пишите - значит диск не тянет.

Еще можно посмотреть насколько файловая система работает с потоками, то есть можете ли вы одновременно работать с вашим диском или рейдом. Есть методика расчета этих показателей, по которой можно определить, он в один поток работает или в несколько. Бывает, такая старая файловая система или ядро старое, и вы работаете в один поток, у вас все тормозит, а вы даже не знаете об этом. Все можно с помощью утилиты iostat посмотреть.

К сожалению, не всегда iostat показывает информацию по дискам, например, для VPS с виртуализацией OpenVZ.

Очередь выполнения

Простой тест в Nagios, который показывает число процессов, которые хотят, чтобы их выполнил центральный процессор. Если их много, значит вы что-то не оптимизировали код, слишком много софта запускаете одновременно, либо сервер слабый.

Размер и использование SWAP

Тест в Nagios, который проверяет объем swap, количество свободного места в нем. Вообще, для чего нужен swap? В основном, чтобы у вас утром было время дойти до работы и от него избавиться – такой защитный механизм операционной системы. Если у вас система вываливается в swap, то есть из оперативной памяти программа выгружается на swap-диск, на самом деле это плохо, система начнет тормозить, так как работа с диском на несколько порядков дольше, чем работа с памятью.

Вы должны увидеть проблему и сразу же принять меры: увеличиь размер оперативной памяти, либо уменьшить буфер для программ, которые запускаете. Не надо думать: swap – хорошо. Хотя Linux пытается нас убедить: swap - хорошо, но мы с этим не согласны. За этим нужно следить. Нередко из-за ошибок конфигурации система вываливается в swap, плохо.

Vmstat

Еще одна интересная утилита в Nagios, которая показывает:

Сеть. netstat, -o -p

Мониторим сеть, для этого используем утилиту netstat для Nagios. Она позволяет видеть происходящее в сети, кто нагружает сеть: memcache, PHP, Apache или MySQL.

Полезные утилиты: atop, ps, pstree, apachetop, innotop

А также полезные утилиты:

Мониторинг MySQL

Ключевые тесты

Посмотрим, параметры можно тестировать в MySQL. Мы тестируем:

Число потоков

Число запущенных потоков, которые работают. Мы знаем, если запущено 50 потоков, 100 потоков, при этом MySQL забирает какой-то объем оперативной памяти и таким образом нагружает систему. Если потоков слишком много, значит система будет тормозить. Поэтому полезно поставить датчик и проверять - сервер не перегружен?

Медленные запросы

Очень важный параметр. Если MySQL тормозит, этот показатель высветится желтым или красным цветом. Медленные запросы могут возникать по разным причинам, но если они появляются – плохо, скорее всего, и вам нужно принимать меры.

Долгие процессы

Бывает, программисты экспериментируют, запускают долгие процессы, которые в итоге выполняются день, два, три, и забывают про них. Эти процессы висят и нагружают диск. Такие процессы отлавливаются таким тестом.

Репликация

Вообще ключевой тест. Когда вы используете Битрикс-кластер и master-slave репликацию, вам нужно знать, не отвалилась ли репликация. К сожалению, она отваливается. Например, сервер перезагрузился, система ушла в swap и остановила MySQL. Бывает, отстает репликация. Этот стандартный тест Nagios позволяет следить за отставанием. Вы же не будете читать данные с сервера, который отстал на 2 дня или на 2 часа. У вас клиенты с ума сойдут, тут купил, а там, оказывается, еще не купил. Веб-кластер Битрикс умеет это делать, но этот тест тоже пригодится.

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

По поводу MySQL, как увидеть температуру больного по палате: тормозит база или нет. Приходит руководитель и говорит: «Посмотри, база не тормозит?». Что значит «тормозит»? Есть легкий способ, он в Percona реализован, патче к MySQL. В Percona выполняется команда, ее нет в стандартном MySQL, которая строит гистограмму распределения хитов по времени, и если вы видите: запросов больше 0,1 секунды много, значит сервер тормозит, если их мало – нормально. Можно сделать плагин для Munin и сразу видеть, тормозит база или нет.

Мониторинг веб-приложения

Лог работы скрипта – обновился за N часов

Для каждого бизнес-скрипта, который, например, обновляет заказы, что-то выгружает, экспорт / импорт, который должен обязательно выполниться и без ошибок, а если с ошибками, то мы об этом должны обязательно узнать, для этого делаем лог работы скрипта и ставим тест Nagios проверки обновления, например, каждые 2 часа. Если файл не обновился, значит скрипт не отработал. Например, так как крон выпал, если кто-то закомментировал или что-то еще случилось.

Лог ошибок работы скрипта – должен быть пуст

И дальше для каждого скрипта делаем лог ошибок. В Unix есть поток ошибок 2, и мы его направляем в другой файл. Все что угодно может случиться: PHP вылетел, оперативной памяти не хватило и т.п. Этот лог должен быть пустой. Обязательно по всем скриптам ведите 2 лога: лог работы и лог ошибок. Лог ошибок должен быть пустой. Столько «чудес» может появляться в логе ошибок, которые даже не ждем. Вдруг может возникнуть другая, какая-то другая программа остановила нашу и сразу в логе появится запись - ей чего-то не хватило.

Обязательно ротируем логи – logrotate

Иногда про логи забывают и система через полгода умирает, так как все забито логами. Есть простой инструмент – logrotate, который позволяет в автоматическом режиме подчищать устаревшие логи, чтобы они не забили диск. Все логи ротируйте, тогда система выходит на уровень какой-то по заполненности дисков и больше из него не выходит. Она приходит в стабильное состояние.

Число ошибок в хитах за 15 минут – меньше L (из pinba)

Pinba – отличный инструмент, кроме всего прочего позволяет мониторить количество ошибок в хитах за последние 15 минут, чтобы их было меньше, например, пяти. Если у нас что-то происходит с сайтом, посыпались ошибки, с базой, с PHP, ошибки на диске, тогда Pinba сразу дает знать Nagios’у и приходит СМС’ка, что, например, PHP заглючило.

Макс. время хита (тэга) – меньше M сек.

Тоже из Pinba берем максимальное время хита. Если вдруг начали появляться хиты на 10 секунд, 20 секунд, 30 секунд, такое бывает – могут быть ошибки. Сразу об этом узнаем и разбираемся.

Макс. использование памяти хитом – меньше N Мб

Бывают ошибки в приложении, когда PHP-скрипт начинает 500Мб отнимать, 1Гб, 2Гб, ужасные утечки начинаются, и сразу об этом узнаем, придет уведомление.

Графики рисует простой плагин для Munin

Оперативную память нужно контролировать, чтобы система не уходила в swap.

Гистограммы распределения времени хитов, памяти, кодам ответа – из логов (awk-скрипт) или pinba

Гистограммы помогают быстро понять, тормозит сайт или нет, точно также как и для базы данных. Можно строить по логам или по pinba, например гистограмму по времени PHP-хитов и использование памяти PHP-скриптами по объему. Полученные графики можно вывести на большом экране, чтобы наглядно видеть происходящее с проектом и стремиться его «отодвигать» в нулевую зону.

Аналитика – Munin

Дисковая подсистема

Для чего нам нужны такие красивые графики? Это тренды. Анализируя произошедшее с системой в прошлом, можно прогнозировать будущее. Например: на дисках скоро закончится место месяца через три, или заметить проблему, случившуюся ночью вчера при нагрузке. Эти вещи важно уметь читать, чтобы проактивно реагировать на поведение веб-проекта.

В Munin для дисков можно смотреть:

Сеть

В munin есть стандартные графики:

Память

Нужно «прикинуть» максимальный расход памяти в приложениях и следить за ней

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

Также этот график хорош, так как на нем видна зеленая зона, которую рекомендуется держать не более 70% от всей оперативной памяти и оставлять операционной системе какое-то место для буферов и файлов. Иногда можно меньше оставлять, но оно должно быть, иначе все просто остановится. Бывает, если места нет, в систему вообще нельзя залогиниться.

Поэтому, чтобы чтобы зеленая зона была небольшой, нужно настроить параметры:

На графиках после этого будет видно, как например MySQL начнет съедать память и за неделю он сможет ее съесть всю. Nagios не покажет, надо обязательно иметь графики и по ним смотреть, тогда более точно можно построить систему.

SWAP

Скорость работы с диском на несколько порядков ниже, поэтому нужно стараться избегать своппинга.

Рекомендуется добиваться, чтобы график swap был на нуле или хотя бы до десяти страниц в секунду.

Нагрузка

Зеленый график – запущенные процессы, синий – залипшие на диске или сети. Это свидетельствует о каких-то проблемах с дисками или сетью.

Этот график показывает нагрузку. Нельзя сказать, 20 или 40 – много или мало. Это зависит от числа процессоров. Например, для восьми-ядерной системы 20 – нормально, лучше, конечно, держать меньше. Просто следите, чтобы система была не перегружена. Чем ближе к нулю, тем лучше.

Если прерывания и переключения контекста сильно скачут, значит надо смотреть почему запускается много процессов, возможно с каким-то софтом какие-то проблемы.

График показывает число процессов в системе. При этом важно понимать: процессы порождают потоки. Например, MySQL порождает только потоки, один процесс – много потоков. Поэтому надо сначала следить за числом процессов, потом за числом потоков.

График показывает число потоков. Если в nagios поставить тест на верхнее значение числа потоков, то можно будет отследить проблему, когда Apache или MySQL начнет работать неправильно и порождать излишнее число потоков.

Memcached – ключевые графики

Memcached тоже можно мониторить с помощью бесплатных плагинов. Например, место, занятое в memcached Битриксом, на графике – 300Мб зеленая линия. Оранжевый график показывает число элементов в memcached, сколько ключей кеша там хранится, тоже важная информация.

График показывает количество команд в секунду показывает интенсивность использования memcahed, то есть насколько он вообще востребован. Если бы не было memcached, то кеш хранился бы в файлах, было бы эффективно? Здесь сразу видно, мониторьте.

Аналитика – MySQL

График показывает количество запросов в секунду. Важно смотреть, какие типы запросов идут к базу данных, какая нагрузка какими типами запросов создается: SELECT, DELETE, UPDATE, INSERT и т.д. Если используется много запросов типа SELECT, то можно попробовать использовать кеширование запросов query_cache. Если много UPDATE, то его нет смысла использовать.

Крайне полезно видеть структуру типов запросов и в зависимости от этого настраивать параметры MySQL.

График показывает число потоков. Если возникает резкий всплеск, значит возникла какая-то проблема, база начинает тормозить. В этом случае нужно следить на уровне Apache MaxClients и php-fpm. Стоит поберечь MySQL и не пропускать на него большее число потоков, чем он может «переварить», иначе он будет тормозить.

Кеширование запросов – Query Cache

Много есть споров, нужен Query Cache или нет. Иногда нужен, иногда нет. Чтобы разобраться, можно настроить мониторинг и понять, сколько запросов идет из кеша и сколько запросов добавлено в кеш, и по процентному отношению можно будет принять решение, нужен он или нет.

График показывает, сколько на самом деле памяти используется под Query Cache из отведенного объема. Иногда выделяешь 1Гб, а по факту используется не более 100Мб. Зачем тогда выделять 1Гб.

Медленные запросы

Приходишь утром на работу, а на графиках куча медленных запросов – база висела. По графику видно, когда, в какое время. Дальнейший анализ по времени позволяет установить причину, почему.

Если в базе данных не расставлены нужные индексы, то сразу вылезают операции сканирования – Scan, сортировок – Rows sorted. По графикам можно суть о качестве разработки веб-проекта в части настройки базы данных и запросов к ней.

Поиск узких мест

XHProf, pinba, XDebug

Когда вы обнаружили проблему, важно быстро найти строчку в коде, которая ее породила.

Pinba позволяет измерять «температуру по палате», например, количество запросов в секунду к странице, время выполнения.

XHProf – профилировщик от разработчиков Facebook.

Xdebug может давать трейс выполнения приложения построчно, можно найти, что и где тормозит, но он требует слишком много ресурсов от сервера, на котором запущен. Если его включить на «бою», «бой» просто упадет. А нужен более легкий инструмент, причем на «бою». Для таких случаев как раз подходит профилировщик XHProf, который практически не замедляет работу сайта и может быть включена постоянно, позволяя сделать трейс медленного запроса, нарисовать красивую картинку и показать ее разработчику.

Например, можно настроить XHProf, чтобы для всех запросов дольше 5 секунд сохранялись их трейсы в файлы, которые высылаются на электронную почту разработчикам. По сути перед нами - техническое задание на оптимизацию. Отличный инструмент.

Apache /server-status

Простые известные инструменты, которых почему-то в большинстве проектов нет.

Apache / server-status табличка должна быть, нужно хорошо понимать все колонки. Эта страничка – первый инструмент при тормозах веб-приложения. Она помогает увидеть, откуда заходит клиент, с какого виртуального хоста, в какое время, какой запрос отправляет. Без нее вы просто слепые. Будете биться и получть одни отрицательные эмоции от системы.

Включенные логи медленных запросов php-fpm, nginx, apache, mysql

Дополнительно рекомендуется включать лог медленных запросов. Для php-fpm - лог, в который пишутся php-запросы более 5 секунд. Приходите утром, а там 5 запросов. Причем пишется не только запрос, пишется трейс, с какой строки кода он вызван. Сразу ТЗ готово на оптимизацию, можно передавать программисту на доработку.

Чтобы быстро определить, в чем причина торможения, нужно иметь логи, либо иметь графики, поэтому логировать желательно все. Без этого вы причину никогда не узнаете.

Чтобы победить систему, нужно вести логи и строить графики.

Часть 3

Нагрузочное тестирование сайта

Чего позволяет добиться нагрузочное тестирование на этапе разработки?

Каково определение «время загрузки страницы»?

Говоря о производительности системы, пользователи и разработчики часто говорят о разном:

1. генерация страницы
• Получение и обработка запроса
• Запрос к БД и обработка
• Обработка данных
• Формирование страницы HTML
2. передача страницы и обработка
• передача полученной страницы HTML и контента (картинки, видео и пр.) пользователю
  
3. обработка на стороне клиента

В большинстве случаев, когда говорят о скорости загрузки страницы, чаще всего говорят о том, как можно быстрее сгенерировать страницу на стороне веб-сервера. Иногда говорят о скорости передачи страницы, которая может занимать очень много времени, которое пытаются сократить за счет использования CDN. И вообще никто не говорит про третью часть – обработку страницы на стороне клиента в браузере. Хотя на самом деле для конечного пользователя – «сайт тормозит».

Никто не произносит слово «JavaScript», хотя это одна из ключевых проблем сегодня. Масштаб на графике сохранен, примерно так все в пропорциях это все занимает. Про доставку через CDN чуть-чуть говорят. Очень редко можно услышать: «много весит страница» и «можно ли её уменьшить»? Почему так происходит?

По двум причинам: во-первых, разработчикам нравится ковыряться со всей этой серверной частью кода, ведь интересно. Во-вторых, когда говорят про производительность, подразумевают надежность. В России у большинства проектов вопрос стоит не «быстро / медленно», а «падает / не падает».

Клиентов, которые бы сказали: «хотим, чтобы посетитель получал страницу не за 2 секунды, а за 1», в России почти нет. Только большие проекты: Яндекс, Mail.ru и др.

Какие бывают нагрузки?

Все сайты разные. Нагрузки тоже бывают разные, и это сильно влияет и на характер выбранного теста и на стратегию развития и масштабирования системы:

Во всех российских проектах действует принцип «халявы»: есть день и ночь, что принципиально меняет многие подходы. Дневная нагрузка интересует прежде всего. В России редко встречаются проекты, которые работают круглосуточно.

Когда интернет-магазин продает дистрибутивы ПО, их после оплаты скачивают пользователи, там совсем другие узкие места – используется CDN и пр.

Не всегда пользователь начинает просмотр сайта с Главной страницы. Если более точно, не более чем в 30% случаев. Чаще всего он из поисковой системы или объявления контекстной рекламы попадает на внутреннюю посадочную страницу, например, на детальную страницу товара. В среднем 10 хитов приходится на пользователя, 3 из них будет оформление заказа и корзина, например.

Для новостного сайта важна Главная страница, именно на нее чаще всего приходят посетители и далее переходят на страницы со статьями. Зачастую кеширование выборок данных и html-страниц на стороне сервера все решает.

Правильно настроенная система

Чего мы хотим добиться и как должна работать правильно настроенная система? Должен ли правильно настроенный сервер обрабатывать все запросы и как? В чем измеряется результат?

Во-первых, когда речь заходит про производительность или надежность, нет одного числа – одна или две секунды. Здесь имеем дело со статистическим распределением времени загрузки страниц сайта за период времени. Тогда требование по производительности может звучат так: мы хотим, чтобы 90% запросов обрабатывалось в промежутке времени от 0,5 до 2 секунд. При этом уточняем – генерировалось, доставлялось или интерпретировалось в браузере. Другими словами, нельзя сказать, все страницы.

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

Есть приемы, позволяющие управлять ожиданием посетителя. Например, если есть тяжелый запрос, импорт файла какой-нибудь, посетитель стерпит 5 секундную задержку. Если добавить «крутилку» на экран, он подождет 10 секунд. А если поставить прогресс-бар, который показывает от нуля до ста процентов, то он будет готов ждать и минуту.

Вывод: разные запросы по-разному воспринимаются посетителем сайта, и с этим тоже можно работать, такими приемами как прогресс-бар и т.д.

В третьих, система должна справляться с динамическими нагрузками, то есть корректно отрабатывать всплески. Хотя и здесь тоже существует много приемов. Например, даем рекламу на Яндексе на пылесос, она ведет на детальную страницу интернет-магазина. Мы делаем ее статической, и вопрос нагрузки на эту страницу резко упрощается. Так делают многие новостные сайты, когда у них какие-то события происходят, и резко возрастает нагрузка. Всегда должен быть план действий на динамическую нагрузку.

В-четвертых, хорошая система не должна падать. Согласно теории массового обслуживания производительность системы зависит от нагрузки, то есть, если кассир просто работает, он может обслужить пять покупателей в минуту, но если к нему подойдут пять покупателей в минуту, он уже обработает четыре, а если к нему одновременно подойдут двадцать покупателей, он не сможет обработать и двух.

То есть, когда система подходит к своему пределу, она начинает деградировать по производительности. Подобное мы часто видим на примере пробок. Вот, вроде, дорога, она в обычной жизни пропускает сто машин, а сейчас не пропускает никого, а потом раз, и закончилась пробка. Другими словами, когда система подходит к порогу производительности, начинает падать, начинает деградировать и умирает.

Поэтому одна из самых ключевых задач любой хорошей системы – не дать ей предельную нагрузку, то есть накопить допустимую очередь, а остальные запросы сбросить. И такая система не падает. Она может давать отказ пользователю, задержку, очередь, но сама она не падает.

Для менеджера простой индикатор, хорошо настроена система или плохо – падает под нагрузкой или нет. Главная цель менеджера – сделать систему масштабируемой по железу. Мечта любого менеджера проекта – купил сервер, и проект работает быстрее.

Для большинства проектов подобное довольно легко достижимо. Проблемы начинаются тогда, когда становится не достаточно 3-4 и более серверов, когда 6, 7 сервер уже ничего не дает.

Большая проблема – плохой код. Можно сколько угодно рассуждать про нагрузки, плохой программист испортит любую систему. Даже миллионы, потраченные на архитектуру, не помогут, если код кривой. Вторая проблема – плохой код есть всегда. В России в принципе очень плохое качество кода в основной массе. Поэтому как только возникает разговор про какой-то здоровый uptime – 98 или 99%, сталкиваемся с одним – делаем отгрузку свежих доработок на боевой сервер, и все умирает.

Нагрузочное тестирование сайта на этапе разработки - зачем?

Сама по себе производительность системы – еще не цель. Цель – высокая надежность, то есть малый процент отказов. Однако, высокая надежность достигается не столько и не только производительностью системы, сколько культурой разработки и прежде всего, культурой отгрузки изменений и управлению этим процессом:

Нельзя дать отгрузить то, что может остановить сервер. Это, к сожалению, проще сказать, чем сделать, по разным причинам.

Во-первых, нормально протестировать дороже, чем сделать. Многие этого не знают и не понимают. Как только добавить работы по тестированию, себестоимость разработки начинает нелинейно увеличиваться. Чем вы ожидания по качеству отгрузки, тем дороже будет производство. Почти никто к этому не готов.

Во-вторых, совершенно другие процессы и культура. Как выглядит большинство производственных отделов – есть разработчики, которые говорят: «завтра отгрузим». Отгружают и все, на этом все заканчивается.

Во всех больших ответственных проектах люди, которые отвечают за поддержку и надежность системы, и люди, которые ее делают – абсолютно разные люди. У разработчиков нет даже доступов к боевому серверу. Охрана боевого – задача номер один. И отгрузка зачастую может занимать месяц, так как не пропускают, не проходит план-тест, не проходят автотесты.

Если жестко не разделить эти два процесса – поддержка и производство, никогда не получится выстроить такую систему, потому что производстве все время push’ит, давай-давай, их заставляют торопиться. Поэтому если просто отгрузить, то сайт с высокой вероятностью падает.

Большая часть работ по проверке – нагрузочное тестирование. Перед тем, как что-то уйдет на бой, должны пройти план-тесты. Один из план-тестов – нагрузочный тест.

Как выглядит нагрузочное тестирование сайта

Задача нагрузочного тестирования – сэмитировать нагрузку на систему достаточно близкую к реальной и получить статистику ответов:

Берем набор типовых цепочек, то есть то, как пользователь ходит по сайту. Количество цепочек, очевидно, стремится к бесконечности. В реальной жизни цепочки могут быть очень разными, и каждый день появляются все новые и новые, поэтому абсолютно все цепочки протестировать не получится. Тем не менее, существует набор сценариев, который мы считаем наиболее вероятным, и 50% посетителей по нему пройдут.

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

Очень важно сэмилировать максимально приближенную к реальности ситуацию. Должны быть авторизации, сессии, завершение авторизации, тестовые данные, близкие к реальным. Так как тест достаточно условный и дает не до конца качественный результат, то его нужно проводить на пиковом значении. Например, три часа держим пиковую нагрузку и смотрим, что происходит. Двенадцать часов держим пиковую нагрузку. Однако, тест позволяет нам выявить не так много.

Результат нагрузочного тестирования сайта

Результатом нагрузочного тестирования является не утверждение о производительности сайта или программного кода, а скорее утверждение о пределе производительности всей системы:

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

Поэтому сам по себе тест не гарантирует отсутствие узких мест и плохого кода. Он указывает на предельную системную нагрузку, то есть сколько архитектурно системно проект может выдержать без учета плохого кода и узких мест.

Даже после подобного тестирования с большой долей вероятности (30-40%) отгрузка вызовет тормоза, потому что на реальных данных и реальных посетителя будут выявлены те узкие места, которые нагрузочный тест выявить не может.

Как проводится нагрузочное тестирование сайта?

Для организации правильного нагрузочного тестирования требуется не так много

навыков или технологий, как знаний и опыта. Важно придумать, как протестировать систему:

Тестовые цепочки можно взять из Яндекс.Метрики веб-проекта, например, 100 наиболее частых сценариев. Инструмент для проведения измерений должен обладать точностью выше, чем то, что мы измеряем. Например, если нужно сэмулировать сто тысяч посетителей и для них один миллион хитов, значит инструмент не должен быть узким местом и должен выдержать больше.

У взрослых проектов действует так: есть тестовая копия, которая равна бою, с нее идет отгрузка на рабочую копию, и если все в порядке, она идет на бой. Причем зачастую рабочая копия часто выступает в роли бэкапа. А у совсем взрослых бой тоже разделен на части: первая бета, вторая бета и т.д. Для тестирования крайне желательна копия боевой площадки.

Встроенные инструменты 1С-Битрикс позволяют находить узкие места при тестировании.

Важно понимать, положительные результаты нагрузочного тестирования, когда например в течение 24 часов было сэмулирован миллион посетителей, являются необходимым условием проверки, но не достаточным, и говорит лишь о том, что веб-проект на системном архитектурном уровне на такое способен и можно переходить к следующему шагу вывода проекта на бой.