直观:丢，我讲的是监控，不是QPS

　　直观:丢，我讲的是监控，不是QPS

　　你好，我3岁

　　今天奥斯汀项目给大家一个不一样的点：花点时间关注文章完成，屏幕壁纸即可。我上传一张图，大家就明白了。

　　每当同事扫视你的电脑，就会发现是一个图形化的黑色界面，看起来很高端：“嗯，我又在找bug了。”

　　对了，要聊的话题是监控

　　01. 为什么要监控

　　记得以前采访的时候，有人问我：“网上有问题，你是怎么调查的？调查的方法是什么？”

　　我以前的部门负责人非常重视稳定性，经常要求我们整理系统的上下行和接口信息。我认为：要想提高系统的稳定性，就需要有完善的监控和及时的告警。

　　有了监控，可以快速定位问题（而不是打印日志找问题，很多问题可以通过监控数据直接看到）。有了监控，我们可以配置监控中的所有指标，不管是技术还是业务（但业务数据叫看板，系统数据叫监控）。有了监控，我们会从不同的角度看系统（全面了解系统的性能指标和业务指标）

　　如果你的在线系统没有被监控，那真的不可行。

　　02. 监控开源组件

　　无需考虑监控和报警。直接依赖开源组件就足够了。只有大公司才有人力开发自己的监控和报警组件。

　　我选择了Prometheus，这个在业界还是很有名的，很多公司都用它来做监控和告警。

　　在prometheus官网，我们可以从文档中找到一个架构图：

　　根据我的理解，我“不恰当地”简化了上图

　　简化后发现：他妈一家人的照片很美

　　总的来说，prometheus 的核心在于服务器。如果我们要访问prometheus，其实是打开prometheus拉取数据的界面，然后在web-ui下配置图形界面，实现监控功能。

　　03. Prometheus环境搭建

　　prometheus的环境搭建，我这次也是直接用docker。毕竟，Redis 和 Kafka 都在 docker 上。新建prometheus文件夹，存放docker-compose.yml的信息：

　　version: '2'<br /><br />networks:<br />    monitor:<br />        driver: bridge<br /><br />services:<br />    prometheus:<br />        image: prom/prometheus<br />        container_name: prometheus<br />        hostname: prometheus<br />        restart: always<br />        volumes:<br />            - ./prometheus.yml:/etc/prometheus/prometheus.yml<br />#            - ./node_down.yml:/usr/local/etc/node_down.yml:rw<br />        ports:<br />            - "9090:9090"<br />        networks:<br />            - monitor<br /><br />    alertmanager:<br />        image: prom/alertmanager<br />        container_name: alertmanager<br />        hostname: alertmanager<br />        restart: always<br />#        volumes:<br />#            - ./alertmanager.yml:/usr/local/etc/alertmanager.yml<br />        ports:<br />            - "9093:9093"<br />        networks:<br />            - monitor<br /><br />    grafana:<br />        image: grafana/grafana<br />        container_name: grafana<br />        hostname: grafana<br />        restart: always<br />        ports:<br />            - "3000:3000"<br />        networks:<br />            - monitor<br /><br />    node-exporter:<br />        image: quay.io/prometheus/node-exporter<br />        container_name: node-exporter<br />        hostname: node-exporter<br />        restart: always<br />        ports:<br />            - "9100:9100"<br />        networks:<br />            - monitor<br /><br />    cadvisor:<br />        image: google/cadvisor:latest<br />        container_name: cadvisor<br />        hostname: cadvisor<br />        restart: always<br />        volumes:<br />            - /:/rootfs:ro<br />            - /var/run:/var/run:rw<br />            - /sys:/sys:ro<br />            - /var/lib/docker/:/var/lib/docker:ro<br />        ports:<br />            - "8899:8080"<br />        networks:<br />            - monitor<br />

　　此处拉取的图片有：

　　新建prometheus配置文件prometheus.yml（这个配置其实就是告诉prometheus从哪个端口拉取相应的监控数据）

　　global:<br />  scrape_interval:     15s<br />  evaluation_interval: 15s<br />scrape_configs:<br />  - job_name: 'prometheus'<br />    static_configs:<br />    - targets: ['ip:9090']  ## TODO ip自己写<br />  - job_name: 'cadvisor'<br />    static_configs:<br />    - targets: ['ip:8899']  ## TODO ip自己写<br />  - job_name: 'node'<br />    static_configs:<br />    - targets: ['ip:9100']  ## TODO ip自己写<br />

　　（注意这里的端口，根据自己的配置）

　　把这个prometheus.yml的配置复制到/etc/prometheus/prometheus.yml路径下（有很多配置信息我都忽略了没写，prometheus的功能还是挺强大的，想知道的话更多关于监控，可以查看官网文档）

