关于微服务:最佳实践|Spring-Boot-应用如何快速接入-Prometheus-监控

6次阅读

共计 6318 个字符,预计需要花费 16 分钟才能阅读完成。

简介:SpringBoot 微服务的开发、公布与部署只占其生命周期的一小部分,利用和零碎运维才是重中之重。而运维过程中,监控工作更是占据重要地位。那么,为了对系统的状态进行继续地观测,面向 Spring Boot 利用咱们该如何疾速实现 Prometheus 监控接入。本文为大家具体解说残缺接入流程与接入事项!

作者:凡星

对于开发者而言,大部分传统 SSM 构造的 MVC 利用背地的蹩脚体验都是来自于搭建我的项目时的大量配置,稍有不慎就可能踩坑。为了解决上述问题,Spring Boot 应运而生。正如其名,Spring Boot 的外围价值就是主动配置,只有存在相应 jar 包,Spring 能够主动配置。如果默认配置不能满足需要,还能够替换掉主动配置类,应用自定义配置,疾速构建企业级应用程序。

但构建 Spring Boot 利用只是第一步,随着利用上线之后,咱们又该如何进行监测?

基础知识及概念

首先,在正式解说前,先向大家解说本次分享所须要的基本知识和概念。一般来说,搭建一套残缺易用的监测零碎次要蕴含以下几个要害局部。

收集监测数据

目前,行业常见的收集监测数据形式次要分为推送(Push)和抓取(Pull)两个模式。以越来越广泛应用的 Prometheus 监测体系举例,Prometheus 就是以抓取(Pull)模式运行的典型零碎。利用及基础设施的监测数据以 OpenMetrics 标准接口的模式裸露给 Prometheus,由 Prometheus 进行定期抓取并长期存储。

这里简略介绍一下 OpenMetrics。作为云原生、高度可扩大的指标协定,OpenMetrics 定义了大规模上报云原生指标的事实标准,并反对文本示意协定和 Protocol Buffers 协定,文本示意协定在其中更为常见,也是在 Prometheus 进行数据抓取时默认采纳的协定。下图是一个基于 OpenMetrics 格局的指标示意格局样例。

指标的数据模型由指标 (Metric) 名,以及一组 key/value 标签(Label)定义的,具备雷同的度量名称以及标签属于雷同时序汇合。例如 acme_http_router_request_seconds_sum{path=”/api/v1″,method=”GET”} 能够示意指标名为 acme_http_router_request_seconds_sum,标签 method 值为 POST 的一次采样点数据。采样点内蕴含一个 float64 值和一个毫秒级的 UNIX 工夫戳。随着时间推移,这些收集起来的采样点数据将在图表上实时绘制动态变化的线条。

目前,对于云原生体系下的绝大多数根底组件,大多可能反对以下面提到的 OpenMetrics 的文本协定格局裸露指标,对于尚未可能反对本身裸露指标的组件,Prometheus 社区也存在极其丰富的 Prometheus Exporter 供开发及运维人员应用。这些组件(或 Exporter)通过响应来自 Prometheus 的定期抓取申请来及时地将本身的运行状况记录到 Prometheus 以便后续的解决及剖析。对于利用开发者,还能够通过 Prometheus 多语言 SDK,进行代码埋点,将本身的业务指标也接入到上述的 Prometheus 生态当中。

数据可视化及剖析

在获取利用或基础设施运行状态、资源应用状况,以及服务运行状态等直观信息后,通过查问和剖析多类型、多维度信息可能不便的对节点进行跟踪和比拟。同时,通过规范易用的可视化大盘去获知以后零碎的运行状态。比拟常见的解决方案就是 Grafana,作为开源社区中目前热度很高的数据可视化解决方案,Grafana 提供了丰盛的图表模式与模板。在阿里云 ARMS Prometheus 监控服务中,也基于 Grafana 向用户提供了全托管版的监测数据查问、剖析及可视化。

及时的告警和应急治理

当业务行将呈现故障时,监测零碎须要迅速反馈并告诉管理员,从而可能对问题进行疾速的解决或者提前预防问题的产生,避免出现对业务的影响。当问题产生后,管理员须要对问题进行认领和解决。通过对不同监测指标以及历史数据的剖析,可能找到并解决本源问题。

接入流程概览

