一文了解物联网后端工程师必须知道的性能监控知识

参考视频：鱼皮B站Prometheus教程

本文的学习目的：
1、为什么要学会性能监控？什么是性能监控？性能监控怎么实现？
2、一个物联网平台大概需要监控哪些指标？
3、性能监控最常用的两种方式：APM探针和Prometheus+Grafana分别是怎么用的？

想做一个高性能、稳定的系统，光会写代码还不够。我们还要知道系统当前运行得怎么样、性能瓶颈在哪里，以及出现问题后该从哪个环节开始排查。不然你说你熟系高并发，但是你连排查高并发瓶颈的能力都没有，那不就是纯粹瞎改，瞎优化，蒙着改，祈祷问题能解决。

本文以一个接入 10 万台设备、每台设备每 10 分钟上报一次消息的物联网平台为例，介绍后端工程师需要掌握的性能监控基础知识。

一、先明确要监控什么

10 万台设备每 10 分钟上报一次，平均流量约为：

100000 / 600 ≈ 167 条/秒

这只是平均值。真实系统还要考虑设备集中上线、整点上报、失败重试和网络恢复后补报等情况，所以压测和监控都应该关注峰值，而不能只看平均值。

物联网平台的消息链路通常分为两部分：

• 上行链路：设备主动向平台上报状态或数据。
• 下行链路：平台向设备发送开关、配置更新等指令。

以上行链路为例，消息可能依次经过：

每经过一个组件，都应该关注以下几类信息：

环节	重点监控内容
EMQX	在线连接数、消息流入/流出速率、订阅关系、消息丢弃数、异常断连数
Node-RED	是否收到消息、处理耗时、错误数、CPU、内存
消息队列	生产和消费速率、消费延迟、消息堆积量、失败和重试次数
Java 业务服务	吞吐量、处理耗时、错误率、线程池、连接池、JVM、CPU、内存
落库服务和数据库	写入速率、写入耗时、慢 SQL、连接数、锁等待、磁盘 I/O
所有服务器	CPU、内存、磁盘容量、磁盘 I/O、网络流量和系统负载

下行链路也要使用同样的方法逐段监控，并额外关注指令发送成功率、设备确认耗时和超时重试次数。

只有把整条链路的数据串起来，我们才能回答：消息在哪个环节变慢、从哪里开始堆积，以及瓶颈到底在应用、消息队列还是数据库。

二、性能监控的概念

前面我们从业务链路出发梳理了需要关注的指标，在继续讨论具体的监控方法和工具之前，我们需要知道一些基本的概念，大部分的监控工具和方法都是基于这些概念做的。

可观测性（Observability），强调根据系统产生的外部数据推断内部状态，从而分析事先没有预料到的问题。它通常包括：

• 指标（Metrics）：适合观察趋势和触发告警，例如消息处理速率、错误率。
• 日志（Logs）：记录离散事件和上下文，例如某条消息处理失败的原因。
• 链路追踪（Traces）：记录一次请求经过了哪些服务，以及每个环节花了多长时间。

1. 指标与维度

指标（Metric）是可量化的数值，例如消息总数、处理耗时和在线设备数，关注的是“有多少”。

维度（Dimension）在 Prometheus 中通常表现为标签（Label），用于描述和分类指标，关注的是“属于哪一类”。

例如：

iot_messages_total{direction="up", product="temperature_sensor", result="success"} 128430

其中：

• iot_messages_total 是指标名称。
• direction、product 和 result 是标签。
• 128430 是当前指标值。

标签值的组合越多，生成的时间序列就越多。不要轻易把 device_id、订单号或消息 ID 这类高基数字段作为标签，否则会明显增加 Prometheus 的存储和查询压力。这类信息更适合写入日志。

这里会发现，其实逻辑很简单就是规律时间间隔的记录数据，这个数据有标签和指标值，和你用Excel记录数据是一模一样的。

2. 监控数据的层次

一个完整的监控体系通常需要覆盖以下层次：

