文章目錄

• • 示例架構
  • 事件分析和探索
  • • APM 探索
    • Infra探索
    • Discovery探索
    • Service探索
  • 總結

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

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

示例架構

我們假設有一個寵物醫院的應用，其架構如下：

從上圖可以看到，這是一個常見的前后端分離的微服務架構：

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

在這個架構中的每一次，我們都使用：

• filebeat，用于日志的采集
• packetbeat，用于網絡數據的采集
• Metricbeat，用于系統、中間件指標的采集
• Auditbeat，用于安全、審計事件的采集

事件分析和探索

我們可以通過構建機器學習的任務，持續的對系統里面的各種指標進行監控，并且配合Alert功能，實時的對異常事件進行上報。配置了郵件告警之后，當監測到異常，我們會收到如下告警：

可以將調查鏈接附在郵件里面。通過鏈接，我們可以訪問Kibana的機器學習異常監測界面。

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

機器學習任務包含了多種信息，包括：

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

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

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

可探索的數據包括：

• APM運行時數據 （APM Analysis）
• APM的統計數據儀表板 (Service Analysis)
• 基礎設施監控數據 （Infra Analysis)
• 服務可用性數據 （Uptime Analysis）

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

APM 探索

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

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

通過APM的數據，我們可以看到api/visits在7:58 pm ~ 8:01 pm這個時間段內的調用時間情況。在毛刺之前，api/visits的響應時間在100ms左右，在毛刺階段，響應時間變為1000ms。

基本上，所有的的時間都是花在sping對后端數據庫的訪問上。在異常之前，DB的訪問延時在xxx微秒（百級）左右，在毛刺階段，變為xxxx微秒（千級）

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

Infra探索

要判斷數據庫上的問題，就全方位的IT基礎設施的監控，從主機到數據庫，中間件。
通過Infra Analysis對IT基礎設施進行探索：

可以看到，我們對整個IT基礎設施有一個全景圖。顏色越深的節點，代表該資源在特定時間段內資源使用率越高。我們可以看到，這個時間點內，我們的MySQL服務器的使用情況明顯比其他服務偏高。
可以通過點擊右鍵，進入對應節點的日志。很容易，我們可以發現MySQL服務在這個時間點做了一次多表的聯合掃描。耗時120s

Discovery探索

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

由此，我們找到根本原因

Service探索

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

總結

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。