SQL Monitor是一個SQL Server監(jiān)控工具。它可以監(jiān)控SQL Servers的健康狀況和活動，并通過電子郵件為您發(fā)送監(jiān)測結(jié)果和建議。

點擊下載SQL Monitor正式版

本教程提供了一個解決方案，使用PowerShell和SQL Monitor，可以迅速警告您一系列Windows錯誤、警告和關(guān)鍵事件，包括失敗的服務(wù)器登錄嘗試，這將伴隨著對承載您的SQL Server實例的Windows Server的強力密碼攻擊。前面文章已經(jīng)介紹了一部分內(nèi)容（點此查看），本文為后半部分內(nèi)容——創(chuàng)建SQL Monitor自定義指標(biāo)。

創(chuàng)建SQL Monitor自定義指標(biāo)

以下SQL僅計算過去10分鐘內(nèi)寫入事件表的Windows事件數(shù)。我們有計劃的PowerShell作業(yè)每五分鐘運行一次。

USE ServerEvents
  SELECT Count(*) 
    FROM events 
      WHERE TimeCreated > DateAdd(MINUTE, -10, GetDate())

或者，您可能想要創(chuàng)建兩個指標(biāo)，一個指標(biāo)僅對失敗的登錄次數(shù)進行計數(shù)，而另一個指標(biāo)對其他所有事項進行計數(shù)。這是僅用于獲取失敗登錄的SQL：

USE ServerEvents
  SELECT Count(*) 
    FROM events 
      WHERE TimeCreated > DateAdd(MINUTE, -10, GetDate())
      AND providername LIKE 'Microsoft-Windows-Security-Auditing'

并且，您可以得到其他類似的事件：

USE ServerEvents
  SELECT Count(*) 
    FROM events 
      WHERE TimeCreated > DateAdd(MINUTE, -10, GetDate())
      AND NOT providername LIKE 'Microsoft-Windows-Security-Auditing'

我只使用了一個度量標(biāo)準，因為無論出于何種原因無論如何簽入SSMS都非常有用，但是無論您選擇執(zhí)行哪種操作，現(xiàn)在都可以使用這些查詢在SQL Monitor中創(chuàng)建自定義指標(biāo)以及相關(guān)警報。 顯然，這不是數(shù)據(jù)庫級別的指標(biāo)。 您應(yīng)該指定僅在master上運行。

然后，您可以通過嘗試登錄服務(wù)器并運行PowerShell腳本，將錯誤和警告寫入正在監(jiān)視的各種日志中，以檢查其是否正常運行。

哎呀，有人試圖強行登錄我的一個登錄！呃，沒有。在這種情況下，我只是檢查以確保“水通過所有管道”。您不僅可以檢測到失敗的登錄信息，還可以檢測到更多信息。當(dāng)所有這些都在運行時，在我用作測試平臺的服務(wù)器上進行了系統(tǒng)升級。出了很多問題，現(xiàn)在所有這些都被發(fā)現(xiàn)了。

我通常檢查所有日志嗎？是的。現(xiàn)在，我對顯示器的運行狀況有了充分的確認，并且我非常感謝采用帶正括號的數(shù)據(jù)收集方法，可以獲取整天的數(shù)據(jù)。

對于像我這樣的SQL Server開發(fā)人員而言，將錯誤日志記錄在表中是一個很棒的主意，因為我現(xiàn)在可以將所有數(shù)據(jù)切成薄片并切成小塊并搜索消息。例如，我可以搜索特定的字符串：

SELECT Message, LogName FROM Events WHERE Message LIKE '%Vlad The Impaler%';

給：

message 
  -------------------------------
  An account failed to log on.
  Subject:
    Security ID:        S-1-0-0
    Account Name:       -
    Account Domain:     -
    Logon ID:       0x0
  Logon Type:           3
  Account For Which Logon Failed:
    Security ID:        S-1-0-0
    Account Name:       Vlad the Impaler
    Account Domain:
   Security
  (1 row affected)

我可以按嚴重性細分錯誤：

SELECT Convert(CHAR(11), TimeCreated, 113) AS The_date,
    --Verbose 5,Informational 4,Warning 3,Error 2, Critical 1 LogAlways  0
    Sum(CASE WHEN Level = 5 THEN 1 ELSE 0 END) AS Verbose,
    Sum(CASE WHEN Level = 4 OR Level = 0 THEN 1 ELSE 0 END) AS Informational,
    Sum(CASE WHEN Level = 3 THEN 1 ELSE 0 END) AS Error,
    Sum(CASE WHEN Level = 2 THEN 1 ELSE 0 END) AS Critical,
    Sum(CASE WHEN Level = 1 THEN 1 ELSE 0 END) AS LogAlways, Count(*) AS total
    FROM Events
    GROUP BY Convert(CHAR(11), TimeCreated, 113)
    ORDER BY Min(TimeCreated);

