背景

隨著字節(jié)跳動(dòng)業(yè)務(wù)規(guī)模不斷擴(kuò)大，對(duì)存量和新增業(yè)務(wù)的服務(wù)質(zhì)量承諾變得越發(fā)關(guān)鍵。穩(wěn)定性治理方面：怎樣支持保障服務(wù)線上的高可用性，或者在出現(xiàn)故障/事故時(shí)，如何高效且迅速地止損、定位分析影響面已成為一個(gè)重要議題。

穩(wěn)定性建設(shè)所涉及的話題十分廣泛，涵蓋流程梳理與標(biāo)準(zhǔn)化、數(shù)據(jù)標(biāo)準(zhǔn)化、SLO 定義、故障自愈、事故復(fù)盤和演練等方面，字節(jié)跳動(dòng)基礎(chǔ)架構(gòu)可觀測(cè)團(tuán)隊(duì)提供的穩(wěn)定性平臺(tái)建設(shè)思路是“事前預(yù)防、事中處理、事后復(fù)盤、事后補(bǔ)救/反哺事前”這四個(gè)階段。

其中， 觀測(cè)數(shù)據(jù)標(biāo)準(zhǔn)化以及一系列配套的數(shù)據(jù)鏈路，如：數(shù)據(jù)埋點(diǎn)、數(shù)據(jù)消費(fèi)、數(shù)據(jù)存儲(chǔ)、數(shù)據(jù)查詢、離線數(shù)倉(cāng)等，都是后續(xù)穩(wěn)定性建設(shè)的重要數(shù)據(jù)基石。

并且，由此引申出排障/止損效率的問(wèn)題，由于字節(jié)的服務(wù)/基礎(chǔ)設(shè)施是分層建設(shè)的，包括端側(cè)客戶體驗(yàn)層、網(wǎng)絡(luò)接入層、應(yīng)用服務(wù)層、基礎(chǔ)設(shè)施層、IDC\資源層等，不同層面的統(tǒng)計(jì)/描述口徑是否一致、能否對(duì)應(yīng)，以達(dá)到在跨層間能上卷下鉆和平層內(nèi)過(guò)濾聚合的“車同軌書同文”效果，這對(duì)于大幅提升整體排查效率， 讓 SRE/GOC 同學(xué)能夠自助完成端到端的問(wèn)題排查就顯得尤為重要。

擁有統(tǒng)一的觀測(cè)數(shù)據(jù)標(biāo)準(zhǔn)， 能夠在很大程度上提升團(tuán)隊(duì)間的排障效率，從人工分析的方式提升至更大程度的自助/自動(dòng)化排障的階段。

埋點(diǎn)標(biāo)準(zhǔn)化的重要性

提高研發(fā)效率 & 降低研發(fā)協(xié)同成本

• 面向排障方面：跨層間的上下文過(guò)濾便捷，術(shù)語(yǔ)統(tǒng)一。
• 進(jìn)行歷史數(shù)倉(cāng)分析（容量?jī)?yōu)化）時(shí)，整體數(shù)據(jù)處理邏輯的適配成本會(huì)大幅降低。
• 用戶的學(xué)習(xí)曲線陡峭，理解心智負(fù)擔(dān)沉重。

為 AIOps 提供強(qiáng)有力的數(shù)據(jù)支撐

觀測(cè)數(shù)據(jù)屬于 AIOps 的五大基石（數(shù)據(jù)、知識(shí)、算法、代碼聯(lián)動(dòng)、人機(jī)協(xié)同）之一。在清華裴丹老師的《AIOps 落地的 15 條原則》里，也都提及了數(shù)據(jù)的重要性。

擁有數(shù)據(jù)標(biāo)準(zhǔn)化和統(tǒng)一的訪問(wèn)體驗(yàn)，為后續(xù)穩(wěn)定性的終極目標(biāo) MTTR 1-5-10（1 分鐘發(fā)現(xiàn)，5 分鐘響應(yīng)以及 10 分鐘快恢復(fù)）提供了數(shù)據(jù)層面的保障。包括同層數(shù)據(jù)的聚合 / 過(guò)濾，以及跨層數(shù)據(jù)的下鉆和上卷，都會(huì)有統(tǒng)一的使用方式。

名詞解釋

字節(jié)埋點(diǎn)標(biāo)準(zhǔn)化挑戰(zhàn)與拆解思路

