摘要：通過(guò)這個(gè)平臺(tái)，可以替你提供諸如配置檢查和優(yōu)化監(jiān)控報(bào)警等功能。首先，它的是獨(dú)立于運(yùn)行的，這意味著獲取各項(xiàng)指標(biāo)的能力會(huì)受到限制。其次，這個(gè)需要跟平臺(tái)通訊?？偠灾?，只是將現(xiàn)存的監(jiān)控方式炒冷飯而已。所以我大可放心抬杠，無(wú)需擔(dān)心影響別人家的生意。

對(duì)于 Nginx Amplify 不了解的同學(xué)，可以搜索一下，在 Nginx 官網(wǎng)上有介紹。
簡(jiǎn)單來(lái)說(shuō)，就是你可以在服務(wù)器上安裝一個(gè)開源的 Python 寫的 Agent。這個(gè) Agent 會(huì)上傳你的 Nginx 實(shí)例各種運(yùn)行時(shí)數(shù)據(jù)到 Nginx.inc 的（閉源）SAAS平臺(tái)上。
通過(guò)這個(gè) SAAS 平臺(tái)，Nginx.inc 可以替你提供諸如配置檢查和優(yōu)化、監(jiān)控、報(bào)警等功能。

我第一次聽到它，是在今年 Nginx.conf 放出的一個(gè)視頻：NGINX: Past, Present, and Future。
這個(gè)演講就是在大會(huì)開始的時(shí)候，由 Nginx 官方的主持人回顧歷史、總結(jié)現(xiàn)在、展望未來(lái)。在展望未來(lái)的這一篇章中，主持人介紹了 Nginx Amplify，并演示了它的功能。
由于部門內(nèi) Nginx 的監(jiān)控由我所在的 team 負(fù)責(zé)，出于專業(yè)敏感性，聽完之后我就開始搜索 Nginx Amplify 相關(guān)內(nèi)容。

在閱讀了它的 Agent 源碼之后，我的結(jié)論是，Nginx Amplify 并沒(méi)有什么用。

首先，它的 Agent 是獨(dú)立于 Nginx 運(yùn)行的，這意味著獲取各項(xiàng)指標(biāo)的能力會(huì)受到限制。如果是一個(gè)獨(dú)立的 Nginx 模塊，其能力應(yīng)該會(huì)更強(qiáng)。

其次，這個(gè) Agent 需要跟 SAAS 平臺(tái)通訊。盡管這個(gè)通訊走 https，不過(guò)即使不知道通訊的內(nèi)容，只知道通訊的模式，就可以挖掘出許多有用的數(shù)據(jù)。
要讓部署在內(nèi)網(wǎng)的 Nginx 服務(wù)器跟云端平臺(tái)通訊，這個(gè)很難說(shuō)服別人這么做。

最后，也是最重要的理由：這個(gè) Nginx Amplify 沒(méi)有什么新意。

Nginx Amplify Agent 采集的數(shù)據(jù)源分為三類，Nginx/Nginx Plus/System。拋開 Nginx Plus 不談，下面是 Agent 現(xiàn)在采集的指標(biāo)內(nèi)容：

Nginx

Nginx 配置

stub_status暴露出來(lái)的數(shù)據(jù)

access_log，通過(guò)類似于 tail -f 的方式讀取日志文件獲取

error_log，同上

/proc/ 相關(guān)的數(shù)據(jù)。這是通過(guò) psutils 獲取的

System

/proc/ 下面的數(shù)據(jù)。也是通過(guò) psutils 獲取的

其他零零碎碎的系統(tǒng)數(shù)據(jù)

具體代碼在 collectors 下面，感興趣的同學(xué)可以看下。

老實(shí)說(shuō)，上面列出的各個(gè)指標(biāo)，除了Nginx 配置和/proc相關(guān)的，我們都已經(jīng)在采集了。

我們業(yè)務(wù)用的是 Nginx 的一個(gè)衍生版本——OpenResty，它以 lua API 的形式開放了一些相關(guān)的 Nginx 接口，允許通過(guò) lua 代碼去操作 Nginx 中的數(shù)據(jù)。

