1.3 關于軟件可觀測性的錯誤描述

在繼續之前，我們需要定位“可觀測性”的另一個定義，這個定義正在被一部分軟件即服務（SaaS）開發者工具供應商廣泛推廣。這些供應商堅持認為“可觀測性”沒有任何特殊含義——它只是“遙測”（telemetry）的另一個同義詞，與“監控”沒有區別。這個定義的支持者將可觀測性降級為運維軟件的另一個通用術語。你肯定會聽到這種解釋，即將可觀測性解釋為今天他們已經在做的事情的“三大支柱”：指標（metrics）、日志（log）和鏈路（trace）[2]。

很難判斷哪個定義更糟糕：它是冗余的（為什么我們需要發明“遙測”的另一個同義詞？）或者它的認知是混亂的（為什么要匯編一個由一種數據類型、一種反數據類型、一堆字符串和一種按時間順序可視化事物的方式組成的列表）。無論如何，當你意識到該定義的支持者在出售工具以及基于現有指標、日志和鏈路工具收集和存儲數據的思維方式時，該定義的邏輯缺陷就變得明顯了。這一定義的支持者的業務模型限制了他們對未來可能性的思考。

公平地說，我們——本書的作者——也是可觀測性產品的供應商。然而，本書并不是為了推銷我們的工具而編寫的。我們寫這本書的目的是解釋我們如何以及為什么將可觀測性的原始概念應用于管理現代軟件系統。無論選擇什么工具，你都可以應用本書中的概念來練習構建具有可觀測性的生產軟件系統?？捎^測性不是通過將不同的工具與市場營銷結合在一起實現的。你不必采用一種特定的工具來獲得軟件系統中的可觀測性。相反，我們認為可觀測性要求我們思考如何收集有效調試所需的數據。我們相信，作為一個行業，是時候發展我們用來管理現代軟件系統的實踐了。