在 InfoQ 收錄的 QCon 演講中，CCP Games 的 Nicholas Herring 說明 EVE Online 如何把可觀測性帶進一個二十年的 MMO 架構。傳統應用程式多數是在服務單一使用者的獨特體驗，每個人看到自己的頁面與資料，系統通常不需要讓大量使用者同時處於同一個共享狀態。多人線上遊戲卻相反，它必須讓所有玩家在同一時間看到同一個世界，還要同步、交易化、複製大量狀態。EVE Online 把這件事推到極端，它是單一 shard 的 MMO，沒有北美、亞太或歐洲各自獨立的伺服器，全球玩家共享同一個宇宙，因此系統要處理的是整個太陽系的狀態，而不是單一使用者的工作階段。
從單一使用者到共享宇宙：EVE Online 的觀測起點
EVE Online 的特殊之處還包括它是一個由玩家驅動的經濟體。每天市場約有 50 萬筆交易，約 120 億件物品在生態系中流動，而且這個數字包含宇宙裡每一顆子彈。它也曾創下金氏世界紀錄，包括最昂貴的遊戲內戰鬥，成本接近 40 萬美元；最大規模的玩家對玩家戰鬥，橫跨時間約有 9,000 名玩家參與；以及同一場 PvP 戰鬥中同時在線玩家達 6,500 人。這些數字說明，EVE 的觀測問題不是單純的網站延遲或 API 錯誤率，而是如何在一個持續模擬的共享世界中，分辨哪些訊號真的重要。
更麻煩的是，這套系統非常老。EVE Online 的開發始於 1990 年代末，正式版本在 2000 年前後開始。它累積了超過 200 萬個 changelist，約 170 萬行 C 與 C++ 程式碼，260 萬行 SQL，以及 340 萬行 Python。這裡的 Python 還是 stackless 2.7，執行時只跑在一個邏輯處理器上，也就是一次只做一件事。宇宙的定義另外散落在約 5,300 萬行 YAML 中。舊系統之外，CCP Games 正在把新功能移往內部稱為 Quasar 的架構，包含 Kubernetes、Golang、gRPC、protobuf、RabbitMQ、NATS 等。新舊系統合計每秒處理約 30,000 則訊息，講者在問答中甚至估計即時約有 60,000 則。訊息可能是事件、請求、回應，或推送到客戶端的通知。
在遊戲裡，玩家的表達行為也讓觀測變得更複雜。船艦塗裝系統 Skinner 讓玩家設計外觀，曾有一次測試讓 500 名玩家在同一太陽系快速切換塗裝，並關閉速率限制，結果產生每秒約 5 萬則訊息，相當於整個宇宙的訊息量。遊戲裡還有煙火、雪球等裝飾性互動。另一方面，EVE 的死亡懲罰很重，最大的船艦稱為 Titan，長約 16 公里，換算真實成本約每艘 1,000 歐元。畫面上一群約 40 艘 Titan 就代表 4 萬歐元，而歷史上最大戰役成本約 38.7 萬美元，因為當時場上有約 257 艘 Titan。對觀測系統來說，真正的挑戰是：一艘價值 1,000 歐元的船，和一個粉紅色外觀，哪個該被完整追蹤，哪個可以被取樣掉。
頭端取樣與尾端取樣的取捨
為了回答這個問題，EVE Online 選擇了一條在可觀測性社群中相對少見的路：百分之百採用頭端取樣（head-based sampling），完全不使用尾端取樣（tail-based sampling）。頭端取樣是在追蹤開始時就決定是否保留這個 span，尾端取樣則是把所有 span 先集中到一個地方，等追蹤結束後再根據完整結果決定取樣。許多人聽到 EVE 不做尾端取樣會很驚訝，因為尾端取樣通常能保留更多有價值的錯誤或慢請求，但 EVE 選擇承擔這個取捨。
原因有三個。第一，EVE 是一個已經運作二十年的系統，團隊不想再增加維運負擔。第二，也是更關鍵的效能限制：Python 只跑在一個邏輯處理器上，如果還要先把所有 span 快速送出以支援尾端取樣，模擬本身可能會被拖垮。第三，頭端取樣讓架構保持簡單，不需要集中式 relay 把所有資料送到單一位置。EVE 甚至沒有這樣的 relay。這反而帶來一個好處：當系統開始退化時，團隊可以從哪些部分無法把 span 送到 Honeycomb 推斷出問題位置，而不是把所有資料塞進同一個瓶頸。
確定性取樣與動態取樣也是同樣的邏輯。舊系統經過二十年調校，不能隨意插入動態取樣邏輯，因為那會影響模擬效能，因此舊系統主要採用確定性取樣。新 Quasar 系統才有比較多空間使用動態取樣。團隊也曾考慮讓桌面客戶端直接發出 span，因為那裡有大量效能資料，但桌面客戶端同樣是高度調校的單體，任何額外負擔都可能影響遊戲體驗，這又再一次把他們推向頭端取樣。
EMA 動態取樣與高水位
在 Quasar 的新系統中，團隊大量使用指數移動平均取樣，也就是 EMA（exponential moving average）取樣。它的基本做法是先選一個要追蹤的 key，EVE 選擇的是 protobuf 訊息的 type URL。這個 key 會形成一個 key space，當系統演化、加入更多訊息型別，key space 就會成長。EMA 會動態觀察每個 key 出現的次數，並且有一個很符合直覺的行為：越常看到的東西，取樣越少；越少看到的東西，取樣越多。這正好解決了子彈飛來飛去、玩家不停切換塗裝這類高頻事件的問題，因為這些事件會被自動降低取樣率。
但 EMA 也有限制。子彈不是從新系統發射，而是從舊系統發射，所以舊系統仍然依賴確定性取樣。EMA 取樣沒有中央協調，每個 ingress 實例各自決定，因此整體取樣率會受到三個因素影響：訊息頻率、key space 大小，以及生態系中同時運行多少個實例。EVE 的 Quasar 約有每秒 30,000 則訊息、key space 約 2,000 種訊息、35 個 ingress 實例。把這些數字放在一起，會出現一個高水位現象：平均每天約產生 6,000 萬個事件。即使團隊把每個實例的 sample goal 設成 1/3,000，也無法讓總量低於這個高水位，因為 EMA 永遠會確保每種東西至少被取樣一次。
這個至少取樣到每一個東西一次的特性，對 EVE 來說非常重要。團隊想知道宇宙中至少有一顆子彈被發射、至少有一次重要事件發生，這樣才能用取樣率外推整體健康狀態。Honeycomb 在這裡扮演關鍵角色，它會拿取樣率與觀察到的樣本數去外推真實數量。EVE 的模擬引擎 Destiny 是確定性 lockstep 模擬，每一幀都有大量事件，因此模擬內部的取樣必須是確定性的。團隊發現，即使資料稀疏，Honeycomb 的外推結果通常能在正負 300 個單位內，對統計上顯著的資訊來說相當可靠。
另一個實用技巧是把功能旗標當成控制開關。EVE 使用 LaunchDarkly，透過前綴機制表達兩種意思：對某種訊息提高關注，或讓某個領域變得更安靜。例如視窗焦點、開啟、關閉、拖放這類 UI 事件，對單一客戶端來說 1/1,000 取樣很稀疏，但當有三萬個客戶端同時運行時就不再稀疏。採礦、氣體採集等較高頻的活動也可以用類似方式調整。當團隊需要針對特定船艦或角色深入觀察時，會開啟被戲稱為索倫之眼的目標式臨時取樣，此時配額圖會出現明顯尖峰。
影響、限制與實務經驗
這些技巧最後要解決的是成本與保真度的平衡。EVE 的玩家數量相對穩定，約在三萬到四萬人之間，只有改版時才會有明顯高峰，因此團隊可以根據高水位規劃可觀測性支出，目標是使用約 90% 的配額，平均每天約 5,000 萬個事件。當需要深入調查時再打開索倫之眼，平時則避免超額。團隊也必須建立提醒機制，因為有時會忘記關閉高取樣模式，隨後就會收到自動通知說剛剛花了很多錢。
頭端取樣也讓 SLO 的設計變得更棘手。SLO 是服務水準目標，用來衡量錯誤預算，需要知道成功與失敗事件的比例。尾端取樣可以控制這個比例，但頭端取樣不行。如果對一個 1/1,000 取樣的 UI 互動設下 SLO，可能每幾小時才看到一個樣本，一旦出錯，錯誤預算就會瞬間燒光。因此團隊必須小心判斷哪些統計上顯著的事件適合設 SLO，哪些不適合。
公開應用程式上的遙測埋點也帶來限制。團隊曾讓桌面客戶端與啟動器發出 span，但後來傾向停止這麼做。原因是客戶端太早做出取樣決策，例如錨定太空站這種重要操作如果只有 1/1,000 取樣，就可能被漏掉，而團隊又不想為了提高取樣率去影響客戶端效能。比較好的做法是把決策移到受信任的網路端，等事件進入自家生態系後再決定如何取樣。延遲資訊可以從指標平均取得，不一定需要來自三萬個客戶端的 span。
問答中也揭露一些具體經驗。團隊曾在測試中讓 500 艘船在同一個太陽系，並引爆智慧炸彈，結果產生一個包含 35,000 個 span 的追蹤。這讓團隊第一次清楚看到舊系統內部行為，也成為推動可觀測性的重要證據。另一個例子是賞金系統：摧毀 NPC 船艦後，賞金不是立即發放，而是由某個每五分鐘執行一次的 coroutine 處理。團隊發現後，決定把這類 worker 機制短路，不讓追蹤從那裡開始，避免產生大量無意義的根 span。他們也不追蹤送往客戶端的通知，因為那屬於盡力而為的傳遞，遺失就再送一次即可。請求與回應則被合併成單一 span，並依請求與回應拆開屬性命名空間，一個 span 代表完整來回，成本因此減半。
在資料規模方面，EVE 的生產資料庫約 17 到 18 TB，對遊戲宇宙來說已經高度最佳化。新系統仍在增加，例如玩家建立任務的功能需要記錄誰貢獻了多少，才能發放獎勵。團隊因此在新設計中加入大小限制與 TTL，避免產生無限成長的資料表與失控的雲端帳單。35 個 ingress 實例被稱為服務閘道，會把宇宙中的每個事實送到 Azure Event Hub，資料工程團隊再從資料湖中處理選定資訊。當船艦塗裝系統上線時，Quasar 必須知道宇宙中每艘船在每個模擬 tick 的位置，立即產生大量事件，讓資料工程師一時難以消化。
整體來看，EVE Online 把頭端取樣、確定性取樣、EMA 動態取樣與目標式臨時取樣組合起來，目標不是完整保存每一個事件，而是確保每一種東西至少出現一次，並用外推來掌握系統健康。這套方法多數時候運作良好，也讓工程師難以想像沒有可觀測性的日子。尾端取樣在某些情況下仍然很吸引人，但要為此建立完整基礎設施、解決效能問題，對 EVE 的投資報酬率並不划算。對一個單一 shard、即時模擬、二十年歷史的 MMO 來說，頭端取樣不是妥協，而是一種經過計算的架構選擇。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。