Home PC Games Linux Windows Database Network Programming Server Mobile  
           
  Home \ Database \ How to monitor Nginx     - Linux operating system boot manager -GRUB (Linux)

- How to install and configure a VNC server on CentOS 7.0 (Server)

- Hazelcast integration with MongoDB (Database)

- Configuring Allatori code confusion when developing general Java applications in NetBeans (Programming)

- MySQL optimization of the relevant Group By (Database)

- 10 useful tools for Linux users (Linux)

- Linux install Maven and SVN client (Linux)

- Linux system security norms (Linux)

- How to adjust the system time CentOS (Linux)

- Linux firewall to prevent external network attacks (Linux)

- HttpClient Tutorial (Programming)

- C ++ Supplements - malloc free and new delete the same and different (Programming)

- Netfilter / Iptables Comments (Linux)

- Installation of Gitlab under Ubuntu (Linux)

- Linux System Getting Started Learning: Debian download, installation and graphical interface (Linux)

- Commonly used Linux system camouflage method (Linux)

- Linux some lessons learned about network security (Linux)

- MySQL Slave synchronization problem solving (Database)

- Database Blob data type conversion String (Programming)

- Linux operating system, the internal and external security overview (Linux)

 
         
  How to monitor Nginx
     
  Add Date : 2018-11-21      
         
         
         
  What NGINX that?

NGINX (pronounced "engine X") is a popular HTTP server and reverse proxy. As an HTTP server, NGINX use less memory is very efficient and reliable delivery of static content. As a reverse proxy, it can be used multiple back-end servers or the like caching and load balancing of such single access control point other applications. NGINX is a free open source products, and have a more comprehensive feature called NGINX Plus commercial version.

NGINX can also be used as a mail agent and generic TCP proxy, but this article does not directly discuss monitoring NGINX those use cases.

NGINX key indicators

By monitoring NGINX can capture two types of problems: resources NGINX itself, and the emergence of other problems in your network infrastructure. NGINX most users will use to monitor the following indicators, including the number of requests per second, it provides a view of the upper layer consists of all end-user activities thereof; server error rate, which indicates how long your server has not dealt with the seemingly effective request; also request processing time, indicating a total length of your server handles client requests (and can be seen in performance or other current environmental issues).

More generally, there are at least three major categories of indicators to monitor:

The basic activity indicators
Error indicator
Performance
Below we will analyze the most important indicators in each category NGINX, and with a fairly common but it is worth special mention to illustrate the case: use NGINX Plus as a reverse proxy. We will also describe how to use graphical tools or alternative monitoring tools to monitor all indicators.

This article refers to index term from our "101 Series Monitor" ,, it provides a metric collection and warning framework.

Active basic indicators

Whether you use NGINX under what circumstances, there is no doubt how much you want to monitor the server receives client requests and how to deal with these requests.

The same as open source NGINX can report on basic indicators of active NGINX Plus, but it also offers a slightly different auxiliary modules. We first discuss the open source NGINX, again illustrate the functionality of other indicators NGINX Plus provides.

NGINX


Accepts (accepted), Handled (processed), Requests (request) has been on the increase in counter. Active (active), Waiting (waiting), Reading (Reading), Writing (writing) request with the amount of increase or decrease.

Name Description Type Indicator
Accepts NGINX accepted client connections resources: Function
Handled successful client connection resources: Function
Active currently active client connections resources: Function
Dropped (discarded, calculated) number of connections discarded (acceptance - processed) Work: error *
Requests Client requests work: Throughput
* Strictly speaking, dropped connections saturation index is a resource, but because of saturation will cause NGINX stop service (rather than postpone the request), therefore, "has been dropped," seen as a more appropriate indicator of work.

When NGINX worker process to accept connection requests the OS Accepts counter increased, and Handled is when the actual request was connected (through the establishment of a new connection or re-use a spare). The two counter values are usually the same, if they are different then the connection is Dropped, often this is due to resource constraints, such as restrictions on the worker_connections NGINX has reached.

Once NGINX successfully handle a connection, the connection will be moved to the Active state, where the client requests are processed:

Active state

Waiting: Active connection can also be in Waiting substate, if at the moment there is no active requested. When new connections can bypass this state and goes directly to the Reading state, the most common is the use of "accept filter (Accept Filter)" and "deferred accept (delayed acceptance)," in this case, NGINX not worker received notification process until it has enough data began to respond. If the connection is set to keep-alive, then it will send a response in a wait state.

Reading: When receiving the request, the connection to leave the Waiting state, and the request itself makes Reading state count is incremented. In this state NGINX reads the client request header. Request header is relatively small, so this is usually a fast operation.

