KWDB 运维实战：用 SQL 融合 Metrics 指标与 CMDB 资产数据

性能指标表 (Metrics)

Tag 设计是关键：hostname 是核心维度，它是连接 CMDB 表和 Metrics 表的纽带。

CREATE TABLE server_metrics (
  ts TIMESTAMP NOT NULL,                 -- 时间戳
  hostname VARCHAR(50) NOT NULL,         -- 主机名 (Tag)
  cpu_usage DOUBLE,                      -- CPU 使用率 (%)
  mem_usage DOUBLE,                      -- 内存使用率 (%)
  disk_io_read DOUBLE,                   -- 磁盘读 (MB/s)
  disk_io_write DOUBLE,                  -- 磁盘写 (MB/s)
  net_in DOUBLE,                         -- 网络入 (Mbps)
  net_out DOUBLE,                        -- 网络出 (Mbps)
  PRIMARY KEY (ts, hostname)
);

数据模拟：压测级脚本

为了验证效果，我们编写了一个 Python 脚本 gen_ops_data.py，模拟 4 台服务器过去 6 小时的数据。

import random
from datetime import datetime, timedelta

FILENAME = "ops_data.sql"
HOSTS = ['web-01', 'web-02', 'db-01', 'db-02']
START_TIME = datetime.now() - timedelta(hours=6)
INTERVAL_SECONDS = 5
TOTAL_POINTS = int(6 * 3600 / INTERVAL_SECONDS)

print(f"正在生成 {len(HOSTS)} 台服务器，过去 6 小时的监控数据...")

with open(FILENAME, "w") as f:
    f.write("USE smart_ops;\n")
    f.write("INSERT INTO server_metrics (ts, hostname, cpu_usage, mem_usage, disk_io_read, disk_io_write, net_in, net_out) VALUES\n")
    records = []
    for host in HOSTS:
        # 模拟不同角色的负载特征
        base_cpu = 20 if 'web' in host else 40
        base_mem = 40 if 'web' in host else 70
        
        for i in range(TOTAL_POINTS):
            ts = (START_TIME + timedelta(seconds=i*INTERVAL_SECONDS)).strftime('%Y-%m-%d %H:%M:%S')
            # 波动
            cpu = base_cpu + random.uniform(-10, 30)
            if cpu > 100: cpu = 100
            mem = base_mem + random.uniform(-5, 10)
            if mem > 100: mem = 100
            disk_r = random.uniform(0, 100)
            disk_w = random.uniform(0, 50)
            # 数据库服务器 IO 更高
            if 'db' in host:
                disk_r *= 2
                disk_w *= 3
            net_in = random.uniform(10, 1000)
            net_out = random.uniform(10, 1000)
            records.append(f"('{ts}', '{host}', {round(cpu, 1)}, {round(mem, 1)}, {round(disk_r, 1)}, {round(disk_w, 1)}, {round(net_in, 1)}, {round(net_out, 1)})")
    
    # 批量写入
    batch_size = 1000
    total = len(records)
    for i, record in enumerate(records):
        if (i + 1) % batch_size == 0 or i == total - 1:
            f.write(f"{record};\n")
            if i < total - 1:
                f.write("INSERT INTO server_metrics (ts, hostname, cpu_usage, mem_usage, disk_io_read, disk_io_write, net_in, net_out) VALUES\n")
        else:
            f.write(f"{record},\n")

print(f"生成完毕！总记录数：{total}")
print(f"请运行：time sudo /usr/local/kaiwudb/bin/kwbase sql --certs-dir=/etc/kaiwudb/certs --host=127.0.0.1:26257 < {FILENAME}")

执行导入命令：

python3 gen_ops_data.py
sudo /usr/local/kaiwudb/bin/kwbase sql --certs-dir=/etc/kaiwudb/certs --host=127.0.0.1:26257 < ops_data.sql

执行结果分析：

• 写入性能：从图中可以看到，每一批 1000 条数据的写入时间稳定在 30ms 左右。这意味着在单线程情况下，KWDB 的写入吞吐量轻松达到 3.3 万 TPS。对于 500 台服务器每 5 秒上报一次（即 100 TPS）的场景，KWDB 仅用极小的系统资源就能轻松扛住。
• 稳定性：整个导入过程耗时约 1 分 13 秒，写入了 17280 条记录（模拟数据量），全程无报错，验证了 Batch Insert 方案的健壮性。

业务场景实战

注意：执行前请确保 USE smart_ops;。

场景一：P95 性能分析

需求：计算每台服务器在过去 1 小时内的 P95 CPU 使用率（即 95% 的时间 CPU 都低于这个值），这是容量规划的重要依据。