挑戰(zhàn)：歷史上可觀測(cè)性埋點(diǎn)質(zhì)量偏低

首先，我們對(duì)埋點(diǎn)標(biāo)準(zhǔn)化進(jìn)行定義，包括但不僅限于如下的標(biāo)準(zhǔn)定義，包括覆蓋完整、定義統(tǒng)一、計(jì)量準(zhǔn)確、面向引擎友好等四大方面。

簡(jiǎn)而言之，在 2020 年以前，從覆蓋完整、定義統(tǒng)一、計(jì)量準(zhǔn)確、面向引擎友好等維度來(lái)看，字節(jié)整體的觀測(cè)數(shù)據(jù)埋點(diǎn)存在一定的差距。

具體如下：

負(fù)載均衡 埋點(diǎn)

• 計(jì)量準(zhǔn)確：中等水平

     a.存在較嚴(yán)重的打點(diǎn)丟失問(wèn)題

• 面向引擎友好：較低水平

     a.指標(biāo)打點(diǎn)對(duì)于配置預(yù)計(jì)算不友好

     b.指標(biāo)名膨脹也比較嚴(yán)重

微服務(wù) 埋點(diǎn)

• 覆蓋完整：中等水平

     a.20 年前 Tracing 方案還在 V1 版本

• 計(jì)量準(zhǔn)確：中等水平

     a.遇到高基數(shù)的指標(biāo)會(huì)被封禁

• 面向引擎友好：較低水平

     a.指標(biāo)打點(diǎn)對(duì)于配置預(yù)計(jì)算不友好

     b.指標(biāo)名膨脹也比較嚴(yán)重

     c.加權(quán)計(jì)算也不好實(shí)現(xiàn)

語(yǔ)言運(yùn)行時(shí) 埋點(diǎn)

• 定義統(tǒng)一：較低水平

     a.Golang & C++ 框架 不同的版本定義的指標(biāo)格式都不太一樣

• 面向引擎友好：較低水平

     a.指標(biāo)打點(diǎn)對(duì)于配置預(yù)計(jì)算不友好

容器指標(biāo) 埋點(diǎn)

• 覆蓋完整：較低水平
• 沒(méi)有日志采集覆蓋
• 計(jì)量準(zhǔn)確：中等水平
• 遇到高基數(shù)的指標(biāo)會(huì)被封禁
• 面向引擎友好：較低水平
• 指標(biāo)打點(diǎn)對(duì)于配置預(yù)計(jì)算不友好

基礎(chǔ)架構(gòu)存儲(chǔ) & 數(shù)據(jù)庫(kù) 埋點(diǎn)

• 覆蓋完整：較低水平
• 存儲(chǔ)、數(shù)據(jù)庫(kù)、MQ 客戶端沒(méi)有黃金指標(biāo)打點(diǎn)
• 沒(méi)有日志采集覆蓋
• 計(jì)量準(zhǔn)確：較低水平
• 不同存儲(chǔ)、數(shù)據(jù)庫(kù)、MQ 產(chǎn)品打點(diǎn)格式 都不一
• 面向引擎友好：較低水平

     a.指標(biāo)打點(diǎn)對(duì)于配置預(yù)計(jì)算不友好

思路：分層&向后兼容推進(jìn)埋點(diǎn)標(biāo)準(zhǔn)化

總結(jié)來(lái)說(shuō)，之前的字節(jié)服務(wù)端觀測(cè)數(shù)據(jù)質(zhì)量大致存在三類問(wèn)題。

• 同層數(shù)據(jù)/跨層數(shù)據(jù)不一致。
• 觀測(cè)的多模態(tài)數(shù)據(jù)類型（指標(biāo)、日志、鏈路）的數(shù)據(jù)定義不統(tǒng)一。
• 觀測(cè)數(shù)據(jù)格式對(duì)引擎不夠友好，例如所有數(shù)據(jù)都在 default 租戶的一個(gè)大倉(cāng)里，再比如很多觀測(cè)指標(biāo)的定義對(duì)于預(yù)計(jì)算不友好。

針對(duì)上述問(wèn)題，我們采取了如下的多個(gè)思路逐一進(jìn)行解決。

實(shí)施思路