對(duì)于 stub_status，它的采集數(shù)據(jù)可以通過(guò)如下的變量獲?。?/p>

$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

我們可以通過(guò)ngx.var.connections_active這樣的形式去獲取該變量的值。

對(duì)于 access_log，我們目前是在 OpenResty 的 log_by_lua 階段，去獲取跟請(qǐng)求和響應(yīng)相關(guān)的各種數(shù)據(jù)，包括狀態(tài)碼、響應(yīng)時(shí)間等等。
這些數(shù)據(jù)會(huì)被記錄到每個(gè) Worker 線程獨(dú)立的 LRU Cache 中，然后通過(guò) ngx.timer 周期性地匯總到跨進(jìn)程的 shared_dict 里。
匯總的數(shù)據(jù)可以通過(guò)后臺(tái)任務(wù)定期去讀取、上報(bào)。這個(gè)后臺(tái)任務(wù)也是在 OpenResty 內(nèi)部啟動(dòng)的。
通過(guò) access_log 去獲取相關(guān)的日志數(shù)據(jù)，受限于 access_log 的文件格式。而在 Nginx 請(qǐng)求上下文去記錄數(shù)據(jù)，則更加方便得多。

對(duì)于 error_log，由于 error_log 不像 access_log，沒(méi)有一個(gè)專門的階段進(jìn)行處理，我們無(wú)法通過(guò) lua 代碼的方式介入處理。
目前的做法是引入二次開發(fā)過(guò)的 filebeat 作為 Agent，上傳日志內(nèi)容到日志處理系統(tǒng)。
當(dāng)然你也可以把 error_log 寫到 syslog，或者寫入 stderr。這些都是支持的?？傊?，玩法有很多，用什么取決于現(xiàn)有的監(jiān)控/日志系統(tǒng)是怎么工作的。

對(duì)于 /proc 的數(shù)據(jù)，考慮到 lua 現(xiàn)在并沒(méi)有 lua-psutils 這樣的庫(kù)，如果要想獲得進(jìn)程或系統(tǒng)級(jí)別的數(shù)據(jù)，就只能自己寫 C 模塊調(diào)操作系統(tǒng) API 了。
無(wú)論選擇 lua 自帶的 C binding，還是 luajit 的 ffi，這條路都不會(huì)太難走。

至于 Nginx 配置的檢查和優(yōu)化，這一部分并沒(méi)有開源出來(lái)。Agent 里面也只是上傳了配置文件而已。
不過(guò)如果有必要做，通過(guò)前面的幾個(gè)方式，我們已經(jīng)采集了不少服務(wù)的運(yùn)行數(shù)據(jù)了，根據(jù)這些數(shù)據(jù)調(diào)整下配置參數(shù)也不難。

在官方的演示中，我看到 Nginx Amplify 的監(jiān)控指標(biāo)是可以動(dòng)態(tài)設(shè)置的。這算不上什么黑魔法。
前面說(shuō)到我們?cè)?log_by_lua 里面去獲取相關(guān)的各種數(shù)據(jù)，這部分的獲取邏輯可以是動(dòng)態(tài)的。
獲取的邏輯能夠在 LRU Cache 中配置，依靠定時(shí)任務(wù)從 redis 中更新。
如果不喜歡 pull，也可以開個(gè) "light thread"，訂閱 redis 的變化，由 redis 推到每個(gè) Nginx Worker 進(jìn)程。

總而言之，Nginx Amplify 只是將現(xiàn)存的監(jiān)控方式炒冷飯而已。
當(dāng)然了，我們這種付不起 Nginx Plus 訂閱費(fèi)，只能自己實(shí)現(xiàn)相似功能的窮光蛋部門，自然不會(huì)是 Nginx Amplify 的目標(biāo)客戶。
所以我大可放心抬杠，無(wú)需擔(dān)心影響別人家的生意。

不過(guò)有個(gè) Nginx Amplify Agent 是個(gè)好事，尤其當(dāng)這個(gè) Agent 是運(yùn)行在 Nginx 外部。也許 Nginx 將來(lái)會(huì)因此開放出更多監(jiān)控相關(guān)的接口，到時(shí)我們就可以順勢(shì)而為啦。