USE smart_ops;
-- 简单的平均值可能掩盖毛刺，P95 更能反映真实压力
-- 注意：如果当前版本暂不支持 percentile_cont，可以使用 avg/max 替代
SELECT hostname,
       avg(cpu_usage) as avg_cpu,
       max(cpu_usage) as max_cpu 
FROM server_metrics 
WHERE ts > now() - interval '1 hour'
GROUP BY hostname;

执行结果分析：

• 查询效率：查询耗时仅 9.68ms。
• 数据洞察：结果清晰展示了不同角色的服务器负载特征。db-01 和 db-02 的 CPU 使用率都在 50% 左右（Max 70%），符合数据库服务器的高负载特征；而 web-01 和 web-02 则在 30% 左右。P95 分析（这里用 Max 近似）帮助我们快速识别出了系统的潜在瓶颈在 DB 层。

场景二：机架级负载均衡 (Rack Traffic Analysis)

业务痛点：数据中心的交换机带宽是有限的。如果某个机架上的服务器流量总和过大，会打爆接入交换机，导致整个机架网络瘫痪。这需要我们将'时序数据'与'CMDB 资产数据'关联分析。

需求：统计每个机架（Rack）的总带宽使用量，防止机架交换机打爆。

USE smart_ops;
SELECT s.rack_id,
       sum(m.net_in) as total_net_in,
       sum(m.net_out) as total_net_out 
FROM server_metrics m 
JOIN servers s ON m.hostname = s.hostname 
WHERE m.ts > now() - interval '5 minute'  -- 实时流量
GROUP BY s.rack_id;

执行结果分析：

• 多维聚合：耗时 12.94ms。
• 业务价值：这是一个典型的跨表聚合查询。KWDB 成功将 Metrics 表中的流量数据与 CMDB 表中的机架信息（Rack-A01, Rack-B02）进行了关联。结果显示两个机架的流量负载非常均衡（都在 4.4M 左右），说明当前的负载均衡策略是有效的。如果某个机架流量突增，这个查询能立竿见影地发现问题。

场景三：僵死服务器检测

需求：找出最近 5 分钟没有上报数据的服务器（可能是宕机了）。

USE smart_ops;
SELECT s.hostname, s.ip_address, max(m.ts) as last_heartbeat 
FROM servers s 
LEFT JOIN server_metrics m ON s.hostname = m.hostname 
GROUP BY s.hostname, s.ip_address 
HAVING max(m.ts) < now() - interval '5 minute' OR max(m.ts) IS NULL;

执行结果分析：

• 检测结果：查询耗时 18.58ms，返回 0 rows。
• 含义解读：这说明当前所有在册的服务器（CMDB 中登记的）在过去 5 分钟内都有正常的心跳上报，系统处于极其健康的状态。这种'反向查询'（找缺失的数据）是时序数据库中较难处理的场景，而 KWDB 凭借标准的 SQL 能力（LEFT JOIN + HAVING）轻松搞定。

避坑指南

1. 数据降采样：对于 1 年前的历史数据，不需要保留 5 秒级的精度。建议使用 KWDB 的 Downsampling 功能（如果支持）或者定期跑批任务，将数据聚合为'1 小时 1 点'存入历史表。
2. 索引优化：如果你经常按 rack_id 查询，建议在 servers 表的 rack_id 字段建立索引。

总结

KWDB 在运维监控场景下表现出色，单机即可支撑数千台服务器的指标写入。相比 Prometheus，它最大的优势在于支持标准 SQL，这让运维人员可以非常灵活地进行多维关联分析。

核心价值回顾：

1. 降低门槛：只要会写 SQL 就能做监控分析，无需学习 PromQL 等专用语言。
2. 打破孤岛：在一个数据库内实现了 Metrics（时序）与 CMDB（关系）的融合，让监控数据有了业务含义。
3. 高压缩率：实测显示，KWDB 对同构的时序数据有极高的压缩比，大幅降低了长周期存储的硬件成本。

随着 AIOps 的发展，基于 KWDB 我们还能做更多：

• 异常检测：利用 KWDB 的分析函数，计算 CPU 使用率的同比/环比变化，自动发现'异常突增'。
• 根因分析：当 Web 服务器响应变慢时，通过 SQL 关联查询同一时刻数据库服务器的负载，快速定位是应用层问题还是数据库层问题。
• 日志分析：虽然本文主要讲指标，但 KWDB 同样可以存储结构化的日志数据，实现'指标 + 日志'的统一检索。

通过构建统一的运维数据底座，我们不再是'救火队员'，而是系统的'健康管理师'。