簡介：本文介紹了應(yīng)用性能監(jiān)控的應(yīng)用價值以及解決方案等。

1、什么是全觀測？

要了解全觀測，我們先看看傳統(tǒng)運維存在哪些問題。

• 數(shù)據(jù)孤島，分散在不同部門，分析排查故障困難；
• 多個廠商的多種工具，無法自動化統(tǒng)一分析；
• 故障是立體的，日志、指標(biāo)等都只能看到一方面的可觀察性；
• 只進行收集，沒有真正深入分析，不能發(fā)揮大數(shù)據(jù)的價值；

而全觀測是對傳統(tǒng)運維的改進。它將日志、指標(biāo)、APM數(shù)據(jù)，匯總在一個平臺，讓運維、開發(fā)、業(yè)務(wù)人員對所有的數(shù)據(jù)從統(tǒng)一視角進行觀察分析，可以實現(xiàn)——

• 建立統(tǒng)一的可視化視圖、對齊時間、過濾條件；
• 建立統(tǒng)一的基于規(guī)則的監(jiān)控和告警；
• 建立統(tǒng)一的機器學(xué)習(xí)的智能監(jiān)控和告警。

在整個全觀測中包括日志、指標(biāo)，APM這三要素中，大家相對比較陌生的可能是APM。

2、什么是應(yīng)用性能監(jiān)測APM

APM定義：企業(yè)應(yīng)用APM對自身復(fù)雜的軟件及應(yīng)用程序的運行狀態(tài)進行監(jiān)測、診斷和分析，從而縮短故障定位時間和提升故障的定位準(zhǔn)確度，進而提升應(yīng)用運行效益和優(yōu)化用戶的使用體驗。

APM涉及的技術(shù)類型包括人工智能、大數(shù)據(jù)、云計算，它的核心是用戶體驗，提升應(yīng)用可靠性性，提升應(yīng)用質(zhì)量，降低IT總擁有成本。

隨著當(dāng)今應(yīng)用的多元化和復(fù)雜化，我們需要通過APM這樣一個應(yīng)用性能監(jiān)測，實現(xiàn)端到端業(yè)務(wù)性能的分析，同時幫助了解我們的服務(wù)，比如說時間都花在了什么上面，服務(wù)崩潰的原因是什么，整個服務(wù)的瓶頸在哪里，從而使我們更好的去跟蹤、優(yōu)化終端用戶的體驗。

3、應(yīng)用性能監(jiān)測APM場景

3.1 APM應(yīng)用場景及痛點

? ? 應(yīng)用異常診斷

— ? 分布式微服務(wù)架構(gòu)的應(yīng)用進行故障排查時存在問題定位難的現(xiàn)象；

— ? 業(yè)務(wù)邏輯復(fù)雜化使企業(yè)對應(yīng)用架構(gòu)梳理和治理難度增加。

? ? 應(yīng)用體驗管理

— ? 用戶體驗直接影響應(yīng)用服務(wù)發(fā)展前景，但獲取用戶訪問系統(tǒng)時的真是和具體情況難。需要及時且快速定位新故障或復(fù)現(xiàn)用戶反饋的問題場景，高效解決故障，防止客戶流失

? ? 應(yīng)用異常診斷

— ? 多視角分析關(guān)聯(lián)指標(biāo)和告警數(shù)據(jù)，并生成故障根因分析報告

— ? 結(jié)合歷史數(shù)據(jù)與運維經(jīng)驗，實時分析異常事務(wù)的發(fā)生原因

3.2 APM能力及業(yè)務(wù)價值

? ? 主動監(jiān)測與被動監(jiān)測，注重終端用戶體驗優(yōu)化

? ? 實時、可視化應(yīng)用架構(gòu)，協(xié)助用戶全面了解復(fù)雜的基礎(chǔ)設(shè)施

? ? 應(yīng)用數(shù)據(jù)積累及實時更新，為解決不同平臺問題提供數(shù)據(jù)支撐

? ? 路徑跟蹤與及時預(yù)警，降低故障損失

? ? 深入監(jiān)控應(yīng)用組件，側(cè)重監(jiān)控工具之間運作的成效，助力用戶快速定位和處理問題

4、阿里云Elasticsearch應(yīng)用性能監(jiān)測功能發(fā)布

基于開源Elastic APM構(gòu)建，提供云上一鍵托管的阿里云Elasticsearch應(yīng)用性能監(jiān)控Server節(jié)點服務(wù)拉起，支持使用阿里云Elasticsearch作為其數(shù)據(jù)存儲，并允許實時監(jiān)控數(shù)千個應(yīng)用程序的性能。

用戶可通過Agent收集包含傳入請求、數(shù)據(jù)庫查詢、緩存調(diào)用、外部HTTP請求、錯誤及異常等多種詳細的性能信息，并通過Elasticsearch進行存儲及可視化分析，為企業(yè)及開發(fā)者提供高效的應(yīng)用程序性能優(yōu)化與監(jiān)控能力。

