关于后端:SpringBoot健康检查如何与容器配合

监控的重要性就不用多说了吧，不要再花功夫开会讨论它的必要性了，当你线上遇到问题，就不会再狐疑监控是节约开发成本的建设。监控让人辞别了靠“猜”来维持的救火现状，它可能留下证据，来撑持咱们后续的剖析。
作为监控的首要指标，服务的存活性，也就是它的健康状况，成为了重中之重。SpringBoot能够通过简略的参数，来开启健康检查，并可能和支流的监控系统集成起来。

监控开启

在Spring中，是应用actuator组件，来做监控等相干操作。能够在pom中退出上面的starter：

<dependency>  <groupId>org.springframework.boot</groupId>  <artifactId>spring-boot-starter-actuator</artifactId></dependency>复制代码

对于gradle来说，退出上面这个。

dependencies {  compile("org.springframework.boot:spring-boot-starter-actuator")}复制代码

拜访/actuator/health，即可获取我的项目的健康状况。

{"status":"UP"}复制代码

在application.yml文件里，退出如下的内容：

management:  endpoint:    health:      show-details: always复制代码

再次拜访这个接口，将输入具体的内容。包含DB的状态、磁盘状态等。能够看到，最外层的status，其实是外部各个组件状态的汇合。

{    "status":"UP",    "components":{        "db":{            "status":"UP",            "details":{                "database":"H2",                "validationQuery":"isValid()"            }        },        "diskSpace":{            "status":"UP",            "details":{                "total":250685575168,                "free":31373905920,                "threshold":10485760,                "exists":true            }        },        "ping":{            "status":"UP"        }    }}复制代码

自定义Indicator

这些性能，是由Indicators来实现的（HealthIndicator）。比方上面这些：

DataSourceHealthIndicator
DiskSpaceHealthIndicator
CouchbaseHealthIndicator
MongoHealthIndicator
RedisHealthIndicator
CassandraHealthIndicator

如果你是用的是组件提供的starter，这些Indicator就会在/health接口进行聚合，如果你不想要监控某个组件，能够在配置中把它敞开。

management:  health:    mongo:      enabled: false复制代码

明确了这个情理，在做一些组件的时候时候，就能够通过这种形式，来提供组件自带的健康检查：只须要实现HealthIndicator接口就能够了。代码样例如下：

@Component@Slf4jpublic class X implements HealthIndicator {    @Override    public Health health() {        try {            //查看组件状态异样信息        } catch (Exception e) {            log.warn("Failed to connect to: {}", URL);            return Health.down()                    .withDetail("error", e.getMessage())                    .build();        }        return Health.up().build();    }}复制代码

接入监控零碎

更多状况，咱们是心愿把业务监控的数据，应用业余的监控组件收集起来。这个在SpringBoot中，能够应用micrometer来实现。

以最风行的prometheus为例，在pom里减少上面的内容。

<dependency>    <groupId>io.micrometer</groupId>    <artifactId>micrometer-registry-prometheus</artifactId></dependency>复制代码

当然，咱们也要在yaml里配置一些内容。它当初看起来长这个样子：

management:  endpoints:    web:      exposure:        include: health,info,prometheus  endpoint:    health:      show-details: always复制代码

这时候，拜访/actuator/prometheus，即可获取prometheus格局的监控数据。

相似于上面这种：

jvm_memory_used_bytes{area="heap",id="PS Survivor Space",} 0.0jvm_memory_used_bytes{area="heap",id="PS Old Gen",} 2.9444904E7jvm_memory_used_bytes{area="heap",id="PS Eden Space",} 6.829E7jvm_memory_used_bytes{area="nonheap",id="Metaspace",} 5.917196E7jvm_memory_used_bytes{area="nonheap",id="Code Cache",} 1.0929088E7jvm_memory_used_bytes{area="nonheap",id="Compressed Class Space",} 8420512.0复制代码

在prometheus的target页面，能够看到上面的信息：

最终在Grafana里，长的更加妖艳一些。

那它都能监控一些什么货色呢？咱们来看一下：

服务节点根本信息，包含内存CPU网络IO等
JVM堆栈信息
JVM GC信息，STW信息
默认HikariCP的连接池信息
HTTP申请接口信息（最大耗时，QPS最高）
Tomcat容器监控
Logback日志打印监控（各级别条数）
...其余

能够看到，只须要裸露这么一个接口，就能够对我的项目中的组件，进行比拟全面的掌控。

与容器配合

最初一点，因为SpringBoot服务，常常会公布到一些容器中，比方docker。这个时候，就要用到probes配置（kube有雷同的概念）。probes是探测的意思，用来辨别Liveness和Readiness两种状态。

最终的配置如下：

management:  health:    probes:      enabled: true  endpoints:    web:      exposure:        include: health,info,prometheus  endpoint:    health:      show-details: always复制代码

这时候，咱们将在浏览器的接口中获取两个分组，展现如下：

http://localhost:8080/actuator/health/liveness
http://localhost:8080/actuator/health/readiness

这两个链接，前者用于判断容器是否应该重启；后者判断服务是否可用，如果可用，将开始承受内部的申请。

End

对于规模比拟小的SpringBoot利用来说，应用SpringBootAdmin一类的监控，就曾经足够了。但如果你的企业是集中式部署，节点多且变动频繁，一个对立的监控建设平台是十分必要的。

除了Prometheus，SpringBoot的Metrics还反对以下组件：

AppOptics
Atlas
Datadog
Dynatrace
Elastic
Ganglia
Graphite
Humio
Influx
JMX
KairosDB
New Relic
Prometheus
SignalFx
Simple (in-memory)
Stackdriver
StatsD
Wavefront

你相熟的组件，有没有它的身影呢？
参考：《2020最新Java根底精讲视频教程和学习路线！》

链接：https://juejin.cn/post/690331...