Post

Micrometer打造SpringBoot服务的可观测能力

可观测性(Observability)是一种帮助我们了解系统内部状态的方法,尤其是在系统出现问题时。想象一下,应用程序就像一台机器,而可观测性就是这台机器上的各种“仪表盘”,通过这些仪表盘,我们可以看到它是否运行正常,哪里出现了问题。

一、 引言

可观测性(Observability)是一种帮助我们了解系统内部状态的方法,尤其是在系统出现问题时。想象一下,应用程序就像一台机器,而可观测性就是这台机器上的各种“仪表盘”,通过这些仪表盘,我们可以看到它是否运行正常,哪里出现了问题。

更具体地说,可观测性通过三类主要数据来帮助我们:

1
2
3
1.	指标(Metrics):这些是系统的关键数字,例如 CPU 使用率、内存消耗、响应时间、请求数等,就像汽车仪表盘上的速度表或油量表,帮助我们了解系统的运行状况。
2.	日志(Logs):这些是系统的“日记”,记录着系统中发生的每一件事。日志可以告诉我们什么时候发生了什么问题,为什么会出现错误。
3.	追踪(Traces):这就像跟踪一封快递的路线,在微服务架构中,它帮助我们追踪一个请求从头到尾经过了哪些服务,哪里出现了延迟或故障。

通过收集和分析这些数据,我们可以更快地找到系统中的问题,并提高系统的性能和可靠性。总结一下,可观测性就是帮助我们看见系统内部发生了什么,尤其是在出现问题时能迅速找到根源。

1.1 监控和可观测性区别

监控 和 可观测性 都是用来了解系统运行状态的工具,但它们的作用和深度不太一样,可以用一个生活中的例子来说明它们的区别。 监控: 监控就像给你的汽车装了一个基本的仪表盘,告诉你一些关键的数据,比如车速、油量、水温等。这些数据很有用,可以让你知道车子是否在正常工作。如果车速过快了或者油量低了,你就知道需要注意。但监控通常是提前设定好的,你只能看到固定的几项数据,无法更深入地了解问题的具体原因。 特点:

  • 预设的指标:比如系统的 CPU 使用率、内存占用、响应时间等,都是事先定义好的。
  • 告警:当这些关键指标超过了阈值,系统就会发出告警,比如服务器响应时间超过 1 秒,CPU 使用率超过 90%。
  • 局限性:如果出现了问题,监控可能只会告诉你“出问题了”,但不能帮你深入分析问题的根源。

可观测性: 可观测性就像是在汽车上安装了一套更高级的系统,它不仅显示车速和油量,还可以告诉你引擎内部发生了什么、各个部件的详细状态。如果车子出现问题,你不仅知道哪里出错了,还能通过它的“内部透视”来找出问题的具体原因,并进行快速修复。 特点:

  • 不仅仅是指标:除了基础的监控指标,可观测性还包括日志和追踪,可以更细致地了解系统中每个部分的运行情况。
  • 深入分析:当问题发生时,可观测性不仅告诉你有问题,还能帮你分析为什么出问题,比如某个服务响应时间变慢,是因为某个依赖服务卡住了。
  • 灵活性:不像监控需要提前设定什么数据要看,可观测性可以让你根据需要动态地观察系统内部状态。

在微服务架构中,可观测性就像是拥有一张系统的“地图”和“放大镜”,它让我们不仅能看清楚系统各个部分是怎么运作的,还能在问题发生时迅速找到原因。这在微服务架构中尤其重要,因为系统变得更加复杂,不再是一个单一的大应用,而是由很多小服务组成的。

1.2 为什么可观测性在微服务架构中很重要?

  1. 系统复杂度增加 微服务架构把一个大系统拆成很多独立的小服务,每个服务负责一个特定的功能。虽然这样可以让每个部分独立更新、扩展和维护,但也带来了新的挑战。比如:
  • 每个服务之间要通过网络通信,如果某个服务出问题,可能会影响其他服务。
  • 服务之间的依赖关系复杂,问题可能源自某个不起眼的服务,导致整个系统出现异常。

