有哪些數(shù)據(jù)類型會被監(jiān)控

監(jiān)控數(shù)據(jù)通常由幾種類型的數(shù)據(jù)組成：

·日志數(shù)據(jù)：豐富、詳細的文本和數(shù)據(jù)；

·可以用于遙測的標簽數(shù)據(jù)；

·運行狀況檢查數(shù)據(jù)；

·來自應用程序的性能數(shù)據(jù)；

日志數(shù)據(jù)

日志信息幾乎可以記錄攻擊者需要的任何東西，包括漏洞信息、通信信息、電子郵件信息等。不過要將這些信息進行輸出，沒有一定的技術和付出是不可能的。首先，你需要為日志記錄本身分配字符串，比如內(nèi)存和垃圾收集（適用于.NET和其他一些平臺）。當你在某處進行日志記錄時，磁盤空間必定要運行。如果我們遍歷網(wǎng)絡（在某種程度上是在本地），這也意味著帶寬和延遲。

日志數(shù)據(jù)會記錄所有的事情。如果技術能力夠硬且付出一定的成本，你就能詳細查看這些日志，挖掘更多內(nèi)容。所以聰明的人，會通過構建日志記錄，記錄他們認為需要的內(nèi)容。但這個構建過程并不容易，比如當出現(xiàn)問題時，你會發(fā)現(xiàn)有時新添加的功能沒有正確的日志記錄。

至于日志具體能記錄什么？這取決于系統(tǒng)。在本文的示例中，我們使用StackExchange.Exceptional執(zhí)行記錄操作，這是我維護的一個開源.NET的數(shù)據(jù)庫的中央異常日志查看器。這些異常日志會記錄到SQL Server，然后通過應用程序或通過Opserver（Stack Overflow 的開源監(jiān)控產(chǎn)品）查看。

對于像Redis，Elasticsearch和SQL Server這樣的系統(tǒng)，我們只需使用內(nèi)置的日志記錄和日志回旋（Log Rotation）機制登錄到本地磁盤。日志回旋（Log Rotation） 可以設定日志的回旋是基于文件大小還是基于時間間隔。當滿足其中的一個條件時，當前訪問日志被關閉，新的訪問日志被創(chuàng)建。對于其他基于SNMP的系統(tǒng)，如network gear，我們可以將所有這些日志轉發(fā)到Logstash集群，Logstash 是開源的服務器端數(shù)據(jù)處理管道，能夠同時從多個來源采集數(shù)據(jù)，轉換數(shù)據(jù),然后將數(shù)據(jù)發(fā)送到您最喜歡的 “存儲庫” 中。不過用Logstash之前，可以先用Kibana（一個開源的分析和可視化平臺）查詢。 將日志轉發(fā)到Logstash集群后，Bosun會在發(fā)出警報時，詢問其中的很多細節(jié)和趨勢，我們將在下文中深入探討。Bosun 是一個新型的監(jiān)控和告警系統(tǒng)，由Stack Exchange團隊打造，使用golang編寫，支持定義復雜的告警規(guī)則，支持OpenTSDB、Graphite、Logstash-Elasticsearch 等數(shù)據(jù)源。

用HAProxy構建日志監(jiān)控

HAProxy默認情況下并沒有啟用日志功能，或者說已經(jīng)啟用了但需配合日志軟件方能有效。

在本文的示例中，我們還記錄了通過HAProxy（負載均衡器）的公共HTTP請求，不過其中只記錄了頂級域名，沒有cookie，沒有表單數(shù)據(jù)等。

在這些請求中，我們將使用某些特定的性能數(shù)字將標頭發(fā)送到HAProxy， HAProxy會捕獲這些標頭并將這些標頭剝離到我們轉發(fā)的syslog行中，以便最后進行SQL處理。這些標頭包括：

·SQL Count（查詢）；

·Redis Count（查詢命中次數(shù)）；

·HTTP Count（發(fā)送請求）；

·Tag Engine Count (查詢)；

·Elasticsearch Count（查詢命中）；

