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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

·SQL Count（查詢）；

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

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

·Tag Engine Count (查詢)；

·Elasticsearch Count（查詢命中）；

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

監(jiān)控syslog并將其保存為SQL的過程稱為流量處理服務(wù)（Traffic Processing Service），因?yàn)槲覀冇?jì)劃在一天內(nèi)發(fā)送報(bào)告。

除了這些標(biāo)頭之外，默認(rèn)的HAProxy日志行格式還有一些其他計(jì)時(shí)請求：

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

Tw：排隊(duì)等待的時(shí)間；

Tc：等待連接到web服務(wù)器的時(shí)間；

Tr：web服務(wù)器完全呈現(xiàn)響應(yīng)所花費(fèi)的時(shí)間；

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

運(yùn)行狀況檢查

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

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

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

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

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

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

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

1.選擇如何分配負(fù)載；

2.更容易測試新構(gòu)建；

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

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

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

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

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

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

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

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

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

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

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

監(jiān)控指標(biāo)

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

·時(shí)間：2018-01-01 18:30:00（UTC）

·標(biāo)簽：服務(wù)器：NY-WEB01，應(yīng)用程序：StackExchange-Network

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

警報(bào)信息的處理

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

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

// 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ù)計(jì)數(shù)器中，添加更多標(biāo)簽，例如，計(jì)數(shù)器在哪個(gè)服務(wù)器上運(yùn)行（通過主機(jī)標(biāo)簽），我們可以在IIS中添加應(yīng)用程序池，或者用戶點(diǎn)擊的Q＆A網(wǎng)站等。

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

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

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

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

1.通過每個(gè)應(yīng)用程序總結(jié)我們的異常錯(cuò)誤日志；

2.通過Fastly和HAProxy；

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

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

Grafana

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

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

以下是一個(gè)狀態(tài)儀表板，顯示了Fastly的運(yùn)作方式。因?yàn)槲覀兊牟寮?huì)支持他們的DDoS保護(hù)和更快的內(nèi)容發(fā)送，所以當(dāng)前顯示的狀態(tài)也是我們的當(dāng)前狀態(tài)。

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

客戶端計(jì)時(shí)

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

幾年前，當(dāng)我們需要的部分首次在瀏覽器中可用時(shí)，我構(gòu)建了一個(gè)客戶機(jī)計(jì)時(shí)管道。這個(gè)概念很簡單:使用web瀏覽器中可用的導(dǎo)航計(jì)時(shí)API并記錄它。要了解其工作原理，請?jiān)L問teststackoverflow.com 。

MiniProfiler

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

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

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

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

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

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

Opserver：主要儀表板

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

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

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

Opserver：SQL Server

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

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

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

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

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

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

Opserver：Redis

對于Redis，我們希望查看主要副本和副本的拓?fù)滏溡约懊總€(gè)實(shí)例的總體狀態(tài)：

請注意，你可以終止客戶端連接、獲取運(yùn)行配置、更改服務(wù)器拓?fù)湟约胺治雒總€(gè)數(shù)據(jù)庫中的數(shù)據(jù)（可通過Regexes配置）。最后一個(gè)是KEYS和DEBUG OBJECT掃描，因此我們在副本節(jié)點(diǎn)上運(yùn)行它或允許在主服務(wù)器上強(qiáng)制運(yùn)行它（為了安全起見）。分析看起來像這樣：

Opserver：Elasticsearch

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

Opserver：異常

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

此處的頂級視圖可以只是應(yīng)用程序（默認(rèn)），也可以按組配置。在上面的例子中，我們按團(tuán)隊(duì)配置應(yīng)用程序組，這樣團(tuán)隊(duì)就可以標(biāo)記或快速單擊他們負(fù)責(zé)的異常。在每個(gè)例外頁面中，詳細(xì)信息如下所示。

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

Opserver：HAProxy

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

對于每個(gè)后臺(tái)組，特定后端服務(wù)器，整個(gè)服務(wù)器或整個(gè)層，它還允許一些控制。如果我們需要將其關(guān)閉以進(jìn)行緊急維護(hù)等，可以讓后端服務(wù)器停止運(yùn)作，或者讓整個(gè)后端關(guān)閉，或者讓web服務(wù)器退出所有后端。