Welcome!

Release Management Authors: Pat Romanski, Elizabeth White, David H Deans, Liz McMillan, Jnan Dash

Blog Feed Post

Nginx Reverse Proxy (NRP) monitoring

nignx monitoringNginx server currently occupies one of the most popular positions in the world. It is a free, open-source, high-performance HTTP server and reverse proxy, which is known for its high performance, stability, rich feature set, simple configuration, and low resource consumption. Unlike traditional servers, Nginx doesn’t rely on threads to handle requests. Instead it uses a much more scalable event-driven (asynchronous) architecture.

In order to monitor Nginx servers and make sure everything is running “nice and smoothly”, any sysadmin naturally has the option to turn on Nginx’s stub_stats module. However, notice that the statistics available for this popular module unfortunately often don’t convey enough information, especially if you are using Nginx as an HTTP reverse proxy or balancer.  This paper presents the possibility of using the Monitis custom monitor approach to perform online monitoring of a reverse proxy built on the Nginx server platform.

Usage approach

The possibilities for getting statistics from Nginx are very limited, but fortunately, it has a powerful feature to configure a log file. This makes it possible to create necessary statistics by configuring the log file and then watching and grabbing the monitoring data from it.

The presented monitor is divided into two parts: a watching part and a processing part.

The watching part follows the NRP monitor log and accumulates the necessary statistics. The processing part periodically reads the accumulated statistics, executes necessary calculations and sends them to the Monitismainserver.  Then you can simply see the NRP status online on your Monitis account dashboard.

Usually it is important to know while monitoring NRP what the input load is on the NRP server, how this load is divided between target servers and what the percentage of successful responses is, from the target servers.

The current monitor calculates and shows the following metrics:

  1. The input load to NRP (in_load)
    The number of requests which were received, divided by the observation time
  2. The load redirected to destination host 1 (out1_load)
    The number of requests redirected to destination host 1, divided by the observation time
  3. The load redirected to destination host 2 (out2_load)
    The number of requests redirected to destination host 2, divided by the observation time
  4. The percentage of requests which  were redirected to destination host 1 (out1_reqs)
  5. The percentage of requests which  were redirected to destination host 2 (out2_reqs)
  6. The percentage of successfully processed requests by destination host 1 (out1_2xx)
    The number of responses with a successful status code (2xx) relative to the total number of requests to destination host 1
  7. The percentage of successfully processed requests by destination host 2 (out2_2xx)
    The number of responses with a successful status code (2xx) relative to the total number of requests to destination host 2
  8. The common estimation of NRP state (status)

○     OK – normal working state

○     IDLE – idle state (don’t receive any requests)

○     DEAD – NRP is down (Nginx process isn’t found)

 

Notice that metrics 4 and 5 show the real distribution of requests between destination hosts. Their sum always should equal 100%.

NRP monitor log file configuration

The Nginx log format is very flexible, so you can build it by using a lot of Nginx runtime variables. To prepare your ownlogfile there are two directives:

log_format <name> <format pattern>
access_log <path> <[format name [buffer=size]] |> [off]

The log_format directive describes the format of a log entry. Most of the variables can be used to format a log file pattern. The access_log directive sets the path, format and buffer size for the access log file.

For example, the “Own log” file can be declared as follows:

# Own log format
log_format own ‘ $time_local | $server_name | $request_length ‘;
# Own access log
access_log /var/log/nginx/monitor.log own;

It was decided that this monitor log file should have the following format:

<status code>#<responding host address>  e.g.  404#12.13.11.12:80

To do this, we have to add 2 additional lines in the “/etc/ngnix/sites-available/default” config file near the definition of Nginx standard log files in the ngnix server block to define a new log file “monitor.log” like the following:

# definition of new log file format

log_format monitor '$upstream_status#$upstream_addr';

# specification of location for new log file

access_log /var/log/nginx/monitor.log monitor;

NRP monitor customization

The monitor consists of two main scripts – the watching and accumulating script (called monitor.sh) and the processing script (called nginx_monitor.sh) that periodically requests data, processes it and sends it to Monitis. Besides these, there is the Monitis OpenAPI wrapper script (called monitis_api.sh) and few serviced scripts. Thus, as you can see, it was fully implemented by using Linux Bash scripts.

To use it you should tune it by replacing some parameters (constants) by your own – APIKey, ServiceKey, HRP host IP, Target servers IPs, and so on. For detailed instructions you can look through the sourcecode.

NRP monitor test

The simplest configuration was chosen for testing of the reverse proxy.

