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