For those who don't know about Nginx Amplify, you can search for it and introduce it on the Nginx website.
Simply put, you can install an open source Python written agent on the server. This Agent will upload various runtime data for your Nginx instance to the (closed source) SAAS platform of Nginx.inc.
Through this SAAS platform, Nginx.inc provides you with features such as configuration checking and optimization, monitoring, and alarms.

The first time I heard about it, it was a video released this year at Nginx.conf:NGINX: Past, Present, and Future。
This speech was made at the beginning of the conference, and the official Nginx host reviewed the history, summed up the present, and looked into the future. In this chapter looking into the future, the host introduced Nginx Amplify and demonstrated its capabilities.
Since the monitoring of Nginx in the department is the responsibility of my team, for professional sensitivity, I started searching for Nginx Amplify after listening.

After reading its agentSource codeAfter that, my conclusion is that Nginx Amplify is not useful.

First, its Agent runs independently of Nginx, which means that the ability to get metrics is limited. If it is a standalone Nginx module, its capabilities should be stronger.

Second, the Agent needs to communicate with the SAAS platform. Although this communication goes to https, even if you don't know the content of the communication, you only know the communication mode, you can mine a lot of useful data.
To make the Nginx server deployed on the intranet communicate with the cloud platform, it is difficult to convince others to do so.

Finally, and for the most important reason: this Nginx Amplify is nothing new.

The data sources collected by the Nginx Amplify Agent are divided into three categories, Nginx/Nginx Plus/System. Aside from Nginx Plus, here's what the Agent is collecting now:

• Nginx

  • Nginx configuration

  • stub_statusExposed data

  • Access_log, read log file by way similar to tail -f

  • Error_log, same as above

  • /proc/<nginx_pid> related data. This is throughpsutils Acquired

• System

  • /proc/ The following data. Also passedpsutils Acquired

  • Other fragmented system data

The specific code iscollectors Below, interested students can look at it.

Honestly, the various indicators listed above, exceptNginx configurationwith/procRelated, we are already collecting.

Our business uses a derivative version of Nginx -OpenRestyIt opens up some related Nginx interfaces in the form of the lua API, allowing the data in Nginx to be manipulated via lua code.

For stub_status, its collected data can be obtained by the following variables:

$connections_active
    same as the Active connections value;
$connections_reading
    same as the Reading value;
$connections_writing
    same as the Writing value;
$connections_waiting
    same as the Waiting value

We can passngx.var.connections_activeThis form takes the value of the variable.

For access_log, we are currently at OpenRestylog_by_lua In the stage, to obtain various data related to the request and response, including status code, response time, and so on.
This data is logged to the separate LRU Cache for each worker thread and then passedngx.timer Periodically aggregated into cross-processshared_dict in.
The aggregated data can be read and reported periodically through background tasks. This background task is also started inside OpenResty.
Obtaining relevant log data through access_log is limited by the file format of access_log. It is much more convenient to log data in the Nginx request context.

For error_log, since error_log is not like access_log, there is no special stage for processing, we can't intervene in the way of lua code.
The current practice is to introduce secondary development.filebeat As an agent, upload log content to the log processing system.
Of course you can also write error_log to syslog or write to stderr. These are all supported. In short, there are many ways to play, and what depends on how the existing monitoring/logging system works.

For the data of /proc, considering that lua is not currentlylua-psutils Such a library, if you want to get data at the process or system level, you can only write the C module to adjust the operating system API.
Whether you choose the C binding that comes with lua or the ffi of luajit, this road will not be too difficult to go.

As for the checking and optimization of Nginx configuration, this part is not open source. The Agent only uploads the configuration file.
However, if it is necessary to do, through the previous several methods, we have collected a lot of service running data, and it is not difficult to adjust the configuration parameters based on these data.

In the official demo, I saw that Nginx Amplify's monitoring metrics can be dynamically set. This is not a black magic.
Said before that we arelog_by_lua Inside to get the relevant data, this part of the acquisition logic can be dynamic.
The acquired logic can be configured in the LRU Cache and updated from redis by timing tasks.
If you don't like pull, you can also open a 'light thread' and subscribe to the redis changes, which are pushed by redis to each Nginx Worker process.

All in all, Nginx Amplify just sizzles the existing monitoring methods.
Of course, we can't afford the Nginx Plus subscription fee, we can only achieve the similar function of the poor, and naturally it will not be the target customer of Nginx Amplify.
Therefore, I can safely lift the bar without worrying about affecting the business of others.

However, having a Nginx Amplify Agent is a good thing, especially if the Agent is running outside of Nginx. Maybe Nginx will open up more monitoring-related interfaces in the future, and then we can take advantage of it.