利用這些查詢，我們可以輕松查詢和比較歷史數(shù)據(jù)。它在我們從未真正想過的方式中也很有用。例如，我們將看到一個請求和運行的SQL查詢計數(shù)，它將告訴我們用戶沿著代碼路徑走了多遠?；蛘弋擲QL連接池堆積起來時，我們可以查看特定時間內(nèi)來自特定服務器的所有請求，以查看導致該爭用的原因。我們所做的就是跟蹤n個服務的通訊次數(shù)和時間。這個方法非常簡單，但也非常有效。

監(jiān)控syslog并將其保存為SQL的過程稱為流量處理服務（Traffic Processing Service），因為我們計劃在一天內(nèi)發(fā)送報告。

除了這些標頭之外，默認的HAProxy日志行格式還有一些其他計時請求：

TR：客戶端向我們發(fā)送請求所用的時間(在keepalive運行時相當無用)；

Tw：排隊等待的時間；

Tc：等待連接到web服務器的時間；

Tr：web服務器完全呈現(xiàn)響應所花費的時間；

另一個簡單但重要的例子是，Tr和AspNetDurationMs報頭(一個計時器在請求的開始和結束時開始和結束)之間的增量，會告訴我們在操作系統(tǒng)中花費了多少時間，在IIS中等待線程等。

運行狀況檢查

在任何負載分配設置（例如一起工作的服務器集群或一組服務器前面的負載均衡器）中，運行狀況檢查是一種查看成員是否符合角色或任務的方法。例如，在Elasticsearch中，如果一個節(jié)點宕機后，當節(jié)點恢復運行時，再次執(zhí)行此操作。在Web層中，負載均衡器將停止向下行節(jié)點發(fā)送流量，并繼續(xù)在運行流量節(jié)點之間進行操作。

在HAProxy中，我們使用了內(nèi)置的運行狀況檢查和警告。截至2018年末，在我們編寫這篇文章時，仍用的是ASP.NET MVC5。一個重要的細節(jié)是我們的錯誤頁面是一個重定向的，例如出現(xiàn)/questions的時候，會定向到/error?aspxerrorpath=/questions。應該說這是舊.NET基礎結構的運行細節(jié)，但是當與HAProxy結合使用時，就成了問題。例如，如果你有：

server ny-web01 10.x.x.1:80 check

然后它將接受200-399個HTTP狀態(tài)碼響應（它只會發(fā)出一個HEAD請求），如果是400或500個HTTP狀態(tài)碼響應，則不會觸發(fā)運行，但我們的302重定向不會發(fā)生此情況。發(fā)生重定向后，瀏覽器將獲得5xx狀態(tài)代碼，但HAProxy實際上不會這樣做。你可以在同一后端使用http-check expect 200（或任何狀態(tài)代碼或范圍或正則表達式）來更改此設置，這意味著我們的運行檢查終端只允許200。

不同的應用程序因運行檢查端點而異，但對于stackoverflow.com，由于它是主頁，它會檢查我們可能無法檢查的事情，全面檢查很重要。我的意思是，如果用戶點擊同一頁面，它會全面檢查嗎？，如果我們進行了運行檢查，數(shù)據(jù)庫和一些緩存和理智檢查了我們知道需要聯(lián)機的大事，那就太棒了，就這樣了有總比沒有好。如果我們對數(shù)據(jù)庫和緩存進行了運行檢查，檢查我們需要的大數(shù)據(jù)。但是，假設我們在代碼中放入了一個漏洞，此時一個看起來并不重要的緩存都沒有重新被正確加載，此時所有用戶都會呈現(xiàn)在頂欄。

我們還在數(shù)據(jù)庫內(nèi)進行了運行檢查，最簡單的表現(xiàn)就是心跳（Heartbeat）進程的檢查。例如，StackExchange.Redis用于定期檢查與Redis的套接字連接是否處于運行狀態(tài)。我們會使用相同的方法來查看套接字是否仍然打開，并在Stack Overflow（一個與程序相關的IT技術問答網(wǎng)站）上利用WebSocket實現(xiàn)數(shù)據(jù)的實時推送。這是一種沒有在這里大量使用的監(jiān)控，但它確實被使用了。

