TDengine 的 AI 应用实战——运维异常检测

作者： derekchen  

Demo数据集准备

我们使用公开的 NAB数据集 里亚马逊 AWS 东海岸数据中心一次 API 网关故障中，某个服务器上的 CPU 使用率数据。数据的频率为 5min，单位为占用率。由于 API 网关的故障，会导致服务器上的相关应用陷入频繁的异常处理和重试，进而导致 CPU 使用率的异常波动。TDgpt 的异常检测算法将识别出这种异常。

该数据文件，放置于 https://github.com/taosdata/TDgpt-demo 仓库的 demo_data 目录下，请参考下文的步骤导入 TDengine 以完成演示。数据集的统计信息如下：

演示环境准备

环境要求

您可基于 Linux、Mac 以及 Windows操作系统完成 Demo 系统的运行。但为使用 docker-compose，您计算机上需要安装有下属软件：

1. Git
2. Docker Engine: v20.10+
3. Docker Compose: v2.20+

Demo中包含 3 个 docker 镜像 (TDengine, TDgpt, Grafana)，以及一组用于产生预测/异常检测结果的shell脚本。组件版本的要求如下：

克隆Demo仓库到本地

1. git clone https://github.com/taosdata/TDgpt-demo
2. cd TDgpt-demo
3. chmod 775 analyse.sh

文件夹下包含docker-compose.yml、tdengine.yml两个yml文件。docker-compose.yml 包含了所有一键启动demo所需的镜像配置信息，其引用tdengine.yml作为Grafana的数据源配置。

TDgpt-demo/demo_data下包含三个csv文件（electricity_demand.csv、wind_power.csv、ec2_failure.csv），以及三个同前缀sql脚本，分别对应电力需求预测、风力发电预测和运维监控异常检测场景。

TDgpt-demo/demo_dashboard下包含了三个json文件（electricity_demand_forecast.json、wind_power_forecast.json、ec2_failure_anomaly.json），分别对应三个场景的看板。

docker-compose.yml中已经定义了TDengine容器的持久化卷：tdengine-data，待容器启动后，使用docker cp命令将demo_data拷贝至容器内使用。

运行和关闭Demo

注意：在运行demo前，请根据您宿主机的架构（CPU类型），编辑docker-compose.yml文件，为TDengine指定对应的platform参数：linux/amd64（Intel/AMD CPU）或linux/arm64（ARM CPU）。TDgpt必须统一使用linux/amd64参数。

进入docker-compose.yml文件所在的目录执行如下命令，启动TDengine、TDgpt和Grafana一体化演示环境：

1. docker-compose up -d

首次运行时，等待10s后请执行如下命令将TDgpt的Anode节点注册到TDengine：

1. docker exec -it tdengine taos -s "create anode 'tdgpt:6090'"

在宿主机执行下列命令，初始化体验测试环境的数据：

1. docker cp analyse.sh tdengine:/var/lib/taos
2. docker cp demo_data tdengine:/var/lib/taos
3. docker exec -it tdengine taos -s "source /var/lib/taos/demo_data/init_ec2_failure.sql"

关闭演示环境，请使用：

1. docker-compose down

进行演示

1. 打开浏览器，输入http://localhost:3000，并用默认的用户名口令admin/admin登录Grafana。

2. 登录成功后，进入路径”Home → Dashboards”页面，并且导入ec2_failure_anomaly.json文件。

3. 导入后，选择 “ec2_failure_anomaly”这个面板。面板已经配置好了真实值、k-Sigma以及Grubbs的检测结果。当前只有真实值的数据曲线。异常检测算法检测是异常窗口，并计算输出异常窗口内的统计特征。呈现结果时，将_wstart，即异常窗口的起始时间戳作为检测结果的时间戳，将异常窗口内的均值作为异常统计值输出。为了直观对比了两种算法的预测结果，k-Sigma算法的绘图点略大于Grubbs，从而让二者的结果不会被相互覆盖。

4. 我们以analyze.sh脚本，来进行异常检测。首先完成k-Sigma算法的演示：