或按提供者，以每天查看提供者的錯誤數(shù)量。

DECLARE @variable NVARCHAR(MAX) =
    'Select Convert(CHAR(11), TimeCreated, 113),'
    +
      (
      SELECT 
        String_Agg
         (Convert
            (NVARCHAR(MAX),
             'sum(Case when Providername like '''
              + providername + ''' then 1 else 0 end) as ['
              + providername + ']'
             ), ', '
          )
        FROM (SELECT ProviderName FROM Events GROUP BY ProviderName) AS f(providername)
      )
    + ',count(*) as [total] 
    FROM Events
    GROUP BY Convert(CHAR(11), TimeCreated, 113)
    ORDER BY Min(TimeCreated);';
  EXECUTE sp_executesql @variable;

我可以解決特定問題，而不必在日志中進行混亂的搜索。另外，由于我可以將數(shù)據(jù)保留在SQL Server數(shù)據(jù)庫中，因此可以保留更長的歷史記錄。

擴展解決方案

我寧愿將它留給如何將其擴展到一組服務(wù)器。SQL Monitor方面很容易，但是要使其正常工作，Windows事件需要存儲在每個實例上。您需要決定是否從中心位置進行收集，并在收集每個服務(wù)器的記錄時為它們編寫副本，或者是否在每個服務(wù)器上運行腳本。我認為這取決于SQL Server的大小，但這是一個判斷問題。

中央錯誤收集器的優(yōu)點在于檢查它。Get-WinEventcmdlet將可以通過網(wǎng)絡(luò)收集日志記錄，如果你告訴它的服務(wù)器從哪里獲得日志記錄，所以腳本和數(shù)據(jù)模型并不復(fù)雜，但憑據(jù)方面可能會導(dǎo)致混亂。

結(jié)論

如果一個外星人飛下來問我有關(guān)關(guān)系數(shù)據(jù)庫系統(tǒng)的問題，我將很難向它解釋SQL Server安全性。作為數(shù)據(jù)庫人員，我們會密切注意實例，但很少關(guān)注托管它的服務(wù)器。當(dāng)我告訴外星人我無法輕易獲得有關(guān)Windows嚴重或錯誤事件的警報時，我?guī)缀蹩梢钥吹剿墓殴直砬椤?/p>

幸運的是，假設(shè)我可以從Ops員工處獲得同意以執(zhí)行計劃的PowerShell任務(wù)，那么當(dāng)外星人詢問我對數(shù)據(jù)庫安全性在地球上是如何工作時，我就不會有這種社交尷尬的風(fēng)險了。希望DevOps合作的精神也可以擴展到允許我以腳本方式收集這些任務(wù)，從而使我免遭星際尷尬的困擾。

盡管Azure SQL數(shù)據(jù)庫位于一個良好的、可管理的繭中，就像一個滿足的昆蟲幼蟲一樣，但對于網(wǎng)絡(luò)上托管的數(shù)據(jù)庫并不一定是如此。許多成功的SQL Server滲透，例如暴力破解密碼攻擊，都依賴于宿主服務(wù)器的安全性問題，因此在服務(wù)器級別了解安全警報和警告似乎是正確的。實際上，需要注意所有事件。不僅可以破壞Windows Server的惡意入侵者，還可以進行自動升級或電源不足。

至少現(xiàn)在，在SQL Monitor的幫助下，我可以獲得有關(guān)失敗的登錄和其他Windows安全事件發(fā)生的警報和基線，然后深入研究SQL Server數(shù)據(jù)庫中的詳細信息。是的，了解在服務(wù)器級別發(fā)生了什么錯誤、警報和警告以及它們何時發(fā)生是非常有用的！

本教程內(nèi)容到這里就完結(jié)了，希望文章內(nèi)容對您有所幫助~感興趣的朋友可以下載SQL Monitor試用版嘗試一下~

相關(guān)內(nèi)容推薦：

使用監(jiān)控工具SQL Monitor，檢查失敗的服務(wù)器登錄、服務(wù)器錯誤和警告（上）

監(jiān)控工具SQL Monitor：使用SQL Monitor跟蹤數(shù)據(jù)庫上的活動會話數(shù)

使用SQL Server監(jiān)控工具SQL Monitor，監(jiān)視Azure SQL數(shù)據(jù)庫的性能問題（上）

使用SQL Server監(jiān)控工具SQL Monitor，監(jiān)視Azure SQL數(shù)據(jù)庫的性能問題（下）

想要購買SQL Monitor正版授權(quán)，或了解更多產(chǎn)品信息請點擊