當我們設計復雜系統時，生產環境系統的可觀察性是必須的。有人說能夠監控生產環境中的系統比在開發過程中測試它的所有功能更重要。對我來說，它們不是真正可以進行比較的東西，你也不能放棄其中之一。

傳統上，如果組織中有IT 運維部門，可能會有人使用Nagios 等工具進行黑盒監控。這個工具給你一些信號，如系統停機、服務器/服務停機、CPU 消耗高等。這是必須的，非常有利于識別問題的癥狀，但沒法知道根本原因。

一旦你得到的癥狀告訴你有什么不對勁。你需要深入了解并理解根本原因。這個時候需要用到白盒監控。白盒監控可以幫助你確定問題的根本原因，更重要的是，如果設計正確，可以通過查看系統上的某些趨勢，對于可能出現的可預防問題，為你提供主動告警。因為應用程序的內部可以提供更有價值和可操作的告警，使得對邊界場景和類似性能問題采取行動時更加主動，并在問題發生之前采取行動。

白盒監控還包括日志記錄、度量和分布式跟蹤，它們指的是一類使用系統內部報告的數據的監控工具和技術。我想寫一下白盒監控范圍內可觀察性的這三個支柱。當正確使用這些工具時，通常你可能就不需要進行黑盒監控了，但如果你問我，繼續進行黑盒監控當然很好。

• 日志
• 度量
• 分布式跟蹤

他們之間有何不同之處以及我們如何通過這三個支柱實現這一基礎。

日志

大多數我曾經工作過的系統都實現了這一支柱。

日志是系統中發生的事件，是來自系統的詳細的優先級消息。我認為將系統中的日志作為事件不是一個壞主意。

日志最大缺點是處理、存儲和運輸的成本高。它們包含發生在系統中的每個請求的數據。如果你在數百臺服務器上運行應用程序，則需要將它們小心地匯聚到一個中心位置，否則無法在每一臺服務器上查看它們。就像你可能知道的，ELK 是最常見的技術棧。

另外將所有的日志集中到一起也有一些缺點。如果你正在處理大量流量，你可能需要考慮要發送什么，不發送什么（提示：正確的日志記錄級別），你還需要有一個合適的聚合集群，大多數情況下是Elasticsearch 集群。擁有一個Elasticsearch 集群來聚合所有日志卻在黑色星期五這樣出現日志峰值的日子里出現故障，這種情況并不少見。

類似SLF4J、log4j、log4net 這樣的庫（根據你所使用的技術棧有很多選項）用于創建格式化的純文本日志。最常見的應用程序日志傳送方式是將它們寫入到磁盤上的文件，然后使用FileBeat 等工具將它們發送到ELK。但是應用程序也可以將日志直接發送到日志聚合器。有很多選項，你可以根據自己的情況評估。我曾經開發了一個log4net appender，它將日志作為消息推送到ampq（我們使用RabbitMQ），然后我們使用Logstash 從RabbitMQ 接收日志并將它們寫入到elasticsearch 中，并使用Kibana 進行可視化。

最近我們開始使用Docker Engine 來發送我們的日志。Docker 添加了一項功能，將日志發送到中心日志存儲庫，如ELK 技術棧。我知道的大多數中央日志存儲庫都支持Graylog 擴展日志格式（GELF），我想這就是docker 引擎的傳輸方式。

你還可以從基礎設施工具中獲取日志。大多數流行的消息代理（如kafka、RabbitMQ、nsq）、HTTP 反向代理、負載均衡器、數據庫、防火墻、應用程序服務器、中間件都提供了日志，你可以將它們發送到中心日志聚合器。

度量

度量作為時序數據，是跨時間間隔的可聚合和測量的數字。度量針對存儲和數據處理進行了優化，因為它們只是一段時間內聚合的數字。

基于度量的監控的一個優點是度量生成和存儲的開銷是恒定的，它不像基于日志的監控那樣，與系統負載的增加成正比，隨之改變。這意味著磁盤和處理利用率不會根據流量的增加而改變。磁盤存儲利用率僅根據時序數據庫上存儲的數據而增加，當你在應用程序代碼中添加新指標或啟動新服務/容器/主機時，才會發生這種情況。

Prometheus（p8s）客戶端不會將每個度量發送到p8s。常見的prometheus 客戶端，例如流行的Coda Hale 度量庫（它是java 項目，但是也支持不同語言），在應用程序進程中聚合時序數據，并在進程內計算生成度量輸出。

