有時只需要知道數(shù)據(jù)庫客戶端在數(shù)據(jù)庫中執(zhí)行的操作。這些操作可能是：

• 調(diào)試應(yīng)用程序并嘗試確定其數(shù)據(jù)庫交互是否存在問題。
• 分析無服務(wù)器功能的性能以確定某些查詢是否耗時過長。
• 測試應(yīng)用程序并確保其數(shù)據(jù)庫交互符合預(yù)期。
• 審核系統(tǒng)以確保它不會在數(shù)據(jù)庫中做任何有趣的事情。
• 對應(yīng)用程序進行逆向工程。

數(shù)據(jù)庫客戶端是指直接與數(shù)據(jù)庫對話的任何事務(wù)：它可能是在應(yīng)用服務(wù)器中運行的中間層、報表編寫器、Excel中的電子表格、用PHP編寫的Web應(yīng)用程序、云中的lambda函數(shù)，等等。

不管是什么原因，了解客戶的數(shù)據(jù)庫交互對于理解客戶的行為非常有幫助。

一般來說，有兩種常見的方法：基于服務(wù)器的和基于客戶端的。還有第三種不太常用的選項：監(jiān)控數(shù)據(jù)庫連接。這是中間路線：它既不關(guān)注數(shù)據(jù)庫服務(wù)器，也不關(guān)注數(shù)據(jù)庫客戶端，而是關(guān)注它們之間的連接。

以下了解常見解決方案的優(yōu)缺點，并看看這第三種方法帶來了什么。

服務(wù)器端監(jiān)控

大多數(shù)企業(yè)數(shù)據(jù)庫都有內(nèi)置的監(jiān)控功能。如果用戶對數(shù)據(jù)庫具有管理員級別的訪問權(quán)限，那么這種類型的監(jiān)控可能是一個很好的解決方案，但如果有多個客戶端訪問數(shù)據(jù)庫，它可能并不總是易于使用。

主要從數(shù)據(jù)庫的角度觀察世界的人員更喜歡服務(wù)器端監(jiān)控，因為這種類型的監(jiān)控使企業(yè)可以完全訪問數(shù)據(jù)庫服務(wù)器中發(fā)生的所有事情：CPU和內(nèi)存、網(wǎng)絡(luò)和磁盤使用情況、死鎖等。

這種解決方案的主要缺點是：

• 需要對數(shù)據(jù)庫進行特權(quán)訪問。
• 對于云計算數(shù)據(jù)庫，經(jīng)常被云計算供應(yīng)商提供的任何東西所困擾。
• 可以看到來自所有客戶端的所有請求，這可能會讓人不知所措，并且可能成為一個安全問題。

客戶端監(jiān)控

專注于數(shù)據(jù)庫客戶端的解決方案要求用戶在客戶端中安裝代理。這可以采用庫或模塊的形式，或者可能是攔截所有數(shù)據(jù)庫調(diào)用的替代驅(qū)動程序庫。

客戶端監(jiān)控是更關(guān)心數(shù)據(jù)庫客戶端觀點的人員的首選，例如應(yīng)用程序開發(fā)人員和測試人員。它允許用戶專注于一個特定的客戶端，并準(zhǔn)確查看該客戶端在做什么、它發(fā)送什么請求、它得到什么響應(yīng)等等。大多數(shù)解決方案還不僅僅是監(jiān)控數(shù)據(jù)庫交互。

但是，這種類型的監(jiān)控也有缺點：

• 它要求用戶對客戶端進行一些更改，這可能很困難。
• 如果用戶不控制客戶端(例如第三方應(yīng)用程序、不再維護等)，它甚至可能不是一個選項。
• 如果監(jiān)控解決方案不支持客戶的語言或平臺，這甚至不是一個選項。
• 如果用戶需要監(jiān)控多個客戶端，則可能會很不方便，因為需要在每個客戶端中安裝代理。

基于代理的監(jiān)控：中間道路

還有第三種選擇：使用數(shù)據(jù)庫代理監(jiān)視客戶端和服務(wù)器之間的連接。

客戶端并不是直接連接到數(shù)據(jù)庫，而是連接到代理，代理轉(zhuǎn)發(fā)客戶端和服務(wù)器之間的所有請求和響應(yīng)，并將這些活動報告給監(jiān)控服務(wù)。

代理在有線協(xié)議級別工作：它的行為與數(shù)據(jù)庫服務(wù)器完全相同，因此客戶端無法知道它實際上并未直接與數(shù)據(jù)庫服務(wù)器通信。

這種方法的主要優(yōu)點是它不需要對數(shù)據(jù)庫客戶端或數(shù)據(jù)庫服務(wù)器進行任何更改，因此可以在任何環(huán)境中以任何語言為任何客戶端工作。唯一的要求是客戶端應(yīng)該連接到代理而不是數(shù)據(jù)庫，這通?？梢酝ㄟ^更改配置參數(shù)、數(shù)據(jù)源定義或有時是網(wǎng)絡(luò)設(shè)置來完成。

這在處理不受用戶控制的第三方應(yīng)用程序或不再維護的舊應(yīng)用程序時特別有用。在這些情況下，對應(yīng)用程序進行任何更改通常是一個令人生畏的前景。與其相反，指導(dǎo)客戶端連接到代理而不是數(shù)據(jù)庫通常是微不足道的。

對于使用監(jiān)控系統(tǒng)不支持的語言編寫的客戶端，基于代理的監(jiān)控也是唯一實用的解決方案。

例如，New Relic公司擁有適用于C、Java、JavaScript、Go、Ruby、.NET、PHP和Python的應(yīng)用程序性能監(jiān)控庫。如果用戶的客戶端使用不兼容的語言編寫，將無法使用New Relic的代理。

應(yīng)用程序開發(fā)人員和測試人員可以實施基于代理的監(jiān)控，而無需數(shù)據(jù)庫所有者的協(xié)作。一個代理可用于多個客戶端，這在用戶需要監(jiān)控一套應(yīng)用程序時很有幫助。

(1)代理方法的優(yōu)點

• 不需要更改數(shù)據(jù)庫客戶端或數(shù)據(jù)庫服務(wù)器。
• 適用于現(xiàn)場和云計算數(shù)據(jù)庫。
• 支持所有平臺和語言，因為它在有線協(xié)議級別工作。
• 可以同時應(yīng)用于多個客戶端。

(2)代理方法的缺點

• 需要代理服務(wù)器。
• 由于流量通過代理，響應(yīng)時間略有增加。

哪種方法更加適合?

如果主要關(guān)心數(shù)據(jù)庫，例如作為系統(tǒng)管理員(DBA)，那么基于服務(wù)器的監(jiān)控很可能是適合其的解決方案——這不足為奇。

如果用戶是應(yīng)用程序開發(fā)人員或測試人員，或者只需要知道數(shù)據(jù)庫客戶端在數(shù)據(jù)庫中做什么，那么可以在基于客戶端的監(jiān)控和基于代理的監(jiān)控之間進行選擇。

如果用戶在客戶端中安裝代理是合理的，那么這是一個很好的方法。將深入了解客戶的行為，并且有許多產(chǎn)品可供選擇(例如谷歌“APM數(shù)據(jù)庫”)。

如果在用戶的客戶中安裝代理是一個沒有吸引力的前景，或者如果客戶使用不受支持的平臺或語言，那么基于代理的方法可能是用戶的最佳選擇，甚至可能是其唯一的選擇。

原文標(biāo)題：??Application Database Monitoring: The Middle Way??，作者：Max Tardiveau