一方面，在埋點(diǎn)側(cè)就盡可能統(tǒng)一埋點(diǎn) TagKV 定義，而且平臺(tái)級(jí) TagKV 都通過(guò)環(huán)境變量或者請(qǐng)求上下文自動(dòng)注入對(duì)應(yīng)的 Tag Value， 以防止由業(yè)務(wù)手工注入帶來(lái)的人工錯(cuò)誤。

另一方面，對(duì)于指標(biāo)、鏈路和日志侵入式 SDK，我們通過(guò)字節(jié)內(nèi)部的遠(yuǎn)程過(guò)程調(diào)用框架以及存儲(chǔ)、數(shù)據(jù)庫(kù)、消息中間件的客戶端 SDK 搭載嵌入中間件，對(duì)于業(yè)務(wù)來(lái)說(shuō)，能相對(duì)透明地升級(jí)到最新特性的版本。另外， 對(duì)于遠(yuǎn)遠(yuǎn)低于 SDK 基線版本的服務(wù)， 我們也通過(guò)字節(jié)軟件供應(yīng)鏈安全治理平臺(tái)通過(guò)編譯卡點(diǎn)的不同程度[warning 提示/發(fā)布卡點(diǎn)]推動(dòng)業(yè)務(wù)升級(jí)。

在 負(fù)載均衡、應(yīng)用、中間件、存儲(chǔ)計(jì)算組件等各個(gè)縱向方面， 我們也主動(dòng)與對(duì)應(yīng)的平臺(tái)對(duì)接，推動(dòng)指標(biāo)、日志、鏈路的埋點(diǎn)注入。

最后，在指標(biāo)埋點(diǎn)上也額外關(guān)注對(duì)于多租戶的聲明，以達(dá)到一定的分庫(kù)分表功能，以及多值聲明，以最大程度減少數(shù)據(jù)消費(fèi)和存儲(chǔ)成本。如下所示， 就是團(tuán)隊(duì)在各個(gè)不同觀測(cè)對(duì)象的埋點(diǎn)方面所做的業(yè)務(wù)推進(jìn)情況。

難點(diǎn)：識(shí)別和解決

類似觀測(cè)數(shù)據(jù)標(biāo)準(zhǔn)化的工作歷經(jīng)多年，牽涉的團(tuán)隊(duì)眾多，整個(gè)過(guò)程并非毫無(wú)波折。遇到問(wèn)題時(shí)要解決問(wèn)題并思考能否將其標(biāo)準(zhǔn)化或者平臺(tái)化，同時(shí)也要考慮能否盡可能地復(fù)用其他團(tuán)隊(duì)的能力和工具來(lái)助力我們進(jìn)一步推廣。當(dāng)時(shí)如何高效地推動(dòng)業(yè)務(wù)升級(jí)是我們的主要目標(biāo)。

[業(yè)務(wù)推進(jìn)] 高效推動(dòng)業(yè)務(wù)升級(jí)觀測(cè)SDK

在 Metrics SDK 需要升級(jí)到基線版本的情況下，以前的做法是在字節(jié)軟件供應(yīng)鏈安全治理平臺(tái)上配置版本攔截，提醒用戶升級(jí)，但是整體升級(jí)效率比較低，我們也無(wú)法跟蹤用戶的升級(jí)進(jìn)展。因此我們聯(lián)合字節(jié)軟件供應(yīng)鏈安全治理平臺(tái)團(tuán)隊(duì)實(shí)現(xiàn) SDK 自動(dòng)升級(jí)功能。

Metrics SDK 自動(dòng)升級(jí)

Metrics SDK 自動(dòng)升級(jí)功能可以自動(dòng)實(shí)現(xiàn)在當(dāng)前業(yè)務(wù)代碼庫(kù)的代碼提交期間，如果檢測(cè)到對(duì)應(yīng)集成的metrics SDK 低于基線版本，則會(huì)向用戶推送代碼提交失敗的通知，提醒用戶需要主動(dòng)升級(jí)到metrics SDK基線版本或以上的操作。

遠(yuǎn)程過(guò)程調(diào)用 框架 & 基礎(chǔ)組件客戶端 集成 BytedTrace SDK 集成

