別把一切都塞進指標：日誌去重能砍掉百倍成本
日誌、指標、鏈路三種信號裡，日誌最容易被無意義地堆量；用 log drain 做模板化、再配 log dedupe，可以在不丟保真度的前提下把日誌量砍掉一百倍。
原視頻在 YouTube 上放不出來，用音頻聽：
核心論點 · 時間戳為按文稿位置估算
重複的日誌不是保真度，是賬單
Mike Goldsmith 把成本控制的起點放在「冗餘信息」上：同一條看起來完全一樣的記錄被發送十萬次，並不會增加價值，你只需要知道它發生的頻率，然後外推。但無論數據落到後端分析系統還是基礎設施內部的本地系統，處理、存儲、分析都要付錢。所以他的目標不是砍掉保真度，而是保留「什麼重要、為什麼重要」，同時不再保留每一次的精確副本。Martin Thwaites 把這形容成鐵三角：想要好的遙測數據、想要快、想要便宜，還要同時受內存和 CPU 約束。Mike 補了一句反直覺的：如果成本控制做得太粗暴，運行這套成本控制本身的代價，可能和直接把數據全發出去差不多。
— Mike Goldsmith最大的坑是用錯了信號
Ken Rimple 問最常見的痛點是什麼，Mike 說「他們在用錯誤的遙測信號」。他的觀察是團隊過度指標驅動：指標能告訴你某件事發生了、發生了多少次，但因為它被採集的方式，它給不了「為什麼發生」的上下文。日誌和鏈路才是講「為什麼」的信號。Martin 補充了一個區分：little M metrics 是你畫的圖、你盯的可視化，永遠需要；big M metrics 是預先想好的時間序列聚合，服務於「已知問題」。如果有一個需要實時產出的儀表盤，指標就是該用的東西；但要看單個用戶請求裡發生了什麼、不同請求之間有什麼共性，就得靠日誌和鏈路。
— Mike Goldsmithlog drain 把日誌拆成模板加變量
log drain 來自一個老 Python 庫、一篇研究論文，被移植到 Go 後進了 Collector。它分析每條進來的日誌：哪些部分是變量、哪些是靜態的，經過一段學習期後生成模板。比如「user Mike logged in at IP address 192.168...」，模板會把 Mike 和 IP 變成兩個佔位符，其餘是靜態文本。之後 Martin 登錄、Ken 登錄，模板都不用變，只是兩個變量不同。一旦變量被抽成屬性，你就能做有依據的取捨：這個用戶我不關心、這個內部 IP 段我不關心。Martin 建議它應該改名叫「AI log templating」，這樣能賣得更好，說不定還能拿到 VC 的錢。
— Mike Goldsmith模板加去重，日誌量直接除以一百
log dedupe 單獨用有個前提問題：如果日誌正文裡混著 Mike、Ken、Martin 這些變量，它們看起來就不一樣，很難判斷哪些是同一條。把 log drain 生成的模板和 log dedupe 配對之後，就能說「這個日誌形狀發生了一百次」，於是只留一份副本、附上計數，日誌量降為百分之一百，保真度沒有損失。Martin 立刻拋出反例：登錄失敗通常是合規日誌，必須全留，不能去重。Mike 的答案是模板已經告訴你佔位符裡是什麼值，所以可以在兩者之間做過濾、路由，或者在 dedupe 裡把「登錄狀態」這類屬性加進去重邏輯，按不同速率保留。
— Mike Goldsmith該留的證據別送進去重管道
Martin 追問 reroute 是不是意味著可以分流到不同目的地，Mike 確認：用 log template 加 routing connector，基於模板抽出的屬性做判斷——登錄成功的走 log dedupe、千分之一保留，因為你不關心；登錄失敗的整條繞過 dedupe，直接送 S3 或別的存儲。他的原則很直接：log dedupe 是用來主動降量的工具，如果你知道某些東西必須留，就不要讓它經過這個管道。Martin 由此推出成本控制的關鍵結構：熱存儲裡只放需要快速回答問題的運營分析數據，同時另一條管道保留百分之百的數據用於取證分析。他還強調，用託管後端不等於 SRE 和平臺團隊不用碰 Collector，恰恰相反，清洗遙測、實現 log dedupe 和 log drain 正是他們的新工作。
— Mike Goldsmith日誌本該是指標，就把它轉成指標
signal to metrics connector 允許在 Collector 內部跨信號轉換：如果日誌在講一件本來更適合用指標描述的事，就把它轉成指標，指標有低得多的採集間隔，然後過濾掉原始日誌。Mike 說這可能是很多人不知道的能力，同一份信息和上下文可以在不同信號之間移動。對指標本身，他的警告是別過度降基數——那會損害指標能告訴你的保真度，「聚合再聚合，你大概要倒霉了」。interval processor 則是安全的：把每秒或每五秒抓一次的數據聚合成三十秒或六十秒窗口，總量和保真度不變，只是頻率更低。Martin 的立場是，如果你想要秒級粒度，應該用採樣過的鏈路和日誌，而不是拿指標去幹這件事。
— Mike Goldsmith頭採樣會吃掉罕見但重要的路徑
OpenTelemetry 目前有三種採樣策略。頭採樣通常在 SDK 層做，按固定百分比取，完全不看鏈路內部發生了什麼：成本控制很好，但系統裡那些重要卻罕見的路徑會被採樣器整個吃掉。tail sampling processor 是進步，它拿到完整鏈路上下文、在鏈路結束後決策，但可調的旋鈕不夠，尤其是沒法處理高基數屬性——用戶 ID、會話 ID、錢包 ID 這類變化頻繁的值，你沒法保證每種變化都被代表到。這正是動態採樣器要解決的問題。
— Mike Goldsmith按指紋分桶，保證每種變化至少留一條
動態採樣器用的是 Refinery 的算法：你告訴它你在意的屬性——服務名、用戶 ID、錢包 ID、會話 ID——每當這些屬性出現一種組合，就單獨分桶、單獨採樣，並保證每個桶至少留下一條。同一個桶裡的量漲到十、一百、一千，閾值就自動上調，也就是少留一些。你可以按固定百分比（比如大約百分之十）來，也可以按吞吐量（每分鐘多少 span）來。Martin 舉了結賬流的例子：十個不同的忠誠度或折扣算法，其中某條路徑只有二十分之一的概率被走到，如果你因為量太大而按百分之十甚至百分之一採樣，這條路徑基本不可能被採到；放進指紋分桶後，每種算法至少有一條鏈路。
— Mike Goldsmith採樣真正換的是回答問題的信心
Mike 把採樣策略的核心矛盾說成：你對自己基於這批遙測回答問題的信心有多高。頭採樣在低概率事件加高採樣閾值下基本沒戲，除非你專門去獵；尾採樣理論上可行，但門檻很高，你得完全組織好每一條策略、理解每種變化如何被應用。動態採樣器降低複雜度、提高信心，因為你知道每種組合至少會留下一條，也就有了一個可以開始回答問題的立足點。發布狀態上，它已經在 Honeycomb Collector distribution 裡可用，官方 OpenTelemetry Contrib 發行版還要等幾週做最後打磨。Martin 提醒它現在是 alpha，接下來幾週會有破壞性變更，建議等 beta 或正式發布。
— Mike Goldsmith原話 · 已逐字校驗
So when you've got redundant information, you're having something that looks identical, and you'll send it 100,000 times, and it doesn't have a lot of value.
當你有了冗餘信息，你手上是看起來一模一樣的東西，你把它發送十萬次，它並沒有多少價值。
Mike Goldsmith0:00
If you do some cost controls just really heavy-handedly, the cost of running that cost control could not be that much different from just sending all of that data.
如果你非常粗暴地做成本控制，運行這套成本控制本身的代價，可能和直接把數據全發出去差不了多少。
Mike Goldsmith0:00
It doesn't give you context of why something happened. It tells you that something happened and how many times that thing happened.
它不給你「為什麼發生」的上下文。它告訴你某件事發生了，以及那件事發生了多少次。
Mike Goldsmith6:30
I can have one copy of it and tell you that it happened 100 times. And those two, in that scenario there, it's very simplistic, but you've reduced the log volume by 100 times and you haven't lost any fidelity.
我可以只留一份副本，然後告訴你它發生了一百次。在那個場景裡這非常簡單，但你已經把日誌量降低了一百倍，而且沒有損失任何保真度。
Mike Goldsmith16:00
Log Dedupe is a tool that is used to intentionally reduce volume. If you know that you need to keep something, don't pass your data through that.
Log Dedupe 是一個用來主動降低數據量的工具。如果你知道某些東西必須保留，就不要讓你的數據經過它。
Mike Goldsmith20:30
If you aggregate and aggregate, you're probably in for a bad time.
如果你聚合再聚合，你大概要倒霉了。
Mike Goldsmith24:30
With the dynamic sampler, it reduces the complexity and increases your confidence because you know that you're going to get variations of everything.
用動態採樣器，它降低了複雜度、提高了你的信心，因為你知道你會拿到所有東西的各種變化。
Mike Goldsmith31:30
I think a lot of people have this almost misconception that instrumentation and a telemetry pipeline is something that you can just build once and forget. And that's not the case.
我覺得很多人有一種近乎誤解的想法，認為埋點和遙測管道是建一次就可以忘掉的東西。事實並非如此。
Mike Goldsmith35:30
數字與實體
| OpenTelemetry 採樣策略數量 | 3 種（頭採樣、尾採樣處理器、動態採樣器） | 29:00 |
| log dedupe 配合模板後的日誌量降幅 | 降低 100 倍 | 16:00 |
| interval processor 聚合窗口 | 30 秒或 60 秒 | 24:30 |
| 動態採樣器在官方 Contrib 發行版可用時間 | 預計未來幾週 | 35:30 |
術語
- log drain日誌模板化處理器
- 分析日誌、區分靜態與可變部分，生成模板並把變量抽成屬性的 Collector 組件。
- log dedupe日誌去重處理器
- 把形狀相同的日誌合併成一條並附上出現次數，用於主動降低日誌量。
- tail sampling尾採樣
- 等鏈路結束後，基於完整鏈路上下文決定是否保留的採樣方式。
- head sampling頭採樣
- 在鏈路開始時按固定百分比決定是否保留，不看鏈路內部發生了什麼。
- cardinality guardian基數守衛
- 社區貢獻的 Collector 組件，用於降低指標基數。
- RefineryHoneycomb 採樣工具
- Honeycomb 長期自用的專有采樣工具，動態採樣器移植了它的算法。
收聽指南
已經在生產環境跑 OpenTelemetry Collector、被遙測賬單或日誌量壓著的 SRE、平臺工程師和可觀測性負責人。
開頭關於「喜歡啃帶刺鐵絲網」的寒暄可跳過。