文章目錄

• • 示例架構(gòu)
  • 事件分析和探索
  • • APM 探索
    • Infra探索
    • Discovery探索
    • Service探索
  • 總結(jié)

Elastic堅信，如果我們要監(jiān)控企業(yè)的IT基礎(chǔ)設(shè)施或者說完成整個軟件的端到端的全鏈路監(jiān)控，那么就不應(yīng)該漏過任何一個側(cè)面的數(shù)據(jù)。這需要通過360度的全觀察性來完成。Elastic Stack，作為一個大數(shù)據(jù)平臺的技術(shù)棧，在運維監(jiān)控這個垂直領(lǐng)域，已經(jīng)提供了一套完整的技術(shù)解決方案，從日志分析，到指標監(jiān)控，再到軟件性能監(jiān)控和可用性監(jiān)控，都有產(chǎn)品級的開箱即用的方案。

在這篇文章里面，我們通過一個例子，展示如何通過使用Elastic的全觀察性解決方案去快速定位應(yīng)用運行過程中的問題。

示例架構(gòu)

我們假設(shè)有一個寵物醫(yī)院的應(yīng)用，其架構(gòu)如下：

從上圖可以看到，這是一個常見的前后端分離的微服務(wù)架構(gòu)：

• 用戶流量通過K8S的負載均衡進行導(dǎo)入
• 前端部署多個基于REACT的Nodejs服務(wù)器 + NGINX反向代理
• 前端通過K8S的負載均衡對后端服務(wù)器進行訪問
• 后端服務(wù)包含兩組服務(wù)的多個服務(wù)器，分別是：
  • 基于java spring的 web service + NGINX反向代理，用于事務(wù)型操作
  • 基于python flask的 web service + NGINX反向代理，用于檢索型操作
• 數(shù)據(jù)層有兩組服務(wù)器，分別是MySQL和Elasticsearch，用于提供事務(wù)數(shù)據(jù)和可檢索數(shù)據(jù)

在這個架構(gòu)中的每一次，我們都使用：

• filebeat，用于日志的采集
• packetbeat，用于網(wǎng)絡(luò)數(shù)據(jù)的采集
• Metricbeat，用于系統(tǒng)、中間件指標的采集
• Auditbeat，用于安全、審計事件的采集

事件分析和探索

我們可以通過構(gòu)建機器學(xué)習(xí)的任務(wù)，持續(xù)的對系統(tǒng)里面的各種指標進行監(jiān)控，并且配合Alert功能，實時的對異常事件進行上報。配置了郵件告警之后，當監(jiān)測到異常，我們會收到如下告警：

可以將調(diào)查鏈接附在郵件里面。通過鏈接，我們可以訪問Kibana的機器學(xué)習(xí)異常監(jiān)測界面。

因為是實時告警，我們可以直接觀測8:00 PM的異常

機器學(xué)習(xí)任務(wù)包含了多種信息，包括：

• 服務(wù)的總體異常情況（Overall）
• 各子服務(wù)層的異常情況（spring后端和node前端）
• 異常的嚴重程度（Severity）
• 探測器監(jiān)控的指標類型（這里是服務(wù)的時延方差指標）
• 影響因子（/api/owner）
• 指標的實際值、標準值和偏差描述

從這里，我們可以基本分析到，整體響應(yīng)從前端到后端的監(jiān)控都有異常，即問題定位應(yīng)該是在spring的后端服務(wù)上。

通過點擊右邊的Action窗口，我們可以從其他方面探索整個App在這個時間段內(nèi)的實際運行情況：

可探索的數(shù)據(jù)包括：

• APM運行時數(shù)據(jù) （APM Analysis）
• APM的統(tǒng)計數(shù)據(jù)儀表板 (Service Analysis)
• 基礎(chǔ)設(shè)施監(jiān)控數(shù)據(jù) （Infra Analysis)
• 服務(wù)可用性數(shù)據(jù) （Uptime Analysis）

注意，在探索的過程中，被探索的其他數(shù)據(jù)，仍然是鉚定在出現(xiàn)問題的時間窗口的。這個功能很利于我們做數(shù)據(jù)的切片觀察

APM 探索

通過APM Analysis，進入APM的探索頁面，我們可以看到，在7:58 pm 開始，接口調(diào)用的響應(yīng)時間出現(xiàn)了一個明顯的毛刺。我們可以直接在界面上下鉆該毛刺。

可以看到，在這個毛刺產(chǎn)生階段，不只是/api/owner這個API有問題，而且其他的api比如，api/visits同樣出現(xiàn)了問題。
可以繼續(xù)對API接口進行探索：

通過APM的數(shù)據(jù)，我們可以看到api/visits在7:58 pm ~ 8:01 pm這個時間段內(nèi)的調(diào)用時間情況。在毛刺之前，api/visits的響應(yīng)時間在100ms左右，在毛刺階段，響應(yīng)時間變?yōu)?000ms。

基本上，所有的的時間都是花在sping對后端數(shù)據(jù)庫的訪問上。在異常之前，DB的訪問延時在xxx微秒（百級）左右，在毛刺階段，變?yōu)閤xxx微秒（千級）

這時，我們基本可以判斷，問題可能出在數(shù)據(jù)庫上！

Infra探索

要判斷數(shù)據(jù)庫上的問題，就全方位的IT基礎(chǔ)設(shè)施的監(jiān)控，從主機到數(shù)據(jù)庫，中間件。
通過Infra Analysis對IT基礎(chǔ)設(shè)施進行探索：

可以看到，我們對整個IT基礎(chǔ)設(shè)施有一個全景圖。顏色越深的節(jié)點，代表該資源在特定時間段內(nèi)資源使用率越高。我們可以看到，這個時間點內(nèi)，我們的MySQL服務(wù)器的使用情況明顯比其他服務(wù)偏高。
可以通過點擊右鍵，進入對應(yīng)節(jié)點的日志。很容易，我們可以發(fā)現(xiàn)MySQL服務(wù)在這個時間點做了一次多表的聯(lián)合掃描。耗時120s

Discovery探索

我們可以在Discovery頁面再做深度的探索，可以看到，這個多表聯(lián)合掃描和服務(wù)的異常是重疊的。

由此，我們找到根本原因

Service探索

我們也可以在Service Analysis頁面分析服務(wù)層面的影響。比如，查看該事件段有多少用戶登錄了系統(tǒng)，系統(tǒng)響應(yīng)時延的百分位等指標，因為所有的數(shù)據(jù)是關(guān)聯(lián)分析的，我們可以在可視化圖標上集成所有的信息，下圖中，System performance子圖，就使用machine learning的數(shù)據(jù)，在對應(yīng)時間點打上了alert flag

總結(jié)

大多數(shù)時候，我們的可觀察性是被撕裂的，任何從單一維度，比如日志，指標，APM方面獨立去看，可以看到異常，但是卻無法找到根本原因。數(shù)據(jù)需要被放在一起，提供360度的全觀察性進行，才能最大化的對數(shù)據(jù)進行探索。不光是運維問題，商業(yè)洞察，安全分析同樣如此，希望這篇文章對你有所啟發(fā)，能夠構(gòu)建一個真正的大數(shù)據(jù)平臺對數(shù)據(jù)進行探索，因為大數(shù)據(jù)不僅是數(shù)據(jù)量大，數(shù)據(jù)類型多，更重要的是數(shù)據(jù)并非孤立，需要放在一起才能產(chǎn)生價值。

總結(jié)

以上是生活随笔為你收集整理的使用Elastic Stack做应用的360度全观察性监控的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。