觀測(cè)團(tuán)隊(duì)多年來(lái)持續(xù)推動(dòng)公司的遠(yuǎn)程過(guò)程調(diào)用 框架以及基礎(chǔ)組件客戶端 集成 BytedTrace SDK 。借助字節(jié)軟件供應(yīng)鏈安全治理平臺(tái)進(jìn)行遞進(jìn)式卡點(diǎn)推廣，依靠代碼血緣平臺(tái)來(lái)推動(dòng)框架、組件的基礎(chǔ)庫(kù)版本實(shí)現(xiàn)升級(jí)。在存有流量的微服務(wù)上，BytedTrace SDK的覆蓋比例按照 TCE pod 接入情況來(lái)計(jì)算，當(dāng)前已達(dá)到 95%。

從服務(wù)的優(yōu)先級(jí)角度而言，公司當(dāng)前96% 的 P0 服務(wù)中已接入 Bytedtrace SDK 。

[業(yè)務(wù)推進(jìn)] 提升基礎(chǔ)組件觀測(cè)埋點(diǎn)質(zhì)量

TCE 調(diào)度 / 運(yùn)行時(shí) 打點(diǎn)格式設(shè)計(jì)思路

前文提到，提升業(yè)務(wù)層、應(yīng)用層、容器層等多層間指標(biāo)的跨層關(guān)聯(lián)和下鉆能力是指標(biāo)標(biāo)準(zhǔn)化的一個(gè)重要目標(biāo)，而實(shí)現(xiàn)跨層關(guān)聯(lián)的關(guān)鍵動(dòng)作在于保證同一含義的指標(biāo) TagKV 在各層上的定義保持統(tǒng)一，為實(shí)現(xiàn)這一點(diǎn)，我們對(duì)各個(gè)層次上的核心組件進(jìn)行了統(tǒng)一的設(shè)計(jì)，具體如下：

• 縱向上，對(duì)齊Metrics 2.0 SDK 平臺(tái)級(jí)TagKV規(guī)范 | | 容器層 | 與調(diào)度合作，對(duì)容器指標(biāo)采集agent(TCE調(diào)度)進(jìn)行標(biāo)準(zhǔn)化改造 | -   對(duì)齊Metrics 2.0 SDK 平臺(tái)級(jí)TagKV規(guī)范                             |

1. 首先，我們?cè)?Metrics 2.0 SDK 內(nèi)置定義了一套平臺(tái)級(jí) TagKV，這樣所有使用 Metrics 2.0 SDK 的業(yè)務(wù)打點(diǎn)都會(huì)攜帶標(biāo)準(zhǔn)的預(yù)定義的 TagKV。這些共同TagKV包括：_cluster、_psm、_pod_name、_ipv4 等。
2. 在應(yīng)用層，挑選了對(duì)業(yè)務(wù)排障、應(yīng)用觀測(cè)常用且通用的兩類指標(biāo)（運(yùn)行時(shí)、遠(yuǎn)程過(guò)程調(diào)用）進(jìn)行標(biāo)準(zhǔn)化，目標(biāo)是在橫向上，提供跨語(yǔ)言、統(tǒng)一的指標(biāo)名、TagKV語(yǔ)義定義等；在縱向上，對(duì)齊 Metrics 2.0 SDK 平臺(tái)級(jí) TagKV 規(guī)范，以便于跨層關(guān)聯(lián)。以 運(yùn)行時(shí) 指標(biāo)為例，其定義規(guī)范如下：

     a.不同語(yǔ)言的指標(biāo)采用統(tǒng)一命名約定：runtime. {runtime} . {metric}[ . {field}]

     b.不同語(yǔ)言類似含義指標(biāo)采用統(tǒng)一命名風(fēng)格：如 go、java 中統(tǒng)計(jì)堆對(duì)象申請(qǐng)量的指標(biāo)都命名為memory.allocated_bytes

     c.必須包含 Metrics 2.0 SDK TagKV 規(guī)范的平臺(tái)級(jí) TagKV，如 _psm、_pod_name 等

3. 在容器層，與調(diào)度團(tuán)隊(duì)共同推動(dòng)其 TCE 容器指標(biāo)采集 agent(TCE調(diào)度) 的指標(biāo)標(biāo)準(zhǔn)化改造，指標(biāo) TagKV 對(duì)齊Metrics 2.0 SDK TagKV 規(guī)范。