Writing: After the request has been read, it makes Writing status keeps increasing, and remain in this state until a response is returned to the client. This means that, at the time of the request Writing state, on the one hand NGINX waiting for results from an upstream system (system on NGINX "behind"), on the other hand, NGINX also respond simultaneously. Requests tend to spend a lot of time in the state of Writing.

Typically, a connection at the same time accepting only one request. In this case, the number of Active connections == Waiting connection requests + Reading + Writing. However, newer SPDY and HTTP / 2 protocol allows multiple concurrent requests / responses reuse a connection, it may be less than Active Waiting for connection, Reading request, the sum Writing request. (At this writing, NGINX does not support HTTP / 2, it is expected that 2015 will be supported.)

NGINX Plus

As mentioned above, all open source NGINX indicators in NGINX Plus is available, but also provides additional other indicators. This section describes only indicators NGINX Plus available.

Accepted (Accepted), Dropped, the total number is increasing counter. Active, Idle (idle) and in the Current (current) connected to various processing stages under state or the current number of requests with the request and the amount of increase or decrease.

Name Description Type Indicator
Accepted NGINX accepted client connections resources: Function
Dropped connections dropped (to accept - processed) Work: error *
Active currently active client connections resources: Function
Idle current request no client connection resources: Function
Total (all) client requests work: Throughput
* Strictly speaking, dropped connections saturation index is a resource, but because of saturation will cause NGINX stop service (rather than postpone the request), therefore, "has been dropped," seen as a more appropriate indicator of work.

When NGINX Plus worker process to accept connection requests the OS Accepted counter increments. If the worker process to request to establish a connection fails, the connection is dropped (a new connection or through the establishment of a free re-use), Dropped count is incremented. Typically connections to be dropped because of resource constraints, such as restrictions worker_connections of NGINX Plus has reached.

Active and Idle and open source NGINX described above "active" and "waiting" state is the same, but a little key difference: the open source NGINX, "waiting" status is included in the "active", while in NGINX Plus the "idle" connection is excluded from the "active" counter outside. Current and open source NGINX is the same also by the "reading + writing" state components.

Total client requests a cumulative count. Note that a single client connection may involve multiple requests, so this number may be significantly larger than the cumulative number of connections. In fact, (total / accepted) the average number of requests per connection.

Between the different indicators of open source and Plus

NGINX (open source) NGINX Plus
accepts accepted
dropped by dropped directly calculated to
reading + writing current
waiting idle
active (including the "waiting" status) active (exclude the "idle" state)
requests total
Remind index: Drop connection

The number of connections to be dropped is equal to the difference between the Accepts and Handled (NGINX in), or can be obtained directly Standard metrics (NGINX Plus in). Under normal circumstances, the number of dropped connections should be zero. If the drop in the speed of the connection each time the unit starts to rise, we should see if the resource is saturated.

Remind indicators: The number of requests per second

Sampling at regular intervals you request data (source NGINX of requests or NGINX Plus in total) will be provided to you within a unit of time (usually minutes or seconds) the number of requests accepted. Monitoring this indicator can view incoming Web traffic spikes, whether it is legitimate or malicious, or a sudden drop, which usually represents a problem. If the number of requests per second, dramatic changes can remind you of environmental problems, even if it can tell you the exact location of the problem lies. Please note that all requests are counted equally, no matter what the URL is.

Active collection index

NGINX open source provides a simple status page to show the basic server metrics. This status information is displayed in a standard format, graphics or virtually any monitoring tool can be configured to parse the data for analysis, visualization, or reminders. NGINX Plus provides a JSON interface supply more data. Read the article "NGINX metric collection" to enable metrics collection function.

Error indicator

Name Description index type can be used
4xx error code on the client count operation: NGINX error log, NGINX Plus
5xx code server side error count work: NGINX error log, NGINX Plus
NGINX error indicator tells you whether the server often returns error instead of the normal work. Client Error status code returned 4XX, 5XX server error return status codes.

Remind index: Server Error Rate

Server error rate is equal to the total number of the total number of 5xx error status codes within the divided state code (1XX, 2XX, 3XX, 4XX, 5XX) in a unit of time (usually one to five minutes). If your error rate began to rise over time to investigate possible causes. If the sudden increase may need to take urgent action, because the client may receive an error message.

About client error note: While monitoring 4XX is very useful, but the indicators you can capture only limited information, because it is just a measure to capture customer behavior without any special URL. In other words, the change appears 4xx may be a signal, such as a network scanner to your site looking for vulnerabilities.

Error metrics collection

Although the open-source NGINX not immediately get used to monitor the error rate, but at least there are two ways you can get:

