昨天聊到建立監控機制來維護上線的服務，我們可以收集系統的指標如 CPU、RAM 的使用率來確認某一時間內的系統狀態，也可以定期儲存 API Request 的 Response Time、QPS 來觀察系統的效能有沒有被影響。

那麼，這些 Metrics 都是怎麼被我們所收集的呢？又有哪些 Monitoring 的工具及服務可以使用？我們今天就來聊聊這個話題。

監控的資料取樣

假設我們今天要監控一台 Linux Server 的相關指標，例如 CPU Usage、RAM Usage 的等等，可以透過 Linux 的 /proc/stat 和 /proc/meminfo 檔案中來取得資料，這些資訊會被 Linux Kernel 以相當快的速度寫入這兩個檔案。

然而，我們如果要監控這台 Server，不太可能 Kernel 寫多快，我們就存多少，因為不但資料量巨大、頻繁的讀取會消耗性能，而且也沒這個必要。

*資料取樣

所以我們收集這些資料的方式大多都是用取樣的，可能每秒可以產生一筆資料，但我們每 5 秒才取樣一次。雖然這樣做會造成資料這 5 秒內明明有起起伏伏，在事後看起來卻像是這 5 秒內的數值完全不變，但深究常見的需求，我們根本不需要這極短時間內波動的細節。

大部分的指標資料，我們每 5 秒、每 30 秒，甚至每分鐘看一次就已經能看出系統在那段時間內的狀態如何了，CPU 要一直處於高運轉持續個幾分鐘才會讓人感到有緩慢的感覺，若是幾秒內忽然飆高但又降回來，其實使用者也不太會意識到有什麼狀況。

*Monitoring Server 每隔一段時間取樣一次

理解了監控系統的取樣行為，接下來我們來看看取得資料的兩種常見行為，Push Model 及 Pull Model。

Push Model

當 Monitoring Server 要取樣目標 Server 的指標，一種是讓目標 Server 丟資料過來，而另外一種則是主動和目標 Server 要資料。前者就是所謂 Push Model，以被監控的目標 Server 作為 Client，Push 資料到 Monitoring Server。

*Push Model

這種模式的優點就是當目標 Server 難以從外界直接聯絡的狀態時，例如 IoT 的設備、處於 Private Network 時，就可以讓 Target Server 直接將資料 Push 給能被找到位置的 Monitoring Server（例如在範例中的 Public IP Address 1.2.3.4）。

另一個優點就是當我們想監測的指標是比較有時效性的、Event-Based 的資訊，需要立刻收到產生 Alert，也適合用 Push Model。

但是缺點也便是以 Monitoring Server 的角度來看，沒有辦法自由控制什麼時候收到資料。如果想修改所有 Clients（目標的 Servers）的送資料頻率，需要一個一個改。

這類 Push Model 的常見工具有 Graphite，是個時序行資料庫（Time Series Database）。可以搭配 CollectD 放在 Client 中，擷取系統資料 Push 上去 Graphite。

Pull Model

而另一種 Pull Model，做的事情就是以 Monitoring Server 的角度，主動和 Clients（目標的 Servers）要資料，所以稱作 Pull。

其缺點便是當 Clients 處於無法 Access 的網路時，就拿不到資料了，但是反過來說，Monitoring Server 反倒可以位於某 Private Network 中，因為只要能夠主動連線到 Clients 即可。

*Pull Model

除此之外，在 Push Model 中的難以控制收資料頻率的缺點，在 Pull Model 上就是優點了，這種模式可以輕鬆的統一管理所有的 Clients。

像是 Prometheus 便是 Pull Model 代表的工具之一，在其設定檔中可以列舉所有要監控的 Clients，並指派拉取資料的頻率。

Push Model vs. Pull Model

那麼，兩種模式到底哪一種好呢？

我們一樣可以從需求下手，先看看網路的環境是否是我們能控制的，例如有目標 Servers 在無法直接連線的網路中，就可以挑選 Push Model；若是 Monitoring Server 架在自己的公司的 Private Network 內，或許挑選 Pull Model 就更適合。

如果有需要即時 Alert 的場景，就選用 Push Model；若是有大量的高頻資訊一直被 Push 到 Monitoring Server，可能就改用 Pull Model 較佳。

但選用 Model 也不是非黑即白，小朋友才做選擇，有些情況我兩種都要。例如我的 Monitoring Server 在 Private Network，而且又有 IoT 的設備怎麼辦？

我常用的 Prometheus 就有 Push Gateway 這樣的輔助工具，可以緩解其 Pull Model 的缺陷，透過將資料先 Push 到 Push Gateway 中保存，再被 Prometheus 定期拉取這些資料。

總而言之，一切端看需求，但不論是哪一種 Model 的監控，都能在我們的服務上線之後，給我們更多對於部署環境的掌控度，以及更多的資訊來處理未來可能發生的錯誤。

完賽心得

這算是我第三次參加 iT 鐵人賽，前兩次分別寫了網路相關的系列文：網路通訊輕鬆聊、網路通訊隨意聊，這次特別挑戰撰寫不同的主題，全端開發的系列文。

原本想在撰文的過程中，也將從提需求、開發，一路到測試、部署全生命週期的內容搭配一個實際的產品做範例，並且附上 Git Repository，但現實總是很骨感的。

雖說如此，也很慶幸花精力寫了這些文章，這是平時很難擠出時間整理，屬於自己完整消化過的知識。

最後分享給大家，我寫了三個系列文之後，所觀察、體悟到的幾個「之最」：

1. 撰文最難也最重要的事：收集好的範例，並能搭配主題使用

2. 點閱率最高的文章：講清楚最常見，但也最簡單的理論及 Buzz Word

3. 最有收穫的事：基於不斷的閱讀、撰文、思考，建立一個自己的知識體系

最後的最後，感謝看到這裡的各位讀者，共勉之。