Я поддерживаю и планирую экземпляр сервера EC2, на котором запущен Apache2 на Ubuntu, который в настоящее время получает до 10000 (очень простых) запросов в час. Это просто некоторые данные, поступающие с помощью POST, и на них появляется фиктивный текстовый дефис.
Количество запросов будет постепенно расти примерно до миллиона в час.
Как мне (надежно>) определить, что сервер поставлен на колени и больше не может обрабатывать входящие запросы?
В данный момент я просто проверяю загрузку памяти и процессора в htop - и если они не выходят на полную мощность, то, полагаю, все в порядке.
Что касается количественной оценки производительности apache для конечных пользователей, полезно время, затрачиваемое на обслуживание ответа, и оно будет увеличиваться с увеличением нагрузки на сервер. Обычно я комбинирую регистрацию этого значения с некоторыми программами веб-аналитики, такими как awstats или webalizer.
К сожалению, формат журнала по умолчанию этого не показывает, поэтому я использую в своем Apache специальный формат журнала, это пример;
# Define logfile format used for response time analysis
LogFormat "\"%{%Y-%m-%d %H:%M:%S}t\" %V %m \"%U\" \"%q\" %{Content-Type}o %s %B %O %D" responsetime
CustomLog "/var/log/apache2/responsetime.log" responsetime
Директива пользовательского формата журнала% D указывает время запроса;
% D Время, затраченное на обслуживание запроса, в микросекундах.
Документация Apache:
http://httpd.apache.org/docs/current/mod/mod_log_config.html
Пример отсюда;
http://www.moeding.net/archives/33-Logging-Apache-response-times.html
Думаю, вы правы, наблюдая за системными ресурсами. Средняя нагрузка, нагрузка ввода-вывода, память, своп, процессор и т. Д.
Вы, вероятно, извлечете пользу из некоторых подробностей о внутреннем состоянии Apache, например, о том, что на самом деле делают его процессы.
http://www.tecmint.com/monitor-apache-web-server-load-and-page-statistics/
Пример того, что может показать mod_status на сайте www.apache.org
http://www.apache.org/server-status
Это может помочь со временем собрать информацию, чтобы позже рассмотреть ее в целом.
https://httpd.apache.org/docs/2.4/programs/log_server_status.html
В зависимости от вашей настройки вам нужно будет независимо наблюдать за производительностью серверных служб, которые использует Apache, таких как серверы баз данных и тому подобное.
Отказ от ответственности: я работаю на сайте www.mosoplot.com, который автоматизирует большую часть необходимого здесь планирования мощности. Я использовал несколько диаграмм из MOSOplot, чтобы продемонстрировать, как это сделать.
Вот как я планирую мощность веб-серверов.
Во-первых, использование Htop / top не подходит для такого рода анализа. Они показывают только самый крайний краткосрочный обзор, который отлично подходит для анализа производительности, но не подходит для планирования мощности. Вам действительно нужно взглянуть на более длительный период времени, чтобы точно судить об этом. Это похоже на выборку нескольких человек для определения религиозного облика страны. Откуда вы знаете, что тот короткий период, который вы наблюдали, был репрезентативным для того, что происходит с сервером в остальное время? А когда вы спите? Вы хоть знаете, пик сейчас или нет?
Htop также по умолчанию использует только 2-секундный интервал. Так что всплески приходят и уходят, и они могут иметь значение, а могут и не быть. На самом деле минимальный интервал для планирования мощности будет 5 минут, но я предпочитаю 1 час. Это сгладит всплески, чтобы показать основную тенденцию. Это то, против чего вам нужно спланировать. Однако, если у вас есть основания полагать, что существуют более краткосрочные тенденции (например, если все переводы происходят в течение 10 минут в начале каждого часа), то непременно посмотрите на это.
MOSOplot использует агент collectd, который может собирать метрики apache, а также системные метрики.
Чтобы получить статистику apache (время отклика и объемы), вы можете использовать плагин collectd tail, который будет читать файлы журнала apache и извлекать необходимые данные. Есть специальный плагин для apache, но он не определяет время отклика.
Что-то вроде этого должно быть началом, наряду с изменениями конфигурации, описанными Tom H, чтобы включить% D.
LoadPlugin tail
<Plugin "tail">
<File "/var/log/apache2/access.log"> <-- PUT IN CORRECT FILENAME
Instance "apache"
<Match>
Regex "GET.*?\\s([0-9\\.]+)\\s[0-9\\.]+$"
ExcludeRegex "\\s/(favicon|wp-)"
DSType "GaugeAverage"
Type "response_time"
Instance "last_byte"
</Match>
</File>
</Plugin>
Показателем номер один, на который следует обратить внимание, является время отклика - если ваше приложение не является пакетной системой, в этом случае вы можете игнорировать это.
Попробуйте соотнести использование ЦП и памяти со временем отклика. Это даст вам представление о том, когда ваша система сломается. Время отклика может увеличиться до 5-кратного обычного, но после этого оно может быстро ухудшиться. Некоторые приложения могут даже не справиться с этим, так что это зависит от обстоятельств.
Вот ссылка на диаграмму, в которой показан пример сравнения количества посещений ЦП и посещений веб-сервера в минуту. В этом случае объемы низкие, и похоже, что мы могли бы легко достичь 15 обращений в минуту. число обращений процессора в минуту
Если вам не удалось собрать время отклика, вам нужно использовать фиксированные пороги. Определенно НЕ ждите, пока ЦП и / или память не выйдут на полную мощность. Для начала, он, вероятно, начнет деградировать примерно на 60% (в среднем за час). Во-вторых, Amazon использует пакетный режим в некоторых своих системах на отметке 60%, что является хорошим показателем того, что они считают это хорошим порогом. Если вы часто превышаете пакетный уровень, вам следует подумать об обновлении.
Память должна быть в порядке примерно до 90%, но, учитывая, что apache может иногда иметь проблемы с OOM (nginx лучше в этом), я был бы счастлив с пиковым использованием 70%.
Apache имеет тенденцию быть довольно нестабильным в использовании памяти. На одном веб-сервере, который мы отслеживаем, мы в итоге перешли на nginx, потому что это был небольшой экземпляр с оперативной памятью всего 1 ГБ, а apache испытывал ошибки OOM. Вот диаграмма, показывающая, насколько сильно использовалась оперативная память под apache по сравнению с nginx. Переменная памяти с apache v nginx
Еще одна вещь, о которой стоит подумать, - как быстро вы сможете получить одобрение усовершенствовать. Хотя на самом деле обновление на AWS может быть быстрым, если предположить, что ваше приложение масштабируемо, получение одобрения на обновление у большинства клиентов, с которыми я работаю, - это, в общем, ледяная задача! Дайте себе запас на несколько недель / месяцев, если это то, что вам нужно.
