KWDB 运维实战：用 SQL 打通 Metrics 与 CMDB 数据关联

在互联网大厂，服务器监控（AIOps）是基础设施的命脉。传统的监控方案（如 Zabbix、Prometheus）在面对海量指标时各有痛点：Zabbix 擅长告警但历史数据存储能力弱；Prometheus 查询语言（PromQL）学习曲线陡峭且不易与业务数据（如 CMDB）进行关联分析。

运维人员真正需要的是：既能像 Prometheus 一样吞吐海量时序数据，又能像 MySQL 一样用标准 SQL 进行复杂关联查询。

本文将介绍如何用 KWDB 3.1.0 搭建一个轻量级但高性能的服务器监控系统，用一个数据库搞定'指标存储'与'资产管理'。

• 场景设定：监控 500 台服务器的 CPU、内存、磁盘 IO 和网络流量。
• 核心挑战：
  1. 高并发写入：每台服务器每 5 秒上报一次，每秒 100+ 次写入，且数据量随业务扩张线性增长。
  2. 复杂聚合：需要快速计算每台机器的 P95 CPU 使用率，甚至跨机架、跨业务线进行聚合分析。
  3. 长周期存储：需要保留 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 
(,,,,,),
(,,,,,),
(,,,,,),
(,,,,,);