在这种情况下,可观测性就相当于给你一张全景地图,让你能看到这些小服务是如何相互联系的,出现问题时,能够快速找到哪个环节出了问题。

  1. 问题排查更加困难

在传统的单体架构中,所有功能都在一个应用程序里运行,出问题时,通常可以通过查看日志或监控几个关键指标来找到问题。然而在微服务架构中,问题可能隐藏在多个服务的交互中,比如:

  • 一个服务响应慢了,其他依赖它的服务也会受到影响。
  • 某个服务偶尔出错,但它并不直接影响用户,直到某个关键时刻导致故障。

可观测性通过追踪(Tracing)技术,帮助你跟踪每一个请求在多个服务中的流动轨迹。如果请求在某个服务中变慢或出错,你能清楚地看到是哪个服务的问题,像一条线索一样追踪到源头。

  1. 实时监控,快速响应

微服务架构通常需要在生产环境中不断更新和扩展服务,可能每天都会有新功能上线。在这种动态的环境中,服务的健康状况和性能可能会发生变化,甚至突然出现故障。可观测性提供了实时的监控和告警,当某个服务性能下降或者出现异常时,系统会自动发出告警,帮助开发者快速响应,减少故障带来的损失。

  1. 性能优化与扩展

可观测性不仅用于发现问题,还能帮助优化系统性能。通过监控系统中的各种指标(如请求处理时间、数据库查询时间等),可以识别出哪些服务存在性能瓶颈,哪些服务需要扩展(比如增加更多实例以应对更高的负载)。

二、Spring Boot 与可观测性

在 Spring Boot 中,常见的可观测性组成部分可以帮助我们更好地监控和了解应用的运行状况,尤其是当出现问题时,能迅速定位问题的根源。这些组成部分就像是一个综合的“体检报告”,从不同方面展示系统的健康状况。主要包括指标(Metrics)、日志(Logs) 和 追踪(Traces),每一部分都有不同的作用。

2.1 指标(Metrics)

指标是系统中关键数值的集合,用来监控应用的整体健康状况和性能。这些数值就像汽车仪表盘上的各种读数,帮助我们实时了解系统的工作情况。

  • 常见的指标:
  • CPU 使用率:应用程序使用了多少处理器资源。
  • 内存使用量:应用占用了多少内存。
  • 请求数量:某个时间段内接收到多少次请求。
  • 响应时间:每个请求的处理时间,尤其是查看是否有延迟过长的请求。

在 Spring Boot 中,通常通过 Micrometer 这个工具来收集和记录这些指标。然后可以把这些指标发送给 Prometheus 等监控系统,用图表展示出来,帮助你发现应用中的瓶颈或异常。

2.2 日志(Logs)

日志就是应用程序运行过程中记录的“日记”,详细记录了系统执行的每个操作和发生的事件。日志可以告诉你每个请求的具体细节,比如谁请求了什么,什么时候请求的,发生了什么问题等。

  • 常见的日志内容:
  • 请求日志:记录每个 HTTP 请求的详细信息,比如请求的路径、方法、状态码等。
  • 错误日志:当系统发生错误时,日志会记录具体的错误信息,比如数据库连接失败或者某个服务超时。
  • 调试日志:开发者为了排查问题,可能会记录一些程序运行中的详细信息,帮助分析问题。

Spring Boot 默认使用 Logback 作为日志框架,开发者可以根据需求调整日志的级别(INFO, DEBUG, ERROR 等),并可以将日志集中到 ELK(Elasticsearch, Logstash, Kibana) 或 Loki 等系统中进行统一管理和分析。

2.3 追踪(Traces)