通過(guò)將這些核心組件進(jìn)行標(biāo)準(zhǔn)化改造，為跨層的指標(biāo)關(guān)聯(lián)和下鉆提供了能力基礎(chǔ)。同時(shí)，在每個(gè)核心組件的指標(biāo)定義上，我們還通過(guò)以下兩個(gè)方式進(jìn)一步提升埋點(diǎn)的性能和成本收益，第一點(diǎn)是對(duì)各個(gè)組件使用獨(dú)立租戶，實(shí)現(xiàn)資源的隔離，保障寫入穩(wěn)定性和查詢性能；

第二點(diǎn)是在語(yǔ)義明確的前提下，盡量使用多值格式定義指標(biāo)，降低存儲(chǔ)成本。以 TCE調(diào)度 指標(biāo)為例，將原來(lái) mem 相關(guān)的四個(gè)指標(biāo)合并為一個(gè)多值指標(biāo)的四個(gè)字段，存儲(chǔ)成本大致可以被認(rèn)為降低至四分之一。

[配套工具] 幫助平滑遷移觀測(cè)數(shù)據(jù)

[工具1] 語(yǔ)義化指標(biāo)替換

我們提供語(yǔ)義化指標(biāo)替換，稱為Measurement，其能力就是對(duì)原始 Metrics 打點(diǎn)的語(yǔ)義化封裝；同時(shí)能識(shí)別在不同條件下應(yīng)該使用哪個(gè)版本的指標(biāo)以及對(duì)應(yīng)的 TagKV。這兩個(gè)關(guān)鍵能力能夠促使在做數(shù)據(jù)遷移時(shí)，觀測(cè)大盤和報(bào)警基本達(dá)到比較平滑的狀態(tài)。

原始 Metrics 打點(diǎn)：直接寫入時(shí)序數(shù)據(jù)庫(kù)（可以是 metrics \ influxdb \ prometheus）的數(shù)據(jù)。

語(yǔ)義化封裝：用標(biāo)準(zhǔn)的語(yǔ)義化來(lái)包裝原始的 metrics 打點(diǎn)數(shù)據(jù)。比如 go 服務(wù)的 gc 數(shù)量的 metrics 打點(diǎn)是 go.{{.psm}}.numGcs，其中{{.psm}}為具體的 psm， 我們會(huì)定制一個(gè)語(yǔ)義化指標(biāo)名叫 "runtime.go.gc_num"來(lái)表達(dá) go 服務(wù)的 gc 數(shù)量，包括用統(tǒng)一的 TagKV 來(lái)封裝對(duì)應(yīng)的原始 TagKV。不管是 open api 還是前端調(diào)用， 都用指標(biāo) "runtime.go.gc_num" 對(duì)measurement 服務(wù)進(jìn)行調(diào)用。

不同條件下的查詢路由：需要這個(gè)能力是因?yàn)樵谧止?jié)內(nèi)部原始 Metrics 的打點(diǎn)會(huì)不斷的升級(jí)， 比如 golang 運(yùn)行時(shí) 歷史上會(huì)有 v1 、v2 、v3 多個(gè)版本，我們需要能夠在給定的輸入信息條件下去查詢到對(duì)應(yīng)的指標(biāo)版本。這個(gè)判斷條件實(shí)現(xiàn)的邏輯一般為可用輸入的 psm 名字構(gòu)成 Metrics go v1 的指標(biāo)名，再根據(jù)指標(biāo)名的數(shù)據(jù)是否存在來(lái)判斷是 runtime v1、runtime v2 或者 runtime v3 的版本，指標(biāo)判斷也以此類推?；蛘呖梢酝ㄟ^(guò) psm 的 scm 編譯信息確定該 psm 編譯的 golang 運(yùn)行時(shí) 版本是 v1、v2 或者 v3。通過(guò)對(duì)應(yīng)條件的判斷來(lái)做到對(duì)應(yīng)數(shù)據(jù)的查詢路由。

在有了 Measurement 能力后，我們抽象出了 Measurement 服務(wù)，該服務(wù)作為觀測(cè)大盤和報(bào)警的一個(gè)數(shù)據(jù)源。在盡量不需要用戶介入的情況下完成數(shù)據(jù)打點(diǎn)的遷移和替換。

