一篇文章講透線上應用監控

「線上服務停了，要重啓一下」？久經職場作研發的程序員，視線會逐漸轉移到線上應用的運行狀態。設想一下，若是你在半夜兩點正在酣眠好夢時，微信羣裏忽然炸開鍋：「服務停了，先重啓。。。」，對於有起牀氣的你而言，好夢終結，是否能忍？

今天主要分三大塊：應用狀態監控、基於應用日誌的監控、昇華部分（老司機，帶你飛），稍微聊一下應用監控相關的知識。

聲明：

1. 今天的內容至關的燒腦，請提早喝足六個核桃！
2. 但我相信堅持閱讀到最後，你確定不枉此行！複製代碼

一. 應用服務狀態監控

生產上應用服務的運行通常要求 7 x 24，穩定運行率達到 99.99%。其中除了保證應用自己的健壯性外，固然還須要依賴一些守護程序作監控。否則一旦服務出現假死了怎麼辦？

首先咱們能想到的，即是經過寥寥幾行 linux 命令，組成一個小而精悍的 shell 文件，偶爾再配上 crontab 定時任務，來完成應用服務的進程守護。不扯別的，打開經常使用的monitor.sh 腳本一探究竟（以 tomcat 爲例）。

麻雀雖小五臟俱全，讓咱們解剖一下麻雀。

如何判斷應用處於假死？

經過配置健康檢查 url，專門用於心跳檢測，當每次訪問時正常返回 200 狀態碼，就認爲應用還能夠正常提供服務。若是返回的不是 200 狀態碼，則判斷應用的進程 ID 是否存在，存在則說明處於假死狀態。

如何實現假死應用重啓？

經過

ps -ef|grep "tomcat" |grep -w 'tomcat' | grep -v "grep" |awk '{print $2}'複製代碼

獲取對應的進程 ID，若是進程 ID 存在，則進行kill，而後調用啓動命令進行完成服務重啓。

上面的方式是在shell 腳本中，實現每 60 秒檢查一次應用服務狀態。另外我也常常會用 Linux 系統提供的 crontab，配置定時來調用監控腳本，完成應用監控，仍是以上面的 monitor.sh 腳本爲例，稍做改動註釋掉循環語句。

完成了腳本的編寫，接下來就是搭配 crontab 調度任務（第一次據說 crontab 這個詞的，請自行尋找谷歌、百度，惡補一下知識）

*/1 * * * * /app/script/monitor.sh > /dev/null 2>&1 複製代碼

若是你準備採用上述方案試用時，有兩個注意事項：

注意一：請注意修改對應的目錄，包括 tomcat 目錄、腳本目錄、心跳檢測url；

注意二：請注意針對shell 腳本賦上可執行權限。

小腳本解決大問題，因此別拿豆包不當乾糧，概有四兩撥千斤之勢。

其實依據過往的經歷，靜下來想想，面對其它非 tomcat 服務監控時，又未嘗不是這種方案呢。

到此最基本、最簡單也最實用的應用服務狀態監控方案就說完了。你 get 到了沒？

二. 基於應用日誌的監控

接觸過金融項目的都知道，日誌是解決系統 Bug 的最後一盞阿拉丁神燈。

在微服務發展如火如荼的今天，服務粒度越拆越細、模塊分工愈來愈明確，隨之而來的就是根據日誌排查問題就趨於繁瑣。

那麼是否是能夠把微服務的日誌進行歸集到一塊兒呢？業界已經有不少成型的方案。那接下來就聊聊如何進行日誌歸集呢？歸集的日誌如何進行存儲呢？存儲的日誌該如何展現呢？如何實現告警呢？

如何進行日誌歸集？

業界常見的日誌歸集方案，莫非就分爲兩種：一種是直採方式；另外一種是 agent 方式。

所謂的直採方式，就是在應用程序中將日誌，直接上傳到存儲層或者服務端，例如 Log4j 的 appender 。

所謂的 agent 方式，至關於在應用機器上部署一個 agent 服務，專門用於採集日誌，而後推送到存儲層或者服務端，應用自己只負責產生日誌。