1. docker exec -it tdengine /var/lib/taos/analyse.sh --type anomaly --db tdgpt_demo --table ec2_failure --stable single_val --algorithm ksigma --params "k=3" --start "2014-03-07" --window 7d --step 1h

上述shell脚本，将从指定的起始时间开始（2024-03-07）以七天的数据为输入，使用k-Sigma算法监测ec2_failure数据表中的异常，直到达到ec2_failure表中最后一天的记录，并将结果写入ec2_failure_ksigma_result表中。执行新的预测前，脚本会新建/清空对应的结果表。执行过程中将持续在控制台上，按照一小时为单位推进输出如下的执行结果：

1. taos> INSERT INTO ec2_failure_ksigma_result
2. SELECT _wstart, avg(val)
3. FROM ec2_failure
4. WHERE ts >= '2014-03-07 02:00:00' AND ts < '2014-03-14 02:00:00'
5. ANOMALY_WINDOW(val, 'algo=ksigma,k=3')
6. Insert OK, 10 row(s) affected (0.326801s)

这里使用1小时的预测推进步长（–step），仅仅是为了让动态检测过程能够很快的完成。–step也可以设置为更加细粒度的单位，例如5m，从而产生更加实时的检测结果。在具体应用场景下，请用户根据数据粒度、检测实时性以及计算资源灵活使用。

5. Grafana的看板上，配置刷新频率为5s，将动态显示预测结果的黄色曲线，直观呈现与实际值的对比。为了展示清晰，请按住command键点击左下角的Real以及ksigma图例（Mac下，Windows下请使用win键），从而只保留这两条曲线展示。

6. 完成Grubbs模型的演示：

1. docker exec -it tdengine /var/lib/taos/analyse.sh --type anomaly --db tdgpt_demo --table ec2_failure --stable single_val --algorithm grubbs --start "2014-03-07" --window 7d --step 1h

与第四步类似，HoltWinters模型将动态输出预测结果并呈现在看板上。从预测结果中可以看到，相比于采用默认参数k=3的k-Sigma算法，Grubbs算法的异常检测误差较小。k-Sigma产生了较多的误报情况。

基于鼠标圈选的方式，我们可以查看一段时间内的细粒度预测结果对比：

您也可以尝试其他算法或模型，来找到最合适自己场景的算法和模型。

Demo脚本使用详解

脚本概述 

analyse.sh脚本用于在 TDengine 数据库上执行时间序列预测和异常检测分析，支持滑动窗口算法处理。主要功能包括：

• 时间序列预测 ：使用 HoltWinters 等算法进行未来值预测 。
• 异常检测 ：使用 k-Sigma 等算法识别数据异常点 。
• 自动窗口滑动 ：支持自定义窗口大小和步长进行连续分析。

参数说明

TDengine推荐使用超级表来进行数据建模。因此，Demo中建立了一个名为single_val的超级表，包含 ts (timestamp类型) 和val (float类型)，以及标签定义 scene (varchar (64))。现阶段 TDgpt 只支持单列值输入输出，因此这个超级表可以作为所有源数据表和结果表的结构定义。子表的表名与tag名称保持一致即可。

db参数指定了源数据表和结果表隶属的数据库。结果表将以【源表名称】_【算法名称】_【result】格式存储。Grafana里面通过查询结果表实现分析结果和原始数据的对比。

一般情况下，对于非必填项，用户在demo过程中只需要设置–start参数以节省运行时间。对于必填项，请参考示例值进行设置。

时间格式说明

step和window参数指定的滑动步长和分析窗口大小需符合如下参数约定：

脚本执行流程

1. graph TDgpt_Demo
2. A[开始] --> B[参数解析与验证]
3. B --> C{是否指定start?}
4. C -->|否| D[查询最小时间戳]
5. C -->|是| E[转换时间格式]
6. D --> E
7. E --> F[计算时间窗口]
8. F --> G[生成结果表]
9. G --> H{是否到达数据终点?}
10. H -->|否| I[生成并执行SQL]
11. I --> H
12. H -->|是| J[输出完成信息]

使用更多的数据