4.1 用戶根據(jù)默認提供的代理Agent及數(shù)據(jù)采集模板進行數(shù)據(jù)收集

用戶可使用與服務(wù)相同的語言編寫的開源庫，代理程序會掛鉤應(yīng)用程序并收集性能指標(biāo)和錯誤，所有數(shù)據(jù)都會收集并發(fā)送到Server端。

4.2 云上托管阿里云ES應(yīng)用性能監(jiān)控Server實例創(chuàng)建與管理

一鍵拉起Server節(jié)點并進行靈活的擴縮及配置，Server通過JSON HTTP API從代理接收數(shù)據(jù)，單個節(jié)點通常可以處理來自數(shù)百個代理的數(shù)據(jù)。

4.3 配置關(guān)聯(lián)阿里云ES實例，結(jié)合Kibana進行性能指標(biāo)數(shù)據(jù)存儲及分析

結(jié)合阿里云ES自研日志Indexing Service以及海量存儲Openstore，可以達到高并發(fā)的寫入能力，以及低成本、近實時地存儲搜索海量數(shù)據(jù)。云上免費托管拉起的Kibana節(jié)點提供豐富的數(shù)據(jù)分析及可視化能力。

5、全觀測場景技術(shù)難點和解決方案

如何通過云上Elastic Stack能力去解決全觀測-日志場景下的痛點。

5.1 全觀測場景面臨哪些痛點

• 日志/指標(biāo)獲取難

機器、業(yè)務(wù)系統(tǒng)、網(wǎng)絡(luò)鏈路、操作系統(tǒng)，諸多指標(biāo)及日志獲取手段不一，落地過程復(fù)雜；

• 日志/指標(biāo)規(guī)格化要求高

上下游鏈路配合銜接過程中，如何將有效信息從海量日志中獲取；

• 高并發(fā)寫入、系統(tǒng)穩(wěn)定性差

業(yè)務(wù)/流量抖動，日志寫入峰值往往會很高，旁路系統(tǒng)穩(wěn)定性受到很大的挑戰(zhàn)；

• 海量數(shù)據(jù)存儲成本高

日志場景涉及海量數(shù)據(jù)，TB級別起步，甚至PB級；

• 日志分析和指標(biāo)監(jiān)控統(tǒng)一難

借助時序系統(tǒng)可以很好的完成監(jiān)控，但異常分析困難相反，如何在統(tǒng)一平臺完成；

• 系統(tǒng)可擴展性要求高

業(yè)務(wù)調(diào)整帶來的技術(shù)演進一直在發(fā)生，技術(shù)組件更新快，運維框架需要有強大的兼容性；

5.2 云上ELK全觀測解決方案能力

• Beats/APM獲取日志/指標(biāo)

輕量化的提供各類metic、logs、APM數(shù)據(jù)采集能力；

• 數(shù)據(jù)清洗SQL化更簡易

支持各類網(wǎng)絡(luò)格式的日志/指標(biāo)采模板，實時計算Flink提供完整流式SQL能力；

• 云上ES寫入托管及超強穩(wěn)定性

提供Indexing service自研ES寫入托管服務(wù)，及跨機房部署、同城容災(zāi)、場景內(nèi)核優(yōu)化；

• 低成本數(shù)據(jù)存儲

阿里云ES提供冷熱分離數(shù)據(jù)存儲方式，及自研存儲引擎Openstore優(yōu)化存儲壓縮算法；

• 日志分析、指標(biāo)監(jiān)控、APM能力齊全

阿里云ElastiStack全托管，提供日志分析、監(jiān)控、Tracing一站式能力；

針對時序場景，針對性優(yōu)化引擎，保證時序日志監(jiān)控和分析的性能；

• 開源生態(tài)具備強大的可擴展性

基于分布式架構(gòu)，以及靈活開放的RestAPI和Plugin框架，支持各種擴展能力。

6、ES全觀測解決方案實現(xiàn)日志監(jiān)控/運維/分析

• 方案選型：100%兼容開源，與各類開源生態(tài)組件無縫銜接；支持多云/跨云的日志監(jiān)控、運維分析場景
• 方案優(yōu)勢：云上Elasticsearch端到端的采集傳輸及分析能力，提供面向海量數(shù)據(jù)的高性能讀寫、高彈性、低成本解決方案

7、時序日志場景痛點分析

寫多讀少的日志場景下會遇到什么問題？

（1）高峰期寫入壓力大彈性擴展難以有效實施

（2）海量計算+存儲資源成本高低峰期資源閑置

（3）為保證系統(tǒng)穩(wěn)定性集群運維管理復(fù)雜

8、阿里云Elasticsearch日志增強版

基于云原生自研引擎技術(shù)的全觀測數(shù)據(jù)寫入托管及海量存儲能力

• 日志寫入Serverless

自研寫入加速Indexing Service，支持ES日志場景海量數(shù)據(jù)寫入，寫入按實際流量計費，提供極致的彈性和強大的業(yè)務(wù)系統(tǒng)洪峰應(yīng)對能力，客戶無須預(yù)留資源并維護大規(guī)模集群；