其他運行檢查還包括標簽引擎服務器，我們可以通過HAProxy來平衡負載(這會增加一個跳轉)，但是讓每個Web層服務器直接了解每個標簽服務器對我們來說都是更好的選擇。我們可以監(jiān)控的信息如下：

1.選擇如何分配負載；

2.更容易測試新構建；

3.獲取每服務器操作計數(shù)指標和性能數(shù)據(jù)；

我們可以通過一個簡單的“ping”命令進行運行狀況檢查，例如它最后一次在數(shù)據(jù)庫更新的時間。

所以，這可以保證對你的運行狀態(tài)的絕對監(jiān)控。Microsoft .NET團隊一直致力于開發(fā)一個在ASP.NET Core中進行運行檢查的統(tǒng)一方法。

不過，對運行狀態(tài)的監(jiān)控與運行的頻率有關，比如每100毫秒的運行監(jiān)控與每秒、5秒或每分鐘的監(jiān)控都不一樣。

Stack Overflow就是一個實際的例子：當你將HAProxy后端服務器從MAINT（維護模式）切換到ENABLE時，后端會正常運行，直到檢查運行狀態(tài)發(fā)現(xiàn)問題時，才會停止。但是，當你從DRAIN切換到ENABLE時，后端會先停止運行，必須通過3次狀態(tài)檢查才能獲得流量。當我們處理線程池增長限制和緩存試圖啟動時（比如我們的Redis連接），由于運行狀況檢查，我們可能會遇到非常討厭的線程池饑餓（thread pool starvation）問題。這個影響是巨大的。因為在進行模式切換時，我們需要大約8-20秒才能完全準備好在新構建的Web服務器上提供流量。

使用httpUnit構建監(jiān)控系統(tǒng)

HttpUnit是基于JUnit構建的一個開源測試框架，專門針對Web應用的測試，解決使用JUnit框架無法對遠程Web內(nèi)容進行測試的弊端。

HttpUnit通過模擬瀏覽器的行為，包括提交表單（form）、處理頁面框架（frames）、基本的http驗證、cookies及頁面跳轉（redirects）處理等。通過HttpUnit提供的功能，用戶可以方便的和服務器端進行信息的交互，將返回的網(wǎng)頁內(nèi)容作為普通文本、XML Dom對象或者是作為鏈接、頁面框架、圖像、表單、表格等的集合進行處理，然后使用JUnit框架進行測試，還可以導向一個新的頁面，然后進行新頁面的處理，這個功能使你可以處理一組在一個操作鏈中的頁面?？偟膩碚f，httpUnit是一個相當簡單易用的工具，我們用它來檢查端點的狀態(tài)，看看此URL是否返回我們期望的狀態(tài)代碼？

通過不斷檢查并在失敗時提供警報，我們可以快速識別問題，尤其是那些來自基礎架構的無效配置更改的問題。在應用用戶負載之前，我們還可以輕松測試新的配置或基礎架構，防火墻規(guī)則等。

使用Fastly構建監(jiān)控系統(tǒng)

Fastly作為美國的CDN廠商，近年來不斷在邊緣云領域深度布局。你可以將Fastly視為負載均衡器時，它類似于HAProxy后端，內(nèi)置了運行檢查。

監(jiān)控指標

監(jiān)控指標可以是時間序列數(shù)據(jù)，這意味其中你有一個名稱、一個時間戳、一個值，在本文的示例中，有一些標簽。例如，單個條目看起來如下所示：

·時間：2018-01-01 18:30:00（UTC）

·標簽：服務器：NY-WEB01，應用程序：StackExchange-Network

條目中的值也可以采用幾種形式，但一般情況下是計數(shù)器。計數(shù)器會報告一個不斷增加的值（通常在重新啟動時重置為0）。通過計算值隨時間的差值，你可以找到窗口中的Delta值。例如，如果我們在10分鐘之前有129389139個進程，我們就知道在那十分鐘內(nèi)該服務器上的進程運行了100個Gen 0垃圾收集通道。另一個例子是報告一個絕對時間點的值，例如“此GPU當前為87°”，那么我們用什么來處理這些監(jiān)控到的數(shù)據(jù)問題呢？

警報信息的處理