　　然后在目录下启动docker-compose up -d，这样我们就可以访问了：

　　一个 docker-compose 有 5 个服务器，非常好用！

　　04. Grafana配置监控

　　现在我们已经启动了Grafana，我们可以直接使用Grafana作为监控的可视化工具（prometheus有自己的可视化界面，但是我们不需要）。进入Grafana主页，我们首先需要配置prometheus作为我们的数据源

　　进入配置页面，记下对应的URL，保存。

　　

　　配置好数据源后，我们就可以配置相应的监控信息了。常用的配置监控已经有相应的模板，我们不需要一一配置。（不满意还是要自己配）

　　在这里，我将演示如何使用现有的模板，直接导入相应的模板，相关的模板可以在这里找到。

　　我们只是使用 8919 来直接监控服务器。

　　导入后可以直接在tall上看到监控页面：

　　因为我们使用docker启动了很多服务，所以也可以看一下Docker监控（上面启动的cadvisor服务收录Docker信息），我们使用模板893来配置监控docker信息：

　　05. Java系统指标

　　没想到通过上面的短内容已经配置好了服务器和Docker服务的监控，但是还是少了点什么吧？我们写Java程序，但是JVM相关的监控还没做？这怎么能行。

　　所以，起来

　　配置Java监控也很简单，只要我们在项目中再引入两个pom依赖（SpringBoot自带的监控组件执行器）

　　<br /><br />  org.springframework.boot<br />  spring-boot-starter-actuator<br /><br /><br /><br />  io.micrometer<br />  micrometer-registry-prometheus<br /><br />

　　然后在配置文件中添加对应的配置（开启监控，让prometheus拉取配置）

　　# 监控配置  TODO<br />management:<br />  endpoint:<br />    health:<br />      show-details: always<br />    metrics:<br />      enabled: true<br />    prometheus:<br />      enabled: true<br />  endpoints:<br />    web:<br />      exposure:<br />        include: '*'<br />  metrics:<br />    export:<br />      prometheus:<br />        enabled: true<br />

　　当我们启动服务时，访问/actuator路径可以看到很多输出指标，包括prometheus

　　可以看到打印了这些指标，说明我们的程序访问已经完成，剩下的就是通过prometheus来采集应用指标了。

　　获取prometheus采集到Java应用的数据，其实只要改一下对应的配置文件就大功告成了。在前面写的prometheus.yml文件中添加相关配置信息：

　　  - job_name: 'austin'<br />    metrics_path: '/actuator/prometheus' # 采集的路径<br />    static_configs:<br />    - targets: ['ip:port'] # todo 这里的ip和端口写自己的应用下的<br />

　　当我们访问：ip:9090/targets 时，可以看到 prometheus 采集 可以到达的端点。如果我们看到自己配置的状态是up，说明是正常的。

　　然后我们继续在 Grafana 中配置相应的监控。这里我选择了4701模板的JVM监控和12900的SpringBoot监控，可以简单的看看它们的效果：

　　06.压力测量

　　到目前为止，我们要发送的消息都是通过 HTTP 接口调用的，恰好 Spring 执行器可以监控 HTTP 数据。那我们再做压力测试，看看监控平台的指标会不会有变化？

　　这里我使用的是压测工具wrk（使用起来很简单）所以，首先安装它（环境Centos 7.6）：

　　sudo yum groupinstall 'Development Tools'<br />sudo yum install -y openssl-devel git <br />git clone https://github.com/wg/wrk.git wrk<br />cd wrk<br />make<br /># 将可执行文件移动到 /usr/local/bin 位置<br />sudo cp wrk /usr/local/bin<br /><br /># 验证安装是否成功<br />wrk -v<br />

　　百度打压测试下：wrk -t2 -c100 -d10s --latency（开启两个线程并发100个10s请求百度）

　　压测我们的接口，然后看数据：wrk -t4 -c100 -d10s --latency ':8888/sendSmsTest?phone=&amp;templateId=1'

　　

　　明明数据有明显波动，而且数据似乎和我们的压力测试不相符？

　　个人理解：prometheus每N秒拉一次暴露的数据（可配置），界面上配置的可视化也是每N秒执行一次Query（可配置）。基于这种架构，我们很难得到某个时刻（秒）对应的值。

　　所以在prometheus系统下只能看到一个时间段内的数值，对QPS、RT等指标不太友好。

　　07. 将项目部署到Linux

　　通过上面的命令，我在 Linux 下运行了 austin 项目，虽然这是一个比较基础的东西。不过为了新人，我把具体过程贴一下吧？

　　首先，我们需要下载JDK

　　下载JDK：https://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html<br /><br />账号：liwei@xiaostudy.com<br />密码：OracleTest1234<br />

　　之后，我们需要将下载的包上传到 Linux。我用的是Mac（使用Windows的同学可以百度下载，估计很简单），IP切换到对应地址。