• 海量存儲Openstore

可根據(jù)實際數(shù)據(jù)的存儲量按量計費，無須提前預(yù)留集群存儲容量，數(shù)據(jù)兼容ES原生查詢。單據(jù)節(jié)點可存儲百TB數(shù)據(jù)并通過靈活易用的數(shù)據(jù)生命周期策略進行數(shù)據(jù)管理

• 云端10倍寫入彈性擴縮

云端海量算例突破寫入瓶頸，無須提前預(yù)留資源，無低峰閑置浪費

• 成本降低50%以上

按需使用，按實際寫入流量付費，云端按量寫入，優(yōu)化資源成本

• 存儲超低成本

相較于高效云盤存儲成本降低70%，無須提前預(yù)留資源，無低峰閑置浪費

• 海量數(shù)據(jù)可查詢

相較于高效云盤存儲成本降低70%，存儲Serverless按實際用量用多少付多少

9、應(yīng)用服務(wù)數(shù)據(jù)鏈路追蹤與分析

某汽車品牌案例（SLA/KPI指標(biāo)跟蹤、銷售支撐系統(tǒng)鏈路追蹤與日志分析），基于阿里云Elasticsearch的“汽車行業(yè)應(yīng)用服務(wù)數(shù)據(jù)鏈路追蹤和日志分析”介紹。

（1）場景需求

在整體汽車行業(yè)推動業(yè)務(wù)全流程數(shù)字化轉(zhuǎn)型的背景下，內(nèi)部支撐系統(tǒng)，以及依賴的IT組件(如：移動網(wǎng)關(guān))，快速上云后，內(nèi)部系統(tǒng)產(chǎn)生大量的Metric、TraceLog、Log等數(shù)據(jù)，需要在云上快速落地。

某汽車品牌企業(yè)IT部門下，有多個內(nèi)容管理系統(tǒng)(CMS)、分銷商經(jīng)營辦公系統(tǒng)(DMO)、運營質(zhì)量監(jiān)控系統(tǒng)(QIS)、營銷經(jīng)營分析系統(tǒng)(MMP)、BI系統(tǒng)等內(nèi)部支撐系統(tǒng)。

?IT業(yè)務(wù)系統(tǒng)復(fù)雜，既要滿足持續(xù)的業(yè)務(wù)需求，又要整體上云，需要有快速平遷、對接原有云上/云下的IT系統(tǒng)的產(chǎn)品，并能保證技術(shù)架構(gòu)的靈活、開放性，支持后續(xù)的自由拓展；

? 預(yù)期未來的日志數(shù)據(jù)規(guī)模超PB級(180天)，底層技術(shù)架構(gòu)需要兼?zhèn)涞统杀敬鎯?、快速獲取、按需檢索和分析的能力；

（2）方案價值點

極低遷移/改造成本：外資/合資背景的車企IT架構(gòu)借鑒外資方海外的IT架構(gòu)，ES是非常普及的技術(shù)架構(gòu)方案，阿里云ES完全兼容開源，客戶運維系統(tǒng)上云的遷移/改造成本極低，最快一周內(nèi)完成系統(tǒng)上線；

低存儲成本：存儲的數(shù)據(jù)量很大（客戶單個日志集群240TB存儲量）。提供分級存儲的存儲介質(zhì)。例：OSS中存儲的1 PB日志12.6W/月，每月多付3W元/月，日志即可獲得秒級模糊檢索、聚合分析查詢等能力(比自建ELK直接使用高效云盤便宜了20.9W/月)；

真正的彈性伸縮：提供Serverless(服務(wù)化)存算分離架構(gòu)，按流量收取寫入費用，沒有流量不收錢，真正意義上的“瞬時彈性伸縮”；

整體方案架構(gòu)

10、ES應(yīng)用性能APM Server創(chuàng)建

3min快速拉起APM Server進行數(shù)據(jù)傳輸，最低僅需180元/月

在APM server控制臺列表，可以查看有多少個APM server在運行。

我們可以看到APM server的訪問地址，將這個訪問地址配到APM agent里面。APM agent采集過程中，可以支持多種客戶端語言，可以快速的實現(xiàn)數(shù)據(jù)采集的配置。

當(dāng)數(shù)據(jù)采集之后，我們就可以來到Kibana的界面，通過Dev tools進行一些索引的創(chuàng)建。

Kibana界面可以查看所有的APM服務(wù)數(shù)據(jù)，如平均響應(yīng)時長，P95值，異常發(fā)生的時間等等。

進入查看某個服務(wù)的詳細數(shù)據(jù)：

點擊查看某個具體的請求數(shù)據(jù)的瀑布視圖：

查看瀑布視圖的詳情：

比如發(fā)現(xiàn)有很多select正在進行，可以點擊查看具體詳情：

查看全鏈路數(shù)據(jù)：

原文鏈接

本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。?

總結(jié)

以上是生活随笔為你收集整理的【全观测系列】Elasticsearch应用性能监控实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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