當(dāng)前借助 Measurement 能力，針對(duì)公司的 遠(yuǎn)程過(guò)程調(diào)用、HTTP 等框架，容器引擎、FaaS、機(jī)器學(xué)習(xí)推理等平臺(tái)，還有負(fù)載均衡、緩存、數(shù)據(jù)庫(kù)、消息隊(duì)列等基礎(chǔ)組件，以及golang 運(yùn)行時(shí) 等，均進(jìn)行了統(tǒng)一的標(biāo)準(zhǔn)化語(yǔ)義封裝，這些語(yǔ)義化封裝在觀測(cè)平臺(tái)上均有所展現(xiàn)。

[工具2] Metrics 前綴分流

怎樣幫助業(yè)務(wù)順利地遷移到新租戶，同時(shí)確保新老指標(biāo)的查詢方式均可使用，是我們?cè)谕苿?dòng)業(yè)務(wù)租戶遷移時(shí)所面臨的較大挑戰(zhàn)。

針對(duì)上述問(wèn)題，觀測(cè)團(tuán)隊(duì)起初推進(jìn)引導(dǎo)用戶主動(dòng)遷移至新租戶，旨在實(shí)現(xiàn)租戶隔離，提供更優(yōu)的穩(wěn)定性保障，進(jìn)行精細(xì)化容量治理以降低成本。然而，后來(lái)發(fā)現(xiàn)主動(dòng)遷移的速度太慢，趕不上打點(diǎn)量的自然增長(zhǎng)。于是，推出了讓用戶無(wú)感知的被動(dòng)租戶遷移方案。大致思路是依據(jù)某些特定的指標(biāo)前綴，主要涵蓋一級(jí) / 二級(jí)前綴，通過(guò)特定配置把這些指標(biāo)分別路由到不同的新租戶，并且在新租戶上支持查詢翻譯，即便用戶不修改查詢租戶，繼續(xù)用 Default 租戶查詢?nèi)阅苷＋@取數(shù)據(jù)。該方案具有以下優(yōu)勢(shì)：

1. 業(yè)務(wù)在讀寫兩側(cè)無(wú)需進(jìn)行代碼變更，就能將流量遷移到新租戶集群。
2. 最大程度減少不同租戶間因集群變更和讀寫流量變化對(duì)線上穩(wěn)定性產(chǎn)生的相互影響，提供更出色的穩(wěn)定性保障。
3. 精準(zhǔn)對(duì)接業(yè)務(wù)線租戶，便于后續(xù)進(jìn)行打點(diǎn)流量治理、容量規(guī)劃以及資源充值等操作。

具體的實(shí)現(xiàn)由 Metrics 組件中各模塊的相互配合完成，包括寫入、控制面、查詢、數(shù)倉(cāng)等方面，大致的實(shí)現(xiàn)流程如下：

前綴分流租戶的整個(gè)過(guò)程存在眾多細(xì)節(jié)，為減少過(guò)程中的過(guò)多人為操作，防止出現(xiàn)某些環(huán)節(jié)被遺忘的情況，觀測(cè)團(tuán)隊(duì)設(shè)計(jì)了分流流程工單以及白屏化運(yùn)維平臺(tái)，盡可能讓整個(gè)操作流程實(shí)現(xiàn)自動(dòng)化，提高分流租戶的效率。此外，前綴分流遷移新租戶的整個(gè)過(guò)程對(duì)于業(yè)務(wù)來(lái)說(shuō)成本為零，同時(shí)對(duì)于 觀測(cè)團(tuán)隊(duì)而言不像依賴業(yè)務(wù)方主動(dòng)遷移那樣周期漫長(zhǎng)，其周期短、生效時(shí)間快，能夠收斂團(tuán)隊(duì)人力的持續(xù)投入。

總的來(lái)說(shuō)，觀測(cè)團(tuán)隊(duì)提供了一種讓用戶無(wú)感知、實(shí)現(xiàn)無(wú)縫遷移新租戶的方案，用戶的核心觀測(cè)大盤和報(bào)警也無(wú)需修改，最大程度降低了埋點(diǎn)標(biāo)準(zhǔn)化對(duì)用戶的打擾。

埋點(diǎn)標(biāo)準(zhǔn)化字節(jié)的實(shí)踐與效果

觀測(cè)數(shù)據(jù)質(zhì)量前后對(duì)比

經(jīng)過(guò) 2020-2022 年推進(jìn) BytedTrace SDK 覆蓋率、2023 年推動(dòng)云基礎(chǔ)組件和應(yīng)用層指標(biāo)租戶遷移之后， 從埋點(diǎn)標(biāo)準(zhǔn)化的 4 個(gè)維度看，都有不同程度的質(zhì)量提升。

