SpringBoot 监控各工具分析
方案一:Spring Boot Admin
Spring Boot Admin是一个开源社区项目,用于管理和监控SpringBoot应用程序,依赖spring boot actuator。可通过注册中心与admin-client两种方式使用。
优点:
- 比较美观的可视化界面,能够监控CPU、线程、内存、性能、类、JVM线程、缓存、配置属性、依赖关系等使用情况。
- 容易集成,仅需启动一个spring boot admin 工程加入到注册中心即可(支持consul,eureka,zookeeper等注册中心)。
缺点:
- 没有提供可配置的告警功能(需要自己去实现)。实现链接:https://www.cnblogs.com/jmcui/p/11025819.html
文档地址:https://codecentric.github.io/spring-boot-admin/2.2.1/
总结:轻量级监控,监控指标较为全面,对业务代码无影响。

方案二:Premetheus
Prometheus是最初在SoundCloud上构建的开源系统监视和警报工具包,依赖spring boot actuator。
主要通过服务提供接口,prometheus主动请求获取监控信息。
优点:
- 提供多维度数据模型和灵活的查询方式,通过将监控指标关联多个tag,来将监控数据进行任意维度的组合,并且提供简单的PromQL查询方式,还提供HTTP查询接口,可以很方便地结合Grafana等GUI组件展示数据
- 在不依赖外部存储的情况下,支持服务器节点的本地存储,通过Prometheus自带的时序数据库,可以完成每秒千万级的数据存储;不仅如此,在保存大量历史数据的场景中,Prometheus可以对接第三方时序数据库和OpenTSDB、influxDB、ES等。
- 定义了开放指标数据标准,以基于HTTP的Pull方式采集时序数据,只有实现了Prometheus监控数据才可以被Prometheus采集、汇总、并支持Push方式向中间网关推送时序列数据,能更加灵活地应对多种监控场景
- 支持通过静态文件配置和动态发现机制发现监控对象,自动完成数据采集。Prometheus目前已经支持Kubernetes、etcd、Consul等多种服务发现机制
- 易于维护,可以通过二进制文件直接启动,并且提供了容器化部署镜像。
- 支持数据的分区采样和联邦部署,支持大规模集群监控
缺点:
- prometheus 需要通过pull方式获取数据,需要保证prometheus的网络可达到所有监控节点。
- prometheus eureka中需要添加consul适配器去发现服务(consul不需要)。
文档地址:https://prometheus.io/docs/prometheus/latest/getting_started/
方案三:Cat
CAT 作为服务端项目基础组件,提供了 Java, C/C++, Node.js, Python, Go 等多语言客户端,为美团点评各业务线提供系统丰富的性能指标、健康状况、实时告警等。
优点:
- 多语言支持,在美团点评的基础架构中间件框架(MVC框架,RPC框架,数据库框架,缓存框架等,消息队列,配置系统等)深度集成。
- 秒级的数据传输与处理,分钟级的报表监控,提供监控数据是全量统计,客户端预计算;链路数据是采样计算。
缺点:
- 对于资源要求较高,分布式服务端每台设备需要给服务提供10G以上内存资源。
- 项目架构依然是传统的spring webapp架构。
总结:适合微服务量级较高的平台。
方案四:Zipkin
Zipkin是一个分布式跟踪系统。它有助于收集解决服务体系结构中的延迟问题所需的时序数据。功能包括该数据的收集和查找。如果日志文件中有跟踪ID,则可以直接跳至该跟踪ID。
主要通过拦截请求实现,并将数据发送至zipkin服务端。
优点:
- 能够追踪到服务每次请求的情况,包括http.method,http.path,服务开始请求时间,服务结束请求时间,请求服务地址等,适合全链路服务响应时间监控。
- 拥有友好的服务调用图可以直观查看服务调用过程。
缺点:
- 监控粒度较粗,仅监控到服务层面。
- 未提供告警功能。
总结:适用于服务接口耗时监控。
方案五:Pinpoint
基于Google dapper思想产生。
Pinpoint是用于用Java / PHP编写的大规模分布式系统的APM(应用程序性能管理)工具。受Dapper的启发,Pinpoint提供了一种解决方案,可通过跟踪跨分布式应用程序的事务来帮助分析系统的整体结构以及其中的组件如何互连。
优点:
- Java 探针技术,非侵入式:使用字节码增强技术,添加新功能无需修改代码。
- 提供直观的服务调用拓扑图,能够清晰看到服务调用的整个流程(从用户访问到数据库)。
- 代码跟踪,实时监控程序的状况,能够监控JVM,CPU等指标。
- 客户端仅安装apm代理即可,无需修改代码,对性能影响最小(资源使用量增加约3%)。
缺点:
- 部署相对复杂,依赖hbase,mysql等组件。
- 客户端机器需要安装agent。
- 没有提供告警功能,需要自行拓展。
方案六:Skywalking (待完成)
方案七:TICK (telegraf,InfluxDB,Chronograf,Kapacitor)
Telegraf 是一个数据收集和入库的工具。提供了很多 input 和 output 插件,比如收集本地的 cpu、load、网络流量等数据,然后写入 InfluxDB 、Kafka或者OpenTSDB等。相当于ELK栈中的 logstash 功能。
InfluxDB 是一个开源的GO语言为基础的数据库, 用来处理时间序列数据,提供了较高的可用性。与opentsdb类似,支持HTTP API方式,写入和读取数据。相当于ELK栈中的elasticsearch功能。
Chronograf 从InfluxDB时间序列数据的数据可视化工具,负责从InfluxDB收集数据,并将数据图表以web的形式发布。它使用简单,包括模板和库可以快速构建实时数据的可视化仪表板,轻松地创建报警和自动化的规则。相当于ELK栈中的kibana功能。
Kapacitor是InfluxDB的数据处理引擎,主要作用是时间序列数据处理、监视和警报。
方案八:Graphite
Graphite是高度可扩展的实时图形系统。作为用户,您编写了一个应用程序,该应用程序收集您对制图感兴趣的数字时间序列数据,然后将其发送到Graphite的处理后端carbon,后者将数据存储在Graphite的专用数据库中。然后可以通过石墨的网络界面将数据可视化。
优点:
- 能够水平拓展。
- 高性能,大容量。
缺点:
- 未与Spring做集成,需要通过actuator自己实现。
原创声明
平台文章均为原创文章,未经许可,禁止转载。
如需转载,请联系作者获取授权,并注明来源及原文链接。