1、
/metrics
接口提供的信息进行简单分类如下表:
分类 | 前缀 | 报告内容 |
---|---|---|
垃圾收集器 | gc.* | 已经发生过的垃圾收集次数,以及垃圾收集所耗费的时间,适用于标记-清理垃圾收集器和并行垃圾收集器(数据源自java.lang.management. GarbageCollectorMXBean) |
内存 | mem.* | 分配给应用程序的内存数量和空闲的内存数量(数据源自java.lang. Runtime) |
堆 | heap.* | 当前内存用量(数据源自java.lang.management.MemoryUsage) |
类加载器 | classes.* | JVM类加载器加载与卸载的类的数量(数据源自java.lang. management.ClassLoadingMXBean) |
系统 | processors、instance.uptime、uptime、systemload.average | 系统信息,例如处理器数量(数据源自java.lang.Runtime)、运行时间(数据源自java.lang.management.RuntimeMXBean)、平均负载(数据源自java.lang.management.OperatingSystemMXBean) |
线程池 | thread.* | 线程、守护线程的数量,以及JVM启动后的线程数量峰值(数据源自 java.lang .management.ThreadMXBean) |
数据源 | datasource.* | 数据源连接的数量(源自数据源的元数据,仅当Spring应用程序上下文里存在 DataSource Bean 的时候才会有这个信息) |
Tomcat 会话 | httpsessions.* | Tomcat的活跃会话数和最大会话数(数据源自嵌入式Tomcat的Bean,仅在使用嵌入式Tomcat服务器运行应用程序时才有这个信息) |
HTTP | counter.status._、gauge.response._ | 多种应用程序服务HTTP请求的度量值与计数器 |
对数据源的监控:
数据源指标
-
Spring Boot会为你应用中定义的支持的DataSource暴露以下指标:
最大连接数(datasource.xxx.max)
最小连接数(datasource.xxx.min)
活动连接数(datasource.xxx.active)
连接池的使用情况(datasource.xxx.usage) -
所有的数据源指标共用 datasoure. 前缀。该前缀对每个数据源都非常合适:
如果是主数据源(唯一可用的数据源或存在的数据源中被@Primary标记的)前缀为datasource.primary
如果数据源bean名称以dataSource结尾,那前缀就是bean的名称去掉dataSource的部分(例如,batchDataSource的前缀是datasource.batch)
其他情况使用bean的名称作为前缀 -
通过注册一个自定义版本的DataSourcePublicMetrics bean,你可以覆盖部分或全部的默认行为。默认情况下,Spring Boot提供支持所有数据源的元数据;如果你喜欢的数据源恰好不被支持,你可以添加另外的DataSourcePoolMetadataProvider beans。具体参考DataSourcePoolMetadataProvidersConfiguration。
2、
三、总结
以上四种监控手段都与Spring boot无缝集成,使用方便快捷,并且可以对微服务有一个全面的健康体检,包括动态和静态信息,但是在纵向上没有时间序列上的监控数据,只是对孤立节点的监控数据快照;在横向上同一节点下不同实例(水平扩展)没有得到聚合,没有对不同节点实例进行比较分析的过程。所以,下一步的微服务监控应该怎么做?
- 基于Prometheus
Prometheus是一套开源的监控&报警&时间序列数据库的组合,起始是由SoundCloud公司开发的,工作原理:定时去目标上抓取 metrics(指标) 数据,经过分析处理,基于Grafana实现数据可视化。
- 优化Ui展示
整合应用下所有实例节点,将各节点实例的监控信息做横向比较分析,通过Ui进行展示。
- 告警系统
目前的监控信息的获取都是通过客户触发的,没有一个自动报警机制,如果服务异常时,监控平台检测到异常,产生实施报警,那我们的监控工作真的可以高枕无忧了