為什麼明明 CPU 負載不高，指標卻會嚴重丟失？為什麼加了資源，數據落差依然存在？ 在本場演講中，我將分享一個真實案例：在進行壓力測試時，我們發現 Ingress Nginx 的請求數與 OpenTelemetry 收集到的數據有顯著落差 。即便翻倍提升 Collector 資源，數據不一致的問題仍揮之不去 。

我將分享一場從表象到核心的全路徑排查經驗：

• - 底層迷霧：解析 Linux 核心丟包真相 分析 K8s CPU Throttling 如何引發 Linux Kernel 的 TCPBacklogDrop 。當 Collector 被強制暫停時，核心緩衝區被塞爆，導致 OTLP 數據在抵達應用層前就已在內核蒸發 。

• - 協議紅利：Prometheus 3.0 與高效能轉換 深入 OTel Collector 內部，揭露舊版 String Sanitization 造成的 CPU 負載瓶頸 。我們將分享基準測試數據，展示升級 Prometheus 3.0 (支援 UTF-8 與 OTLP 原生格式) 後，可見的處理效能提升。

• - 架構陷阱：Processor 順序與身分識別 解析 Batch Processor 配置順序如何導致數據在 Collector 內部被「錯誤合併」 。此外，我們將分享如何透過 K8s Downward API 注入 Pod UID，解決 ErrOlderStart 報錯，達成 100% 的指標流識別精準度 。

聽眾收穫：

核心價值在於解決「數據不一致」與「效能瓶頸」，聽眾將獲得：

• 超越 CPU 指標的排查視野： 理解為什麼 CPU 利用率不高也會 Throttling，並學會透過 TCPBacklogDrop 抓出隱藏在 Linux 核心的丟包真相。
• OTel Collector 配置的最佳實踐： 掌握 Processor Chain 的正確順序（例如 Batch 為什麼要放最後），以及如何利用 Resource Attributes 解決指標流識別錯誤造成的數據遺失。
• 協議升級的量化收益： 透過您的 Benchmark 數據，理解 Prometheus 3.0 原生支援 OTLP (UTF-8) 帶來的效能紅利，學習如何優化大規模監控系統的成本。