　　scp -P22 /Users/3y/Downloads/下载的dmg/jdk-8u311-linux-i586.tar.gz root@ip:/root/austin<br />

　　解压java包

　　tar -zxvf jdk-8u231-linux-x64.tar.gz<br />

　　配置相应的环境变量：

　　vim /etc/profile <br />  <br /># 在配置文件后添加下面的内容<br />export JAVA_HOME="/root/java/jdk1.8.0_311"<br />export PATH="$JAVA_HOME/bin:$PATH"<br /><br />#刷新配置文件<br />source /etc/profile<br /><br /># 检查版本看是否安装成功 <br />java -version<br /><br /># 如果出现以下错误，则安装下面的环境  -- 未出现则忽略<br />-bash: /root/java/jdk1.8.0_311/bin/java: /lib/ld-linux.so.2: bad ELF interpreter: 没有那个文件或目录<br /><br /># 安装环境<br />yum install glibc.i686<br />

　　在本地输入对应的jar包：

　　mvn package -Dmaven.test.skip=true<br />

　　上传到Linux服务器（同上），然后后台启动：

　　nohup java -jar austin-web-0.0.1-SNAPSHOT.jar --server.port=8888 &<br />

　　08.业务指标

　　从上面，我配置了 docker 监控、服务器监控和 SpringBoot 应用程序监控。但可以发现，其中大部分是系统性的指标监测。有朋友可能会问：“是吗？你不是说有业务监控吗？怎么没看到？”

　　我们也可以为采集实现自定义指标监控到prometheus，但是如果系统本身连接的是类似ELK的系统，那么我们更倾向于在ELK上做业务指标数据。毕竟ELK是用来做日志数据的。我们只要记录日志，就可以清理日志数据，进行业务指标面板监控。

　　对于austin项目，ELK相关的组件会在后面接上。所以这里不需要prometheus去采集业务指标。我更喜欢使用 prometheus 作为 采集 系统指标的组件。

　　09. 总结

　　这篇文章主要讲监控的基本介绍（一般都是运维团队做的，但是作为开发者最好了解一下）。如果你公司的系统没有被监控，你可以规划规划，用开源组件搭建相对容易。

　　一个系统对于监控来说确实是必不可少的，监控和故障排除的问题会快得多。

　　最后，我们来回答一下之前采访中提出的问题：“网上有问题，你是怎么调查的？调查的思路是什么？”

　　我是这样理解的：首先，如果网上出现问题。然后想想最近系统有没有发布。很多时候在线问题是由系统的版本变化引起的。如果系统是最近发布的，对线上问题影响比较大，先回滚，不要先排查。

　　如果系统最近没有发布，那么检查系统的监控是否正常（流量监控、业务监控等），一般情况下我们可以从监控中发现问题（毕竟我们最了解系统） ，很快就出现异常。可以定位问题）

　　如果系统监控没有问题，那么在线查看是否有特殊的错误日志，使用错误日志来排查问题。一般来说，如果你对系统有更深入的了解，还是很容易看出来的。如果没有，就去开发环境用请求参数调试执行过程。

　　所以：我们有回滚机制、监控机制和一般错误，我们会及时提醒他们SMS、电子邮件和IM 工具。如果这些都不可用，我们可能必须通过错误日志来重现问题。这是我的一般调查思路。

　　这个文章就到这里了，预警：我已经在代码中连接了分布式配置中心

　　不知不觉写了这么久。喜欢它并不过分。

　　《》公众号持续分享面试题，没关注的同学可以关注一下！这是奥斯汀项目的最后一个系列，质量杆

　　奥斯汀项目Gitee链接：

　　奥斯汀项目 GitHub 链接：

　　直观:走近监控系统的神经中枢

　　随着软件系统的发展，监控目标场景越来越广泛，对监控系统的能力要求也越来越高。对于监控系统，基本可以分为六部分：数据采集、数据计算、数据存储、异常检测、告警处理和监控可视化。为了更好地应对*敏*感*词*复杂的监控业务场景，我们不仅需要深化和加强具体的监控能力，还需要建立相应的机制来协调这些能力，使其协同工作。今天的文章文章将介绍监控系统的神经中枢——配置管理和分发系统，让我们一起揭开它的神秘面纱！

　　需要

　　在业务系统开发初期，由于场景简单，监控需求也比较简单。比如只需要采集默认机器监控数据，不需要进程、日志等监控能力。同时，监控的规模也比较小，用户配置的数量一般在几百或几千的水平。这时候只需要定期读取数据库中的配置就可以正常工作了。

　　随着业务系统的快速发展，业务量越来越大，业务的复杂度越来越高，对监控的需求也越来越高。传统的简单读数据库配置在业务扩展性和性能方面遇到了挑战。

