對於乙個系統來說，監控、鏈路追蹤、日誌的這三者需求都是必然存在的，而有的時候我們會搞不清楚這三者相互之間是什麼關係。我之前在做系統設計的時候也考慮過，是不是有必要引入那麼多元件，畢竟如果這三者完全分開每乙個一項的話，就有三個元件了（事實上就是：prometheus+grafana、jaeger、elk）。
因此想做個筆記嘗試舉例來梳理下。
monitoring（監控）舉例來說就是：定期體檢。使用監控系統把需要關注的指標採集起來，形成報告，並對需要關注的異常資料進行分析形成告警。
特點是：
這也是prometheus的架構做得非常簡單的原因，monitoring的需求並沒有包含非常高的併發量和通訊量。反過來說：高併發、大資料量的需求並不適用於monitoring這個點。
tracing（鏈路追蹤）舉例來說就是：對某一項工作的定期匯報。某個工作開始做了a，製作a事件的報告，收集起來，然後這個工作還有b、c、d等條目，乙個個處理，然後都彙總進報告，最終的結果就是乙個tracing。
特點是：
因為tracing是針對某乙個事件（一般來說就是乙個api），而這個api可能會和很多元件進行溝通，後續的所有的元件溝通無論是內部還是外部的io，都算作這個api呼叫的tracing的一部分。可以想見在乙個業務繁忙的系統中，api呼叫的數量已經是天文數字，而其衍生出來的tracing記錄更是不得了的量。其特點就是高頻、巨量，乙個api會衍生出大量的子呼叫。
也因此適合用來做monitoring的系統就不一定適合做tracing了，用prometheus這樣的系統來做tracing肯定完蛋（prometheus只有拉模式，全部都是http請求，高併發直接掛掉）。一般來說tracing系統都會在本地磁碟io上做日誌（最高效、也是最低的cost），然後再通過本地agent慢慢把文字日誌資料傳送到聚合伺服器上，甚至可能在聚合伺服器和本地的agent之間還需要做訊息佇列，讓聚合伺服器慢慢消化巨量的訊息。
tracing在現在的業界是有標準的：opentracing，因此它不是很隨意的日誌/事件聚合，而是有格式要求的日誌/事件聚合，這就是tracing和logging最大的不同。
logging（日誌）舉例來說就是：廢品**站。各種各樣的物品都會彙總進入到配品**站裡，然後經過分門別類歸納整理，成為各種可**資源分別**到商家那裡。一般來說我們在大型系統中提到logging說的都不是簡單的日誌，而是日誌聚合系統。
從本質上來說，monitoring和tracing都是logging，logging是這三者中覆蓋面最大的超集，而前兩者則是其一部分的子集。logging最麻煩的是，開發者也不會完全知道最後記錄進入到日誌系統裡的一共會有哪些東西，只有在使用（檢索）的時候才可能需要彙總查詢總量中的一部分。
要在一般的loggin系統中進行monitoring也是可以的，直接把聚合進來的日誌資料提取出來，定期形成資料報告，就是監控了。tracing也是一樣，只要聚合進了logging系統，有了原始資料，後面要做都是可以做的。因此logging系統最為通用，其特點和tracing基本一致，也是需要處理高頻併發和巨大的資料量。
這樣一看就很清楚了，每個元件都有其存在的必要性：
一文搞懂監控 鏈路追蹤 日誌三者的不同之處
對於乙個系統來說，監控 鏈路追蹤 日誌的這三者需求都是必然存在的，而有的時候我們會搞不清楚這三者相互之間是什麼關係。我之前在做系統設計的時候也考慮過，是不是有必要引入那麼多元件，畢竟如果這三者完全分開每乙個一項的話，就有三個元件了 事實上就是 prometheus grafana jaeger el...
SPA SEO SSR三者有什麼區別
頁面之間的切換非常快 一定程度減少了後端伺服器的壓力 後端程式只需要提供api，不需要客戶端到底是web端還是手機等 我們之前說spa單頁面應用，通過ajax獲取資料，這就難保證我們的頁面能被搜尋引擎正常收到，並且有一些搜尋引擎不支援執行js和通過ajax獲取資料，那就更不用提seo了。為了解決這個...
BTC BCH和BSV三者到底有什麼區別？
位元幣發展到今天已經有10個年頭了，在這十年的發展中，位元幣一共經歷了兩次重要的 現在變成了三種貨幣，第一種是目前繼承了位元幣絕大多數遺產的btc 第二種是bch 第三種是bsv。那這三種貨幣到底有什麼區別呢？btc現在是繼承了位元幣絕大多數遺產，包括冠名權和整個生態。是目前共識最大的位元幣。btc...