共计 6717 个字符，预计需要花费 17 分钟才能阅读完成。
我是 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
账号：liwei@xiaostudy.com
明码：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 我的项目】继续高强度更新中！求 star！！原创不易！！求三连！！
austin 我的项目源码 Gitee 链接：gitee.com/austin
austin 我的项目源码 GitHub 链接：github.com/austin