我是3y，一年CRUD經驗用十年的markdown程式員???????常年被譽為職業八股文選手
今天austin專案來給大家整點不一樣的：花點時間跟著文章做完，螢屏壁紙就可以有了，我來上個圖，大家就懂了，
每當同事一瞄你的電腦，發現都是圖形化的、黑色的看起來就比較高端的界面：“嗯，這逼又在找Bug了吧”
沒錯，要聊的話題就是監控
01、為什么監控
過去在面試的時候，我記得曾經被問過：“線上出了問題，你們是怎么排查的？排查的思路是怎么樣的？”
我以前的部門老大很看重穩定性，經常讓我們梳理系統的上下鏈路和介面資訊，我想：想要提高系統的穩定性就需要有完備的監控和及時告警，
有了監控，出了問題可以快速定位（而不是出了問題還在那里列印日志查找，很多問題都可以通過監控的資料就直接看出來了），有了監控，我們可以把指標都配置在監控內，無論是技術上的還是業務上的（只不過業務的資料叫做看板，而系統的資料叫做監控），有了監控我們看待系統的角度都會不一樣（全方位理解系統的性能指標和業務指標）
如果你線上的系統還沒有監控，那著實是不太行的了
02、監控開源組件
監控告警這種想都不用想，直接依賴開源組件就完事了，應該只有大公司才有人力去自研監控告警的組件了，
我選擇的是Prometheus（普羅米修斯），這個在業內還是很出名的，有很多公司都是用它來做監控和告警，
從prometheus的官網我們可以從檔案中找到一張架構圖：
我把上面圖以我的理解“不適當地”簡化下
簡化完了之后，發現：還是他娘的人家的圖畫得好看
總體而言，prometheus的核心是在于Server，我們要接入prometheus的話，實際上就是開放介面給prometheus拉取資料，然后在web-ui下配置圖形化界面進而實作監控的功能，
03、prometheus環境搭建
對于prometheus的環境搭建，我這次也是直接用docker來弄了，畢竟Redis和Kafka都上了docker了，新建一個prometheus的檔案夾，存放docker-compose.yml的資訊：
version: '2'
networks:
monitor:
driver: bridge
services:
prometheus:
image: prom/prometheus
container_name: prometheus
hostname: prometheus
restart: always
volumes:
- ./prometheus.yml:/etc/prometheus/prometheus.yml
# - ./node_down.yml:/usr/local/etc/node_down.yml:rw
ports:
- "9090:9090"
networks:
- monitor
alertmanager:
image: prom/alertmanager
container_name: alertmanager
hostname: alertmanager
restart: always
# volumes:
# - ./alertmanager.yml:/usr/local/etc/alertmanager.yml
ports:
- "9093:9093"
networks:
- monitor
grafana:
image: grafana/grafana
container_name: grafana
hostname: grafana
restart: always
ports:
- "3000:3000"
networks:
- monitor
node-exporter:
image: quay.io/prometheus/node-exporter
container_name: node-exporter
hostname: node-exporter
restart: always
ports:
- "9100:9100"
networks:
- monitor
cadvisor:
image: google/cadvisor:latest
container_name: cadvisor
hostname: cadvisor
restart: always
volumes:
- /:/rootfs:ro
- /var/run:/var/run:rw
- /sys:/sys:ro
- /var/lib/docker/:/var/lib/docker:ro
ports:
- "8899:8080"
networks:
- monitor
這里拉取的鏡像分別有：
cadvisor用于獲取docker容器的指標node-exporter用戶獲取服務器的指標grafana監控的web-ui好用的可視化組件alertmanager告警組件（目前暫未用到)prometheus核心監控組件
新建prometheus的組態檔prometheus.yml (這份配置其實就是告訴prometheus要去哪個埠中拉取對應的監控資料)
global:
scrape_interval: 15s
evaluation_interval: 15s
scrape_configs:
- job_name: 'prometheus'
static_configs:
- targets: ['ip:9090'] // TODO ip自己寫
- job_name: 'cadvisor'
static_configs:
- targets: ['ip:8899'] // TODO ip自己寫
- job_name: 'node'
static_configs:
- targets: ['ip:9100'] // TODO ip自己寫
（這里要注意埠，按自己配置的來）
把這份prometheus.yml的配置往/etc/prometheus/prometheus.yml 路徑下復制一份（有很多配置的資訊我都忽略沒寫了，prometheus的功能還是蠻強大的，對監控想深入了解的可以官網看看檔案）
隨后在目錄下docker-compose up -d 啟動，于是我們就可以分別訪問：
http://ip:9100/metrics( 查看服務器的指標)http://ip:8899/metrics（查看docker容器的指標）http://ip:9090/(prometheus的原生web-ui)http://ip:3000/(Grafana開源的監控可視化組件頁面)
一個docker-compose起了5個服務器，真好使！
04、Grafana配置監控
既然我們已經起了Grafana了，就直接用Grafana作為監控的可視化工具啦（prometheus有自帶的可視化界面，但我們就不用啦），進到Grafana首頁，我們首先要配置prometheus作為我們的資料源
進到配置頁面，寫下對應的URL，然后保存就好了，
配置好資料源之后，我們就可以配置對應的監控資訊了，常見的配置監控已經有對應的模板了，就不需要我們一個一個地去配置了，（如果不滿足的話，那還是得自己去配）
在這里，我就演示如何使用現有的模板吧，直接import對應的模板，相關的模板可以在 https://grafana.com/grafana/dashboards/ 這里查到，
我們直接服務器的監控直接選用8913的就好了
import后就能直接看到高大上的監控頁面了：
因為我們用docker啟動的服務還是蠻多的，也可以看看Docker的監控（上面啟動的cadvisor服務就采集了Docker的資訊），我們使用模板893來配置監控docker的資訊：
05、Java系統指標
沒想到，通過上面短短的內容已經配置好了服務器和Docker服務的監控，但還是缺了什么對吧？我們寫Java程式的，JVM相關的監控都沒搞起來？這怎么能行啊，
所以，得支棱起來
配置Java的監控也特別簡單，只要我們在專案中多引入兩個pom依賴（SpringBoot自帶的監控組件actuator）
<!--監控-->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<!--適配prometheus-->
<dependency>
<groupId>io.micrometer</groupId>
<artifactId>micrometer-registry-prometheus</artifactId>
</dependency>
然后在組態檔上加上對應的配置（開啟監控并可以讓prometheus拉取配置）
# 監控配置 TODO
management:
endpoint:
health:
show-details: always
metrics:
enabled: true
prometheus:
enabled: true
endpoints:
web:
exposure:
include: '*'
metrics:
export:
prometheus:
enabled: true
當我們啟動服務后，訪問/actuator路徑就能看到一大堆輸出的指標了，包括prometheus的
能看到這些指標被列印了，說明我們程式接入已經完成了，剩下的就是通過prometheus來采集應用的指標了，
要讓prometheus采集到Java應用的資料，其實就是改下對應的組態檔就完事了，在前面寫好的的prometheus.yml檔案下添加相關的配置資訊：
- job_name: 'austin'
metrics_path: '/actuator/prometheus' # 采集的路徑
static_configs:
- targets: ['ip:port'] # todo 這里的ip和埠寫自己的應用下的
我們訪問：ip:9090/targets這個路徑下，能看到現在prometheus能采集到的端點有哪些，看到都是自己所配置的狀態為up，那就說明正常了，
那我們繼續在Grafana配置對應的監控就好啦，這里我選用了4701模板的JVM監控和12900SpringBoot監控，可以簡單看下他們的效果：
06、壓測
到目前為止，我們想要發訊息，都是通過HTTP介面進行呼叫的，而恰好的是，Spring actuator是能監控到HTTP的資料的，那我們就壓測一把看看監控平臺的指標會不會變？
這里我使用wrk這個壓測工具來（它足夠簡單易用）所以，首先安裝他(環境Centos 7.6)：
sudo yum groupinstall 'Development Tools'
sudo yum install -y openssl-devel git
git clone https://github.com/wg/wrk.git wrk
cd wrk
make
# 將可執行檔案移動到 /usr/local/bin 位置
sudo cp wrk /usr/local/bin
# 驗證安裝是否成功
wrk -v
壓測下百度來玩玩：wrk -t2 -c100 -d10s --latency http://www.baidu.com （開兩個執行緒 并發100 持續10s 請求百度）
壓測下我們的介面，完了之后看資料：wrk -t4 -c100 -d10s --latency 'http://localhost:8888/sendSmsTest?phone=13888888888&templateId=1'
顯然資料是有明顯的波動的，而資料貌似跟我們壓測的對不太上？
在我個人的理解下：prometheus是每隔N秒（可配置）去拉取暴露的資料，而在界面上配置的可視化也是按N秒（可配置）去執行一次Query，基于這種架構下，我們是很難得出某一時刻（秒）對應的數值，
所以在prometheus體系下，它只能看到一個時間段內的值，這對于QPS和RT這些指標并不太友好，
07、部署專案到Linux
從上面的命令來看，我是將austin專案放在Linux下跑了，雖然這是比較基礎的事了，但為了新人，我還是貼下具體的流程吧，點個贊不過分吧？
首先，我們需要下載JDK
下載JDK：https://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html
賬號：[email protected]
密碼：OracleTest1234
完了之后，我們需要把下載的包上傳到Linux上，我用的是Mac（用Windows的同學可以百度下，估計都挺簡單的），IP自己切換成對應的地址
scp -P22 /Users/3y/Downloads/下載的dmg/jdk-8u311-linux-i586.tar.gz root@ip:/root/austin
解壓java包
tar -zxvf jdk-8u231-linux-x64.tar.gz
配置對應的環境變數：
vim /etc/profile
# 在組態檔后添加下面的內容
export JAVA_HOME="/root/java/jdk1.8.0_311"
export PATH="$JAVA_HOME/bin:$PATH"
#重繪組態檔
source /etc/profile
# 檢查版本看是否安裝成功
java -version
# 如果出現以下錯誤，則安裝下面的環境 -- 未出現則忽略
-bash: /root/java/jdk1.8.0_311/bin/java: /lib/ld-linux.so.2: bad ELF interpreter: 沒有那個檔案或目錄
# 安裝環境
yum install glibc.i686
在本地打好對應的jar包：
mvn package -Dmaven.test.skip=true
上傳到Linux服務器（跟上面的操作一致），然后使用后臺的方式啟動：
nohup java -jar austin-web-0.0.1-SNAPSHOT.jar --server.port=8888 &
08、業務指標
從上面我配置了docker的監控、服務器的監控、SpringBoot應用程式的監控，但可以發現的是，這大多數都是系統的指標監控，有的小伙伴可能就會問了：”呀？你不是說有業務監控嗎？咋不見你弄？“
我們也是可以實作自定義指標監控給到prometheus進行采集的，但如果系統本身如果接入了類ELK的系統，那我們更偏向于把業務指標資料在ELK上做掉，畢竟ELK面向的是日志資料，只要我們記錄下了日志就可以把日志資料清洗出來做業務指標面板監控，
對于austin專案而言，后期是會接ELK相關的組件的，所以，這里就不用prometheus來采集業務指標的資訊了，我更偏向于把prometheus作為采集系統指標的組件，
09、總結
這篇文章主要講的是監控的基本入門（一般這塊是由運維團隊去做的，但作為開發最好懂點吧），如果你公司內的系統還沒監控，那可以規劃規劃下，用開源的組件入門下還是比較容易搭建出來的，
一個系統真不能少了監控，有監控排查的問題會快很多，
最后還是來回答下之前面試被問到的問題吧：“線上出了問題，你們是怎么排查的？排查的思路是怎么樣的？”
我是這樣理解的：首先，如果線上出了問題，那要想想最近有沒有曾經發布過系統，很多時候線上出現的問題都是由系統的發布更改所導致的，如果最近發布過系統，并且對線上的問題是造成比較大的影響，那首先先回滾，而不是先排查問題，
如果最近沒有發布系統，那看下系統的監控是否正常（流量監控、業務監控等等），一般情況下我們能從監控上就發現問題了（畢竟系統我們是最了解的，有例外很快就能定位出問題了）
如果系統監控也沒問題，那得看下線上有沒有比較特殊的錯誤日志了，通過錯誤日志去排查問題，一般對系統比較了解的話，那還是容易能看出來的，再不行就拿著請求引數去dev環境上debug看執行程序吧，
所以：我們這有回滾的機制、有監控機制、一般的錯誤我們會及時告警到短信、郵件以及IM工具上，如果這些都沒有，那可能就得翻錯誤日志復現問題，這是我的一般排查思路，
這篇文章到這里就結束了，預告下：分布式配置中心我在代碼里已經接入了
不知不覺已經寫了這么長了，點個贊一點都不過分吧？我是3y，下期見，
歡迎關注我的微信公眾號【Java3y】來聊聊Java面試和專案，對線面試官系列持續更新中！
【對線面試官+從零撰寫Java專案】 持續高強度更新中！求star！！原創不易！！求三連！！
Gitee鏈接：https://gitee.com/austin
GitHub鏈接：https://github.com/austin
更多的文章可往：文章的目錄導航轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/436302.html
標籤：Java