我們?nèi)绾翁幚硭羞@些數(shù)據(jù)呢？ Bosun是我們內(nèi)部的主要警報源，它由OpenTSDB支持存儲。它是一個基于HBase構建的時間序列數(shù)據(jù)庫，具有很高的可擴展性。bosun是常用的報警系統(tǒng)，通過配置metrics(items)圖可以得到某一個參數(shù)在指定時間內(nèi)的變化，比如設為10s，每隔10s就會監(jiān)控這個數(shù)據(jù)并畫圖，依據(jù)這個圖可以實現(xiàn)對某些參數(shù)的監(jiān)控，以此作為報警的依據(jù)。

在.NET中，我們使用我們維護的另一個開源NuGet庫BosunReporter發(fā)送監(jiān)控指標。它看起來像如下這樣：

// Set it up once globallyvar collector = new MetricsCollector(new BosunOptions(ex => HandleException(ex)){

MetricsNamePrefix = 'MyApp',

BosunUrl = 'https://bosun.',

PropertyToTagName = NameTransformers.CamelToLowerSnakeCase,

DefaultTags = new Dictionary

{ {'host', NameTransformers.Sanitize(Environment.MachineName.ToLower())} }});// Whenever you want a metric, create one! This should be likely be static somewhere// Arguments: metric name, unit name, descriptionprivate static searchCounter = collector.CreateMetric('web.search.count', 'searches', 'Searches against /search');// ...and whenever the event happens, increment the countersearchCounter.Increment();

我們還可以在Bosun的數(shù)據(jù)計數(shù)器中，添加更多標簽，例如，計數(shù)器在哪個服務器上運行（通過主機標簽），我們可以在IIS中添加應用程序池，或者用戶點擊的Q＆A網(wǎng)站等。

許多其他系統(tǒng)都可以發(fā)送指標，scollector為Redis、Windows、Linux等提供了大量的內(nèi)置功能。我們用于關鍵監(jiān)控的另一個外部示例是一個小型Go服務，它可以監(jiān)控Fastly日志的實時流。有時Fastly可能會返回503，錯誤的原因也許是被切斷的套接字，或者是路由問題，或者是壞的證書。無論原因是什么，我們都希望在這些請求失敗并且用戶感覺到失敗時系統(tǒng)會發(fā)出警報。這個小服務只會監(jiān)控日志流，不過它從每個條目中解析一些信息，并將它們匯總后發(fā)送給Bosun。

我真正喜歡Bosun的一個關鍵特性是，它能夠監(jiān)控歷史警報。這有助于我們了解警報具體是何時觸發(fā)的，這是一個很棒的監(jiān)控過程。說實話，很多監(jiān)控來自經(jīng)驗教訓，警報經(jīng)常是在事情發(fā)生之后，才將出錯的信息添加到其中。

你可以看到在11月18日有一個很低的系統(tǒng)值，低到足以觸發(fā)安全警告。

我們還通過以下幾種方式監(jiān)控（通過Bosun）錯誤：

1.通過每個應用程序總結我們的異常錯誤日志；

2.通過Fastly和HAProxy；

如果我們在這兩種應用程序上都看到了高錯誤率，那么一兩分鐘后，帶有詳細信息的消息就會出現(xiàn)在聊天中。由于它們是基于聚合計數(shù)的，因此不能立即執(zhí)行。

另一種傳遞警報的方式是電子郵件，Bosun就有這個功能。電子郵件可能只是一個簡單的提醒。比方說，磁盤空間正在減少，或者CPU處于高位運行，而電子郵件中的一個簡單圖表就能說明很多問題。要想得到更復雜的警報，我們可以為電子郵件本身添加故障和詳細信息。你可以得到更好的信息來處理(或者甚至決定忽略)一封電子郵件的提醒，而無需進一步深入。這是本文的示例中，NY-TSDB03的CPU突發(fā)事件的郵件示例，其中包括了最近的10個事件。

Grafana

Grafana是一個開源的度量分析和可視化套件，它最常用于可視化基礎設施和應用程序分析的時間序列數(shù)據(jù)。

