建站
咨詢
售后
建站咨詢
新聞中心
[[275278]]
TL;DR(too long don't read)
想要做到統(tǒng)一監(jiān)控，不外乎做到下面這么幾件事情。阿里云有日志服務(wù)，開源有 ELK。
1. 全鏈路調(diào)用唯一ID
2. 標(biāo)準(zhǔn)化日志
3. 打點方案
4. 監(jiān)控大盤
5. 告警方案
前言
比如我們對于我們開出去的接口，所依賴調(diào)用別人的二方三方服務(wù)，究竟是怎樣的表現(xiàn)，如果沒有監(jiān)控告警體系，那我們基本就是亂猜。比如，沒有客訴，那么大概系統(tǒng)運行得還不錯吧。這太瞎扯了，作為一個合格的工程師不允許這種情況出現(xiàn)。
投入一定的資源進行監(jiān)控告警的建設(shè)什么好處呢?最大的好處就是，我們知道究竟有多少個服務(wù)被依賴，依賴了多少三方服務(wù)，QPS 是多少，接口平均 RT 多長，成功率是多少，失敗的各個錯誤碼分布是怎樣的，一旦超過閾值能否比較及時觸達到開發(fā)、運營人員。
有了監(jiān)控，我們隨時都可以對我們的系統(tǒng)有一個比較全面的了解，以及有一個比較全面的把控。有了告警，遇到問題我們可以第一時間感知，也可以第一時間介入。這些事情我們需要去解，各個公司各個平臺的技術(shù)實力和經(jīng)濟實力都不同，所以解決方案也差別比較大。這些可能都是我們開發(fā)人員需要花時間額外去做的，無論是一次性的營銷方案，還是長期運行的系統(tǒng)，都需要準(zhǔn)備監(jiān)控告警方案。用錢換時間，以及用時間換錢，這就是我們需要權(quán)衡的東西。當(dāng)然，準(zhǔn)備方案基本都是一致的，在這里我先只聊接口層面的監(jiān)控。其他的關(guān)于數(shù)據(jù)庫、JVM、消息隊列、分布式緩存、tomcat 線程、主機CPU磁盤網(wǎng)絡(luò)等，均不在此次討論范圍，這些需要更高層面的聚合服務(wù)來實現(xiàn)監(jiān)控，監(jiān)控邏輯幾乎都是一致的。
監(jiān)控告警五部曲
想要做到統(tǒng)一監(jiān)控，不外乎做到下面這么幾件事情，但是每一件事都很難很重要。
1. 全鏈路調(diào)用唯一ID
2. 標(biāo)準(zhǔn)化日志
3. 打點方案
4. 監(jiān)控大盤
5. 告警方案
1. 全鏈路調(diào)用唯一ID
全鏈路調(diào)用使用唯一ID，這是一個比較有價值的事情，可以用來判斷某個調(diào)用鏈的調(diào)用過程是怎樣的，能夠在排查問題的追溯過程確保追溯流程的準(zhǔn)確性。比如我們有5個系統(tǒng)，如果我們沒有了這個唯一ID，在跨越五個系統(tǒng)的時候我們必然只能靠時間、訂單、人 等業(yè)務(wù)維度來確定調(diào)用鏈路。只有兩個字，低效。
正確的解決方式，就是在開始調(diào)用的時候生成一個幾乎全局唯一的ID，然后在調(diào)用的過程中不斷地傳遞給下游和分支，然后讓下游再鏈?zhǔn)降貍鬟f給下游。
比如在 Java 中的處理方案。所有的接口入?yún)⒍荚黾右粋€ traceId，然后放到 ThreadLocal 中，方便在任何地方進行打點。
2. 標(biāo)準(zhǔn)化日志
如果需要最終進行統(tǒng)一化分析，那么就要求我們在打日志的過程中，進行標(biāo)準(zhǔn)化統(tǒng)一化，大家全局的日志格式都一致，那么我們最終分析的時候也會比較簡單。一個比較可行的標(biāo)準(zhǔn)化日志方案是長這樣的。
3. 打點方案
標(biāo)準(zhǔn)化返回值
其中最核心的就是 ，具體可以參照下 大蕉蕉的三道 Java 私房菜 No.131 中的 ResultExecutor + ResultDTO 組合，核心就是標(biāo)準(zhǔn)化所有的出參，以便可以標(biāo)準(zhǔn)化進行 AOP 打印日志，核心值就是 succ 和 code。經(jīng)過了標(biāo)準(zhǔn)化返回值之后，我們就可以針對返回值進行打點了，這就到了第二步。
AOP 切面
我們會使用切面的方式來進行日志打點，比如提供的服務(wù)接口調(diào)用前后，調(diào)用數(shù)據(jù)庫的調(diào)用前后，調(diào)用公共緩存服務(wù)前后，調(diào)用消息中間件前后。如果是 Java 的話，建議使用 AspectJAroundAdvice，這樣可以增加統(tǒng)計 rt (響應(yīng)時間)。
日志文件規(guī)劃
可以標(biāo)準(zhǔn)化成 rpc_access.log(內(nèi)部服務(wù))、http_access.log(http 類型服務(wù)，帶登錄態(tài))、proxy_access.log(調(diào)用外部服務(wù)的代理)、db_access.log(db 類型日志)。這樣分類有兩個好處，第一個是在排查問題的時候可以有針對性地縮小排查范圍，第二個是在最終日志聚合的時候可以有的放矢。
當(dāng)然，打這么多日志，我們肯定會考慮，真的不會影響服務(wù)性能嗎?這就到了第三步。
滾動日志&異步appender
我們每天的訪問量都是海量的，如果任由日志不斷打的話，機器無論有多大基本都是不夠用的，所以我們可以使用滾動日志的方式，比如 Java 下是 slf4j2。至于打日志，其實是一個磁盤 IO 的過程，這個過程如果量比較大的話，是有可能會影響服務(wù)的 rt 的，如果我們做成異步的appender，那么我們打點的過程對于原來的服務(wù)來說影響幾乎可以忽略不計。那么日志打完就放到本地嗎?明顯是不合適的，肯定需要有一個歸檔的地方，按照某種策略進行歸檔。
歸檔數(shù)據(jù)庫
這類歸檔數(shù)據(jù)庫的寫入其實有兩個方案，第一個是使用 SDK 的方式進行寫入。第二個是安裝一個 agent 進行定時文件掃描，然后上傳到歸檔數(shù)據(jù)庫?？蛇x擇的方案大概有 ElasticSearch、SLOG、時序數(shù)據(jù)庫、HBase、Graphite 等 NOSQL 的數(shù)據(jù)庫。在這里強烈建議不要放到關(guān)系型數(shù)據(jù)庫里，畢竟日志的量實在是太大了，無論放到哪個關(guān)系型數(shù)據(jù)庫里，最終的結(jié)果都只會因為基礎(chǔ)數(shù)據(jù)量太大，而導(dǎo)致幾乎任何查詢都進行不下去。
4. 監(jiān)控大盤
開源方案
Graphite
Graphite does two things:
- Store numeric time-series data
- Render graphs of this data on demand
Graphite 就做了兩件事，第一件事就是存儲了時序數(shù)字類型的數(shù)據(jù)，第二件事就是把這些數(shù)據(jù)用圖表的方式展示出來，至于安裝和使用的過程比較復(fù)雜，請自行進行閱讀。 https://www.infoq.cn/article/graphite-intro/
ELK(ElasticSearch + Logstach + Kibana)
這里的監(jiān)控大盤主要使用了 Kibana 的自定義視圖能力，要求就是數(shù)據(jù)必須寫入到 ElasticSearch 里邊。
高成本方案
阿里云 SLOG 日志服務(wù)
SLOG 是阿里云提供的一個日志服務(wù)，只要根據(jù) key-value 的形式將數(shù)據(jù)寫入到 SLOG 上，就可以自定義配置一些監(jiān)控大盤，一定量以內(nèi)是免費的。所以如果量不大，技術(shù)實力又不強，可以嘗試一下這個方案。當(dāng)然如果有一定的資金，SLOG 本身其實并不算太貴，而且可靠性和性能都非常強。除了官方提供的方式外，也可以對接到一個自定義的日志平臺或者監(jiān)控平臺，通過 API 的形式進行監(jiān)控數(shù)據(jù)查詢，并進行展示。
高技術(shù)方案
Flink 實時計算
這里使用的主要 Flink 的基于窗口的聚合能力，能夠?qū)⒋笈康牧魇綌?shù)據(jù)進行聚合，然后再將聚合的結(jié)果輸出到某個庫，提供一定的大盤能力，比如雙十一的 GMV 計算大屏。優(yōu)點就是可定制型非常非常強以及性能可以得到很好的調(diào)優(yōu)和定制，缺點就是技術(shù)實力可能要求比較高，而且對每一個需要監(jiān)控的點基本都需要進行代碼開發(fā)。
5. 告警方案
高成本方案
阿里云 SLOG 日志服務(wù)本身也提供了告警功能，詳細(xì)可以進入官網(wǎng)查看。
高技術(shù)方案
這里主要是對于自控形式比較強的團隊?？梢宰孕虚_發(fā)告警服務(wù)，主要技術(shù)手段就是，按照某種聚合方式，定時從時序數(shù)據(jù)庫里查詢，然后進行告警的觸發(fā)。當(dāng)然如果技術(shù)實力夠的話，也可以集合一定的規(guī)則引擎以及配置的能力，對于開發(fā)人員進行 devOps 的支持，也就是告警的自定義。
觸達方式
有了告警之后，我們肯定希望能夠準(zhǔn)確快速觸達到對應(yīng)的人員，一般來說我們的觸達方式可以有 釘釘群機器人、企業(yè)微信群機器人、郵件、電話、短信。這幾個方式都算比較便捷實現(xiàn)，我們要考慮的點是，什么樣的告警需要怎樣的頻率進行觸達，比如告警 1 分鐘用群機器人，重要的用短信，告警持續(xù) 5 分鐘還未關(guān)閉則通過自動化語音播報的形式進行電話觸達。
總結(jié)
為什么很多的開發(fā)人員在上線后會心慌，因為這部分的工程師對于系統(tǒng)的表現(xiàn)毫無概念，毫無可以著手的，毫無把控能力。這就是我們需要監(jiān)控告警的作用，監(jiān)控是讓我們擁有對系統(tǒng)一定的把控能力，告警是讓我們不需要時時刻刻盯著所謂的大盤。上面所說的這些，都是我們需要在開發(fā)完成或者開發(fā)初期就需要考慮到的，是需要納入到項目工作量里面的(當(dāng)然如果項目經(jīng)理不管這個，你需要對他進行宣告。又或者給自己留一定的 buffer 進行監(jiān)控告警的建設(shè))。我們需要在哪里進行打點，打怎樣的點，怎么進行監(jiān)控，什么樣的內(nèi)容需要告警，作為一個合格的工程師，這是我們效率方面非常非常非常值得的投入。
沒有監(jiān)控的系統(tǒng)就是半廢，你，敢上線嗎?
本文名稱：定心丸之沒有監(jiān)控的系統(tǒng)就是半廢
網(wǎng)站路徑：http://www.dlmjj.cn/article/ccscjhh.html
