一般來講應用程式負責四塊功能：
一個可能同時承擔多種業務；
應用可能會需要複雜的計算；
應用可能會需要經曆網絡來調用其他應用提供的服務；
應用會需要通路或更新包括資料庫和緩存在内的資料。
對應用的監控也應當分析這四個點，但要全部做到會比較難，或者實作的代價會很大。
同時承擔多種業務的情況不在我們重點讨論的範圍内，在現在的網際網路相關應用系統中，完全不調用資料的應用極少，相對也比較好監控，去除資料通路後，基本上隻有程式語言自身的gc（指記憶體的回收）、cpu的消耗和網絡了，隻要優化gc參數、cpu足夠并且網絡的帶寬和響應時間正常，應用不太會有大問題，是以監控的重點和難點在于應用如何處理和通路資料層，尤其是以關系資料庫為核心地帶。
緩存隻需要關注調用的頻率，每次的響應時間不會有太大的波動。對關系資料庫來講就不同了，sql所能表達的邏輯遠超緩存類的kv表達能力，比如多表關聯、分組彙總、分頁、以及多個sql語句組成的事務。除了受到網絡的影響，還受到資料分布、緩存命中率、資料更新沖突、事務一緻性等多種因素的複雜影響。
應用程式作為所有資料互動的發起方，可能覺得是最适合來做性能監控的，理論上是如此，比如輸出盡可能詳細的日志，再将日志收集到專門的日志處理平台上，進行統計分析。但事實上這種方式要求非常高，表現為以下幾點：
需要有一套日志分析平台，如果應用規模比較大，所需的日志分析平台也要比較大。
需要修改應用程式以列印足夠詳細的日志，目前通用的切面注入方式，并不能得到足夠詳細的資訊，無通用的不入侵應用的解決方案。
列印過多的日志本身會影響應用的性能，過多的io和過多的記憶體消耗引起的gc問題，會讓性能資料失真。
應用規模較大時，極難統一日志的格式，對曆史遺留應用基本上沒有任何辦法。
應用日志的輸出内容其他團隊比較難以了解。
需要投入比較寶貴的人力資源，也許國内這一點不存在。
除非在應用開發的初期能夠有很好的規劃，或者有非常統一的基礎架構，才能實作較為豐富的日志輸出。這個很難做到，公司的初創期或應用的建設期一定程度上是比較粗放式的，并不是萬事都俱備了才動手建設應用的。
在資料層，包括kv的關系資料庫都提供了非常好的監控功能，包括自身的cpu/記憶體/網絡使用率、每一條sql語句的處理時間，并且已經非常成熟。問題是從單條的sql要聯想到應用是非常困難的，并不是和開發交流的最好方式，單條的sql并不是應用與關系資料庫的互動方式，互動的基本單元是事務，一條sql也可以構成一個事務，多條sql也可以構成事務，在絕大部份場景下，引起問題的關鍵點在于多條語句構成的事務，其次是複雜的單條sql語句，最後才是簡單的單條sql語句。可以說沒有事務的單條sql是非常易于優化的，現在的應用開發人員已經基本上完全了解了。
應用研發人員和資料層的維護人員在各自的領域都十分專業，但如果缺少交流的共同語言，将非常難以互相了解，在不同的樓層或辦公區一定程度上會妨害互相之間的交流、了解和協作，但根本的問題在于如何輕松地了解對方所做的事情的關鍵部份。要應用研發人員去完全了解資料庫是很難的，資料庫也有幾十年的曆史了；要資料層的維護人員去了解應用也很難，應用涉及開發語言和不同的業務，并且開發人員的數量遠超維護人員，不是了解一兩個應用就能解決的事情。
◆ ◆ ◆ ◆ ◆
在回顧了過去多年的工作經驗以後，包括在ebay和阿裡巴巴與不同的應用研發團隊交流的經曆後，總結出以下三點：
要和應用開發人員講事務，不要去講一條sql，要去講有多個sql構成的一個事務，一個事務基本上表示了應用的一個接口或者一個功能。如果看到一個事務的sql結構，無論應用開發和維護人員都可以較快地互相了解。
要和不同的應用講不同的事務。在過去的經曆中發現應用開發也面臨非常大的業務壓力，這也是公司初創階段和系統開發階段不可能設計完善的日志輸出一樣的道理，盡量比較準确和高效地去交流。
對系統的把握是取決于整個團隊的，但細節上是取決于團隊個人的，幫助個人最終提升的是團隊能力。即不要假設開發理所當然地對應用是一清二楚的，考慮到個人的離職、調崗、文檔缺失、時間久遠等因系，不完全了解細節，或需要較大成本地了解問題可能是常态。如果能幫他更快更好地了解應用，是會非常歡迎的（假設他是想做事的）。
在想到以上這些點以後，發現應用層很難實作這幾個目的，而現有的資料層也很難實作這一目的，在仔細思考後發現中間件可以很好地解決這幾個問題：第一，中間件必須知道會話的狀态，也就是必須知道事務狀态，那麼就可以判斷sql是否是在事務中執行的，進而可以知到一個事務的sql構成；第二，中間件層知道sql和事務的請求來自于哪個ip位址，進而可以對應到哪個應用，可以和不同的應用開發人員做準确的交流；第三，基于通信協定的中間件不需要修改應用打日志，可以處理曆史遺留應用；第四，并且不需要複雜的日志分析平台，完全可以在記憶體中分析、整理和索引這些有用資訊。
在oneproxy中間件上，可以透明地獲得如下資訊：
統計sql的執行情況，這一功能在資料層也能獲得，中間件層獲得的時間資料包含了網絡，可以更真實地反映網絡品質。
統計不同表的通路情況，包括增删改查，這一功能也可在資料層間接或直接獲得。
統計不同ip的sql執行情況，即按ip位址統計top sql，或者檢視某個sql在不同ip機器上的執行情況。
統計多表一起使用（出現在同一個語句或同一個事務中）的情況，包括表的組合和調用頻率。
根據ip次元統計多表一起使用的情況，也就是可以快速地知道某個應用中，多表一起使用的情況，也可以反查哪些ip中有多表組合使用的情況。
統計事務的執行情況，包括組成事務的sql語句、事務調用次數、sql調用次數、事務持續時間、純sql處理時間、純dml處理時間等有用資訊。
根據ip次元統計事務的執行情況，也就是可以快速地知道某個應用的事務的具體情況。
當然還有一些資訊需要進一步去挖掘，已經發現事務部份的資訊，無論是從應用日志角度還是後端資料層角度都非常難以獲得，這将使得中間層具有意義非凡的應用監控功能，不管是布線上上生産環境還是線下測試環境，都非常有效。
讓我們來看一個真實的事務監控的例子，下圖是oneproxy中捕捉到的三個事務，第一個來自于sysbench程式的oltp類型壓測，其餘兩個來自于mysql用戶端工具的輸入。
除了非常有用的sql語句構成外，還呈現了很多的數字，值得好好看一下。
exec
事務的執行次數，累計值。
call
事務的sql調用次數（累計值），除事務數就是每次事務調用多少個sql語句。
dml call
事務中dml類型sql的調用次數（累計值），除事務數就是每次事務調用多少次dml語句（正在考慮是否按插入/更新/删除做分類統計）。
time
事務執行的累計時間，包括了網絡時間，應用在事務中調用其他服務的時間，以及sql的執行時間（包括資料庫鎖等待的時間），gc的時間等等。
avg time
事務的平均執行時間。
busy
純sql語句的執行時間統計，這裡去除了應用在事務中調用其他服務的時間，及gc的時間等等。
dml busy
純dml類型sql語句的執行時間統計，包括資料庫鎖等待的時間。一般來講查詢語句是不會有鎖等待的。
avg busy
平均sql執行時間。
後面還有一個記錄數的統計，這裡就不一個一個講解了，相信你也能看得懂。可以看到手工執行的兩個時間，sql層的處理時間遠遠小于整個事務的執行時間，原因是在一條一條地敲指令，整個事務的時間以秒計算，最需要優化的不是sql語句的性能，而是我應當将指令預先寫好放到檔案中去執行。而第一個事務中，平均時間隻有57ms，sql時間占了53ms，可以認為整個事務除了sql處理外基本上沒有其他額外的環節，隻需要優化sql處理就可以提升接口性能了。隻要維護人員對這個事務所處理的業務有所了解，就可以告訴開發人員到底是sql需要優化還是應用内部的調用邏輯更需要優化，而應用開發人員在看到這些資訊後，估計會很自覺地處理好。
接下來讓我們看一下wordpress中各個表的通路情況，考慮到應用特征是以讀為主，是以我們按查詢操作進行倒排。如下表所示：
假設現在因為資料庫壓力過大，需要進行垂直拆分，從查詢操作的執行次數及記錄數來看，将表“wp_posts”和“wp_postmeta”兩個表拆分出去的效果是最佳的。當然對于wordpress而言中間件自身提供的讀寫分離功能是最适合的，但我們就讨論拆分了。
當下定決定後，開發人員在接到這樣的任務後，第一反應是這兩個表拆分出去得有多少工作量？這個拆分是不是會非常困難？搞出點亂子我是不是會被公司解雇？不能要求開發會很高興地去掃描一遍所有的應用代碼，去分析和評估出所有工作量，新業務的壓力遠大于老業務的改造，絕大多數場景下，新業務帶來的個人業績也遠大于老業務的改造，除非是投入産出比很高的項目。
想要推動這件事情，就得先說明這并不是一件麻煩的事情，反而是低投入高産出的事情。比如說，我們已經對應用如何通路資料庫做了很深入的分析，這些表都是一個一個的單表，并且沒有出現在事務中，隻需要開發人員你花點力氣做确認，唯一麻煩的事情是“wp_posts”表上有兩個複雜的sql和“wp_comments”及“wp_term_relationships”有關聯查詢。這樣就從全應用代碼梳理變成了一兩個點人突擊檢查，從投入巨大的項目變成了投入極少的項目。而這些表之間關系的分析都可以從oneproxy中間件的事務分析功能中直接得到，毫不費力，如下所示：
隻需要告訴開發人員，這個統計是你花了很長時間才得到的，并且都是基于線上的真實sql流量進行的統計，并且是統計了數個月之久，沒有理由不打動他的。他不做的話可以放話去找其他的開發人員去配合，誰也不想放棄這樣明确超級掙錢的機會。
作者介紹 樓方鑫
oracle ace，onesql&平民科技創始人。
<b></b>
<b>本文來自雲栖社群合作夥伴"dbaplus"，原文釋出時間：2016-06-07</b>