如果監(jiān)控數(shù)據(jù)，你看不到，那么這些數(shù)據(jù)有什么用呢？所以時間序列數(shù)據(jù)的圖形化可視化是一種很好的方式。這就是我們?yōu)槭裁词褂肎rafana的地方，它是一個優(yōu)秀的開源工具，為此我們提供了一個Bosun插件，這樣它就可以成為一個數(shù)據(jù)源。 （從技術上講，你可以直接使用OpenTSDB）。注意：我們對Grafana的使用過程，會使用圖片的方式來解釋。

以下是一個狀態(tài)儀表板，顯示了Fastly的運作方式。因為我們的插件會支持他們的DDoS保護和更快的內(nèi)容發(fā)送，所以當前顯示的狀態(tài)也是我們的當前狀態(tài)。

這是一個隨機的儀表盤，它是按地域劃分的，你可以看到當人們醒著的時候，世界各地的網(wǎng)絡流量分布情況。

客戶端計時

關于上面提到的所有內(nèi)容，一個重要的注意事項是它是服務器端。記住，渲染網(wǎng)頁的速度并不重要，這一點至關重要。

幾年前，當我們需要的部分首次在瀏覽器中可用時，我構建了一個客戶機計時管道。這個概念很簡單:使用web瀏覽器中可用的導航計時API并記錄它。要了解其工作原理，請訪問teststackoverflow.com 。

MiniProfiler

有時，你要捕獲的數(shù)據(jù)比上述方案更具體和詳細。MiniProfiler是一款針對.NET, Ruby, Go and Node.js的性能分析的輕量級程序。可以對一個頁面本身，及該頁面通過直接引用、Ajax、Iframe形式訪問的其它頁面進行監(jiān)控，監(jiān)控內(nèi)容包括數(shù)據(jù)庫內(nèi)容，并可以顯示數(shù)據(jù)庫訪問的SQL（支持EF、EF CodeFirst等 ）。并且以很友好的方式展現(xiàn)在頁面上。MiniProfiler的一個特別有用的功能是它與數(shù)據(jù)庫框架的集成。除了.NET原生的DbConnection類，MiniProfiler還內(nèi)置了對實體框架（Entity Framework）以及LINQ to SQL、RavenDb和MongoDB的支持。任何執(zhí)行的Step都會包括當時查詢的次數(shù)和所花費的時間。為了檢測常見的錯誤，如N 1反模式，profiler將檢測僅有參數(shù)值存在差異的多個查詢。

默認情況下，你可以看到這個數(shù)字，但是你可以將其展開以查看樹形式中哪些內(nèi)容需要花費多長時間。在那里鏈接的命令也是可見的，因此你可以Fastly查看運行的SQL或Elastic查詢，或發(fā)出的HTTP調(diào)用，或者獲取的Redis緩存等。

由于MiniProfiler的運行成本很低，我們可以在每個請求上運行它。為此，我們在Redis中保留了每MVC路由的配置文件樣本。例如，我們在給定時間保留任何路由的100個最慢的配置文件。這樣我們就可以看到用戶可能會遇到的問題，我們可以看到Bosun中的路由速度很慢，HAProxy日志中的點擊率下降了，還有需要深入研究的配置文件快照。

使用Opserver構建日志監(jiān)控系統(tǒng)

那么，什么是Opserver？Opserver是Stack Overflow的開源監(jiān)控產(chǎn)品，stackoverflow網(wǎng)站是基于asp.net開發(fā)的，它是一個基于網(wǎng)絡的儀表板和監(jiān)控工具。大約5年前，我們遇到了一個問題，即SQL Server AlwaysOn可用性組在SSMS儀表板上顯示為綠色（由主服務器提供支持），但是副本已經(jīng)好幾天沒有看到新數(shù)據(jù)了。這是一個監(jiān)控極度失效的例子。發(fā)生的情況是HADR線程池耗盡，并停止更新處于“all good”狀態(tài)的視圖。這樣的設計不一定是有缺陷的，但是當緩存/存儲一個事物的狀態(tài)時，它需要有一個時間戳。如果尚未在中更新，則為紅色警報。無論如何，進入Opserver。它做的第一件事是監(jiān)控每個SQL節(jié)點而不是信任主節(jié)點。