接下来,咱们讲讲面向部署在 Kubernetes 集群上的 Spring Boot 微服务利用如何进行 Prometheus 接入。针对 Spring Boot 利用,社区提供了开箱即用的 Spring Boot Actuator 框架,不便 Java 开发者进行代码埋点和监测数据收集、输入。从 Spring Boot 2.0 开始,Actuator 将底层改为 Micrometer,提供了更强、更灵便的监测能力。Micrometer 是一个监测门面,能够类比成监测界的 Slf4j。借助 Micrometer,利用可能对接各种监测零碎,例如:AppOptics,Datadog,Elastic,InfluxDB 等,当然,也包含咱们明天所介绍的 Prometheus。

Micrometer 在将 Prometheus 指标对接到 Java 利用的指标时,反对利用开发者用三个类型的语义来映射:

MicroMeter 中的 Counter 对应于 Prometheus 中的 Counter,用来形容一个枯燥递增的变量,如某个接口的拜访次数,缓存命中 / 拜访总次数等。Timer 在逻辑上蕴含了 Counter,即如果应用 Timer 采集每个接口的响应工夫,必然也会采集拜访次数。故无需为某个接口同时指定 Timer 与 Counter 两个指标

MicroMeter 中的 Gauge 对应于 Prometheus 中的 Gauge,用来形容在一个范畴内继续稳定的变量,如 CPU 使用率,线程池工作队列数等。

MicroMeter 中的 Timer 对应于 Prometheus 中的 Histogram,用来形容与工夫相干的数据,如某个接口 RT 工夫散布等等。

Micrometer 中的 DistributionSummary 对应 Prometheus 中的 Summary,与 Histogram 相似,Summary 也是用于统计数据散布的,但因为数据的散布状况是在客户端计算实现后再传入 Prometheus 进行存储,因而 Summary 的后果无奈在多个机器之间进行数据聚合,无奈统计全局视图的数据分布,应用起来有肯定局限性。

当咱们须要把部署在 Kubernetes 集群中的 Spring Boot 利用接入到 Prometheus 时,须要依照代码埋点 -> 部署利用 -> 服务发现这个流程来进行。

首先,咱们须要在代码中引入 Spring Boot Actuator 相干 maven 依赖,并对咱们须要监测的数据进行注册,或对 Controller 内的办法打上响应的注解。

其次,咱们将埋点后的利用部署在 Kubernetes 中,并向 Prometheus 注册向利用拉取监测数据的端点(也就是 Prometheus 服务发现)。阿里云 Prometheus 服务提供了应用 ServiceMonitor CRD 进行服务发现的办法。

最初在指标利用的监测采集端点被 Prometheus 胜利发现后,咱们就能够开始在 Grafana 下面配置数据源及相应的大盘了。当然,咱们同时也须要依据某些要害指标进行对应的告警配置。这些需要在阿里云 Prometheus 监控服务都能很不便地满足。

接入流程详解