負(fù)載均衡

-計(jì)量準(zhǔn)確：較高水平 [2020年為中等水平]

• 通過(guò) 2.0 SDK 三個(gè)特性， 基本消除丟點(diǎn)的問(wèn)題：

     a.打點(diǎn)本地聚合

     b.面向字節(jié)流的 codec 編碼

     c.Agentless 投遞

-面向引擎友好：較高水平 [2020年為較低水平]

• 實(shí)現(xiàn)面向預(yù)計(jì)算友好的效果

-成本收益：

• Metrics 2. 0 打點(diǎn)商品成本相對(duì) 1.0 下降 94%
• Metrics 2. 0 很好地解決了打點(diǎn)封禁問(wèn)題，特別是在一些配置量巨大的核心集群，解決了其超過(guò) 90%打點(diǎn)無(wú)法查詢的情況
• Metrics2. 0 TLB 機(jī)器成本初步統(tǒng)計(jì)主容器和 adaptor 打平，同時(shí)相對(duì) 1.0 節(jié)約了 ms2 的 15000 核資源

微服務(wù)

-覆蓋完整：較高水平 [2020年為中等水平]

• 80%以上 PSM 覆蓋到 BytedTrace SDK 集成

-計(jì)量準(zhǔn)確：中等偏上水平 [2020年為中等水平]

• 高基數(shù)的指標(biāo)封禁問(wèn)題 由于遷移到了新租戶 可以做封禁閾值定制化

• [計(jì)劃中] 升級(jí) bytedTrace 內(nèi)的 metrics 2.0 SDK 降低丟點(diǎn)的風(fēng)險(xiǎn)

-面向引擎友好：較高水平 [2020年為較低水平]

• 實(shí)現(xiàn)面向預(yù)計(jì)算友好的效果

-成本收益：

• 以計(jì)算關(guān)鍵組件 Consumer 為例，新租戶只需要老租戶 20%的資源，就可以完成相同數(shù)據(jù)的寫入計(jì)算；其他寫入計(jì)算類組件也類似
• 以存儲(chǔ)關(guān)鍵組件 tsdc 為例，新租戶只需要老租戶 55%的資源，就可以完成數(shù)據(jù)的寫入、存儲(chǔ)

語(yǔ)言 運(yùn)行時(shí)

• 定義統(tǒng)一：較高水平 [2020年為較低水平]
• 統(tǒng)一了不同語(yǔ)言和框架的 運(yùn)行時(shí) 打點(diǎn)格式

容器指標(biāo)

-覆蓋完整：中等水平 [2020年為較低水平]

• TCE調(diào)度 接入日志租戶

-計(jì)量準(zhǔn)確：較高水平 [2020年為中等水平]

• 引入多值 降低指標(biāo)名數(shù)量
• 高基數(shù)的指標(biāo)封禁問(wèn)題 由于遷移到了新租戶 可以做封禁閾值定制化
• 通過(guò) 2.0 SDK 三個(gè)特性， 基本消除丟點(diǎn)的問(wèn)題

    a.打點(diǎn)本地聚合

    b.面向字節(jié)流的 codec 編碼

    c.Agentless 投遞

-面向引擎友好：較高水平 [2020年為較低水平]

• 實(shí)現(xiàn)面向預(yù)計(jì)算友好的效果

基礎(chǔ)架構(gòu) 存儲(chǔ) & 數(shù)據(jù)庫(kù)

-計(jì)量準(zhǔn)確：較高水平 [2020年為中等水平]

• 引入多值 降低指標(biāo)名數(shù)量
• 高基數(shù)的指標(biāo)封禁問(wèn)題 由于遷移到了新租戶 可以做封禁閾值定制化
• 通過(guò) 2.0 SDK 三個(gè)特性， 基本消除丟點(diǎn)的問(wèn)題
• 打點(diǎn)本地聚合
• 面向字節(jié)流的 codec 編碼

-面向引擎友好：中等水平 [2020年為較低水平]

• 打點(diǎn)格式調(diào)整的 支持預(yù)計(jì)算配置

-成本收益：