　　1 支持不同类型的配置管理

　　监控指标采集、计算、告警等配置类型越来越多。如物理机的机器资源指标，采集应用进程和日志指标配置，站点连通性采集配置，服务器宕机检测任务配置，多实例间指标计算任务配置，异常检测配置指标数据、告警信息发送配置等

　　2 支持不同场景下的配置分发

　　3 支持从故障中快速恢复

　　配置分发系统用作监控中心。有很多相关的模块。系统故障会影响采集、计算、报警子系统的正确性，用户新的监控配置不会生效。因此，需要相应的解决方案来保证监控。系统的快速恢复或重建能力保证了监控系统的可用性。

　　图1 配置管理与分配系统交互流程图

　　程序

　　

　　梳理出问题和需求后，下一步就是针对这些问题进行相应的改造升级。下面从技术角度来介绍一下如何解决这些问题！

　　1 支持配置可扩展性

　　完善的监控能力意味着监控系统的配置灵活多样。如果配置分发模型与业务模型直接相连，则意味着业务中的每一次变更都需要配置并分发到系统中进行相应的变更。那么如何统一配置的多样性，让配置下发对上层业务透明呢？答案是：分类+抽象。

　　1、不同的配置按“目录”分类管理，达到统一的配置管理要求。

　　2、以文件为载体，所有配置都以文件的形式进行管理。不同的文件内容格式代表不同类型的配置。将原有格式的升级和新类型的增加统一抽象成文件处理，增强了系统的扩展能力。

　　3、通过代码管理系统管理文件，实现变更历史跟踪。通过定期备份文件系统，构建快速故障恢复机制，提高系统的可用性和可靠性。

　　图 2 配置分类与抽象

　　在分类方面，由于不同的能力需要不同的配置形式，我们以此为基础进行分类。对应实现，通过目录来表达分类的含义，通过子目录来表达配置的级别和属性的关系。这里我们将配置目录的级别划分为三个级别：监控功能级别-&gt;用户级别-&gt;应用级别，将具体配置（如进程监控配置、日志监控配置）写入应用目录下的文件中。

　　2 确保一致的交付

　　通过对配置管理方法的抽象和分类，可以通过构建配置文件内容的一致性机制来解决配置的一致*敏*感*词*付问题。我们使用“版本”作为文件内容一致性机制的核心。当用户更改配置时，配置管理系统会生成一个全局唯一的版本来描述配置更改操作，该版本收录更改操作对应的配置文件更改详情。

　　配置发布时，各子系统会定期检测配置版本差异，将本地配置更新到最新版本，以保证每个更新周期内配置一致。

　　3 应对高并发压力

　　

　　*敏*感*词*的压力主要体现在 采集 Agent 的配置分发部分。由于代理只需要获取部署主机所需的监控配置，因此配置文件按照监控的最小单位进行拆分，按照规范打包。

　　图3 代理配置拆分&amp;下载流程

　　目前的业务部署往往采用混合分布的方式，多个不同类型的应用部署在同一台主机上。为了支持这种监控场景，部署在宿主机上的采集Agent会查找宿主机上部署的应用，并下载对应的多个应用配置。随着业务规模的增加，物理机数量增加，配置下载请求也呈指数级增长，因为配置存储的服务器端很容易达到性能瓶颈。采用横向扩展的静态文件下载服务，应对高并发下载压力，采用ETag方式检测文件是否发生变化，只传输变化的配置文件，减少下载流量，最终满足百万主机和千万实例的需求。配置交付要求。

　　4 快速​​从故障中恢复

　　考虑到配置在监控系统中的重要性，为了保证业务的可用性，需要为监控系统构建快速故障恢复机制。

　　同时，由于监控系统配置集中管理，随着系统的发展，配置量也在不断增加。配置文件的体积达到几十GB的级别，全部由小文件组成，文件数量达到百万级别。为了减轻系统压力，在系统中加入了“快照”机制，定期生成当前全配置的快照。当发生大量更新时，先使用“快照”减少更新量，然后通过相应的同步机制处理少量文件。更新。

　　总结

　　经过不断的努力和多次改造，目前的配置管理和分布已经可以满足监控系统的需要。因为可以灵活地管理多种配置并将它们快速一致地交付给每个系统。面对故障场景，也可以及时撤回配置，避免更大的损失。但是，随着监控服务的发展和系统架构的变化，起核心作用的配置管理和分发系统将面临新的挑战。任重而道远，我要上上下下一探究竟！

　　关于作者：

　　思进，百度高级研发工程师，负责百度智能运维（Noah）监控平台的设计与研发，在监控系统配置管理方面拥有丰富的实践经验。

　　本文转载自公众号AIOps智能运维（ID：AI_Ops）。

　　原文链接：