csjukong 2019-04-12
Spring Boot Actuator通过/metrics端点,以开箱即用的方式为应用程序的性能指标与响应统计提供了一个非常友好的监控方式。
由于在集群化的弹性环境中,应用程序的节点可以增长、扩展,并由非常大量的应用实例所组成。对于孤立节点的监控可能即费力又没有什么实际效果。所以,使用基于时间序列的数据聚合工具将获得更好的效果。
本文的目标在于找出一种仅需要通过工具和配置的方式就能实现的解决方案,来对Spring Boot Metrics实现基于时间序列的监控。
像NewRelic, AppDynamics或DataDog这些APM系统都能很好地完成这样的任务,它们通过使用JVM和字节码工具来生成自己的指标、分析工具和相关事务。也可以通过使用@Timed注释方法来实现。但是,这些方法将忽略所有Spring Boot Actuator库所提供的可用资源。另外,使用这些方法还有一个与保留数据相关的问题,它们对于短时间窗口内的监控是相对模糊的。
NewRelic在1分钟时间窗口内被发现和检测的事务
spring-boot-admin 可以作为另外一个备选方案,因为它可以连接到Spring Boot的实例、并且可以聚合节点等。但是, /metrics 端点并不是根据时间轴来进行监控的,同时在不同节点上的相同应用模块(水平扩展)也没有得到聚合。这意味着您将面对这两种情况:没有时间序列的监控数据、只有对孤立节点的监控数据快照。
Spring Boot Admin with metrics from Actuator: a snapshot of metrics data of a given application node
Spring Boot Admin with JMX and MBeans read data of a give application node
jconsole和visualvm可能是另外一种选择,它们通过RMI直接连接到JMX节点。Actuator存储来自JMX的MBean内的Metrics数据。另外,通过使用 Jolokia,MBeans以RESTful HTTP端点的方式暴露,/jolokia。所以,相同的信息可以通过两个端点来获取:JMX MBean Metrics和Rest HTTP Jolokia端点。然而,这种方式存在同样的问题,它们直接连接到集群环境中的单个节点,另外还伴随着痛苦的老式RMI协议。
JConsole old-school JMX Metrics of a given application node
VisualVM JMX Metrics of a give application node
继续前进,我尝试了一些可能可以解决这些问题的现代化运维工具:
经过一番研究,我发现了一个更好的解决方案:通过InfluxDB 和Telegraf实现,零编码,只需要通过一些正确的配置。
简而言之,配置所有这些东西都非常的简单。
Spring Boot Actuator Raw Metrics
Metrics sent by Telegraf to InfluxDB, collected by Jolokia and JMX over HTTP
Grafana InfluxDB data source configuration