直採方式適用於：在面對沒有額外的資源，能夠獨立部署採集日誌的 agent 時，例如負載均衡設備，那就不得不考慮直採方式。

agent 方式適用於：只要應用將日誌以文件的形式輸出到磁盤上，agent 就能夠將日誌採集到，而且對應用自己鬆耦合。與直採方式相比：可擴展性、可維護性，agent採集方式更勝一籌。

業界常見的日誌歸集工具備哪些呢？

一大堆輪子呼之欲出。

Elastic旗下的 Logstash、Elastic 旗下的 Filebeat、Apache 麾下的Flume、Linux 系統提供的 Syslog/Rsyslog/Syslog-ng、Facebook 名下的 Scribe 等等等。

估計堅持閱讀到此的你會一臉的懵逼（笑哭），不過不要緊，就當今天擴展一下知識面吧。

今天我主要提提我用過的兩款：Elastic 旗下的 Filebeat、Apache 麾下的 Flume。

Filebeat 是用 Go 語言開發，是一個二進制文件，部署無依賴，佔用資源極少，輕量 3M 多，開箱即用，親測使用特別方便。並且業界名聲也不小，是 ELK 架構升級後的產物，請問你是否據說過 ELK 呢（笑哭）？

Flume 是用 Java 語言開發，我用 Flume 主要是集成到項目框架中提供日誌歸集的能力，主要針對 Flume 去除了一些冗餘，擴展了部分功能，進行了二次擴展開發（後續有時間專門寫一篇 Flume 二次開發的那些事兒，請期待）。

歸集的日誌如何進行存儲呢？

又一堆輪子呼之欲出。

ElasticSearch、Mongodb、HDFS、時序數據庫 influxdb、opentsdb、rrd等等。

因爲工做場景的須要，經過關鍵詞進行定位查詢，而 elasticsearch 作查詢是最合適不過的了。由於每一個輪子，有每一個輪子的使用場景，在此就不作深刻展開。

有哪些日誌分析可視化工具？

對，你確定猜到了，又一堆輪子呼之欲出。

基於 Node.js 開發的展現工具，提供日誌展現、彙總、搜索，分析儀表盤等功能的kibana。

基於 go 語言開發的專一於根據CPU 和 IO 利用率之類的特定指標提供時間序列圖表的 Grafana。

如何實現告警呢？

萬里長征，只差一步。日誌歸集完成了，那若是想看看有沒有某個關鍵字，例如 error、exception 等等，出現關鍵字就發個告警通知，實現起來豈不是 so easy。

洋洋灑灑聊了這麼多關於日誌歸集的，我常常用的是 ELK，後續找個時間詳細寫一篇關於日誌歸集的文章吧。

三. 昇華一下，老司機帶你裝 B，帶你飛

到目前爲止，你已經瞭解瞭如何實現應用服務狀態的監控，而且知道了如何基於日誌作監控的思路。那你曾經有沒有糾結過：一筆請求的調用關係呢？一筆請求大概穿越了多少個系統？一筆請求大概耗時都花費那個節點？

先給你們拋個概念「APM應用性能監控」（不懂的先自行填補一下知識空白），若是有時間的話，請你多重點關注如下三種 APM 組件。

第一種： Zipkin，是由 Twitter 公司開源的分佈式的跟蹤系統，主要包括：數據的收集、存儲、查找和展示。

第二種：Pinpoint：由韓國人開源的分佈式跟蹤組件，是一款對 Java 編寫的大規模分佈式系統的 APM 工具。

第三種：Skywalking：國產的優秀 APM 組件，是一個對 Java 分佈式應用的業務運行狀況進行追蹤、告警和分析的系統。

輪子千萬款，總有一款適合你。

四. 寫在最後

互聯網寒冬下，大環境很差的狀況下，你只能自強！自強！！自強！！！

不知不覺碼了這麼多字，不知道你 get 到了多少。若是感受對你有點幫助，請不用讚揚，請多多推薦給身邊的朋友就很欣慰。