從那時起，我在基于Web的Fastly視圖中為我們想要的其他系統(tǒng)添加了監(jiān)控功能。

Opserver：主要儀表板

登陸儀表板是一個服務器列表，顯示了內(nèi)容的概述。用戶可以按名稱、服務標簽、IP地址、VM主機等進行搜索。你還可以深入查看每個節(jié)點上CPU、內(nèi)存和網(wǎng)絡的歷史記錄圖表。

在每個節(jié)點內(nèi)看起來像這樣：

如果使用Bosun并運行Dell服務器，則我們添加了如下硬件元數(shù)據(jù)。

Opserver：SQL Server

在SQL儀表板中，我們可以看到服務器狀態(tài)以及可用性組的工作方式。我們可以看到每個節(jié)點在任何給定時間有多少活動，以及哪個節(jié)點是主節(jié)點(藍色部分)。底部是AlwaysOn可用性組，我們可以看到每個可用性組的主服務器是誰，復制的進度落后了多少，以及備份了多少隊列。如果事情變糟并且副本不運行，則會出現(xiàn)更多指示符，例如哪些數(shù)據(jù)庫存在問題以及T-logs中涉及的所有驅動器的主數(shù)據(jù)庫上的可用磁盤空間（因為如果復制仍然停止，它們將開始增長）：

還有一個頂級的全部作業(yè)視圖，用于Fastly監(jiān)控和啟用/禁用：

在每個實例視圖中，我們可以看到有關服務器、緩存等的統(tǒng)計信息，我們發(fā)現(xiàn)它們隨著時間的推移而變得相關。

對于每個實例，我們還報告頂級查詢（基于計劃緩存，而不是查詢存儲），active-right - now查詢（基于sp_whoisactive）、連接和數(shù)據(jù)庫信息。

如果你想深入到一個頂部的查詢，它看起來是這樣的。

在數(shù)據(jù)庫視圖中，可以查看表、索引、視圖、存儲過程、存儲使用情況等。

Opserver：Redis

對于Redis，我們希望查看主要副本和副本的拓撲鏈以及每個實例的總體狀態(tài)：

請注意，你可以終止客戶端連接、獲取運行配置、更改服務器拓撲以及分析每個數(shù)據(jù)庫中的數(shù)據(jù)（可通過Regexes配置）。最后一個是KEYS和DEBUG OBJECT掃描，因此我們在副本節(jié)點上運行它或允許在主服務器上強制運行它（為了安全起見）。分析看起來像這樣：

Opserver：Elasticsearch

對于Elasticsearch，我們通常希望看到集群視圖中的內(nèi)容，因為這就是它的行為方式。下面沒有看到的是，當索引變?yōu)辄S色或紅色時。當這種情況發(fā)生時，儀表板的新增的部分將顯示出有問題的碎片、它們正在做什么(初始化、重新定位等)，并且計數(shù)將出現(xiàn)在每個集群中，匯總有多少碎片處于哪種狀態(tài)。

Opserver：異常

Opserver中的異常是基于StackExchange.Exceptional。在這種情況下，我們特別關注Exceptional的SQL Server存儲提供程序。Opserver是許多應用程序共享單個數(shù)據(jù)庫和表布局的一種方式，并允許開發(fā)人員在一個地方查看其異常。

此處的頂級視圖可以只是應用程序（默認），也可以按組配置。在上面的例子中，我們按團隊配置應用程序組，這樣團隊就可以標記或快速單擊他們負責的異常。在每個例外頁面中，詳細信息如下所示。

還記錄了詳細信息，例如請求標頭（帶有安全過濾器，因此我們不會記錄身份驗證cookie），查詢參數(shù)以及添加到異常的任何其他自定義數(shù)據(jù)。

Opserver：HAProxy

HAProxy部分非常簡單，我們只是簡單地呈現(xiàn)當前的HAProxy狀態(tài)并允許對其進行控制。這是主儀表板的樣子：

對于每個后臺組，特定后端服務器，整個服務器或整個層，它還允許一些控制。如果我們需要將其關閉以進行緊急維護等，可以讓后端服務器停止運作，或者讓整個后端關閉，或者讓web服務器退出所有后端。