對於乙個系統來說，監控、鏈路追蹤、日誌的這三者需求都是必然存在的，而有的時候我們會搞不清楚這三者相互之間是什麼關係。我之前在做系統設計的時候也考慮過，是不是有必要引入那麼多元件，畢竟如果這三者完全分開每乙個一項的話，就有三個元件了（事實上就是：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基本一致，也是需要處理高頻併發和巨大的資料量。
這樣一看就很清楚了，每個元件都有其存在的必要性：
鏈路追蹤 一文讀懂鏈路追蹤
原文 在微服務橫行的時代，服務化思維逐漸成為了程式設計師的基本思維模式，但是，由於絕大部分專案只是一味地增加服務，並沒有對其妥善管理，當介面出現問題時，很難從錯綜複雜的服務呼叫網路中找到問題根源，從而錯失了止損的 時機。而鏈路追蹤的出現正是為了解決這種問題，它可以在複雜的服務呼叫中定位問題，還可以在...
技術分析 搞懂鏈路追蹤
背景介紹 在微服務橫行的時代，服務化思維逐漸成為了程式設計師的基本思維模式，但是，由於絕大部分專案只是一味地增加服務，並沒有對其妥善管理，當介面出現問題時，很難從錯綜複雜的服務呼叫網路中找到問題根源，從而錯失了止損的 時機。而鏈路追蹤的出現正是為了解決這種問題，它可以在複雜的服務呼叫中定位問題，還可...
swoft 日誌鏈路追蹤
該庫主要通過設定traceid，spanid，來實現日誌鏈路記錄，保證同一請求的鏈路traceid一致 並且增加redishandler可以將日誌直接記錄到redis中 協程方式 後續可以通過elk同步日誌 另外通過日誌配置增加version inte ce method params cost 時...