1. 系统指标：CPU、内存、磁盘 I/O、网络流量等基础设施数据。
2. 应用指标：请求量、响应时间、错误率、线程池、连接池和 JVM 状态。
3. 中间件指标：EMQX 连接数、消息队列堆积量、数据库连接数等。
4. 业务指标：设备在线数、上报成功率、指令下发成功率、消息处理总量等。
5. 调用链数据：一次请求经过的服务、各个 Span 的耗时和错误信息。

其中，Trace 表示一次完整请求的调用链，Span 表示调用链中的一个操作单元。通过 Trace 和 Span，可以看到请求在分布式系统中的流转过程。

三、性能监控中的常用指标

排查一个服务时，可以先关注四类核心信号：

• 流量：每秒请求数、每秒消息数。
• 延迟：平均耗时以及 P50、P90、P99 等百分位耗时。
• 错误：失败率、超时数、异常数。
• 饱和度：CPU、内存、线程池、连接池和队列是否接近上限。

百分位数

P50、P90、P99 都是百分位数：

• P50：50% 的请求耗时不超过这个值，也就是中位数。
• P90：90% 的请求耗时不超过这个值。
• P99：99% 的请求耗时不超过这个值。

例如，某接口的 P99 响应时间是 500 ms，表示约 99% 的请求可以在 500 ms 内完成，其余约 1% 更慢。平均值可能会掩盖少量特别慢的请求，所以定位长尾延迟时要重点关注 P99，但也不能只看单一百分位数。

四、可观测性体系怎么落地

构建可观测性体系时，需要依次回答四个问题：

1. 统计什么：根据系统目标和业务特点确定关键指标。
2. 如何收集：通过代码埋点、Exporter、Agent 或日志采集器获取数据。
3. 如何存储：指标通常存入时序数据库，日志和链路数据使用各自适合的存储系统。
4. 如何展示和告警：通过仪表盘展示趋势，并在满足告警规则时通知相关人员。

在实际项目中，大部分公司都会使用以下两种方式，用APM 探针与 Prometheus+Grafana的方式，二选一或者两者都用。

1. APM 与 Java Agent

ARMS是阿里云提供，开箱即用的云监控平台，实现逻辑如下，具体怎么操作可以看一下鱼皮的视频。

ARMS 等 APM 产品可以使用 Java Agent 采集应用性能数据。Java Agent 是 JVM 提供的一种扩展机制，可以借助 Java Instrumentation API 在类加载过程中增强字节码，在 HTTP 请求、数据库访问和远程调用等关键位置记录耗时、状态和调用关系。

它的大致流程是：

1. 字节码增强：在目标类加载时插入监控逻辑。
2. 数据采集：记录方法耗时、异常、数据库调用和远程调用等数据。
3. 上下文传递：在跨服务请求中传递 Trace ID 等上下文。
4. 数据上报：将采集结果发送到 APM 后端进行存储和分析。

这种方式通常不需要修改业务代码，但仍然需要添加 Agent 启动参数、配置采集规则，并评估版本兼容性和运行开销。

APM 比较适合定位：

• 哪个接口或方法执行较慢。
• 哪条 SQL 执行较慢。
• 哪个下游服务拖慢了整个请求。
• JVM 是否存在频繁 GC 等问题。
• 一次请求对应哪些日志和调用链。

2. Prometheus 与 Grafana

Prometheus 主要负责指标的采集、存储、查询和告警规则计算，Grafana 主要负责数据展示和分析。典型架构如下：

Prometheus 将指标保存为带时间戳的时间序列。每条时间序列由指标名称和一组标签唯一标识，例如：

http_requests_total{method="POST", handler="/api/device/report"} 1024

Prometheus 可以查询过去一段时间内的请求速率、CPU 使用率和接口耗时等数据。例如，下面的 PromQL 用于计算最近 5 分钟上行消息的每秒平均增长速率：

rate(iot_messages_total{direction="up"}[5m])

Prometheus 的关键组件

