内容簡要：
一、為什麼需要監控系統
二、用監控系統解決問題
三、監控系統的部署
離開監控系統管理資料庫就像蒙眼開車，我們通過利用監控系統實作對資料庫狀态的觀察與管理，下面通過兩個實驗舉例說明。
（一）實驗1：利用監控系統觀測查詢負載
1）使用正常連接配接數負載，觀察系統狀态
這裡我們做一個實驗，已有一主兩從的資料庫叢集PG-test，為叢集添加50的讀寫QPS，1000的隻讀QPS，利用監控系統的資訊，印證我們主動施加的負載。這個負載是用PG自帶的壓測工具PG Bench生成的。
指令一：
while true; do pgbench -nv -P1 -c4 --select-only --rate=1000 -T10 postgres://test:test@pg-test:5434/test; done
指令二：
第一行指令我們用PG Bench給從庫select-only加上了1000的TPS，第二條指令我們給主庫加上了50的TPS，從庫使用4條連接配接，主庫使用2條連接配接。
那麼我們期待的結果總共加了1050的TPS，主庫50，兩個從庫每人各500，從庫總共1000。
如上圖所示，我們可以看到整個叢集的GPS資料，主庫上的TPS差不多是50左右，從庫上的TPS差不多是1000，符合我們的預期。
2）使用十倍的連接配接數施加同樣負載，觀察系統狀态
接下來我們稍微改動一下，施加同樣的負載，但使用十倍的連接配接數量，原來我們使用了2條讀寫連接配接，4條隻讀連接配接，現在翻十倍變為20條和40條，觀察連接配接池在這一過程中起到的作用。
while true; do pgbench -nv -P1 -c40 --select-only --rate=1000 -T10 postgres://test:test@pg-test:5434/test; done
while true; do pgbench -nv -P1 -c20 --rate=50 -T10 postgres://test:test@pg-test:5433/test; done
我們來看一下監控系統，PG Cluster Session是專門繪畫關于叢集相關的名額，其中的Active Clients by Instance是按照執行個體劃分的連接配接數。如上圖所示，通過最近5分鐘的情況可以看到，之前使用的是6條連接配接，2主2從2從，現在使用60條，就變成20， 20，20。如果說TPS名額它是有一定抖動誤差的話，那麼連接配接數這樣的名額可以算是相當精确了。
3）使用盡可能大的負載，觀察系統在過載下的表現
我們采用沒有 TPS限制的PG Bench，用最大負載把叢集盡可能打滿，觀察系統在過載情況下的表現。
指令一：while true; do pgbench -nv -P1 -c20 -T10 postgres://test:test@pg-test:5433/test; done
指令二：while true; do pgbench -nv -P1 -c40 --select-only -T10 postgres://test:test@pg-test:5434/test; done
如上圖所示，我們回到首頁可以看到，監控面闆目前的負載水準已經超過100%，主庫負載嚴重超标，兩個從庫也基本進入過載狀态，整個系統已經爆表。當我們将負載定量重新調低後，整個系統的負載水準會逐漸回到溫和狀态。
以上實驗反映了監控系統的基本功能，它能夠如實地反映使用者給叢集施加的負載以及叢集本身内部的狀态。
（二）實驗二：重新開機主庫，觀察叢集上司權交接
我們通常所說的高可用，指的是當一個系統的主庫當機時，應該有一個從庫自動被提升出來接管系統。如果沒有監控系統的話，這個操作對我們而言是一個很抽象的事情，下面我們借助監控系統來觀察一下這個操作過程。
比如我們登入到第一台主庫所在的機器上，然後執行ssh –t node-1 sudo reboot，可以看到負載都開始報錯。但在短短數秒内，無論是讀流量還是寫流量，它都自行恢複正常運作。
如上圖所示，我們可以看到監控系統中原本的主庫pg-test1已經被踢掉了， pg-test2被提升成新的主庫了，開始承接寫流量。當pg-test1重新開機完成之後，它是一台死掉的Primary，會嘗試将自己降格為一台新的從庫，重新挂在pg-test2的位置上。
同時我們可以看到，整個叢集的上司權Leadership圖表已經發生轉移，比如說原來叢集的新上司是pg-test1，現在變成pg-test2。
通過以上兩個實驗可以看出，監控系統對于反應系統狀态來說，是一個非常實用的工具。
二、用監控系統解決一些實際問題
（一）用監控系統解決問題
1.黃金監控名額
Pigsty提供了約1200個名額，但最重要的就是這10個，這也是PG Cluster首屏上呈現出的關鍵名額。
資料庫負值和飽和度是最重要的名額。按照Google SRE的監控最佳實踐，這些名額可以分為4大類，飽和度、延遲、流量和錯誤，都具有很重要的參考價值。
2.PG Load 衡量資料庫的負載程度
PG的負載是不是也可以采用類似于 CPU 使用率和機器負載的方式來定義？當然可以，而且這是一個極棒的主意。讓我們先來考慮單程序情況下的PG負載，假設我們需要這樣一個名額，當該PG程序完全空閑時負載因子為0，當該程序處于滿載狀态時負載為1(100%）。類比 CPU使用率的定義，我們可以使用“單個PG程序處于活躍狀态的時長占比”來表示單個PG後端程序的使用率。
如上圖所示，在一秒的統計周期内，PG處于活躍（執行查詢或者執行事務）狀态的時長為 0.6 秒，那麼這一秒内的PG負載就是 60％。如果這個唯一的PG程序在整個統計周期中都處于忙碌狀态，而且還有 0.4 秒的任務在排隊，如那麼就可以認為PG的負載為 140％。
對于并行場景，計算方法與多核CPU的使用率類似，首先把所有 PG程序在統計周期（1S）内處于活躍狀态的時長累加，然後除以“可用的PG程序／連接配接數”，或者說“可用并行數”，即可得到PG本身的使用率名額，如上圖所示。兩個PG後端程序分别有 20Oms + 400ms 與 80Oms 的活躍時長，那麼整體的負載水準為：
(0.2S+0.4S+0.8S)/1S/2=70 %
總結一下，某一段時間PG的負載可以定義為：
pg_load=pg_active_seconds/time_eroid /parallel
l pg_active_seconds 是該時間段内所有 PG 程序處于活躍狀态的時長之和。
l time_peroid 是負載計算的統計周期，通常為1分鐘， 5分鐘， 15分鐘，以及實時(小于10 秒）。
l Para11el 是 PostgreSQL 的可用并行數，後面會詳細解釋．
因為前兩項之商實際上就是一段時間内的每秒活躍時長總數，是以這個公式進一步可以簡化為活躍時長對時間的導數除以可用并行數，即：
rate(pg_active_seconds [time_peroid ])/parallel
time_peroid 通常是固定的常量（1,5, 15分鐘），是以問題就是如何擷取 PG程序活躍總時長pg_active_seconds這個名額，以及如何評估計算資料庫可用并行數 max_ para11el了。
3.黃金名額： 資料庫飽和度
資料庫負載 pg load= pg conn busy time / avail CPU time
資料庫飽和度saturation = max(cpu_ usage, pg_load)
飽和度用于反映資料庫整體資源使用率理論上應當取所有飽和度名額的最大值（PG，CPU，記憶體，網絡，磁盤……）
PG Saturation = max(PG Load, CPU Usage, xxxUsage…)
實際應用中，飽和度名額取 PG Load與 CPU Usage的最大值作為飽和度，當資料庫使用非獨占式部署，其他應用占用CPU資源時，PG Saturation比單純的PG Load更能反映資料庫整體負載水位。
- record: pg:ins:saturation0 expr: pg:ins:load0 > node:ins:cpu_usage or node:ins:cpu_usage
- record: pg:ins:saturation1 expr: pg:ins:load1 > node:ins:cpu_usage or node:ins:cpu_usage
- record: pg:ins:saturation5 expr: pg:ins:load5 > node:ins:cpu_usage or node:ins:cpu_usage
- record: pg:ins:saturation15 expr: pg:ins:load15 > node:ins:cpu_usage or node:ins:cpu_usage
（二）慢查詢定位優化
1.什麼是慢查詢？
慢查詢是資料庫的大敵，這裡我們使用PG Bench 用例模拟一個慢查詢。
ALTER TABLE pgbench_accounts DROP CONSTRAINT pgbench_accounts_pkey ;
該指令會移除pgbench_accounts 表上的主鍵，導緻相關查詢變慢，系統瞬間雪崩過載。
2.定位慢查詢
定位叢集RT異常，定位到具體的執行個體和查詢。首先，使用PG Cluster面闆定位慢查詢所在的具體執行個體，這裡以pg-test2為例，然後使用PG Query面闆定位具體的慢查詢：編号為 -6041100154778468427
該查詢表現出：響應時間顯著上升：17us升至 280ms QPS顯著下降：從500下降到7，花費在該查詢上的時間占比顯著增加，可以确定就是這個查詢變慢了。
3.發現異常
接下來，利用PG Stat Statements面闆，根據查詢ID定位慢查詢的具體語句。查詢以aid作為過濾條件查詢pgbench_accounts 表查詢變慢，大機率是這張表上的索引出了問題。
分析查詢後提出猜想：該查詢變慢是pgbench_accounts表上aid列缺少索引，下一步，查閱PG Table Detail面闆，檢查pgbench_accounts 表上的通路。定位潛在問題，找出順序掃表，建立所需索引。
4.性能優化
我們嘗試在pgbench_accounts表上為aid列添加索引，看看能否解決這個問題。
CREATE UNIQUE INDEX ON pgbench_accounts (aid);
可以看到，查詢的響應時間與QPS已經恢複正常，整個叢集的負載水準也恢複正常，報警也平息下來。精準衡量優化效果，直覺展示工作成績，真正做到資料驅動。
（三）定位系統故障
人工時時盯着名額，是一個非常辛苦的活，更好的選擇是由機器來盯着這些名額，您設定好規則，機器發現這些名額超出異常範圍的時候，自動給你觸發發送報警，Pigsty裡面提供了一系列的報警規則，同時報警事件也可以在監控系統的面闆裡面看到，通過這種條狀甘特圖的方式，我們可以看到哪一個時間段觸發了報警事件，進而有的放矢的去排查。報警系統提供了很多計算好的衍生名額，是以不用再寫特别複雜的表達式，可以直接用。
（四）系統水位評估
1.水位評估： 飽和度的曆史分位點
除了直覺的衡量實時的資料庫負載水準，還可以用來計算資料庫的水位，水位就是一個長期的資源使用量名額，通常來說，如果我們的某一個資料庫叢集長時間處于高負載狀态，我們就是說它水位比較高，我們可能就要給它擴容。如果它長時間處于低水位狀态，處于閑置，那麼我們就要給他縮容。
擴容和縮容的依據就是所謂的水位，水位就是過去某一個時間段飽和度的百分位點。比如說現在采用的就是過去一天裡面水位的99分位點，對于那種有周期性的負載來說，一天是一個比較好的這種衡量名額，如果您的業務周期性是一周或者一月，可以使用過去一周或者一月的飽和度資料，來計算它的99分位點或者99.99分位點，來評估叢集的水位。比如這裡某一套叢集，它的水位是30%，那麼就是意味着系統在過去一天的99%的時間裡面，它的資源使用率都在30%以内，我們就認為它的水位是30%。像這樣的名額對于評估長時間段系統的資源使用率很有用。評估資源使用率，就可以評估成本，及時的進行優化，這是一個典型應用。
三、How 如何部署一套監控系統？
（一）開源軟體
參考文檔：
http://pigsty.cc （二）公開文檔與示範
l 上手
基于Vagrant，快速在本機拉起示範系統。
這篇文檔将介紹如何在您手頭的筆記本或PC機上，基于Vagrant與Virtualbox，拉起Pigsty示範沙箱。
本教程着眼于在本地單機建立Pigsty示範環境，如果您已經有可以用于部署的機器執行個體，可以參考部署教程。
l 太長；不看
如果使用者的本地計算機上已經安裝有Vagrant、Virtualbox與Ansible，那麼隻需要克隆并進入本項目後，依次執行以下指令即可：
正常情況下執行結果詳見參考-标準流程。
（三）快速上手
快速開始
git clone
https://github.com/Vonng/pigstycd /tmp
make up
make ssh
sudo make
dns make init