Expansion module status commercial support provided NGINX Plus
NGINX configuration log module write access to the log response codes
About these two methods, please read the article "NGINX metrics collection."

Performance

Name Description index type can be used
request time (request processing time) processing time for each request, in seconds. Work: Performance Logs NGINX
Remind indicators: request processing time

Request processing time indicators recorded NGINX processing time for each request from the client to read the first byte of a request to complete the request. Longer response time illustrate the problem upstream.

Collection and processing time index

NGINX and NGINX Plus users can add $ request_time variable to the access log format to capture the data processing time. More details on configuring Log Monitoring in NGINX metrics collection.

Reverse proxies

Name Description index type can be used
Active links upstream server client connections currently active resource: Function NGINX Plus
5xx error code server upstream server malfunction: Error NGINX Plus
Upstream of each group passed health checks available server server resource: Availability NGINX Plus
NGINX reverse proxy is one of the most common methods of use. Commercial support NGINX Plus show a lot about the back-end (or "upstream upstream") of server metrics, these reverse proxy-related settings. This section highlights several key upstream indicators NGINX Plus available to the user.

NGINX Plus it is first upstream indicators by group separately, and then is directed to a single server. Thus, for example, your reverse proxy requests assigned to five upstream Web server, you can see at a glance whether there is too much pressure on a single server, you can see the health of the upstream group servers to ensure good Response time.

Active Index

The number of active connections for each of the upstream server can help you identify the correct reverse proxy is assigned to work on your entire server group. If you are using NGINX as a load balancer, obvious bias connections of any one server process may indicate that the server is trying to digest request, or load balancing method you used for configuration (for example, round-robin or IP hashing) is not most suitable for your traffic patterns.

Error indicator

Error indicator is higher than the above mentioned 5XX (server error) status code is a valuable monitoring indicators, especially the response code section. Number NGINX Plus allows you to easily extract each of the upstream server 5xx error codes, and the total number of responses, in order to determine the error rate of a particular server.

Availability objectives

For the health of the web server, there is another point of view, NGINX current total amount of available servers can easily monitor the health of your upstream group by each group. On a large reverse proxy, which you may not be very concerned about the current state of a server, as long as you have an available server group can handle the current load on the line. But the total upstream server monitoring all the work within the group can provide a higher level of perspective for judging the health of Web servers.

Collected upstream indicators

NGINX Plus upstream indicators appear on the internal NGINX Plus monitoring dashboard, and can also be a JSON interface and services to a variety of external monitoring platform. In our related article "NGINX metrics collection," There is a case in point.

in conclusion

In this article, we have discussed some useful indicators that you can use to monitor form NGINX server. If you are just getting started with NGINX, most or all of the monitoring indicators provided below, you can make a good understanding of health and the level of activity of your network infrastructure:

Dropped connections
Requests per second
Server Error Rate
Request processing data
Eventually, you'll learn more and more professional measure, especially with regard to your own infrastructure and usage. Of course, an indicator monitoring which will depend on your available tools. See related article to walk you through the metrics collection, whether you use NGINX or NGINX Plus.

In Datadog, we have integrated NGINX and NGINX Plus, so you can with minimal settings to collect and monitor metrics for all Web servers. In this article learn how to use NGINX Datadog to monitor, and start your free trial Datadog it.
     
         
         
         
  More:      
 
- Linux variable learning experience (Linux)
- Enterprise Encrypting File System eCryptfs Comments (Linux)
- Strategy Games Ubuntu installation of Wesnoth 1.12.1 (Linux)
- Linux Detailed instructions alias settings (Linux)
- Install VMware Tools in Debian (Linux)
- SpringMVC the use of interceptors (Programming)
- Python regular expressions: how to use regular expressions (Programming)
- Firewall Configuration Red Hat Enterprise Linux 4 (Linux)
- Ceph tuning --Journal and tcmalloc (Server)
- C / C ++ language usage summary of const (Programming)
- Linux compiler of GCC (Linux)
- Linux static library generated Guide (Programming)
- Ubuntu how to install and use Objective-C (Linux)
- To batch create users under Linux (Linux)
- MySQL Tutorial: Philosophical Reflections on the unauthenticated user (Database)
- CentOS system Amoeba + MySQL Master-slave configuration (Database)
- Linux file content inspection - cat, tac, no, more, less, head, tail, od (Linux)
- Summary of Docker mounted directory (Server)
- VirtualBox virtual machine can not start to solve under Ubuntu (Linux)
- Under CentOS 7 installation and deployment environment Ceph (Server)
     
           
     
  CopyRight 2002-2020 newfreesoft.com, All Rights Reserved.