• 以 mysql 遷移為例

     a.Mysql 租戶 成本節(jié)省 45.7%

     b.Mysql 租戶 帶寬節(jié)省了 80%

截止到今年年初， Metrics 在中國(guó)國(guó)內(nèi)區(qū)域已經(jīng)接入 60+ 租戶，占總流量的 70% 左右。

賦能效果總結(jié)

加速微服務(wù)端到端根因定位

通過(guò)指標(biāo)標(biāo)準(zhǔn)化 & 多模觀測(cè)數(shù)據(jù) [指標(biāo)， 日志，鏈路]標(biāo)簽術(shù)語(yǔ)的標(biāo)準(zhǔn)化， 我們實(shí)現(xiàn)面向微服務(wù)的上卷 & 下鉆關(guān)聯(lián)分析。

也使得使得跨層問(wèn)題根因分析有了可能性：

目前端到端根因定位覆蓋了60%以上的報(bào)警場(chǎng)景，日均觸發(fā)根因定位 50余萬(wàn) 次，用戶對(duì)定位結(jié)果的正反饋率超過(guò)80%。

簡(jiǎn)化服務(wù)性能離線數(shù)倉(cāng)構(gòu)建

在實(shí)現(xiàn)了在線觀測(cè)數(shù)據(jù)的標(biāo)準(zhǔn)化，并將其導(dǎo)入統(tǒng)一的存儲(chǔ)介質(zhì)之后，構(gòu)建字節(jié)整體關(guān)于服務(wù)性能、容量、吞吐量的數(shù)倉(cāng)大盤就更加便捷。比如 展現(xiàn)某服務(wù)的單核 QPS 分時(shí)熱力圖 如下:

目前基于微服務(wù)應(yīng)用性能數(shù)倉(cāng)已覆蓋公司超97%的微服務(wù)量化，有效支持字節(jié)跳動(dòng)各業(yè)務(wù)線服務(wù)性能、服務(wù)應(yīng)用健康度度量，由此帶動(dòng)一系列精準(zhǔn)的成本優(yōu)化。

觀測(cè)底座自身收益

• 從穩(wěn)定性角度看，由于引入metrics多租戶概念，所以我們能夠通過(guò)邏輯租戶映射到物理資源，從而降低故障半徑，減少不同租戶間流量的相互干擾。
• 從成本角度看，我們能夠依據(jù)每個(gè)租戶的副本數(shù)、存儲(chǔ)時(shí)長(zhǎng) TTL、打點(diǎn)的最小精度以及多值定義，最大程度地降低寫入流量和存儲(chǔ)容量的成本。metrics 多租戶遷移前后對(duì)比，成本節(jié)省幅度在 20% ~ 80% 不等。

總結(jié)

歷經(jīng)上述觀測(cè)埋點(diǎn)套件 BytedTrace SDK推廣、Metrics 指標(biāo)標(biāo)準(zhǔn)化遷移和推廣、部分業(yè)務(wù)接入日志多租戶，字節(jié)后端觀測(cè)數(shù)據(jù)的質(zhì)量在覆蓋完整度、定義統(tǒng)一、計(jì)量準(zhǔn)確、面向引擎友好四個(gè)方面上取得了顯著的質(zhì)量提升。這也為后續(xù)的全景全棧高效排障奠定了堅(jiān)實(shí)的基礎(chǔ)，幫助更多業(yè)務(wù)團(tuán)隊(duì)在業(yè)務(wù)穩(wěn)定性方向持續(xù)建設(shè)。

依托字節(jié)跳動(dòng)內(nèi)部可觀測(cè)團(tuán)隊(duì)大規(guī)模技術(shù)實(shí)踐，通過(guò)內(nèi)外合力，在火山引擎上推出了應(yīng)用性能監(jiān)控全鏈路版（APMPlus）、托管 Prometheus（VMP）、云監(jiān)控等可觀測(cè)產(chǎn)品，致力于為用戶提供全面、智能、高效、易用且安全的全?？捎^測(cè)解決方案。

目前 APMPlus Server 端監(jiān)控已正式 GA 并支持最新的大模型鏈路追蹤相關(guān)能力，歡迎咨詢了解。

?? 相關(guān)鏈接

APMPlus ： www.volcengine.com/product/apmplus

VMP ： www.volcengine.com/product/prometheus

云監(jiān)控 ： www.volcengine.com/product/cloudmonitor