指标采集怎么做？

本文目录导读：

1. 核心逻辑框架：指标采集的5步法
2. 第一步：定义指标（最容易被忽略，但最重要）
3. 第二步：选择采集技术/工具（分场景）
4. 第三步：设计与传输协议（怎么把数据拿回来）
5. 第四步：数据清洗与预处理（边缘计算）
6. 第五步：存储与可视化
7. 常见问题与避坑指南
8. 一个常见的具体实施方案

“指标采集”是一个很广泛的概念，不同领域（如IT性能监控、数据分析、物联网、DevOps）的做法差异很大。

为了给你一个通用且可落地的框架，我会将这个问题拆解为5个核心步骤，并分别说明不同场景下的常用方案。

核心逻辑框架：指标采集的5步法

无论你在哪个领域，指标采集都遵循这个流程：定义 -> 发现 -> 采集 -> 传输 -> 存储/可视化。

---

第一步：定义指标（最容易被忽略，但最重要）

在动手采集之前，需要明确采集什么和为什么采集。

• 界定核心（KPI）： 区分关键指标（如用户增长率、API延迟）和调试指标（如内存碎片）。
• 确定粒度： 是每秒采集一次，还是每分钟？是看平均值，还是P99（第99百分位数）？
• 来源分析： 指标从哪里来？（服务器、用户浏览器、数据库、业务系统、传感器？）

第二步：选择采集技术/工具（分场景）

这是“怎么做”的核心，我按最常见的4大场景为你拆解：

场景A：IT基础设施与运维监控（服务器、网络、CPU、内存）

这是最经典的场景，核心是Agent（代理） 模式。

• 常用工具： Prometheus（云原生标准）、Zabbix（传统企业级）、Telegraf（开源采集器）、Datadog Agent（SaaS）。
• 怎么做？
  1. 在每台服务器上安装一个轻量级Agent（如Prometheus Node Exporter）。
  2. 该Agent读取操作系统的/proc目录（Linux内核暴露的接口）或调用系统API。
  3. Agent通过HTTP端口（如9100）暴露指标数据，等待中心服务器（Prometheus Server）来拉取。
• 代码示例（Node Exporter）： 它自动采集CPU使用率、内存、磁盘IO、网络流量等上百个标准指标。

场景B：业务与应用程序指标（用户行为、订单量、支付成功率）

这类指标需要从应用代码内部“打桩”采集。

• 常用工具： Micrometer（Java）、StatsD（通用协议）、OpenTelemetry SDK（语言无关标准）。
• 怎么做？
  • 在你的业务代码中，调用SDK（软件开发工具包）定义计数器（Counter）、直方图（Histogram）、仪表盘（Gauge）。
  • 示例（伪代码）：

    # 假设你有一个处理订单函数
    def create_order(user_id， amount):
        # 1. 业务逻辑
        order = save_to_db(...)
        # 2. 指标采集：增加订单总数
        order_counter.increment()
        # 3. 指标采集：记录订单金额分布
        order_amount_histogram.record(amount)
        # 4. 如果是高价值用户，记录一个标签数据
        if user_id in vip_users：
            vip_order_gauge.set(vip_count)

  • 传输： SDK通常会将数据本地缓存，然后批量发送到后端（如Telegraf或直接发送到时序数据库）。

场景C：前端与用户体验（页面加载时间、JS错误、点击热力图）

这类指标完全由客户端侧主动上报。

• 常用工具： Google Analytics（产品级）、Sentry（错误追踪）、性能API（Web Vitals）。
• 怎么做？
  1. 使用浏览器原生API（如 PerformanceObserver， navigator.sendBeacon()）。
  2. 采集关键指标：FCP（首次内容绘制）、LCP（最大内容绘制）、CLS（累计布局偏移）、TTFB（首字节时间）。
  3. 核心技巧： 利用sendBeacon方法，在页面卸载时也能可靠地发送数据,避免数据丢失。
  4. 将数据打包发送至你的BI（商业智能）后端或第三方SaaS（软件即服务）平台。

场景D：物联网与传感器（温度、湿度、转速）

这类指标通常是非标准协议和边缘计算。

• 常用工具： MQTT协议、Modbus协议、EdgeX Foundry（边缘计算框架）。
• 怎么做？
  1. 数据流： 传感器（通过GPIO（通用输入输出）/Modbus） → 网关/边缘盒子 → MQTT Broker → 后端时序数据库。
  2. 采集逻辑： 网关读取Modbus寄存器或传感器数字信号，解析为浮点数，然后通过MQTT发布到特定Topic（主题）。

第三步：设计与传输协议（怎么把数据拿回来）

采集到的数据需要从源头送到处理中心。

• 拉模式（Pull）：
  • 代表： Prometheus。
  • 优点： 采集者控制节奏，目标端只需暴露端口,无需担心负载导致崩溃。
  • 缺点： 发现新目标需要服务发现（Consul/K8s API）。
• 推模式（Push）：
  • 代表： StatsD， OpenTelemetry。
  • 优点： 指标源主动上报，适合短时作业（如Cron任务）或防火墙内的设备。
  • 缺点： 容易对后端造成突发流量冲击。

第四步：数据清洗与预处理（边缘计算）

在数据进入存储之前,做一点处理可以减少后期工作量。

• 聚合： 如果传感器每100毫秒发一次数据,可以在采集端先算好1分钟的平均值再发送。
• 过滤： 过滤掉明显异常值或调试日志。
• 格式转换： 将非标准数据转换为标准格式（如OpenTelemetry Protocol， Prometheus Exposition Format）。

第五步：存储与可视化

数据被采集传输后,需要地方存放和展示。

• 时序数据库： InfluxDB、TimescaleDB、Prometheus（自带存储）、VictoriaMetrics。
• 可视化： Grafana（业界标准，几乎可以对接所有数据源）、Kibana（配合Elasticsearch）。

---

常见问题与避坑指南

1. 指标爆炸：

   • 现象： 采集了200万个时间序列,导致系统变慢。
   • 对策： 对高基数指标（支持大量唯一的标签组合，如user_id）进行降采样，或者使用TDigest（一种估算百分位数的算法）替代精确计算。

2. 时间戳不准：

   • 现象： 图表出现锯齿或完全不显示。
   • 对策： 统一使用UTC时间戳，务必使用NTP（网络时间协议）同步所有采集节点的时钟。

3. 数据丢失：

   • 现象： CPU在10：01是100%，10：02显示为0。
   • 对策： 在采集端启用缓冲或本地文件备份（如Telegraf的file输出插件）,网络恢复后再补传。

一个常见的具体实施方案

目标： 搭建一个微服务监控系统。

1. 定义： 采集API的QPS、延迟P99、错误率和Pod的CPU/内存使用率。
2. 采集端： 每个微服务部署OpenTelemetry SDK（用于业务指标），部署Node Exporter（用于基础设施指标）。
3. 传输： SDK通过gRPC协议将数据推送至 OpenTelemetry Collector（一个统一的数据接收、处理、转发代理）。
4. 存储： Collector将元数据过滤后，写入 VictoriaMetrics（一个高性能的Prometheus兼容时序数据库）或 Prometheus。
5. 可视化： 在 Grafana 中配置Dashboard,展示实时数据。

一句话回答你的问题： 指标采集的核心是定义好你要什么，然后根据数据来源（服务器、代码、浏览器、传感器）选择合适的SDK或Agent，通过Pull或Push模式传输，最后存储到时序数据库并用Grafana展示。