Модуль ngx_http_limit_req_module (0.7.21) позволяет ограничить скорость обработки запросов по заданному ключу или, как частный случай, скорость обработки запросов, поступающих с одного IP-адреса. Ограничение обеспечивается с помощью метода “leaky bucket”.
Пример конфигурации
Директивы
| Синтаксис: | limit_req zone = название [ burst = число ] [ nodelay | delay = число ]; |
|---|---|
| Умолчание: | — |
| Контекст: | http , server , location |
Задаёт зону разделяемой памяти ( zone ) и максимальный размер всплеска запросов ( burst ). Если скорость поступления запросов превышает описанную в зоне, то их обработка задерживается так, чтобы запросы обрабатывались с заданной скоростью. Избыточные запросы задерживаются до тех пор, пока их число не превысит максимальный размер всплеска. При превышении запрос завершается с ошибкой. По умолчанию максимальный размер всплеска равен нулю. Например, директивы
позволяют в среднем не более 1 запроса в секунду со всплесками не более 5 запросов.
Если же избыточные запросы в пределах лимита всплесков задерживать не требуется, то следует использовать параметр nodelay :
Параметр delay (1.15.7) задаёт лимит, по достижении которого избыточные запросы задерживаются. Значение по умолчанию равно нулю и означает, что задерживаются все избыточные запросы.
Директив limit_req может быть несколько. Например, следующая конфигурация ограничивает скорость обработки запросов, поступающих с одного IP-адреса, и в то же время ограничивает скорость обработки запросов одним виртуальным сервером:
Директивы наследуются с предыдущего уровня конфигурации при условии, что на данном уровне не описаны свои директивы limit_req .
| Синтаксис: | limit_req_dry_run on | off ; |
|---|---|
| Умолчание: | |
| Контекст: | http , server , location |
Эта директива появилась в версии 1.17.1.
Включает режим пробного запуска. В данном режиме скорость обработки запросов не ограничивается, однако в зоне разделяемой памяти текущее число избыточных запросов учитывается как обычно.
| Синтаксис: | limit_req_log_level info | notice | warn | error ; |
|---|---|
| Умолчание: | |
| Контекст: | http , server , location |
Эта директива появилась в версии 0.8.18.
Задаёт желаемый уровень записи в лог случаев отказа в обработке запросов при превышении скорости и случаев задержек при обработке запроса. Задержки записываются в лог с уровнем на единицу меньшим, чем отказы, например, если указано “ limit_req_log_level notice ”, то задержки будут записываться в лог на уровне info .
| Синтаксис: | limit_req_status код ; |
|---|---|
| Умолчание: | |
| Контекст: | http , server , location |
Эта директива появилась в версии 1.3.15.
Позволяет переопределить код ответа, используемый при отклонении запросов.
| Синтаксис: | limit_req_zone ключ zone = название : размер rate = скорость [ sync ]; |
|---|---|
| Умолчание: | — |
| Контекст: | http |
Задаёт параметры зоны разделяемой памяти, которая хранит состояние для разных значений ключа. Состояние в частности хранит текущее число избыточных запросов. В качестве ключа можно использовать текст, переменные и их комбинации. Запросы с пустым значением ключа не учитываются.
В данном случае состояния хранятся в зоне “one” размером 10 мегабайт, и средняя скорость обработки запросов для этой зоны не может превышать 1 запроса в секунду.
В качестве ключа используется IP-адрес клиента. Обратите внимание, что вместо переменной $remote_addr используется переменная $binary_remote_addr . Длина значения переменной $binary_remote_addr всегда равна 4 байтам для IPv4-адресов или 16 байтам для IPv6-адресов. При этом размер состояния всегда равен 64 байтам на 32-битных платформах и 128 байтам на 64-битных платформах. В зоне размером 1 мегабайт может разместиться около 16 тысяч состояний размером 64 байта или около 8 тысяч состояний размером 128 байт.
При переполнении зоны удаляется наименее востребованное состояние. Если и это не позволяет создать новое состояние, запрос завершается с ошибкой.
Скорость задаётся в запросах в секунду (r/s). Если же нужна скорость меньше одного запроса в секунду, то она задаётся в запросах в минуту (r/m), например, ползапроса в секунду — это 30r/m.
Параметр sync (1.15.3) разрешает синхронизацию данной зоны разделяемой памяти.
Встроенные переменные
$limit_req_status хранит результат ограничения скорости поступления запросов (1.17.6): PASSED , DELAYED , REJECTED , DELAYED_DRY_RUN или REJECTED_DRY_RUN
how to calculate the average processing time in nginx
I wish to calculate the average processing time of requests going through nginx. More specifically, it would be awesome to get various percentiles. and it would be even better if I could get these by HTTP method (post/get etc).
I do have a bunch of bad/not-so-great solutions:
- forgo nginx and do this math from the loadbalancer’s logs
- expose each requests’s processing time in the nginx access log, ship it and then process it (or just do it locally with cron/bash).
but there must be a better way to do this.
2 Answers 2
I also tried to get different statistics on the Nginx performance. There is a non-free nginx-amplify-doc that can get you what you want. I am not sure what is the pricing policy there — I ended up parsing the access logs because I did not wanted to pay for such service.
Nginx как посчитать req sitdf
I have gone through some tools like nagios, collectd but they din’t find best as we need to monitor no_of_req/sec for each virtual host with all response status, with response time also.
2 Answers 2
I’m Using ELK Stack :
Separate access logs for each server block for better visibility or you can separate charts via URLs.
Then Use ELK stack :
- Feed the logs to logstash via filebeat.
- Create grok pattern for your log model.
- Create charts via kibana and monitor in real time.
For realtime monitoring:
Try netdata, Its amazing. Please note its not a replacement for nagios or zabbix.
After some quick research, I found this: check_nginx_status.pl. I think defining something like:
is probably just what you’re looking for.
The -s flag ($ARG1$) would be the hostname of the virtual host
The -u flag ($ARG2$) would be the specific url (/something/status)
And then the rest of the args would be used if you needed to add any additional flags.
gfrankliu/nginx-http-reqstat
This module will help monitor running status of nginx.
It can provide running status information of nginx.
The information is divided into different zones, and each zone is independent.
The status information is about connections, requests, response status codes, input and output flows, rt, and upstreams.
It shows all the results by default, and can be set to show part of them by specifying zones.
patch -p1 < /path/to/nginx-http-reqstat/connection.patch ./configure —add-module=/path/to/nginx-http-reqstat
when you call ‘/tenginestats’, you will get the results like this:
Each line shows the status infomation of a «$host,$server_addr:$server_port».
- kv value of the variable defined by the directive ‘req_status_zone’
- bytes_in_total total number of bytes received from client
- bytes_out_total total number of bytes sent to client
- conn_total total number of accepted connections
- req_total total number of processed requests
- 2xx total number of 2xx requests
- 3xx total number of 3xx requests
- 4xx total number of 4xx requests
- 5xx total number of 5xx requests
- other total number of other requests
- rt_total accumulation of rt (round trip time)
- upstream_req total number of requests calling for upstream
- upstream_rt accumulation of upstream rt
- upstream_tries total number of times calling for upstream
tsar can parse the result and monitor, see also https://github.com/alibaba/tsar
Syntax: req_status_zone zone_name value size
Default: none
Context: main
create shared memory for this module. ‘zone_name’ is the name of memory block. ‘value’ defines the key, in which variables can be used. ‘size’ defines the size of shared memory.
- Notice, if you want to use tsar to monitor, you should not use comma in the key.
Syntax: req_status zone_name1 [zone_name2 [zone_name3]]
Default: none
Enable monitoring. You can specify multiple zones to monitor.
Syntax: req_status_show [zone_name1 [zone_name2 [. ]]]
Default: all the targets defined by ‘req_status_zone’
Context: loc
Display the status information. You can specify zones to display.
This is a tengine module copied from tengine-2.1.0, and made to work with nginx. It follows original tengine license.
Nginx: как узнать время обработки запроса
Веб-сервер nginx позволяет настраивать формат записей лог-файлов. В конфигурационном файле за это отвечает директива log_format.
После установки nginx в файле конфигурации можно увидеть что-то вроде:
В этой записи слово «main» является названием формата лога. После названия с помощью специальных переменных перечислено всё, что должно быть записано в лог.
Переменная $request_time в nginx содержит время обработки запроса в секундах с точностью до миллисекунд (время, прошедшее с момента чтения первых байт от клиента до момента записи в лог после отправки последних байт клиенту).
Создадим дополнительный формат лога, в котором будет использоваться $request_time. Назовём этот формат, к примеру «main_t»:
Теперь можно использовать созданный формат в конфигурациях сайтов (секция server), например: