當(dāng)我們設(shè)計(jì)復(fù)雜系統(tǒng)時(shí)，生產(chǎn)環(huán)境系統(tǒng)的可觀察性是必須的。有人說能夠監(jiān)控生產(chǎn)環(huán)境中的系統(tǒng)比在開發(fā)過程中測試它的所有功能更重要。對(duì)我來說，它們不是真正可以進(jìn)行比較的東西，你也不能放棄其中之一。

傳統(tǒng)上，如果組織中有IT 運(yùn)維部門，可能會(huì)有人使用Nagios 等工具進(jìn)行黑盒監(jiān)控。這個(gè)工具給你一些信號(hào)，如系統(tǒng)停機(jī)、服務(wù)器/服務(wù)停機(jī)、CPU 消耗高等。這是必須的，非常有利于識(shí)別問題的癥狀，但沒法知道根本原因。

一旦你得到的癥狀告訴你有什么不對(duì)勁。你需要深入了解并理解根本原因。這個(gè)時(shí)候需要用到白盒監(jiān)控。白盒監(jiān)控可以幫助你確定問題的根本原因，更重要的是，如果設(shè)計(jì)正確，可以通過查看系統(tǒng)上的某些趨勢，對(duì)于可能出現(xiàn)的可預(yù)防問題，為你提供主動(dòng)告警。因?yàn)閼?yīng)用程序的內(nèi)部可以提供更有價(jià)值和可操作的告警，使得對(duì)邊界場景和類似性能問題采取行動(dòng)時(shí)更加主動(dòng)，并在問題發(fā)生之前采取行動(dòng)。

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

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

他們之間有何不同之處以及我們?nèi)绾瓮ㄟ^這三個(gè)支柱實(shí)現(xiàn)這一基礎(chǔ)。

日志

大多數(shù)我曾經(jīng)工作過的系統(tǒng)都實(shí)現(xiàn)了這一支柱。

日志是系統(tǒng)中發(fā)生的事件，是來自系統(tǒng)的詳細(xì)的優(yōu)先級(jí)消息。我認(rèn)為將系統(tǒng)中的日志作為事件不是一個(gè)壞主意。

日志最大缺點(diǎn)是處理、存儲(chǔ)和運(yùn)輸?shù)某杀靖摺Ｋ鼈儼l(fā)生在系統(tǒng)中的每個(gè)請(qǐng)求的數(shù)據(jù)。如果你在數(shù)百臺(tái)服務(wù)器上運(yùn)行應(yīng)用程序，則需要將它們小心地匯聚到一個(gè)中心位置，否則無法在每一臺(tái)服務(wù)器上查看它們。就像你可能知道的，ELK 是最常見的技術(shù)棧。

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

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

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

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

度量

度量作為時(shí)序數(shù)據(jù)，是跨時(shí)間間隔的可聚合和測量的數(shù)字。度量針對(duì)存儲(chǔ)和數(shù)據(jù)處理進(jìn)行了優(yōu)化，因?yàn)樗鼈冎皇且欢螘r(shí)間內(nèi)聚合的數(shù)字。

基于度量的監(jiān)控的一個(gè)優(yōu)點(diǎn)是度量生成和存儲(chǔ)的開銷是恒定的，它不像基于日志的監(jiān)控那樣，與系統(tǒng)負(fù)載的增加成正比，隨之改變。這意味著磁盤和處理利用率不會(huì)根據(jù)流量的增加而改變。磁盤存儲(chǔ)利用率僅根據(jù)時(shí)序數(shù)據(jù)庫上存儲(chǔ)的數(shù)據(jù)而增加，當(dāng)你在應(yīng)用程序代碼中添加新指標(biāo)或啟動(dòng)新服務(wù)/容器/主機(jī)時(shí)，才會(huì)發(fā)生這種情況。

Prometheus（p8s）客戶端不會(huì)將每個(gè)度量發(fā)送到p8s。常見的prometheus 客戶端，例如流行的Coda Hale 度量庫（它是java 項(xiàng)目，但是也支持不同語言），在應(yīng)用程序進(jìn)程中聚合時(shí)序數(shù)據(jù)，并在進(jìn)程內(nèi)計(jì)算生成度量輸出。

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

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

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

我應(yīng)該收集什么？

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

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

其次，捕獲服務(wù)的服務(wù)時(shí)間。本質(zhì)上是每個(gè)請(qǐng)求的持續(xù)時(shí)間，來捕獲服務(wù)的延遲，即服務(wù)響應(yīng)時(shí)長。

然后，捕獲錯(cuò)誤請(qǐng)求的數(shù)量，以觀察請(qǐng)求服務(wù)失敗的百分比，即請(qǐng)求錯(cuò)誤率。

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

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

應(yīng)用程序監(jiān)控需要日志和度量，并且需要由你自己的團(tuán)隊(duì)去構(gòu)建，而不是IT 運(yùn)維團(tuán)隊(duì)。日志可以讓你深入了解每個(gè)請(qǐng)求，并查找在特定時(shí)間發(fā)生的具體事件的詳細(xì)信息，而指標(biāo)可以向你顯示上下文并了解系統(tǒng)中的趨勢。

分布式跟蹤

日志可以讓你了解特定時(shí)間發(fā)生的情況，但在構(gòu)建分布式系統(tǒng)時(shí)仍然很難將它們關(guān)聯(lián)起來。特別是在微服務(wù)時(shí)代，客戶的請(qǐng)求可能會(huì)導(dǎo)致應(yīng)用程序中出現(xiàn)數(shù)百種不同的服務(wù)調(diào)用。

通過日志很難監(jiān)控超過預(yù)期時(shí)長的調(diào)用、失敗的調(diào)用，以及為什么會(huì)調(diào)用失敗。你可以通過唯一請(qǐng)求ID 查找匹配的日志，但查詢客戶所面臨的最慢的調(diào)用仍然很困難。

因此，如果你處于微服務(wù)領(lǐng)域并致力于分布式系統(tǒng)，你可以想象服務(wù)之間相關(guān)聯(lián)的分布式調(diào)用的可視化是多么有價(jià)值。我在早年嘗試過Zipkin，它并不容易配置，但現(xiàn)在是容器時(shí)代，只需要一條命令。不過不是每個(gè)人都在使用它。OpenTracing 作為所有OSS 項(xiàng)目的唯一標(biāo)準(zhǔn)，可以讓你的應(yīng)用程序代碼不依賴于特定的跟蹤供應(yīng)商。

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

如果你還記得瀏覽器的開發(fā)人員工具并在網(wǎng)絡(luò)選項(xiàng)卡中檢查正在發(fā)起哪些請(qǐng)求，它可以讓你非常了解瀏覽器在做什么，哪些請(qǐng)求是并行產(chǎn)生的，哪些花費(fèi)太長時(shí)間處理而讓客戶等待。分布式跟蹤器為你在服務(wù)端提供類似的可視化。

例如，你可以看到哪些服務(wù)正在被調(diào)用，哪些服務(wù)花費(fèi)的時(shí)間比預(yù)期要長，你接收到的獲取指定類別的產(chǎn)品列表并按照價(jià)格排序的請(qǐng)求有哪些失敗了。

Zipkin 接口可以讓你查詢最長和最短耗時(shí)的調(diào)用棧。這樣你可以關(guān)注性能低的調(diào)用，了解系統(tǒng)的哪個(gè)部分是瓶頸。你還可以可視化服務(wù)之間的依賴關(guān)系，當(dāng)你有數(shù)百個(gè)系統(tǒng)相互通信時(shí)，這會(huì)變得非常有價(jià)值。

英文原文：

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。