追踪是一种用来监控和分析请求在系统中流转路径的工具,尤其是在微服务架构中非常重要。它帮助你了解一个请求从进入系统到返回结果的整个流程,特别是当请求需要经过多个服务时。

  • 分布式追踪的作用:
  • 查看请求的全流程:当一个请求需要经过多个服务,追踪可以让你看到这个请求在每个服务中的处理时间。
  • 定位瓶颈:如果某个服务处理请求的时间过长,追踪可以帮助你找到是哪个服务导致了延迟,从而优化性能。

Spring Boot 可以通过 Spring Cloud Sleuth 来实现分布式追踪,并与 Zipkin 或 Jaeger 集成,来收集和展示这些追踪数据。它们可以帮助你可视化整个请求链,清楚了解请求在哪个环节耗时最多。

2.4 健康检查(Health Checks)

除了上面提到的核心可观测性工具,Spring Boot 还提供了 健康检查 功能。它让你可以随时检查应用的状态,确定服务是否正常运行。通过 Spring Boot 的 Actuator,你可以配置健康检查接口,查看数据库连接、磁盘空间、消息队列等资源的健康状况。

  • 常见的健康检查内容:
    • 数据库连接是否可用。
    • 依赖的外部服务(如 Redis, RabbitMQ)是否正常。
    • 应用的运行环境是否有足够的资源(如磁盘空间、内存)。

三、 指标收集:Spring Boot 与 Micrometer

Micrometer 是一个用于收集和管理应用程序性能指标的工具,特别适合和 Spring Boot 一起使用。简单来说,它就像是一个万能适配器,可以帮助你把应用的关键数据(比如请求次数、响应时间、错误率等)以标准化的方式记录下来,并将这些数据发送到不同的监控系统,比如 Prometheus、Datadog、New Relic 等。

3.1 通俗解释 Micrometer

假设你的应用程序是一台机器,你想知道它的各项性能指标,比如它运转得有多快,哪里可能出问题。这时候你需要一些“传感器”来实时收集这些信息,比如计数器、计量器等,Micrometer 就是这样一个工具,它可以放在你的应用里,自动帮你收集各种重要的性能数据。

而且,Micrometer 不仅仅自己收集数据,它还能够连接到多种不同的监控平台。这就像是你有一个中央数据收集器,不管你想把数据发送到 Prometheus、Datadog 还是其他监控平台,Micrometer 都可以帮你做好连接和数据格式转换。

3.2 Micrometer 的工作原理

Micrometer 就是把应用的各种运行数据标准化,然后用这些数据生成不同类型的指标,比如:

  • 计数器(Counter):记录某件事情发生了多少次,比如一共收到了多少次 HTTP 请求。
  • 计量器(Gauge):记录一个值的当前状态,比如系统当前占用了多少内存。
  • 定时器(Timer):测量某个操作花费了多长时间,比如处理一次请求的时间。

然后,Micrometer 会把这些数据统一格式化,可以发到你使用的监控系统,比如 Prometheus(用于存储和分析时间序列数据),或者 Datadog(提供全面的监控和告警服务)。

3.3 Micrometer 的优点

  1. 多种监控平台支持:Micrometer 支持 Prometheus、Datadog、New Relic、Graphite 等主流监控平台,这样无论你用什么工具来监控应用,Micrometer 都能帮你把数据接入进去。
  2. Spring Boot 的无缝集成:Micrometer 与 Spring Boot 集成得非常好,你只需要做一些简单的配置,就可以自动收集应用的关键指标,比如 HTTP 请求的数量、处理时间、数据库查询次数等。
  3. 统一的 API:你只需要用 Micrometer 的 API 来收集数据,不用为每个监控系统写不同的代码。Micrometer 会自动帮你转换成不同平台需要的数据格式。

3.4 如何使用 Micrometer 集成 Prometheus

• 步骤一:引入 Micrometer 依赖

1
2
3
4
5
6
7
8
<dependency>
	<groupId>io.micrometer</groupId>
	<artifactId>micrometer-core</artifactId>
