在互联网大厂,服务器监控(AIOps)是基础设施的命脉。传统的监控方案(如 Zabbix、Prometheus)在面对海量指标时各有痛点:Zabbix 擅长告警但历史数据存储能力弱;Prometheus 查询语言(PromQL)学习曲线陡峭且不易与业务数据(如 CMDB)进行关联分析。
运维人员真正需要的是:既能像 Prometheus 一样吞吐海量时序数据,又能像 MySQL 一样用标准 SQL 进行复杂关联查询。
本文将介绍如何用 KWDB 3.1.0 搭建一个轻量级但高性能的服务器监控系统,用一个数据库搞定'指标存储'与'资产管理'。
- 场景设定:监控 500 台服务器的 CPU、内存、磁盘 IO 和网络流量。
- 核心挑战:
- 高并发写入:每台服务器每 5 秒上报一次,每秒 100+ 次写入,且数据量随业务扩张线性增长。
- 复杂聚合:需要快速计算每台机器的 P95 CPU 使用率,甚至跨机架、跨业务线进行聚合分析。
- 长周期存储:需要保留 1 年的历史数据用于趋势分析和容量规划,这对存储成本提出了挑战。

1. 架构设计
1.1 监控链路图
HTTP -> Batch Insert -> SQL Query -> SQL Alert 服务器 Agent - Telegraf -> 数据接收服务 -> KWDB 集群 -> Grafana 监控面板 -> 报警中心
2. 建模实战:指标体系
一个优秀的监控系统,必须能打通'固定资产'与'动态指标'。
2.1 初始化环境
sudo /usr/local/kaiwudb/bin/kwbase sql \
--certs-dir=/etc/kaiwudb/certs \
--host=127.0.0.1:26257
CREATE DATABASE IF NOT EXISTS smart_ops;
USE smart_ops;

2.2 服务器资产表 (CMDB)
这是典型的关系型数据,存储服务器的静态属性。
思考:为什么不把这些信息直接写在时序表里?
因为 rack_id(机架)、os_version(操作系统)等信息是所有指标共享的维度。将它们独立存储,既能节省存储空间(无需在每条指标数据中重复记录),又能支持灵活的维度变更(例如服务器迁移机架,只需改一张表)。
CREATE TABLE servers (
hostname VARCHAR(50) PRIMARY KEY, -- 主机名 (唯一)
ip_address (),
rack_id (),
os_version (),
cpu_cores ,
mem_gb
);
servers
(,,,,,),
(,,,,,),
(,,,,,),
(,,,,,);






