2、数据源接入：常见数据源与采集策略
大家好，我是老张。做实时监控这么多年，我最大的体会就是：数据源接入是地基。地基没打好，后面可视化做得再花哨，也是空中楼阁。
今天咱们聊聊三种最常见的时序数据源——Prometheus、InfluxDB、Elasticsearch。我会结合自己踩过的坑，把数据采集策略和清洗预处理讲透。
2.1 三大主流数据源，怎么选？
先看一张图，这是我总结的选型逻辑：
2.2 Prometheus：Pull 模型的王者
Prometheus 是我用得最多的数据源。它的核心机制是 Pull 模型——主动去目标服务上抓取指标。
我个人习惯这样配置：
# prometheus.yml 核心配置
scrape_configs:
- job_name: 'node_exporter'
scrape_interval: 15s # 采集间隔
static_configs:
- targets: ['localhost:9100']
labels:
env: 'production'
team: 'infra'
PromQL 是它的查询语言，写起来很爽：
# 查询过去5分钟CPU平均使用率
avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100
# 按实例分组，取最大值
max by(instance) (node_memory_MemAvailable_bytes)
2.3 InfluxDB：写入性能怪兽
InfluxDB 的强项是 高并发写入。我做过压测，单机每秒能写 50 万点——这个数据很恐怖。
它的数据模型是「measurement + tag + field」：
# 写入示例（Line Protocol格式）
sensor_data,device_id=001,location=机房A temperature=25.6,humidity=60.2 1700000000
# 查询示例
SELECT mean("temperature")
FROM "sensor_data"
WHERE time > now() - 1h
GROUP BY time(5m), "device_id"
2.4 Elasticsearch：日志分析的瑞士军刀
ES 其实不是专门的时序数据库，但它的 全文搜索 + 聚合分析 能力太强了。做日志监控，基本绕不开它。
我建议的索引模板：
{
"index_patterns": ["monitor-*"],
"template": {
"settings": {
"number_of_shards": 3,
"number_of_replicas": 1,
"refresh_interval": "10s"
},
"mappings": {
"properties": {
"@timestamp": { "type": "date" },
"level": { "type": "keyword" },
"message": { "type": "text" },
"service": { "type": "keyword" },
"duration_ms": { "type": "float" }
}
}
}
}
核心要点：ES 的聚合查询是可视化利器。比如用 date_histogram 做时间桶，用 terms 做分组统计，配合 Kibana 的 Vega 图表，能做出很酷的实时仪表盘。
2.5 数据采集策略：别让数据淹死你
嗯，这里要重点说说。很多新手一上来就全量采集，结果存储爆了、查询慢了。我总结了三层策略：
- 采样策略：高频指标（如CPU）每15秒采一次，低频指标（如磁盘容量）每5分钟采一次
- 聚合策略：原始数据保留7天，5分钟聚合保留30天，1小时聚合保留1年
- 过滤策略：只采集有意义的指标，别把调试日志也送进去
举个例子，这是我常用的采集配置：
# Telegraf 采集配置（InfluxDB生态）
[[inputs.cpu]]
percpu = true
totalcpu = true
fielddrop = ["time_*"] # 过滤掉不需要的字段
[[inputs.disk]]
ignore_fs = ["tmpfs", "devtmpfs"]
[[outputs.influxdb]]
urls = ["http://localhost:8086"]
database = "telegraf"
retention_policy = "rp_7d"
2.6 数据清洗与预处理：脏数据是可视化的大敌
说实话，我见过太多可视化翻车案例——图表上突然出现一个巨大的尖峰，查了半天发现是传感器误报。所以数据清洗这步，千万别省。
我常用的清洗规则：
| 问题类型 | 检测方法 | 处理方式 |
|---|---|---|
| 空值/缺失 | isnull() 检测 | 前值填充 / 插值 |
| 异常跳变 | 3σ 法则 / IQR | 标记或剔除 |
| 重复数据 | 时间戳去重 | 保留最新一条 |
| 单位不一致 | 正则匹配 | 统一转换 |
用 Python 做预处理的话，我习惯这样写：
import pandas as pd
import numpy as np
def clean_metrics(df):
# 1. 去重
df = df.drop_duplicates(subset=['timestamp', 'metric_name'])
# 2. 处理空值（前向填充）
df = df.fillna(method='ffill')
# 3. 异常检测（3σ）
mean = df['value'].mean()
std = df['value'].std()
df = df[(df['value'] > mean - 3*std) &
(df['value'] < mean + 3*std)]
# 4. 重采样到固定频率
df = df.set_index('timestamp').resample('15S').mean()
return df
2.7 实战：三源合一的可视化架构
最后分享一个我实际用过的架构。一个大型电商平台，需要同时监控基础设施、业务指标和访问日志：
数据采集层：
├── Prometheus → 容器/服务器指标
├── InfluxDB → 业务埋点（订单量、转化率）
└── ES → Nginx访问日志、应用日志
可视化层：
└── Grafana（统一数据源）
├── Prometheus 数据源 → 基础设施面板
├── InfluxDB 数据源 → 业务KPI面板
└── ES 数据源 → 日志分析面板
这样做的好处是：各取所长，统一展示。用户看到的是一张完整的监控大屏，但背后是三个数据源在协同工作。
总结一下：数据源接入没有银弹。Prometheus 适合基础设施，InfluxDB 适合高写入业务，ES 适合日志分析。关键是搞清楚你的场景，然后选择合适的采集策略和清洗流程。地基打好了，后面的可视化才能游刃有余。
公众号:蓝海资料掘金营，微信deep3321