資訊專欄INFORMATION COLUMN
摘要：通過這個平臺，可以替你提供諸如配置檢查和優(yōu)化監(jiān)控報警等功能。首先，它的是獨立于運行的，這意味著獲取各項指標(biāo)的能力會受到限制。其次，這個需要跟平臺通訊。總而言之，只是將現(xiàn)存的監(jiān)控方式炒冷飯而已。所以我大可放心抬杠，無需擔(dān)心影響別人家的生意。
對于 Nginx Amplify 不了解的同學(xué)，可以搜索一下，在 Nginx 官網(wǎng)上有介紹。
簡單來說，就是你可以在服務(wù)器上安裝一個開源的 Python 寫的 Agent。這個 Agent 會上傳你的 Nginx 實例各種運行時數(shù)據(jù)到 Nginx.inc 的（閉源）SAAS平臺上。
通過這個 SAAS 平臺，Nginx.inc 可以替你提供諸如配置檢查和優(yōu)化、監(jiān)控、報警等功能。
我第一次聽到它，是在今年 Nginx.conf 放出的一個視頻：NGINX: Past, Present, and Future。
這個演講就是在大會開始的時候，由 Nginx 官方的主持人回顧歷史、總結(jié)現(xiàn)在、展望未來。在展望未來的這一篇章中，主持人介紹了 Nginx Amplify，并演示了它的功能。
由于部門內(nèi) Nginx 的監(jiān)控由我所在的 team 負(fù)責(zé)，出于專業(yè)敏感性，聽完之后我就開始搜索 Nginx Amplify 相關(guān)內(nèi)容。
在閱讀了它的 Agent 源碼之后，我的結(jié)論是，Nginx Amplify 并沒有什么用。
首先，它的 Agent 是獨立于 Nginx 運行的，這意味著獲取各項指標(biāo)的能力會受到限制。如果是一個獨立的 Nginx 模塊，其能力應(yīng)該會更強(qiáng)。
其次，這個 Agent 需要跟 SAAS 平臺通訊。盡管這個通訊走 https，不過即使不知道通訊的內(nèi)容，只知道通訊的模式，就可以挖掘出許多有用的數(shù)據(jù)。
要讓部署在內(nèi)網(wǎng)的 Nginx 服務(wù)器跟云端平臺通訊，這個很難說服別人這么做。
最后，也是最重要的理由：這個 Nginx Amplify 沒有什么新意。
Nginx Amplify Agent 采集的數(shù)據(jù)源分為三類，Nginx/Nginx Plus/System。拋開 Nginx Plus 不談，下面是 Agent 現(xiàn)在采集的指標(biāo)內(nèi)容：
Nginx
Nginx 配置
stub_status暴露出來的數(shù)據(jù)
access_log，通過類似于 tail -f 的方式讀取日志文件獲取
error_log，同上
/proc/
System
/proc/ 下面的數(shù)據(jù)。也是通過 psutils 獲取的
其他零零碎碎的系統(tǒng)數(shù)據(jù)
具體代碼在 collectors 下面，感興趣的同學(xué)可以看下。
老實說，上面列出的各個指標(biāo)，除了Nginx 配置和/proc相關(guān)的，我們都已經(jīng)在采集了。
我們業(yè)務(wù)用的是 Nginx 的一個衍生版本——OpenResty，它以 lua API 的形式開放了一些相關(guān)的 Nginx 接口，允許通過 lua 代碼去操作 Nginx 中的數(shù)據(jù)。
對于 stub_status，它的采集數(shù)據(jù)可以通過如下的變量獲?。?/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
我們可以通過ngx.var.connections_active這樣的形式去獲取該變量的值。
對于 access_log，我們目前是在 OpenResty 的 log_by_lua 階段，去獲取跟請求和響應(yīng)相關(guān)的各種數(shù)據(jù)，包括狀態(tài)碼、響應(yīng)時間等等。
這些數(shù)據(jù)會被記錄到每個 Worker 線程獨立的 LRU Cache 中，然后通過 ngx.timer 周期性地匯總到跨進(jìn)程的 shared_dict 里。
匯總的數(shù)據(jù)可以通過后臺任務(wù)定期去讀取、上報。這個后臺任務(wù)也是在 OpenResty 內(nèi)部啟動的。
通過 access_log 去獲取相關(guān)的日志數(shù)據(jù)，受限于 access_log 的文件格式。而在 Nginx 請求上下文去記錄數(shù)據(jù)，則更加方便得多。
對于 error_log，由于 error_log 不像 access_log，沒有一個專門的階段進(jìn)行處理，我們無法通過 lua 代碼的方式介入處理。
目前的做法是引入二次開發(fā)過的 filebeat 作為 Agent，上傳日志內(nèi)容到日志處理系統(tǒng)。
當(dāng)然你也可以把 error_log 寫到 syslog，或者寫入 stderr。這些都是支持的?？傊娣ㄓ泻芏啵檬裁慈Q于現(xiàn)有的監(jiān)控/日志系統(tǒng)是怎么工作的。
對于 /proc 的數(shù)據(jù)，考慮到 lua 現(xiàn)在并沒有 lua-psutils 這樣的庫，如果要想獲得進(jìn)程或系統(tǒng)級別的數(shù)據(jù)，就只能自己寫 C 模塊調(diào)操作系統(tǒng) API 了。
無論選擇 lua 自帶的 C binding，還是 luajit 的 ffi，這條路都不會太難走。
至于 Nginx 配置的檢查和優(yōu)化，這一部分并沒有開源出來。Agent 里面也只是上傳了配置文件而已。
不過如果有必要做，通過前面的幾個方式，我們已經(jīng)采集了不少服務(wù)的運行數(shù)據(jù)了，根據(jù)這些數(shù)據(jù)調(diào)整下配置參數(shù)也不難。
在官方的演示中，我看到 Nginx Amplify 的監(jiān)控指標(biāo)是可以動態(tài)設(shè)置的。這算不上什么黑魔法。
前面說到我們在 log_by_lua 里面去獲取相關(guān)的各種數(shù)據(jù)，這部分的獲取邏輯可以是動態(tài)的。
獲取的邏輯能夠在 LRU Cache 中配置，依靠定時任務(wù)從 redis 中更新。
如果不喜歡 pull，也可以開個 "light thread"，訂閱 redis 的變化，由 redis 推到每個 Nginx Worker 進(jìn)程。
總而言之，Nginx Amplify 只是將現(xiàn)存的監(jiān)控方式炒冷飯而已。
當(dāng)然了，我們這種付不起 Nginx Plus 訂閱費，只能自己實現(xiàn)相似功能的窮光蛋部門，自然不會是 Nginx Amplify 的目標(biāo)客戶。
所以我大可放心抬杠，無需擔(dān)心影響別人家的生意。
不過有個 Nginx Amplify Agent 是個好事，尤其當(dāng)這個 Agent 是運行在 Nginx 外部。也許 Nginx 將來會因此開放出更多監(jiān)控相關(guān)的接口，到時我們就可以順勢而為啦。
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://m.hztianpu.com/yun/39364.html
摘要：如果今后需要修改，再到這段事件處理函數(shù)的位置來修改。這是因為，分清邏輯功能和事件偵聽兩種職責(zé)，是一種良好的實踐。只讓事件處理函數(shù)本身接觸到瀏覽器事件對象，有利于降低代碼耦合，方便獨立測試及維護(hù)。實現(xiàn)事件分發(fā)的設(shè)計模式之一，就是發(fā)布訂閱。 事件分發(fā)的作用 在為頁面添加各類交互功能時，我們熟知的最簡單的做法就是為頁面元素綁定事件，然后在事件處理函數(shù)中，做我們想要做的動作。就像這樣的代碼： ...
摘要：的網(wǎng)站仍然使用有漏洞庫上周發(fā)布了開源社區(qū)安全現(xiàn)狀報告，發(fā)現(xiàn)隨著開源社區(qū)的日漸活躍，開源代碼中包含的安全漏洞以及影響的范圍也在不斷擴(kuò)大。與應(yīng)用安全是流行的服務(wù)端框架，本文即是介紹如何使用以及其他的框架來增強(qiáng)應(yīng)用的安全性。 showImg(https://segmentfault.com/img/remote/1460000012181337?w=1240&h=826); 前端每周清單專注...
摘要：但是，有一件事是肯定的年對全棧開發(fā)者的需求量很大。有一些方法可以解決這個問題，例如模式，或者你可以這么想，其實谷歌機(jī)器人在抓取單頁應(yīng)用程序時沒有那么糟糕。谷歌正在這方面努力推進(jìn)，但不要指望在年會看到任何突破。 對于什么是全棧開發(fā)者并沒有一個明確的定義。但是，有一件事是肯定的：2019 年對全棧開發(fā)者的需求量很大。在本文中，我將向你概述一些趨勢，你可以嘗試根據(jù)這些趨勢來確定你可能要投入的...
摘要：但是，有一件事是肯定的年對全棧開發(fā)者的需求量很大。有一些方法可以解決這個問題，例如模式，或者你可以這么想，其實谷歌機(jī)器人在抓取單頁應(yīng)用程序時沒有那么糟糕。谷歌正在這方面努力推進(jìn)，但不要指望在年會看到任何突破。 對于什么是全棧開發(fā)者并沒有一個明確的定義。但是，有一件事是肯定的：2019 年對全棧開發(fā)者的需求量很大。在本文中，我將向你概述一些趨勢，你可以嘗試根據(jù)這些趨勢來確定你可能要投入的...
閱讀 654·2021-11-18 13:12
閱讀 1394·2021-11-15 11:39
閱讀 2544·2021-09-23 11:22
閱讀 6296·2021-09-22 15:15
閱讀 3728·2021-09-02 09:54
閱讀 2378·2019-08-30 11:10
閱讀 3312·2019-08-29 14:13
閱讀 2965·2019-08-29 12:49
