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