接下来,咱们进入实战演练环节,这里选取一个基于 Spring Boot & Spring Cloud Alibaba 构建的云原生微服务利用(https://github.com/aliyun/ali…)作为咱们革新的基线。

咱们最终目标是:

1、监测零碎的入口:Frontend 服务是一个基于 SpringMVC 开发的入口利用,承接内部的客户流量,咱们次要关注的是内部接口的要害 RED 指标(调用率 Rate,失败数 Error,申请耗时 Duration);

2、监测零碎的要害链路:对后端服务 critical path 上的对象进行监测,如线程池的队列状况、过程内 Guava Cache 缓存的命中状况;

3、对业务强相干的自定义指标(比方某个接口的 UV 等等);

4、对 JVM GC 及内存应用状况进行监测;

5、对上述指标进行对立汇聚展现、以及配置要害指标的告警。

第一步,引入 Spring Boot Actuator 依赖,进行初始配置

小标题

首先,咱们须要引入 Spring Boot Actuator 的相干依赖,在 application.properties 配置中裸露监测数据端口(这里定义为 8091)。胜利后,咱们即可拜访利用的 8091 端口的 /actuator/prometheus 门路拿到 OpenMetrics 规范的监测数据。

<!-- spring-boot-actuator 依赖 -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<!-- prometheus 依赖 -->
<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-registry-prometheus</artifactId>
</dependency>
# application.properties 增加以下配置用于裸露指标
spring.application.name=frontend

management.server.port=8091
management.endpoints.web.exposure.include=*
management.metrics.tags.application=${spring.application.name}

第二步,代码埋点及革新

为了获取某个 Api 接口的 RED 指标,咱们须要在对应的接口办法上打上面的 @Timed 注解。咱们以演示我的项目中的 index 页面接口为例。留神这里,@Timed 注解中的 value 即为裸露到 /actuator/prometheus 中的指标名字,histogram=true 示意咱们裸露这个接口申请时长的 histogram 直方图类型指标,便于咱们后续计算 P99,P90 等申请工夫散布状况。

@Timed(value = "main_page_request_duration", description = "Time taken to return main page", histogram = true)
@ApiOperation(value = "首页", tags = {"首页操作页面"})
@GetMapping("/")
public String index(Model model) {model.addAttribute("products", productDAO.getProductList());

    model.addAttribute("FRONTEND_APP_NAME", Application.APP_NAME);
    model.addAttribute("FRONTEND_SERVICE_TAG", Application.SERVICE_TAG);
    model.addAttribute("FRONTEND_IP", registration.getHost());

    model.addAttribute("PRODUCT_APP_NAME", PRODUCT_APP_NAME);
    model.addAttribute("PRODUCT_SERVICE_TAG", PRODUCT_SERVICE_TAG);
    model.addAttribute("PRODUCT_IP", PRODUCT_IP);

    model.addAttribute("new_version", StringUtils.isBlank(env));
    return "index.html";
}

如果咱们的利用中应用了过程内缓存库,比方最为常见的 Guava Cache 库等等。如果咱们想追踪过程内缓存的运行状况,咱们须要依照 Micrometer 提供的润饰办法,看待监测的要害对象进行封装。

Guava Cache 革新次要是四步骤,代码改变比拟小,很容易就能够接入:

1、注入 MeterRegistry,这里注入的具体实现是 PrometheusMeterRegistry,由 Spring Boot 自行注入即可

2、应用工具类 api,即图中展现的 GuavaCacheMetrics.monitor 包装一下本地缓存

3、开启缓存数据记录,即调用一下.recordStats()办法

4、减少一个名称,用于生成对应的指标。

线程池革新次要是三步骤,也并不是很简单:

1、注入 MeterRegistry,这里注入的具体实现是 PrometheusMeterRegistry;

2、应用工具类 api 包装一下线程池;

3、减少一个名称,用于生成对应的指标。

当然,咱们在开发过程中肯定还有许多业务强相干的自定义指标,为了监测这些指标,咱们在向 Bean 中注入 MeterRegistry 后,须要依照咱们的需要和对应场景结构 Counter,Gauge 或 Timer(这些类型的区别和应用场景上文有提到)来进行数据统计,并将其注册到 MeterRegistry 进行指标裸露,上面是一个简略的例子。

@Service
public class DemoService {

    Counter visitCounter;

    public DemoService(MeterRegistry registry) {visitCounter = Counter.builder("visit_counter")
            .description("Number of visits to the site")
            .register(registry);
    }

    public String visit() {visitCounter.increment();
        return "Hello World!";
    }    
}

至此,咱们的利用代码革新工作到这里就全副实现了,下一步工作就是将利用镜像从新构建并重新部署到已装置 ARMS Prometheus 的 Kubernetes 集群中。之后,咱们 ARMS Prometheus 控制台中配置 ServiceMonitor,进行服务发现。

增加好 ServiceMonitor 后,咱们能够在 Targets 列表中看到刚注册的利用 Service。

第三步,看板配置

利用的监测数据已胜利收集并存储到 ARMS Prometheus。接下来,也是最要害的一步,就是依据这些数据,配置相应的大盘及告警。这里,咱们借助 Grafana 社区中开源大盘模板来构建咱们本人的业务监测模板。次要基于以下两个模板:

Spring Boot 2.1 Statistics:
https://grafana.com/grafana/d…

JVM (Micrometer):
https://grafana.com/grafana/d…

借助这些模板以及 ARMS Prometheus 内置的 Grafana 服务,咱们能够很不便地将日常开发和运维过程中十分关怀的指标组织在一张的 Grafana Dashboard 上。这里给大家抛砖引玉一下,放一张咱们外部基于上述模板和本身业务构建的一个实在的大盘。这外面蕴含了一些总览,比方组件运行工夫,内存使用率等等,也有一些细节指标,如堆内堆外内存,分代 GC 状况等等,还有像接口申请的 RED 等等,这里就不过多赘述了,大家能够充分发挥本人的想象力来发明举世无双的酷炫大盘~


原文链接
本文为阿里云原创内容,未经容许不得转载。

正文完
 0