为什么你的监控总是“事后诸葛亮”？聊聊 InfluxDB、Prometheus 与可视化的正确打开方式

作者：Echo_Wish

前几天有个做运维的朋友跟我吐槽。

“服务器昨天晚上CPU飙到100%，今天老板问我为什么没发现？”

我问了一句：

“你们有监控吗？”

他说：

**“有啊，Prometheus、Grafana 都部署了。”

“那为什么不知道？”

“因为没人看……”**

这句话其实挺扎心。

很多公司花了大量时间部署 Prometheus、InfluxDB、Grafana，最后却变成了"高级截图工具"。

监控不是为了画几个漂亮的大屏，而是为了提前发现问题、定位问题、预测问题。

今天，我们就聊聊时间序列数据库（Time Series Database，简称 TSDB）的两位明星——InfluxDB 和 Prometheus，以及如何真正把数据"展示"出价值。

为什么普通数据库不适合监控？

很多新人都会问：

MySQL 不能存监控数据吗？

当然能。

但是代价很大。

假设每秒采集一次服务器指标。

一台服务器：

CPU
Memory
Disk
Network
Load

五个指标。

1000 台服务器。

一分钟：

1000 × 5 × 60
=300000 条

一天：

2592 万条

一年：

94 亿条

MySQL 会越来越慢。

原因很简单：

监控数据有几个特点：

• 数据量极大
• 按时间写入
• 基本不会更新
• 查询都是按时间范围
• 聚合查询特别多

所以才诞生了：

Time Series Database（时间序列数据库）

它们就是专门干这个的。

InfluxDB 与 Prometheus，到底有什么区别？

很多文章喜欢列一堆表格。

我更喜欢一句话解释：

InfluxDB 更像数据库。

Prometheus 更像监控系统。

可以理解成：

InfluxDB
↓

负责存数据

Prometheus
↓

负责采集数据
负责查询数据
负责告警

很多公司甚至一起使用。

例如：

Exporter

↓

Prometheus

↓

Remote Write

↓

InfluxDB

↓

Grafana

这就是很多互联网公司的经典架构。

Prometheus 为什么这么受欢迎？

因为它太简单了。

比如一个应用暴露接口：

/metrics

返回内容：

http_requests_total 12345
cpu_usage 35
memory_usage 62

Prometheus 每隔几秒访问一次。

配置非常简单：

scrape_configs:
  - job_name: node
    static_configs:
      - targets:
        - 192.168.1.100:9100

启动之后：

Prometheus 自动采集。

不用写 SQL。

不用写存储逻辑。

这一点非常舒服。

PromQL，比 SQL 更适合监控

很多人第一次看到 PromQL 都觉得陌生。

其实非常直观。

例如：

查询 CPU：

node_cpu_seconds_total

最近五分钟平均：

avg(rate(node_cpu_seconds_total[5m]))

CPU 使用率 Top10：

topk(
10,
100-
avg(
rate(node_cpu_seconds_total{mode="idle"}[5m])
) by(instance)
*100
)

是不是有点像 SQL？

但是它天生就是围绕：

时间

进行设计。

所以性能非常高。

InfluxDB 查询也很舒服

InfluxDB 2.x 使用 Flux。

例如：

from(bucket:"server")
|> range(start:-1h)
|> filter(fn:(r)=>r._measurement=="cpu")
|> mean()

查询最近一小时 CPU 平均值。

语义非常清晰。

如果做 IoT（物联网）或者设备监控。

InfluxDB 用起来真的很顺手。

真正重要的，其实不是数据库

很多公司有个误区：

天天研究：

Prometheus

InfluxDB

VictoriaMetrics

ClickHouse

OpenTSDB

到底哪个好。

其实真正影响监控价值的，不是数据库。

而是：

你展示了什么。

很多 Grafana 大屏长这样：

CPU

Memory

Disk

Network

Load

IO

……

几十个图。

领导看不懂。

开发不想看。

运维天天看。

最后：

没人看。

这就是典型的：

有数据，没有信息。