</dependency>
<dependency>
	<groupId>io.micrometer</groupId>
	<artifactId>micrometer-registry-prometheus</artifactId>
</dependency>
  • 步骤二:配置 Prometheus 的指标端点
    1
    2
    
    management.endpoints.web.exposure.include=prometheus
    management.metrics.export.prometheus.enabled=true
    

步骤三:通过 Micrometer 采集常见的指标,如 JVM 内存使用情况、HTTP 请求计数、延迟等。

  • 自定义指标:如何使用 Micrometer 创建自定义的 Counter、Gauge 或 Timer。
1
2
3
4
5
6
7
@Autowired
private MeterRegistry meterRegistry;

public void trackCustomMetric() {
    Counter counter = meterRegistry.counter("custom.metric.counter");
    counter.increment();
}

步骤四:启动应用后,访问指标: 启动应用后,你可以通过 http://localhost:8080/actuator/prometheus 来查看应用收集的所有指标数据。Prometheus 可以通过这个 URL 来定期抓取数据。

四、日志管理:集中化与结构化日志

在 Spring Boot 中,日志记录是了解应用程序运行情况的重要方式。为了更方便地记录和管理日志,Spring Boot 默认使用了 Logback 作为日志框架,同时结合 SLF4J 作为日志的接口。下面我们来通俗解释一下这两者是什么,它们如何协同工作。

4.1 什么是 Logback?

Logback 是一个非常强大且灵活的日志框架,它能够帮你把应用运行时的各种消息、错误、警告等信息记录下来,比如:

  • 系统启动日志。
  • 每次用户请求的详细信息。
  • 程序运行中的错误信息。

这些日志信息可以帮你排查问题、监控应用的健康状况,甚至可以作为未来系统优化的依据。

Logback 的特点是:

  • 高性能:Logback 非常高效,能快速记录大量日志信息,不会影响应用的性能。
  • 灵活配置:你可以控制日志输出的格式、保存位置(比如文件或控制台),还能根据不同的日志级别(如 DEBUG、INFO、ERROR)来控制输出哪些信息。
  • 日志轮转:Logback 可以自动根据时间或日志文件大小,把日志分成多个文件保存,避免日志文件过大而难以管理。

4.2 什么是 SLF4J?

SLF4J(Simple Logging Facade for Java)是一个日志门面,它本身并不记录日志,而是为各种日志框架(比如 Logback、Log4j 等)提供一个统一的接口。你可以把它理解为一座“桥梁”,程序只需要调用 SLF4J 提供的接口,无需关心具体使用哪个日志框架。SLF4J 会把日志请求转发给真正的日志框架来处理。

举个例子:

  • 当你的应用代码中调用 logger.info(“用户请求开始”) 时,SLF4J 会把这个日志请求转交给 Logback(或者其他你配置的日志框架)去实际记录。

SLF4J 的好处是:

  • 灵活性:如果你想从 Logback 切换到其他日志框架(比如 Log4j),只需要修改配置而不需要改动代码,因为 SLF4J 是统一的接口。
  • 更简洁的日志代码:SLF4J 提供的 API 非常简洁,减少了日志代码的复杂度。

4.3 Logback 和 SLF4J 的协同工作

在 Spring Boot 中,SLF4J 和 Logback 是默认搭配使用的。具体来说:

  • SLF4J 作为日志接口,开发者只需要通过 SLF4J 来编写日志代码。
  • Logback 作为日志实现框架,负责实际的日志记录、管理和输出。

这就像在一家餐厅,SLF4J 是服务员,负责接收顾客(开发者)的点餐(日志请求);而 Logback 是厨师,负责真正做菜(记录日志)。顾客(开发者)只需要和服务员(SLF4J)打交道,不需要直接和厨师(Logback)沟通。

4.4 日志输出的最佳实践

