Аналитика

Помимо мониторинга рекомендуется использовать аналитику. Аналитика - это тенденции развития. По её данным можно прогнозировать развитие/деградацию системы. Самый простой пример: по тенденции роста данных вы можете прогнозировать срок, когда переполнится место на дисках и подготовиться к этой ситуации заранее, не доводя систему до остановки.

Для аналитики можно использовать собственные решения, но лучше всё же стандартные. Это лучше делать по тем же причинам, что и для систем мониторинга. Munin, например, кроме стандартных вещей (количество запросов, нагрузка на CPU), позволяет мониторить другие параметры, которые могут быть критичны: скорость генерации страниц, соотношение быстрых и медленных запросов к базе данных. Munin позволят выводить всё это в графики:

Далее рассмотрим, что необходимо анализировать.

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

В дисковой подсистеме один из ключевых параметров - Чтение и запись в секунду байт. 10 МБ/cек - это нормальная нагрузка, 100 МБ/cек - это уже повод для беспокойства. Графики за день и за неделю:

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

  Сеть

Можно использовать стандартные графики, не создавая собственных плагинов. Сеть - это обычный TCP\IP. График нормальной, текущей ситуации:

Если что-то пошло не так, то появляются другие кривые, syn_sent, например.

График трафика позволяет также увидеть тенденции изменений. Если, например, трафик обращений к БД за год растёт, то может разработчики чего-то недооптимизировали.

  Память

На стандартном графике использования памяти можно увидеть тот самый swap, уход в который не желателен для системы, красный цвет:

На иллюстрации: запущенное приложение стало потреблять память - зелёное на графике - и выдавало всю память из операционной в swap, чем убило несколько приложений (белое на графике). Какой-то скрипт убил несколько MySQL серверов с репликацией. На графике видно почему это произошло.

График так же необходим для контроля за расходом памяти. Зелёную зону на графике желательно держать в районе 70%, не более. Операционой системе нужно оставлять какое-то место для буфера и файлов. Регулировать этот показатель можно с помощью, например, Apache MaxClients или MySQL buffers.

Swap

Своппинга надо избегать. На графике чётко видно, что система в какой-то момент ушла в swap, администратор что-то сделал не так. Либо, что-то случилось с системой. А что случилось можно понять по графику использования памяти.

  Нагрузка

Графики нагрузки показывают запущенные процессы (зелёное) и "зависшие" либо в сети, либо на дисковых операциях ввода-вывода (синие).

Чем ниже зелёный график, тем меньше система нагружена. С параметром Load average сложно сказать о конкретных параметрах. 20 или 40? Это сильно зависит от числа процессоров. (20 на 8-и ядерной системе - это нормально, по опыту.) Какое значение параметра показательно для вас вы почувствуете сами по поведению вашей системы. Когда ей "плохо" - она "тупит", значит вы не должны допускать превышения того значения, когда это происходит.

  Переключение контекстов и прерываний

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

Memcached

Memcached мониторится бесплатным плагином. Зелёное - место в memcached занятое приложением, оранжевое - число элементов (ключей кеша) которое хранится. Видно сколько живёт кеш и какой размер он занимает.

График команд показывает число запросов memcached в секунду - интенсивность использования. Можно судить насколько memcached востребован.

MySQL

Важно смотреть какие типы запросов идут в Базу данных. Это позволяет выбирать настройки MySQL. Например, если много select, то можно попытаться использовать Query Cache, а если много update, то его нет смысла использовать.

Потоки в MySQL. Явный всплеск - это перегрузка для системы. Надо следить за такими моментами, уметь их анализировать и недопускать: конфигурировать число серверов или PHP-FM.

Query Cache вызывает много споров когда он нужен, а когда - нет. Чтобы понять нужен он или нет вашему приложению, лучше всего настроить мониторинг и анализировать. Сколько запросов идёт из кеша, а сколько в кеш. И по соотношению этих запросов можно принять решение нужен этот вид кеша или нет. Без аналитики сделать такой вывод сложно.

График заполнения Query Cache данными показывает насколько используется память.

График медленных запросов показывает когда возникли эти запросы. Это позволяет локализовать проблему и решить её.

График сортировки позволяет судить о качестве разработки. Если разработка не качественная, то возникают в большом количестве scan, merge passes, range. Если работа идёт по индексам, то всего этого не будет в таком объеме.