因此，如果要開始使用Prometheus 從應用程序中收集指標，首先需要向應用程序代碼添加采集器。你可以在p8s 網站上找到客戶端列表。Prometheus 基于pull 工作，基本上你可以使用其中可用的一個收集應用程序中的指標，然后在應用程序中通過HTTP 對外開放，通常是應用程序中的/metrics 端點。最后配置prometheus 每隔幾秒從應用程序中收集指標。

度量比查詢和聚合日志數據更有效。但是日志可以提供準確的數據，如果你想獲得服務器響應時間的準確平均值，你可以記錄它們，然后在elasticsearch 上編寫聚合查詢。度量不是百分之百準確，而是使用一些統計算法。類似Prometheus 和常見的度量客戶端這些工具實現了一些高級算法，以便為我們提供最準確的數字。別誤會，我不是說使用日志，我是說正確的使用日志和度量。

在Prometheus 中收集所有指標后，你可以使用Grafana 可視化這些指標。

我應該收集什么？

一旦你配置了自己的收集策略，這是你需要回答的問題。如果要為微服務添加度量;

首先，我建議你捕獲請求數，以觀察你的服務有多繁忙以及每秒/分鐘收到多少請求，即請求數。

其次，捕獲服務的服務時間。本質上是每個請求的持續時間，來捕獲服務的延遲，即服務響應時長。

然后，捕獲錯誤請求的數量，以觀察請求服務失敗的百分比，即請求錯誤率。

最后，如果你不確定要檢查的百分位數，將其設置為95％百分位數。如果你想欺騙自己，平均時長或平均值是皆大歡喜的。

你的應用程序會有非常具體的案例，這些只是對你開始考慮的一些建議。例如，在我們上一個項目中，我們想要測量每個產品的ETL 處理時間。我們在底層系統中捕獲了每個產品的更新速度，并計算到達ETL 管道末尾所花費的時間。通過這種方式我們想看看基于Kafka 的數據流管道是否存在瓶頸。我們可以觀察數據流管道的每個階段，以確定瓶頸，并在需要時提供新的Kafka Streams 容器或Kafka Connect 容器。

應用程序監控需要日志和度量，并且需要由你自己的團隊去構建，而不是IT 運維團隊。日志可以讓你深入了解每個請求，并查找在特定時間發生的具體事件的詳細信息，而指標可以向你顯示上下文并了解系統中的趨勢。

分布式跟蹤

日志可以讓你了解特定時間發生的情況，但在構建分布式系統時仍然很難將它們關聯起來。特別是在微服務時代，客戶的請求可能會導致應用程序中出現數百種不同的服務調用。

通過日志很難監控超過預期時長的調用、失敗的調用，以及為什么會調用失敗。你可以通過唯一請求ID 查找匹配的日志，但查詢客戶所面臨的最慢的調用仍然很困難。

因此，如果你處于微服務領域并致力于分布式系統，你可以想象服務之間相關聯的分布式調用的可視化是多么有價值。我在早年嘗試過Zipkin，它并不容易配置，但現在是容器時代，只需要一條命令。不過不是每個人都在使用它。OpenTracing 作為所有OSS 項目的唯一標準，可以讓你的應用程序代碼不依賴于特定的跟蹤供應商。

現在，你可以使用列出的開源客戶端，并將跨度信息發布到支持的跟蹤器（Zipkin、Jaeger、Appdash、LightStep、Hawkular、Instane 等）。

如果你還記得瀏覽器的開發人員工具并在網絡選項卡中檢查正在發起哪些請求，它可以讓你非常了解瀏覽器在做什么，哪些請求是并行產生的，哪些花費太長時間處理而讓客戶等待。分布式跟蹤器為你在服務端提供類似的可視化。

例如，你可以看到哪些服務正在被調用，哪些服務花費的時間比預期要長，你接收到的獲取指定類別的產品列表并按照價格排序的請求有哪些失敗了。

Zipkin 接口可以讓你查詢最長和最短耗時的調用棧。這樣你可以關注性能低的調用，了解系統的哪個部分是瓶頸。你還可以可視化服務之間的依賴關系，當你有數百個系統相互通信時，這會變得非常有價值。

英文原文：

https://medium.com/hepsiburadatech/3-pillars-of-observability-d458c765dd26

總結

以上是生活随笔為你收集整理的关于可观察性的三大支柱，你应该了解这些的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。