参考「运行和关闭Demo」章节里ec2_failure.sql脚本的内容，确保按照规定格式将数据准备为csv格式（逗号分隔，值需要用英文双引号括起来），即可将数据导入TDengine。然后，请使用「进行演示」中的方法来生成异常检测结果，并调整Grafana中的看板以实现和实际数据的对比。

结论

在本文中，我们展示了使用TDgpt来运维监控异常检测的完整流程。从中可以看到，基于TDgpt来构建时序数据分析，能够以SQL方式实现与应用的便捷集成，大大降低开发和应用时序预测和异常检测的成本。

在不同的实际场景下，用户需要针对数据特点，针对模型算法进行选择和参数调优。TDgpt的企业版中，将为用户提供更多的选择：

• 模型选择器。模型选择器可以自动根据用户的历史数据集，对购买的所有模型进行准确性评估。用户可选择最适合自己场景的模型进行部署和应用。
• TDtsfm_1自研模型的重训练及微调。TDtsfm_1基于海量时序数据进行了预训练，在大部分场景下相比于传统的机器学习和统计预测模型都会有显著的准确率优势。如果用户对于模型预测准确度有更高的要求，可以申请购买TDgpt企业版的预训练服务。使用用户的场景历史数据进行预训练，在特定场景下的预测效果可能更佳。
• 第三方解决方案。涛思数据联合国内外时序分析/异常检测专业厂家、研究机构，为用户提供专业的分析解决方案，包括落地过程中的实施服务等。

关于背景

在服务器运维工作中，时刻关注CPU、内存、硬盘和网络这些核心指标就像定期给汽车做体检。通过持续监控这些数据，我们不仅能了解系统运行状况，还能借助智能分析工具提前发现隐患。比如当CPU使用率突然飙升，可能是程序升级后出现了代码漏洞，或是服务器被植入了挖矿病毒，也可能是硬件老化的信号。 常见的CPU异常波动原因包括：程序更新后线程池配置错误引发的频繁切换、恶意软件占用计算资源、磁盘损坏导致系统反复纠错，以及促销活动带来的突发流量压力。有些波动属于正常现象，比如每天定时任务运行时的规律性峰值；但如果是突然出现的持续性高负载，就需要立即排查处理。 

传统的监控方式依赖人工设定固定阈值，就像用同一把尺子测量不同季节的河水流量，容易产生误判。现在通过分析历史数据建立动态基线，系统能自动识别出真正的异常波动。比如某次版本更新后，算法发现某服务的CPU占用比平时高30%，立即触发告警，而过去这种波动可能被误认为是正常业务增长。 这种智能监控带来的好处实实在在：既避免了半夜被误报警报吵醒，又能真正拦截那些可能导致服务器宕机的严重问题。通过对比服务器正常状态和异常模式，系统就像经验丰富的运维工程师，能准确区分程序漏洞、安全攻击和硬件故障等不同问题类型，为后续处理提供明确方向。

本文提供基于 docker-compose 快速部署 TDgp 体验测试环境的指引，并基于这个环境和真实的数据，展示运维监控场景下进行异常检测的全过程。便于大家快速掌握 TDgpt，迅速让自己拥有AI驱动的时序数据预测与异常检测的能力。

关于TDgpt

TDgpt 是 TDengine 内置的时序数据分析智能体，它基于 TDengine 的时序数据查询功能，通过 SQL 提供运行时可动态扩展和切换的时序数据高级分析的能力，包括时序数据预测和时序数据异常检测。通过预置的时序大模型、大语言模型、机器学习、传统的算法，TDgpt 能帮助工程师在10分钟内完成时序预测与异常检测模型的上线，降低至少80%的时序分析模型研发和维护成本。

截止到3.3.6.0版本，TDgpt 提供Arima、HoltWinters、LSTM、MLP 以及基于Transformer架构自研的TDtsfm (TDengine time series foundation model) v1版和其他时序模型，以及k-Sigma、Interquartile range(IQR)、Grubbs、SHESD、Local Outlier Factor(LOF)、Autoencoder这六种异常检测模型。用户可以根据TDgpt开发指南自行接入自研或其他开源的时序模型或算法。