Welcome!

PHP Authors: Liz McMillan, Carmen Gonzalez, Hovhannes Avoyan, Lori MacVittie, Trevor Parsons

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
Nicolas Fierro is CEO of MIMIR Blockchain Solutions. He is a programmer, technologist, and operations dev who has worked with Ethereum and blockchain since 2014. His knowledge in blockchain dates to when he performed dev ops services to the Ethereum Foundation as one the privileged few developers to work with the original core team in Switzerland.
René Bostic is the Technical VP of the IBM Cloud Unit in North America. Enjoying her career with IBM during the modern millennial technological era, she is an expert in cloud computing, DevOps and emerging cloud technologies such as Blockchain. Her strengths and core competencies include a proven record of accomplishments in consensus building at all levels to assess, plan, and implement enterprise and cloud computing solutions. René is a member of the Society of Women Engineers (SWE) and a m...
Andrew Keys is Co-Founder of ConsenSys Enterprise. He comes to ConsenSys Enterprise with capital markets, technology and entrepreneurial experience. Previously, he worked for UBS investment bank in equities analysis. Later, he was responsible for the creation and distribution of life settlement products to hedge funds and investment banks. After, he co-founded a revenue cycle management company where he learned about Bitcoin and eventually Ethereal. Andrew's role at ConsenSys Enterprise is a mul...
In his general session at 19th Cloud Expo, Manish Dixit, VP of Product and Engineering at Dice, discussed how Dice leverages data insights and tools to help both tech professionals and recruiters better understand how skills relate to each other and which skills are in high demand using interactive visualizations and salary indicator tools to maximize earning potential. Manish Dixit is VP of Product and Engineering at Dice. As the leader of the Product, Engineering and Data Sciences team at D...
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...
Whenever a new technology hits the high points of hype, everyone starts talking about it like it will solve all their business problems. Blockchain is one of those technologies. According to Gartner's latest report on the hype cycle of emerging technologies, blockchain has just passed the peak of their hype cycle curve. If you read the news articles about it, one would think it has taken over the technology world. No disruptive technology is without its challenges and potential impediments t...
If a machine can invent, does this mean the end of the patent system as we know it? The patent system, both in the US and Europe, allows companies to protect their inventions and helps foster innovation. However, Artificial Intelligence (AI) could be set to disrupt the patent system as we know it. This talk will examine how AI may change the patent landscape in the years to come. Furthermore, ways in which companies can best protect their AI related inventions will be examined from both a US and...
Bill Schmarzo, Tech Chair of "Big Data | Analytics" of upcoming CloudEXPO | DXWorldEXPO New York (November 12-13, 2018, New York City) today announced the outline and schedule of the track. "The track has been designed in experience/degree order," said Schmarzo. "So, that folks who attend the entire track can leave the conference with some of the skills necessary to get their work done when they get back to their offices. It actually ties back to some work that I'm doing at the University of San...
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...
Bill Schmarzo, author of "Big Data: Understanding How Data Powers Big Business" and "Big Data MBA: Driving Business Strategies with Data Science," is responsible for setting the strategy and defining the Big Data service offerings and capabilities for EMC Global Services Big Data Practice. As the CTO for the Big Data Practice, he is responsible for working with organizations to help them identify where and how to start their big data journeys. He's written several white papers, is an avid blogge...