好的大屏，应该告诉你什么？

举个例子。

如果我是老板。

我最关心：

今天有没有故障？

哪里异常？

什么时候开始？

影响多少用户？

恢复了吗？

而不是：

CPU：

56%

Memory：

71%

Disk：

82%

这些数字没有意义。

真正好的 Dashboard 应该回答：

现在是不是正常？

例如：

健康指数

98%

↓

请求成功率

99.98%

↓

接口耗时

120ms

↓

错误率

0.03%

四张图。

已经够了。

剩下的钻取分析再展开。

这就是：

概览 + 下钻。

而不是：

第一页放 50 个图。

一个优秀的监控系统应该长什么样？

我比较喜欢下面这种层次。

第一层

业务健康

↓

第二层

应用

↓

第三层

服务器

↓

第四层

容器

↓

第五层

日志

↓

第六层

Trace

出现异常：

一路点进去。

十分钟定位问题。

而不是：

先 SSH。

再 tail。

再 grep。

再翻日志。

效率完全不是一个量级。

Grafana 可视化，不只是画图

很多人觉得：

Grafana 就是折线图。

其实远远不止。

例如：

CPU 趋势：

折线图。

磁盘占比：

饼图。

接口排行：

柱状图。

异常分布：

Heatmap。

告警状态：

Stat。

响应时间：

Gauge。

甚至还能做：

地图。

流程图。

拓扑图。

日志联动。

Trace 联动。

真正优秀的大屏，不是"炫"，而是一眼看懂。

下面是一个典型的监控指标随时间变化示意图，能够直观反映时间序列数据最擅长表达的内容。

看到这样的趋势图，你会比一串孤立数字更容易判断：“09:07 左右发生了明显的异常峰值”，这正是时间序列可视化的价值所在。

一个简单的告警规则示例

监控最大的价值，不是事后看图，而是提前通知。

下面是一个 CPU 告警规则：

groups:
- name: cpu-alert
  rules:
  - alert: HighCPUUsage
    expr: 100 - avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) by (instance) * 100 > 80
    for: 5m
    labels:
      severity: critical
    annotations:
      summary: "CPU使用率持续超过80%"
      description: "实例 {{ $labels.instance }} CPU 持续高负载超过5分钟。"

这样可以避免瞬时尖峰带来的误报，让告警更加稳定可靠。

我越来越认同的一句话

以前我觉得：

监控就是收集指标。

后来觉得：

监控就是画 Dashboard。

现在越来越觉得：

监控真正的价值，是帮助团队快速做决策。

一个成熟的监控平台，不应该让工程师沉迷于几十张图表，而应该在异常发生时，用最短时间告诉你：

• 哪里出了问题？
• 从什么时候开始？
• 影响范围有多大？
• 是否已经恢复？
• 下一步应该查看哪一层数据？

这也是为什么近几年越来越多企业开始把 Prometheus + Grafana 作为实时监控核心，再结合 InfluxDB 或其他高性能时序数据库做长期存储和历史分析。监控体系已经从"采集指标"升级为"数据驱动运维"，而可视化也从"展示数据"升级为"辅助决策"。

数据不会主动创造价值，真正创造价值的是洞察；图表不会自动解决问题，真正解决问题的是能够快速定位异常、指导行动的可视化。

所以，如果你的监控平台还停留在"大屏很炫、图很多、没人看"的阶段，不妨重新思考一个问题：

你的 Dashboard，到底是在展示数据，还是在帮助团队解决问题？

当监控能够让研发、运维和业务人员在几分钟内形成一致判断时，它才真正完成了从"时间序列数据库"到"数据价值平台"的蜕变。这，才是 InfluxDB、Prometheus 与可视化实践真正值得追求的方向。

CPU 使用率趋势示例

模拟过去 12 分钟 CPU 使用率变化，可用于展示时间序列监控趋势。

time cpu
09:00 28
09:01 31
09:02 35
09:03 42
09:04 46
09:05 51
09:06 68
09:07 83
09:08 76
09:09 58
09:10 43
09:11 37