1
2
3
4
5
6
7
8
9
10
11
12
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class MyApp {
    private static final Logger logger = LoggerFactory.getLogger(MyApp.class);

    public void start() {
        logger.info("应用启动了");
        logger.debug("调试信息");
        logger.error("发生了错误", new RuntimeException("异常"));
    }
}
  • logger.info() 会记录普通的信息日志。
  • logger.debug() 用于记录调试信息,只会在调试模式下输出。
  • logger.error() 用于记录错误信息,通常还会伴随异常的详细信息。

你可以通过 application.properties 或 logback.xml 来配置 Logback,控制日志的输出格式、日志级别和输出目标。例如:

  • 把日志输出到文件,而不仅仅是控制台。
  • 设置只记录 ERROR 级别以上的日志,减少不必要的日志量。
  • 自动压缩和归档旧的日志文件。

集中式日志管理 阿里云的 SLS(日志服务,Simple Log Service) 是阿里云提供的一种集中式日志管理服务,帮助开发者和运维人员快速、便捷地收集、存储、查询和分析日志数据。它可以自动化地处理应用和系统的日志,提供实时分析和告警功能,在分布式环境中特别有用。SLS 是一种全托管的云日志解决方案,与 ELK 或 Loki 等开源方案不同,它可以省去复杂的运维和配置工作,提供即开即用的日志管理能力。

五、分布式追踪:Spring Boot 与 Zipkin/Jaeger

5.1 什么是分布式追踪?

分布式追踪是用来追踪和分析一个请求在多个服务之间的流转过程的工具,特别是在微服务架构中非常重要。想象一下,你的应用程序不再是一个大块头,而是由多个小服务组成,每个服务负责一个特定的功能。当一个用户发起请求时,这个请求会经过多个服务处理,最终返回结果。如果其中某个服务处理得比较慢,或者出了问题,你需要知道到底是哪个服务导致的,这就是分布式追踪的作用。

分布式追踪是如何工作的?

  1. 生成 Trace ID:当一个用户请求进入系统时,分布式追踪工具会为这个请求分配一个唯一的 Trace ID,这个 ID 会在请求流转的整个过程中一直携带,帮助系统识别这是同一个请求。
  2. 生成 Span:每当请求经过一个服务时,系统会生成一个 Span,代表这个服务的执行过程。Span 记录了这个服务的开始时间、结束时间以及执行的细节。
  3. Trace 和 Span 组合:Trace ID 是整个请求的唯一标识,而每个 Span 记录了某个服务的具体执行过程。通过组合多个 Span,我们就能清楚地看到整个请求的完整路径。

常用的分布式追踪工具:

  1. Zipkin:一个开源的分布式追踪系统,帮助你收集、存储和查询跟踪数据。
  2. Jaeger:也是一个开源的分布式追踪系统,由 Uber 开发,特别适合用于微服务架构中的性能监控和问题排查。
  3. OpenTelemetry:是一个更通用的标准,用于收集跟踪数据,可以与不同的分布式追踪工具一起使用。

5.2 集成 Zipkin 或 Jaeger

  • 依赖引入: ```xml
org.springframework.cloud spring-cloud-starter-zipkin
1
2
3
4
配置追踪:
你需要一个 Zipkin 服务器来接收和存储追踪数据。可以通过 Docker 运行 Zipkin:
```bash
docker run -d -p 9411:9411 openzipkin/zipkin

在你的 application.properties 文件中配置 Zipkin 的 URL,让 Spring Boot 把追踪数据发送给 Zipkin:

1
2
3
4
5
6
spring:
  zipkin:
    base-url: http://localhost:9411/
  sleuth:
    sampler:
      probability: 1.0

