在一個分佈式的應用程序中，很難使用在開發非分佈式應用程序中常用的調試技術。在出席 2019 年度歐洲測試大會（European Testing Conference 2019）時，Francisco Gortázar 認爲，把生產可觀察性放到測試環境中有助於找到錯誤。他演示了 ElasTest，這是開發人員利用可觀察性以測試和驗證分佈式系統的工具。

Francisco Gortázar 說，可觀察性有助於我們理解應用程序的行爲方式。理解分佈式應用程序行爲的唯一方法就是查看其生成的數據（其外部輸出），以決定其內部狀態。可觀察性的目的是把從被觀察的應用程序中獲得的有用信息提供給測試人員及開發人員，他這樣說到。

Francisco Gortázar 建議，構建接近業務的高級抽象， 以便把有意義的事件與對用戶沒有直接影響的事件區分開來。他說，在生產中，我們通常從原始指標開始，但很快我們就需要開發自己的指標，並在這些指標上設置告警了。隨時收集一切信息需要對大量信息進行管理，因此，他提議使用動態抽樣以避免收集沒有意義的事件，並專注於有影響的事件。當情況變得不正常時，就開始收集更多信息，以更好地診斷問題，並有希望找到解決方案。

ElasTest 是用於提供測試環境中可觀察性的開源工具，旨在幫助開發人員測試和驗證複雜的分佈式系統。它提供與 ELK 堆棧類似的功能，兩者的主要區別在於對測試過程的認識。ElasTest 理解什麼是測試，並能夠在必要的時候收集相關信息，並以一種相當直觀的方式呈現出來，以分別查看錯誤和測試。

ElasTest 項目由歐盟公開資助。該平臺由歐洲學術機構、研究中心、大型工業公司和中小企業聯合開發，使用開源軟件社區的通用工具和服務。

InfoQ 正在跟蹤報道 2019 年度歐洲測試大會，並就測試中的可觀察性採訪了 Francisco Gortázar。

InfoQ：爲什麼收集有關分佈式系統和雲原生應用程序中正在發生的情況的信息那麼難？

Francisco Gortázar：基本上，反映出的是兩個主要問題：首先是從運行在不同機器上的多個服務中收集信息問題。需要用特定的軟件發送所有信息給中央數據庫以供在線或離線檢查。其次是所生成的信息數量的問題。我們在這裏碰到了大數據問題，因此，需要一個好的策略來刪除舊的數據。

除此之外，測試環境還具有一些特性，使它們與生產環境有所不同。因此，有可能會發生這樣的情況：在生產環境中使用同樣的工具在部署和配置時需要花費大量的精力，因此，有時候，公司不希望在測試環境上投入大量精力。而運營團隊通常忙於生產環境，無法將時間花在其他環境中。

InfoQ：對於設置可觀察性，您有什麼建議？

Gortázar：很多不同的工具都有助於給我們的生產系統設置適當的可觀察水平，但是，這需要投入很多精力把所有這些組合到一起，以便獲得必要的可視化抽象。

理想情況下，我們應該在測試環境和生產環境中使用相同的工具。但是，通常，負責這些生產環境中可觀察性系統的團隊沒有時間去爲其他環境部署和維護類似的工具集。在這種情況下，至少開發人員和測試人員仍然可以使用能夠給其測試環境帶來一定程度可觀察性的簡單工具。

InfoQ：在端到端的測試中，有哪些用於可觀察性的工具？我們如何使用？

Gortázar：所謂的 ELK 棧（ELK 是 ElasticSearch、Logstash 和 Kibana 的首字母縮寫，它是通用工具集，用以管理來自 Elastic co. 的原始日誌和指標）以及由該公司開發的 Beat 代理使它非常輕鬆地從系統中收集日誌和指標。一起部署我們要測試的系統和這些代理，並讓它們發送信息給 ElasticSearch 數據庫並不難。對那些失敗的測試，我們可以使用 Kibana 進行進一步的問題調查。Kibana 能夠繪製所收集的指標，也可用於日誌查詢。這兩個功能有助於更好地定位錯誤。

但是，在用於測試環境時，這些工具有侷限性。當我們查看持續集成的系統時，事情就變得非常不同。通常，只在測試作爲該集成過程中的部分運行時，才收集信息。此外，該信息只在測試失敗（如，該應用程序沒有完全按預期運行）時纔有用。通常只有在檢查該信息時，才能找到失敗的根本原因。然而，該信息的呈現方式非常難以理解系統的行爲。例如，控制面板通常不瞭解測試的邊界（測試的起止時間），也無法過濾那些不相關測試的信息，除非我們知道它們在某個特定的時刻開始和結束。因此，隔離出有意義的信息是使用標準可觀察性工具的問題之一。

InfoQ：怎樣才能找到錯誤的根本原因？

Gortázar：在分佈式系統中，要找到問題的根源絕非易事。當我遇到該問題時，我希望能夠把成功的執行和失敗的執行進行比較。由於日誌的自然屬性（在不同的執行中產生的日誌不同），這很難。工具應該能夠識別出通用模式並去掉信息中不相關的部分，這些信息可能在兩個不同的執行中不一樣。

這個比較功能也應該可用於任何其他類型指標。如果我能夠比較兩個連續執行的請求的內存消耗或者延遲情況，也許能夠理解爲什麼第二次執行會失敗。

通常，需要更特定的工具來完成這類任務。在測試環境中，我們對要存儲的那些信息有更多的控制，但是，我們需要在工具中提高對測試過程的認識。這樣，我們能夠在運行測試時，收集必要的信息，並提供適當的抽象以理解特定測試失敗的原因。我們正在研究如何可視化用 ElasTest 收集的信息，以便更快更準確地定位錯誤。我們認爲持續集成環境還有很大提升空間。