1. Prometheus Server：定期抓取指标，保存时间序列，并提供 PromQL 查询能力。
2. Exporter：将操作系统、数据库和中间件的内部状态转换为 Prometheus 可以抓取的指标格式。
3. Alertmanager：接收 Prometheus 产生的告警，负责分组、抑制和通知分发。
4. 客户端库：帮助应用暴露自定义指标；Java 项目常用 Micrometer 或 Prometheus Java Client。

数据收集原理

Prometheus 主要使用拉取模式，定期通过 HTTP 请求目标的 /metrics 端点。这样采集周期和目标管理由 Prometheus 控制，也便于结合服务发现自动增删实例。

在 Prometheus 中：

• Job 表示一组用途相同的抓取目标，例如 java-service 或 node-exporter。
• Instance 表示一个具体抓取目标，通常是 IP:端口。
• up 表示目标最近一次是否抓取成功。
• scrape_duration_seconds 表示抓取耗时。

Prometheus 也可以通过 Pushgateway 接收短生命周期批处理任务推送的指标，但普通常驻服务通常优先使用拉取模式。

四种核心指标类型

1. Counter（计数器）：数值通常只增加，进程重启时会归零，适合记录请求总数、错误总数。查询时通常配合 rate() 或 increase()。
2. Gauge（仪表）：数值可以增加或减少，适合记录在线设备数、队列长度、当前内存使用量。
3. Histogram（直方图）：按照预设桶统计数据分布，同时记录总次数和总和，适合统计请求耗时或消息大小，并可在服务端聚合后计算百分位数。
4. Summary（摘要）：在客户端计算分位数，也会记录总次数和总和。其分位数通常不能跨实例直接聚合，因此多实例场景一般优先考虑 Histogram。

选择指标类型时，要根据数据含义和查询方式决定，不能为了“记录更多”而盲目增加指标和标签。

3. Grafana 做什么

Grafana 可以把 Prometheus 配置为数据源。查询流程可以简单理解为：

1. 开发者在面板中编写 PromQL。
2. Grafana 根据面板时间范围补充查询区间和步长等参数。
3. Grafana 通过 HTTP API 请求 Prometheus。
4. Prometheus 返回查询结果，Grafana 将结果绘制成图表。

Grafana 负责展示，但图表是否有价值，最终取决于指标设计和 PromQL 是否正确。

对于我们后端来讲，现在完全可以用AI生成面板，然后在这里导入就行。

这是具体的面板，最常用的就是可以点进去看具体的PromQL 。

五、常用的指标采集方式

很多基础组件已经有现成的 Exporter 或指标端点，不需要重复开发：

• Linux 主机：Node Exporter。
• MySQL：mysqld_exporter。
• Redis：redis_exporter。
• MongoDB：MongoDB Exporter。
• JVM 和 Java 中间件：JMX Exporter。
• Spring Boot 应用：Micrometer + Actuator 暴露 /actuator/prometheus。
• Kubernetes：kube-state-metrics、kubelet/cAdvisor 等。

EMQX、RocketMQ、ClickHouse 等组件也可以通过官方指标接口或适配的 Exporter 接入 Prometheus。选型时要确认组件版本、Exporter 的维护状态和指标含义。

只有当现成指标无法表达业务状态时，才需要在应用中增加自定义埋点，例如：

• 设备消息接收总数。
• 消息校验失败总数。
• 当前消息堆积量。
• 指令下发成功率。
• 消息端到端处理耗时。

六、最后总结

性能监控不是简单地看 CPU 和内存，而是围绕一条完整业务链路，持续回答三个问题：

1. 系统现在是否正常。
2. 问题发生在哪个环节。
3. 哪个资源或依赖限制了系统性能。

对于物联网平台，可以先从主机、应用、消息队列、数据库和业务指标入手，再逐步补充日志与链路追踪。先把关键链路看清楚，再增加指标，通常比一开始堆很多仪表盘更有效。

参考资料

• Prometheus：数据模型
• Prometheus：指标类型
• Prometheus：Job 与 Instance
• Grafana：Prometheus 数据源