Skywalking 可擴展的觀測
原文地址
http://skywalking.apache.org/blog/2020-08-11-observability-at-scale/
SkyWalking不斷發(fā)展以解決觀測的可擴展性問題秽褒，并從純跟蹤系統(tǒng)發(fā)展為功能豐富的觀測平臺廉油，該平臺現(xiàn)已用于分析每天收集數(shù)百億次跟蹤的大型系統(tǒng)。
SkyWalking解愤，Apache的頂級項目，是用來解決21世紀那些增長迅速城侧、分布式蹦误、異構(gòu)化系統(tǒng)的問題的開源APM和觀測分析平臺。為了解決當前系統(tǒng)管理員碰到的問題：在大量相互依賴的服務中識別和定位針胚嘲，在多語言應用程序之間獲取“Apples to Apples”指標作儿，以及獲得完整而有意義的性能視圖。
譯者注：apples to apples 意思是有意義地比較慢逾，比如將HBase和Sqllite進行比較立倍，幾乎沒有意義
SkyWalking是一個整體平臺，可以觀察網(wǎng)格上或網(wǎng)格外的微服務侣滩，并可以使用輕量級負載提供一致的監(jiān)視口注。
設計可擴展
當SkyWalking于2015年首次初始化時，其主要用例是監(jiān)視中國頂尖電信公司君珠，中國聯(lián)通和中國移動的第一代分布式核心系統(tǒng)寝志。 在2013-2014年間，電信公司計劃用分布式系統(tǒng)替換其舊的傳統(tǒng)單體應用程序策添。 從第一天起材部，支持超大型分布式系統(tǒng)和可擴展性便是高優(yōu)先級的設計目標。 那么唯竹，可擴展設計中的核心是什么乐导？
推還是拉
推模型或者拉模型跟數(shù)據(jù)流相關(guān)。如果agent收集數(shù)據(jù)并且將數(shù)據(jù)推送到后端進行后續(xù)分析處理浸颓，我們叫做推模型物臂。關(guān)于推模型和拉模型的爭論已經(jīng)持續(xù)了很長時間。對觀測系統(tǒng)來說产上，重要的是最小化agent的消耗棵磷，可適配不同類型的觀測數(shù)據(jù)。
收集數(shù)據(jù)后晋涣，Agent會在短時間內(nèi)將數(shù)據(jù)發(fā)送出去仪媒。這樣，我們就不必擔心本地緩存過載谢鹊。一種典型的情況是Endpoint（HTTP的URI算吩，gRPC的服務）的metrics留凭。任何服務都可以輕松擁有數(shù)百個甚至數(shù)千個Endpoint。 APM系統(tǒng)必須具有這些指標分析功能赌莺。
此外冰抢，metrics并不是觀測領域中唯一的事物。 跟蹤和日志也很重要艘狭。 SkyWalking旨在在生產(chǎn)環(huán)境中提供100％的采樣率跟蹤功能挎扰。 顯然，推送模式是唯一的解決方案巢音。
同時遵倦，本機使用推模式并不意味著SkyWalking不能進行數(shù)據(jù)提取。 在最新的8.x版本中官撼，SkyWalking支持從Prometheus儀表支持的服務中獲取數(shù)據(jù)梧躺，以減少最終用戶的非重復工程。 同樣傲绣，拉模式在基于MQ的傳輸中很流行掠哥，通常作為Kafka consumer。 SkyWalking agent 使用推模式秃诵，而OAP服務器使用拉模式续搀。
結(jié)論：推模式是原生方式，但是拉模式在某些特殊情況下也適用菠净。
譯者注：推拉模型還跟您的網(wǎng)絡規(guī)劃息息相關(guān)禁舷，如果您的Skywalking服務器沒有和服務面對面網(wǎng)絡打通，那么拉模型幾乎不可能實現(xiàn)
監(jiān)控指標分析不僅僅只是數(shù)學計算
度量標準依賴于數(shù)學理論和計算毅往。 百分位數(shù)是識別長尾問題的好方法牵咙，合理的平均響應時間和成功率是良好的SLO。 但是攀唯，這些還不是全部洁桌。 分布式跟蹤不僅提供具有詳細信息的跟蹤，而且還提供可以分析的高價值指標侯嘀。
Ops和SRE團隊需要提供服務拓撲圖另凌，以用于NOC儀表板和確認系統(tǒng)數(shù)據(jù)流。 SkyWalking使用STAM（流拓撲分析方法）從跟蹤分析拓撲残拐，或者在服務網(wǎng)格環(huán)境中基于ALS（Envoy 訪問日志服務）進行分析。 無法從簡單的指標SDK提取節(jié)點（服務）和線路（服務關(guān)系）的拓撲和指標
與解決Endpoint metics收集的限制一樣碟嘴，SkyWalking也需要從跟蹤數(shù)據(jù)中進行端點依賴關(guān)系分析溪食。 端點依賴性分析提供了更重要和更具體的信息，包括上游和下游娜扇。 這些依賴關(guān)系和度量標準可幫助開發(fā)人員團隊將性能問題的邊界定位到特定的代碼塊错沃。
預計算還是查詢階段計算栅组？
查詢階段計算更加靈活。在分析階段進行預計算枢析，提供了更好更穩(wěn)定的性能玉掸。再次申明一下設計原則：Skywalking面向大型分布式系統(tǒng)。查詢階段的計算范圍非常有限醒叁，并且大多數(shù)指標計算都需要預先定義和預先計算司浪。 支持大型數(shù)據(jù)集的關(guān)鍵是在設計級別縮小數(shù)據(jù)集的大小。 預先計算允許將原始數(shù)據(jù)合并到下游的匯總結(jié)果中把沼，以用于查詢甚至進行警報檢查啊易。
指標的TTL是另一個重要的業(yè)務推動因素。 由于預計算可以使查詢提供近乎線性的性能饮睬，并且使用類似的查詢基礎結(jié)構(gòu)租谈，組織可以提供更高的TTL，從而提供了擴展的性能可視性捆愁。
說到警報割去，查詢階段的計算也意味著警報查詢需要基于查詢引擎。 但是在這種情況下昼丑，當數(shù)據(jù)集增加時呻逆，查詢性能可能會不一致。 進行指標查詢也是一樣的（也會不一致）矾克。
今天的案例
如今页慷，SkyWalking正在監(jiān)控許多大型企業(yè)中的超大規(guī)模分布式系統(tǒng)，其中包括阿里巴巴胁附，華為酒繁，騰訊，百度控妻，中國電信以及各種銀行和保險公司州袒。在線服務公司的流量比傳統(tǒng)公司（如銀行和電信供應商）更多。
SkyWalking是可觀察性平臺弓候，用于分布式系統(tǒng)的各種用例郎哭，這些用例在許多方面(注：如規(guī)模，語言等)都非常大：
- 拉勾網(wǎng)菇存，在線求職平臺
- SkyWalking監(jiān)控超過100個微服務夸研，500多個jvm實例
- SkyWalking每天收集和分析四十億條跟蹤，以分析性能數(shù)據(jù)依鸥，包括30萬多個端點和依賴項的指標
- 整個集群超過50000消息每秒
- 永輝超市亥至，在線服務
- SkyWalking每天使用指標來分析至少百億+（3B）跟蹤
- SkyWalking的第二個較小的部署，每天分析2億+條跟蹤
- 百度，互聯(lián)網(wǎng)AI公司姐扮，k8部署
- SkyWalking每天從提供120多種服務的1,400多個Pod中收集1T +跟蹤
- 隨著更多服務的添加絮供，規(guī)模繼續(xù)擴大
- 貝殼找房
- 從一開始就使用SkyWalking，并且在PMC團隊中有兩名成員茶敏。
- 部署每天收集16+億條跟蹤
- 阿里云霄（Ali Yunxiao）壤靶，阿里云上的DevOps服務
- SkyWalking每天收集和分析數(shù)十億個Spans
- SkyWalking使AliCloud的45個服務和約300個實例保持穩(wěn)定
- 最大的企業(yè)對消費者在線零售商之一阿里巴巴天貓的一個部門，從淘寶網(wǎng)分拆出來
- 定制版本的SkyWalking每天監(jiān)控數(shù)十億次跟蹤
- 同時惊搏，他們正在利用SkyWalking的代理技術(shù)堆棧構(gòu)建負載測試平臺贮乳，并利用其跟蹤和上下文傳播功能
總結(jié)
SkyWalking的觀測方法遵循以下原則：
- 理解邏輯模型：不要將可觀察性視為數(shù)學工具。
- 首先確定依賴性胀屿，然后確定其指標塘揣。
- 擴展應該輕松而原生地完成。
- 保持不同體系結(jié)構(gòu)之間以及APM本身性能的一致性宿崭。