启动你的 Spring Boot 应用,访问几个 API,然后你可以打开 Zipkin 的 Web UI(http://localhost:9411),查看请求的追踪数据。你会看到每个请求是如何流转的,经过了哪些服务,每个服务花了多少时间。

六、Prometheus:Spring Boot 的监控利器

6.1 Prometheus 概述

Prometheus 和 Grafana 是两个常用的开源工具,通常搭配使用来监控和可视化系统的性能和健康状态。它们在一起工作就像是一对超级搭档:Prometheus 负责收集和存储系统的指标数据,而 Grafana 帮助你把这些数据展示成漂亮的图表和仪表盘,让你可以轻松监控和分析系统的运行情况。

Prometheus 和 Grafana 是如何一起工作的?

  1. Prometheus 收集数据: Prometheus 定期从你配置的服务或应用中抓取指标数据(比如每 15 秒获取一次 CPU 使用率或内存消耗),并把这些数据按时间存储起来。
  2. Grafana 可视化数据: 你可以把 Grafana 连接到 Prometheus 作为数据源,然后通过 Grafana 创建各种图表,展示 Prometheus 中的数据。例如,你可以在仪表盘上实时看到 CPU 使用率的变化趋势,或者某个服务的请求处理时间。
  3. 实时监控与告警: 如果某些关键指标出现问题,比如服务器负载突然激增,你可以通过 Grafana 直观地看到问题,甚至可以配置告警系统,在指标异常时第一时间发出通知。

Prometheus 的集成与配置

如何通过 Prometheus 抓取 Spring Boot 应用的 /actuator/prometheus 端点数据。

  • Prometheus scrape 配置示例: ```yaml scrape_configs:
    • job_name: ‘springboot-app’ static_configs:
      • targets: [‘localhost:8080’] ```

Prometheus + Grafana:可视化应用指标

  • 如何将 Prometheus 数据导入到 Grafana,并创建自定义仪表盘,实时监控应用的健康状态。

  • 关键指标监控:响应时间(latency)、请求数、错误率等。

七、 可观测性最佳实践

采集什么样的指标?

  • CPU、内存、请求数、错误率等基础指标。

  • 数据库连接池、缓存命中率等应用相关指标。

如何平衡可观测性与系统性能?

  • 适当的采样率设置:避免对系统性能产生过多开销。

  • 限制日志的存储时间和日志级别,避免产生大量冗余数据。

步骤 1:引入 Micrometer 和 Prometheus 进行基础指标采集

Spring Boot 提供了与 Micrometer 的集成,Micrometer 是一个可以采集指标并与各种监控系统(如 Prometheus)集成的库。通过它,我们可以轻松收集系统的 CPU、内存、请求数等基础指标。

1.1 在 pom.xml 中引入相关依赖:

1
2
3
4
5
6
7
8
9
10
11
12
<dependencies>
    <!-- Micrometer Prometheus Integration -->
    <dependency>
        <groupId>io.micrometer</groupId>
        <artifactId>micrometer-registry-prometheus</artifactId>
    </dependency>
    <!-- Spring Boot Actuator for exposing metrics -->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-actuator</artifactId>
    </dependency>
</dependencies>

1.2 配置应用暴露 Prometheus 端点

在 application.properties 或 application.yml 文件中,启用 Prometheus 端点并限制只暴露必要的端点:

1
2
3
4
5
6
7
8
9
management:
  endpoints:
    web:
      exposure:
        include: prometheus,health
  metrics:
    export:
      prometheus:
        enabled: true

这个配置确保我们通过 /actuator/prometheus 端点暴露 Prometheus 格式的监控数据。

步骤 2:采集关键的基础指标(CPU、内存、请求数、错误率等)

Spring Boot Actuator 已经提供了许多基础指标,下面是自动采集的指标:

1
2
3
•	CPU 使用率
•	内存使用情况
•	HTTP 请求数 和 错误率

Actuator 和 Micrometer 默认会自动收集这些指标并通过 Prometheus 端点暴露。可以通过 Grafana 等工具将其可视化。

步骤 3:采集数据库连接池和缓存命中率的指标

为了采集数据库连接池和缓存相关的指标,我们可以启用数据源的监控和缓存的指标。

3.1 监控数据库连接池

如果使用 HikariCP 作为数据库连接池,Micrometer 会自动集成并暴露相关指标,比如:

1
2
3
•	活动连接数
•	空闲连接数
•	连接获取时间

确保数据库配置如下:

1
2
3
4
5
6
7
spring:
  datasource:
    url: jdbc:mysql://localhost:3306/mydb
    username: user
    password: pass
    hikari:
      metricsTrackerFactory: io.micrometer.core.instrument.binder.db.HikariMetrics

3.2 监控缓存命中率

假设你使用了 Spring Cache 来实现缓存功能,你可以使用 Micrometer 采集缓存命中率和缓存相关的指标。

首先,确保你在 application.properties 中启用了缓存:

1
2
3
spring:
  cache:
    type: caffeine  # 假设使用 caffeine 作为缓存

在你的缓存配置类中加入指标绑定:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
import io.micrometer.core.instrument.MeterRegistry;
import org.springframework.cache.CacheManager;
import org.springframework.cache.caffeine.CaffeineCacheManager;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class CacheConfig {

    @Bean
    public CacheManager cacheManager(MeterRegistry meterRegistry) {
        CaffeineCacheManager cacheManager = new CaffeineCacheManager();
        cacheManager.setCaffeine(
            Caffeine.newBuilder()
                    .recordStats()
                    .maximumSize(10000)
        );
        cacheManager.getCache("myCache").getNativeCache().metrics();
        return cacheManager;
    }
}

步骤 4:平衡可观测性与系统性能

4.1 设置适当的采样率

为了减少对系统性能的影响,我们可以通过调整采样率来控制监控数据的收集频率。比如,只有部分请求会被追踪和采集详细数据:

1
2
3
4
management:
  tracing:
    sampling:
      probability: 0.1 # 只对 10% 的请求进行采样

步骤 5:验证集成效果

现在,你的 Spring Boot 项目已经能够自动收集 CPU、内存、请求数、错误率、数据库连接池、缓存命中率等关键指标,并且已经采取措施减少系统的性能开销。

你可以通过以下方式验证效果:

1
2
1.	访问 /actuator/prometheus 端点,查看暴露的指标数据。
2.	使用 Prometheus 和 Grafana 集成,将这些指标可视化,监控应用的运行状态。

最终的 application.yml 配置示例:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
management:
  endpoints:
    web:
      exposure:
        include: prometheus,health
  metrics:
    export:
      prometheus:
        enabled: true
  tracing:
    sampling:
      probability: 0.1  # 10%的请求采样

logging:
  level:
    root: INFO
  file:
    name: logs/application.log
    max-size: 10MB
    max-history: 5

spring:
  datasource:
    url: jdbc:mysql://localhost:3306/mydb
    username: user
    password: pass
    hikari:
      metricsTrackerFactory: io.micrometer.core.instrument.binder.db.HikariMetrics

  cache:
    type: caffeine

八、 告警与故障响应

使用 Prometheus 的告警管理(Alertmanager)

  • 设置 Prometheus 告警规则,在指标超出预期时发送告警: ```yaml alerting: alertmanagers:
    • static_configs:
      • targets:
        • ‘localhost:9093’

alert_rules: groups:

  • name: example rules:
    • alert: HighRequestLatency expr: http_server_requests_seconds_count > 0.5 for: 2m labels: severity: critical annotations: summary: “High request latency detected” description: “Request latency is above 500ms for more than 2 minutes.” ```

自动化运维与告警响应流程

  • 当应用发生故障时,通过告警机制快速通知相关人员,减少故障恢复时间。

九、结语

可观测性的未来发展方向

  • 在微服务和容器化应用的时代,可观测性工具和技术如何不断发展。
  • 继续学习的方向:服务网格(Service Mesh)、OpenTelemetry 等新兴技术。

十、扩展阅读与参考资料

This post is licensed under CC BY 4.0 by the author.