Two destination hosts were simulating responses by generating random status codes with normal probability distribution and with mean value – 2xx successful code. The input load was generated by an HTTP generator which provided a load on NRP of about 1 request per second.

NRP was tuned to round-robin distribution so that the input load should have been distributed equally between the designated hosts. As result we got the following monitoring table in our Monitis account:

Notice that during the test the NRP was restarted. The monitor detected this and marked it as NRP DEAD status.

Double-clicking on any line will show more detailed additional information:

Double-clicking on the DEAD status line shows the following:

Naturally, it is possible to look at the graphical presentation of the monitored data:

This graph shows the distribution of requests between the two destination hosts. As you can see, the distribution of requests is done almost equally and the curves fluctuate around 50%, which is normal for our tests.

 

Share Now:del.icio.usDiggFacebookLinkedInBlinkListDZoneGoogle BookmarksRedditStumbleUponTwitterRSS

Read the original blog entry...

More Stories By Hovhannes Avoyan

Hovhannes Avoyan is the CEO of PicsArt, Inc.,

IoT & Smart Cities Stories
CloudEXPO | DevOpsSUMMIT | DXWorldEXPO are the world's most influential, independent events where Cloud Computing was coined and where technology buyers and vendors meet to experience and discuss the big picture of Digital Transformation and all of the strategies, tactics, and tools they need to realize their goals. Sponsors of DXWorldEXPO | CloudEXPO benefit from unmatched branding, profile building and lead generation opportunities.
DXWorldEXPO LLC announced today that Big Data Federation to Exhibit at the 22nd International CloudEXPO, colocated with DevOpsSUMMIT and DXWorldEXPO, November 12-13, 2018 in New York City. Big Data Federation, Inc. develops and applies artificial intelligence to predict financial and economic events that matter. The company uncovers patterns and precise drivers of performance and outcomes with the aid of machine-learning algorithms, big data, and fundamental analysis. Their products are deployed...
All in Mobile is a place where we continually maximize their impact by fostering understanding, empathy, insights, creativity and joy. They believe that a truly useful and desirable mobile app doesn't need the brightest idea or the most advanced technology. A great product begins with understanding people. It's easy to think that customers will love your app, but can you justify it? They make sure your final app is something that users truly want and need. The only way to do this is by ...
Digital Transformation and Disruption, Amazon Style - What You Can Learn. Chris Kocher is a co-founder of Grey Heron, a management and strategic marketing consulting firm. He has 25+ years in both strategic and hands-on operating experience helping executives and investors build revenues and shareholder value. He has consulted with over 130 companies on innovating with new business models, product strategies and monetization. Chris has held management positions at HP and Symantec in addition to ...
Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more busine...
The challenges of aggregating data from consumer-oriented devices, such as wearable technologies and smart thermostats, are fairly well-understood. However, there are a new set of challenges for IoT devices that generate megabytes or gigabytes of data per second. Certainly, the infrastructure will have to change, as those volumes of data will likely overwhelm the available bandwidth for aggregating the data into a central repository. Ochandarena discusses a whole new way to think about your next...
Cell networks have the advantage of long-range communications, reaching an estimated 90% of the world. But cell networks such as 2G, 3G and LTE consume lots of power and were designed for connecting people. They are not optimized for low- or battery-powered devices or for IoT applications with infrequently transmitted data. Cell IoT modules that support narrow-band IoT and 4G cell networks will enable cell connectivity, device management, and app enablement for low-power wide-area network IoT. B...
The hierarchical architecture that distributes "compute" within the network specially at the edge can enable new services by harnessing emerging technologies. But Edge-Compute comes at increased cost that needs to be managed and potentially augmented by creative architecture solutions as there will always a catching-up with the capacity demands. Processing power in smartphones has enhanced YoY and there is increasingly spare compute capacity that can be potentially pooled. Uber has successfully ...
SYS-CON Events announced today that CrowdReviews.com has been named “Media Sponsor” of SYS-CON's 22nd International Cloud Expo, which will take place on June 5–7, 2018, at the Javits Center in New York City, NY. CrowdReviews.com is a transparent online platform for determining which products and services are the best based on the opinion of the crowd. The crowd consists of Internet users that have experienced products and services first-hand and have an interest in letting other potential buye...
When talking IoT we often focus on the devices, the sensors, the hardware itself. The new smart appliances, the new smart or self-driving cars (which are amalgamations of many ‘things'). When we are looking at the world of IoT, we should take a step back, look at the big picture. What value are these devices providing. IoT is not about the devices, its about the data consumed and generated. The devices are tools, mechanisms, conduits. This paper discusses the considerations when dealing with the...