作者：?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，您計算機上需要安裝有下屬軟件：
- Git
- Docker Engine: v20.10+
- Docker Compose: v2.20+
Demo中包含 3 個 docker 鏡像 (TDengine, TDgpt, Grafana)，以及一組用于產生預測/異常檢測結果的shell腳本。組件版本的要求如下：
克隆Demo倉庫到本地
git clone https://github.com/taosdata/TDgpt-democd TDgpt-demochmod 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一體化演示環境：
docker-compose up -d
首次運行時，等待10s后請執行如下命令將TDgpt的Anode節點注冊到TDengine：
docker exec -it tdengine taos -s "create anode 'tdgpt:6090'"
在宿主機執行下列命令，初始化體驗測試環境的數據：
docker cp analyse.sh tdengine:/var/lib/taosdocker cp demo_data tdengine:/var/lib/taosdocker exec -it tdengine taos -s "source /var/lib/taos/demo_data/init_ec2_failure.sql"
關閉演示環境，請使用：
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算法的演示：
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表中。執行新的預測前，腳本會新建/清空對應的結果表。執行過程中將持續在控制臺上，按照一小時為單位推進輸出如下的執行結果：
taos> INSERT INTO ec2_failure_ksigma_resultSELECT _wstart, avg(val)FROM ec2_failureWHERE ts >= '2014-03-07 02:00:00' AND ts < '2014-03-14 02:00:00'ANOMALY_WINDOW(val, 'algo=ksigma,k=3')Insert OK, 10 row(s) affected (0.326801s)
這里使用1小時的預測推進步長（–step），僅僅是為了讓動態檢測過程能夠很快的完成。–step也可以設置為更加細粒度的單位，例如5m，從而產生更加實時的檢測結果。在具體應用場景下，請用戶根據數據粒度、檢測實時性以及計算資源靈活使用。
5. Grafana的看板上，配置刷新頻率為5s，將動態顯示預測結果的黃色曲線，直觀呈現與實際值的對比。為了展示清晰，請按住command鍵點擊左下角的Real以及ksigma圖例（Mac下，Windows下請使用win鍵），從而只保留這兩條曲線展示。
6. 完成Grubbs模型的演示：
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參數指定的滑動步長和分析窗口大小需符合如下參數約定：
腳本執行流程
graph TDgpt_DemoA[開始] --> B[參數解析與驗證]B --> C{是否指定start?}C -->|否| D[查詢最小時間戳]C -->|是| E[轉換時間格式]D --> EE --> F[計算時間窗口]F --> G[生成結果表]G --> H{是否到達數據終點?}H -->|否| I[生成并執行SQL]I --> HH -->|是| 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開發指南自行接入自研或其他開源的時序模型或算法。
