如需與 Amazon Timestream for LiveAnalytics 類似的功能，請考慮使用 Amazon Timestream for InfluxDB。它提供簡化的資料擷取和單一位數毫秒查詢回應時間，以進行即時分析。[在這裡](https://docs.aws.amazon.com//timestream/latest/developerguide/timestream-for-influxdb.html)進一步了解。
本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# InfluxDB 2 的 Timestream 監控和組態最佳化
## 概觀
有效的監控和組態最佳化對於在 Timestream for InfluxDB 部署中維持最佳效能、可靠性和成本效益至關重要。本指南提供 CloudWatch 指標、效能閾值和組態調校策略的完整指引，協助您主動管理 InfluxDB 執行個體。
## CloudWatch 指標參考
Amazon CloudWatch 提供監控 Timestream for InfluxDB 執行個體的詳細指標。了解這些指標及其閾值對於維護系統運作狀態和效能至關重要。
### 資源使用率指標
| CloudWatch 指標名稱 | 維度 | Description | 單位 | 建議的閾值 |
| --- | --- | --- | --- | --- |
| CPUUtilization | DbInstanceName | 使用的 CPU 百分比 | 百分比 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| MemoryUtilization | DbInstanceName | 使用的記憶體百分比 | 百分比 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| HeapMemoryUsage | DbInstanceName | 使用中的堆積記憶體數量 | 位元組 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| ActiveMemoryAllocation | DbInstanceName | 目前作用中記憶體配置 | 位元組 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| DiskUtilization | DbInstanceName | 正在使用的磁碟空間百分比 | 百分比 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
### I/O 操作指標
| CloudWatch 指標名稱 | 維度 | Description | 單位 | 建議的閾值 |
| --- | --- | --- | --- | --- |
| ReadOpsPerSec | DbInstanceName | 每秒讀取操作的數量 | 計數/秒 | 保持低於佈建 IOPS 的 ≥ 30% 總空間範例：12K IOPS → 保持總計 < 8，400 IOPS |
| WriteOpsPerSec | DbInstanceName | 每秒寫入操作數 | 計數/秒 | 保持低於佈建 IOPS 的 ≥ 30% 總空間範例：12K IOPS → 保持總計 < 8，400 IOPS |
| TotalIOpsPerSec | DbInstanceName | 每秒的總 I/O 操作數 （讀取 \$1 寫入） | 計數/秒 | 保持低於佈建 IOPS 的 ≥ 30% 總空間針對執行個體類別功能進行監控 |
### 輸送量指標
| CloudWatch 指標名稱 | 維度 | Description | 單位 | 建議的閾值 |
| --- | --- | --- | --- | --- |
| ReadThroughput | DbInstanceName | 資料讀取輸送量 | 位元組/秒 | 監控儲存輸送量限制 |
| WriteThroughput | DbInstanceName | 資料寫入輸送量 | 位元組/秒 | 監控儲存輸送量限制 |
### API 效能指標
| CloudWatch 指標名稱 | 維度 | Description | 單位 | 建議的閾值 |
| --- | --- | --- | --- | --- |
| APIRequestRate | DbInstanceName、端點、狀態 | 使用狀態碼 (2xx、4xx、5xx) 對特定端點提出 API 請求的速率 | 計數/秒 | 錯誤率： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| QueryResponseVolume | DbInstanceName、端點、狀態 | 依端點和狀態碼的查詢回應量 | 位元組 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
### 查詢執行指標
| CloudWatch 指標名稱 | 維度 | Description | 單位 | 建議的閾值 |
| --- | --- | --- | --- | --- |
| QueryRequestsTotal | DbInstanceName，結果 | 依結果類型區分的查詢請求總數 （成功、執行時間\$1錯誤、編譯\$1錯誤、佇列\$1錯誤） | 計數 | 成功率：> 99% 錯誤率： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
### 資料組織指標
| CloudWatch 指標名稱 | 維度 | Description | 單位 | 關鍵閾值 |
| --- | --- | --- | --- | --- |
| SeriesCardinality | DbInstanceName，儲存貯體 | 儲存貯體中唯一時間序列的數量 | 計數 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| TotalBuckets | DbInstanceName | 執行個體中的儲存貯體總數 | 計數 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
### 系統運作狀態指標
| CloudWatch 指標名稱 | 維度 | Description | 單位 | 建議的閾值 |
| --- | --- | --- | --- | --- |
| EngineUptime | DbInstanceName | InfluxDB 引擎執行的時間 | 秒鐘 | 監控意外重新啟動提醒：執行時間意外重設 |
| WriteTimeouts | DbInstanceName | 逾時的寫入操作數目 | 計數 | 提醒：> 0.1% 的寫入操作關鍵：增加趨勢 |
### 任務管理指標
| CloudWatch 指標名稱 | 維度 | Description | 單位 | 建議的閾值 |
| --- | --- | --- | --- | --- |
| ActiveTaskWorkers | DbInstanceName | 作用中任務工作者的數量 | 計數 | 根據設定的任務工作者限制進行監控提醒：持續達到上限 |
| TaskExecutionFailures | DbInstanceName | 失敗的任務執行次數 | 計數 | 提醒：> 1% 的任務執行關鍵：提高失敗率 |
### 了解關鍵指標關係
#### IOPS 和輸送量關係
**30% 標頭規則：**在每秒的持續操作與佈建的 IOPS 之間，永遠保持至少 **30% 的標頭**。這會為下列項目提供緩衝：
+ 壓縮操作 （可大幅激增 IOPS)
+ 任何資料庫重新啟動以順利執行
+ 尖峰用量期間的查詢暴增
+ 從批次擷取寫入峰值
+ 索引維護操作
**計算範例：**
+ 佈建 IOPS：12，000
+ 目標持續 IOPS 上限 (TotalIOpsPerSec)：8，400 (70% 使用率）
+ 預留會議室：3，600 IOPS (30%)
如果 TotalIOpsPerSec 持續超過 8，400：→ 升級儲存層或最佳化工作負載
**監控公式：**
IOPS 使用率 % = (ReadOpsPerSec \$1 WriteOpsPerSec)/佈建 IOPS × 100
+ 目標：保持 IOPS 使用率 < 70%
+ 警告：IOPS 使用率 > 70%
+ 關鍵：IOPS 使用率 > 90%
### 了解系列基數效能影響
系列基數對系統資源具有乘法效果：
| **系列計數** | **記憶體影響** | **查詢效能影響** | **索引大小影響** | **建議** |
| --- | --- | --- | --- | --- |
| < 100K | 極小 | 可忽略 | 小型 | 標準組態 |
| 100K - 1M | 適中 | 慢 10-20% | 中 | 調校快取設定 |
| 1M - 5M | 重要 | 慢 30-50% | 大型 | 需要積極最佳化 |
| 5M - 10M | 高 | 50-70% 慢 | 非常大 | 最大調校，請考慮重新設計 |
| > 10M | 嚴重 | 70%\$1 較慢 | 過多 | 遷移至 InfluxDB 3.0 |
**為什麼 10M 是關鍵閾值：**
+ InfluxDB 2.x 架構使用記憶體內索引
+ 超過 10M個系列，索引操作變得過於昂貴
+ 記憶體需求以非線性方式成長
+ 查詢規劃額外負荷大幅增加
+ InfluxDB 3.0 使用專為高基數設計的單欄式儲存引擎
## 執行個體大小和效能指導方針
下表提供根據您的系列基數和工作負載特性，適當調整執行個體大小的指引：
| **最大序列計數** | **寫入 （行/秒）** | **讀取 （查詢/秒）** | **建議的執行個體** | **儲存類型** | **使用案例** |
| --- | --- | --- | --- | --- | --- |
| < 100K | \$150，000 | < 10 | db.influx.large | Influx IO 已包含 3K | 小型部署、開發、測試 |
| < 1M | \$1150，000 | < 25 | db.influx.2xlarge | Influx IO 已包含 3K | 中小型生產工作負載 |
| \$1100 萬 | \$1200，000 | \$125 | db.influx.4xlarge | Influx IO 已包含 3K | 中型生產工作負載 |
| < 5M | \$1250，000 | \$135 | db.influx.4xlarge | Influx IO 已包含 12K | 大型生產工作負載 |
| < 10M | \$1500，000 | \$150 | db.influx.8xlarge | Influx IO 已包含 12K | 非常大型的生產工作負載 |
| \$11000 萬 | < 750，000 | < 100 | db.influx.12xlarge | Influx IO 已包含 12K | InfluxDB 2.x 容量上限 |
| > 10M | N/A | N/A | 遷移至 InfluxDB 3.0 | N/A | 超越 InfluxDB 2.x 最佳範圍 |
## 依指標的組態最佳化
### 高 CPU 使用率 (CPUUtilization > 70%)
**徵狀：**
+ **CPUUtilization** > 70% 持續
+ **QueryRequestsTotal** （大量或慢查詢）
+ **ActiveTaskWorkers** （高任務負載）
**組態調整：**
**優先順序 1：控制查詢並行**
+ query-concurrency：設定為 vCPU 計數的 50-75%
+ 範例：8 個 vCPU 執行個體 → query-concurrency = 4-6
**優先順序 2：限制查詢複雜性**
+ influxql-max-select-series：10000 （避免未限制的查詢）
+ influxql-max-select-point：100000000
+ query-queue-size：2048 （防止佇列建置）
**優先順序 3：啟用查詢分析**
+ flux-log-enabled：TRUE （暫時用於偵錯）
+ 日誌層級：資訊 （或偵錯以進行詳細分析）
**重要考量事項：**
減少 `query-concurrency` 會限制可同時執行的查詢數量，這可能會增加排入佇列的查詢，並在尖峰期間導致較高的查詢延遲。如果查詢需求超過減少的並行限制，使用者可能會遇到較慢的儀表板載入或報告逾時。
設定保護限制 (`influxql-max-select-series`、`influxql-max-select-point`) 會導致超出這些閾值的查詢在 **QueryRequestsTotal** 中因 **compile\$1error** 或 **runtime\$1error** 失敗。雖然這可保護系統免於資源耗盡，但可能會中斷先前運作的現有查詢。
**最佳實務：**套用這些變更之前，請使用 **QueryResponseVolume** 和 **QueryRequestsTotal** 指標來分析查詢模式。首先識別和最佳化最昂貴的查詢 - 尋找沒有時間範圍篩選條件的查詢、跨越高基數序列的查詢，或請求過多資料點的查詢。在應用程式層級最佳化查詢，一律比強於強加可能破壞功能的硬性限制。
**硬體動作：**
+ 使用更多 vCPUs擴展到下一個執行個體類別
+ 檢閱查詢模式以取得最佳化機會
### 記憶體使用率過高 (MemoryUtilization > 70%)
**徵狀：**
+ **MemoryUtilization** > 70% 持續
+ **HeapMemoryUsage** 上升趨勢
+ **ActiveMemoryAllocation** 顯示峰值
+ **SeriesCardinality** （高基數會增加記憶體用量）
**組態調整：**
**優先順序 1：減少快取記憶體**
+ storage-cache-max-memory-size：設定為總 RAM 的 10-15%
+ 範例：32GB RAM → 3，355，443，200 到 5，033，164，800 個位元組
+ storage-cache-snapshot-memory-size：26，214，400 (25MB)
**優先順序 2：限制查詢記憶體**
+ query-memory-bytes：設定為總 RAM 的 60-70%
+ query-max-memory-bytes：與 query-memory-bytes 相同
+ query-initial-memory-bytes：query-memory-bytes的 10%
**優先順序 3：最佳化系列快取**
+ storage-series-id-set-cache-size：如果基數高，則減少
+ 高記憶體：100-200
+ 正常：500-1000
**重要考量事項：**
雖然這些變更會降低記憶體壓力，但對應用程式效能會有直接的負面影響。減少`storage-cache-max-memory-size`表示記憶體中快取的資料較少，強制讀取更多磁碟並增加查詢延遲 - 您可能會看到 **ReadOpsPerSec** 增加和 **QueryResponseVolume** 回應時間降低。
限制`query-memory-bytes`會導致 **QueryRequestsTotal** 中**執行時間\$1錯誤**導致記憶體密集型查詢失敗，尤其是彙總大型資料集或傳回大量結果集的查詢。對於先前成功的查詢，使用者可能會遇到「記憶體不足」錯誤。
降低針對高基數資料的查詢效能`storage-series-id-set-cache-size`，因為系統必須更頻繁地重新計算序列結果，而不是從快取中擷取結果。這尤其會影響重複查詢相同序列組合的儀表板。
**最佳實務：**套用這些限制性變更之前，請先分析您的查詢模式並將其最佳化：
+ 檢閱 **QueryResponseVolume** 以識別傳回過多資料的查詢
+ 使用 **QueryRequestsTotal** 尋找可能受益於最佳化的經常執行查詢
+ 新增時間範圍篩選條件，以減少對工作負載所需的資料掃描
+ 在應用程式層級實作查詢結果快取
+ 考慮使用縮減取樣任務預先彙總資料
+ 檢閱 **SeriesCardinality** 並最佳化您的資料模型，以減少不必要的標籤
查詢最佳化應始終是您的第一個方法 - 當最佳化不足時，組態限制應該是最後一個手段。
**硬體動作：**
+ 增加更多 RAM 的執行個體大小
### 高儲存使用率 (DiskUtilization > 70%)
**要監控的 CloudWatch 指標：**
+ **DiskUtilization** > 70%
+ **WriteThroughput** 模式
+ **TotalBuckets** （許多儲存貯體會增加額外負荷）
**組態調整：**
**優先順序 1：檢查記錄組態**
+ log-level：確保設定為 "info" （而非 "debug")
+ flux-log-enabled：除非主動偵錯，否則設定為 FALSE
**優先順序 2：積極保留**
+ storage-retention-check-interval：15m0s （更頻繁的清理）
**優先順序 3：最佳化壓縮**
+ storage-compact-full-write-cold-duration：2h0m0s （較頻繁）
+ storage-cache-snapshot-write-cold-duration：5 公尺0 秒
**優先順序 4：減少索引大小**
+ storage-max-index-log-file-size：524，288 (512KB，用於更快速壓縮）
**重要考量事項：**
**關鍵第一步驟 - 檢查您的記錄組態：**進行任何其他變更之前，請先驗證您的記錄設定。**偵錯記錄和 Flux 查詢日誌可能會耗用比實際時間序列資料多或多的磁碟空間**，這是非預期儲存體耗盡的最常見原因之一。
**記錄影響：**
+ `log-level: debug` 產生極端詳細的日誌，每小時可能數百 MB
+ `flux-log-enabled: TRUE` 使用完整詳細資訊記錄每個 Flux 查詢執行，建立大量日誌檔案
+ 這些日誌會快速累積，且通常在容量規劃期間會遭到忽略
+ 日誌檔案的磁碟空間填充速度比資料擷取更快，特別是在較小的執行個體上
+ 與時間序列資料不同，日誌會在刪除前保留在本機儲存 24 小時
**日誌大型時的立即動作：**
1. 設定 `log-level: info`（從除錯）
1. 設定 `flux-log-enabled: FALSE`
1. 監控 **DiskUtilization** 以立即改善
**壓縮組態權衡：**
這些組態變更專為具有**高擷取輸送量和短期保留時段**的工作負載而設計，其中磁碟用量會大幅波動。它們強制壓縮引擎更積極地工作，這僅在特定案例中有用。
**關鍵權衡：**增加壓縮頻率將大幅增加資源消耗：
+ **CPUUtilization** 將隨著壓縮操作使用 CPU 週期而增加
+ 隨著資料載入和處理，**MemoryUtilization** 會在壓縮期間增加
+ **WriteOpsPerSec** 和 **WriteThroughput** 會在壓縮時段激增，可能會超過您的 30% IOPS 空間
+ 如果壓縮 I/O 與應用程式寫入競爭，則 **WriteTimeouts** 可能會增加
這些變更可能會產生層疊效能問題，其中積極壓縮會耗用查詢和寫入操作所需的資源，即使減少磁碟使用量，也會降低整體系統效能。
**最佳實務：**調整壓縮設定之前，專注於資料和記錄管理：
1. **檢查記錄優先 （最常見的問題）：**確認日誌層級為「資訊」，且flux-log-enabled的功能為 FALSE
1. **檢閱您的資料模型：**您是否正在撰寫實際不需要的資料？ 您可以減少測量或欄位精細程度嗎？
1. **最佳化保留政策：**檢查 **TotalBuckets** 並檢閱每個儲存貯體的保留設定
1. **監控壓縮影響：**變更前將 **CPUUtilization**、**MemoryUtilization** 和 **WriteOpsPerSec** 作為基準
**替代方法：**
+ 增加儲存容量 （通常更簡單且更具成本效益）
+ 實作資料縮減取樣或彙總策略
+ 合併儲存貯體 （減少 **TotalBuckets**) 以減少額外負荷
+ 更嚴格地檢閱和強制執行保留政策
只有在您已最佳化資料管理並確認執行個體有足夠的 CPU、記憶體和 IOPS 空間來處理增加的負載時，才套用積極的壓縮設定。
**硬體動作：**
+ 增加儲存容量
### 高 IOPS 使用率 (ReadIOPS/WriteIOPS/TotalOperationsPerSecond > 佈建的 70%)
**要監控的 CloudWatch 指標：**
+ **ReadOpsPerSec** \$1 **WriteOpsPerSec** = **TotalIOpsPerSec**
+ **ReadThroughput** 和 **WriteThroughput**
+ 比較佈建 IOPS (3K、12K 或 16K)
**組態調整：**
**優先順序 1：控制壓縮 I/O**
+ storage-max-concurrent-compactions：2-3 （限制並行壓縮）
+ storage-compact-throughput-burst：根據磁碟功能調整
+ 3K IOPS：25，165，824 (24MB/s)
+ 12K IOPS：50，331，648 (48MB/s)
**優先順序 2：最佳化寫入操作**
+ storage-wal-max-concurrent-writes：8-12
+ storage-wal-max-write-delay：5m0s
**優先順序 3：調整快照計時**
+ storage-cache-snapshot-write-cold-duration：15m0s （頻率較低）
+ storage-compact-full-write-cold-duration：6h0m0s （頻率較低）
**重要考量事項：**
這些變更會在 I/O 使用率和系統效能之間產生重大權衡：
**限制壓縮 I/O：**
+ 減少 `storage-max-concurrent-compactions`會減慢壓縮操作速度，導致 TSM 檔案累積並更快速地增加 **DiskUtilization**
+ `storage-compact-throughput-burst` 縮短壓縮持續時間，讓壓縮器保持作用更久，並可能封鎖其他操作
+ 壓縮速度變慢表示查詢效能會隨著時間降低，因為儲存引擎必須讀取更多、更小的 TSM 檔案，而不是合併的 TSM 檔案
+ 隨著等待 I/O 時的查詢逾時，您可能會看到 **QueryRequestsTotal** runtime\$1error 率增加
**降低快照頻率：**
+ 增加 `storage-cache-snapshot-write-cold-duration` 和 `storage-compact-full-write-cold-duration`表示資料會保留在預先寫入日誌 (WAL) 中較長的時間
+ 這會增加 **MemoryUtilization**，因為在排清至磁碟之前，快取中會保留更多資料
+ 如果執行個體在快取資料保留之前當機，則資料遺失的風險會稍微增加
+ 隨著必須重新播放更多 WAL 資料，重新啟動後的復原時間會增加
**寫入操作調校：**
+ 減少 `storage-wal-max-concurrent-writes` 會序列化更多寫入操作，在高輸送量期間可能會增加 **WriteTimeouts**
+ 增加`storage-wal-max-write-delay`表示寫入可能會等待更長的時間才會遭到拒絕，這可能會掩蓋容量問題，但使回應緩慢的使用者感到沮喪
**最佳實務：**高 IOPS 使用率通常表示您已超出儲存層，而不是組態問題。在限制 I/O 之前，請分析 I/O 模式並在限制之前進行最佳化。
**硬體動作：**
+ 升級到更高的 IOPS 儲存層 (3K → 12K)
+ 確保維持 30% IOPS 的前端空間
### 高序列基數 (SeriesCardinality > 1M)
**要監控的 CloudWatch 指標：**
+ 每個儲存貯體和總計的 **SeriesCardinality**
+ **MemoryUtilization** （以基數增加）
+ **CPUUtilization** （查詢規劃開銷）
+ **QueryRequestsTotal** (runtime\$1error rate 可能會增加）
**組態調整：**
**優先順序 1：最佳化序列處理**
+ storage-series-id-set-cache-size：1000-2000 （增加快取）
+ storage-series-file-max-concurrent-snapshot-compactions：4-8
**優先順序 2：設定保護限制**
+ influxql-max-select-series：10000 （避免失控查詢）
+ influxql-max-select-buckets：1000
**優先順序 3：最佳化索引操作**
+ storage-max-index-log-file-size：2，097，152 (2MB)
**重要考量事項：**
高序列基數基本上是資料建模問題，而不是組態問題。組態變更只能緩解症狀 - 它們無法解決基礎問題。
**組態權衡：**
增加 `storage-series-id-set-cache-size`將透過快取序列查詢來改善查詢效能，但代價是增加 **MemoryUtilization**。每個快取項目都會耗用記憶體，而且有數百萬個序列，這可能很重要。進行此變更後，請監控 **HeapMemoryUsage** 和 **ActiveMemoryAllocation**。
如果合法查詢超過這些閾值，設定保護限制 (`influxql-max-select-series`、`influxql-max-select-buckets`) 會導致 **QueryRequestsTotal** 中的 **compile\$1error** 失敗。先前運作的儀表板可能會中斷，使用者將需要修改其查詢。這對於以下方面特別有問題：
+ 監控跨許多主機/服務彙總的儀表板
+ 需要比較多個實體的分析查詢
+ 警示評估整個機群條件的查詢
調整`storage-max-index-log-file-size`為較小的值會增加索引壓縮頻率，這會在系統執行更頻繁的索引維護時提高 **CPUUtilization** 和 **WriteOpsPerSec**。
**關鍵了解：**
當 **SeriesCardinality** 超過 5M 時，您將接近 InfluxDB 2.x 的架構限制。在 10M\$1 系列，無論組態為何，效能都會呈指數下降：
+ 查詢規劃變得過於昂貴 （高 **CPUUtilization**)
+ 記憶體需求非線性成長 （高 **MemoryUtilization**)
+ 索引操作主控 I/O (**ReadOpsPerSec**、 **WriteOpsPerSec**)
+ **QueryRequestsTotal** runtime\$1error 率會隨著查詢逾時或耗盡記憶體而增加
**最佳實務：**組態變更是臨時頻帶輔助。您必須解決根本原因：
1. **分析您的資料模型：**
+ 檢閱每個儲存貯體的 **SeriesCardinality**，以識別問題區域
+ 識別哪些標籤具有較高的唯一值計數
+ 尋找未限制的標籤值 (UUIDs、時間戳記、使用者 IDs、工作階段 IDs)
+ 尋找應該是欄位的標籤
**資料模型動作：**
+ 檢閱標籤設計以減少不必要的基數
+ 考慮合併類似的序列
+ **如果 > 10M 系列：**計劃遷移至 InfluxDB 3.0
### 查詢效能問題
**要監控的 CloudWatch 指標：**
+ **QueryRequestsTotal** 依結果類型 （成功、執行時間\$1錯誤、編譯\$1錯誤、佇列\$1錯誤）
+ 狀態 = 500 或狀態 = 499 的 **APIRequestRate**
+ **QueryResponseVolume** （大型回應表示昂貴的查詢）
**組態調整：**
**優先順序 1：增加查詢資源**
+ query-concurrency：增加至 vCPUs的 75%
+ query-memory-bytes：配置總 RAM 的 70%
+ query-queue-size：4096
**優先順序 2：最佳化查詢執行**
+ storage-series-id-set-cache-size：1000 （增加以改善快取）
+ http-read-timeout：60 秒 （避免過早逾時）
**優先順序 3：設定合理的限制**
+ influxql-max-select-point：100000000
+ influxql-max-select-series：10000
+ influxql-max-select-buckets：1000
**重要考量事項：**
增加查詢資源會造成資源競爭和潛在的系統不穩定：
**資源分配權衡：**
增加`query-concurrency`允許更多查詢同時執行，但每個查詢都會競爭 CPU 和記憶體：
+ **CPUUtilization** 會增加，在尖峰查詢期間可能達到飽和
+ 隨著更多查詢同時配置記憶體，**MemoryUtilization** 將會增加
+ 如果您在沒有足夠資源的情況下增加並行，所有查詢都會變慢，而不只是一些佇列
+ 如果並行查詢耗盡可用資源，則會有串聯失敗的風險
配置更多`query-memory-bytes`表示快取和其他操作可用的記憶體較少：
+ **HeapMemoryUsage** 將增加
+ `storage-cache-max-memory-size` 可能需要減少以補償
+ 較少的快取命中表示較高的 **ReadOpsPerSec** 和較慢的查詢效能
+ 如果查詢使用其完整配置，則系統更容易受到記憶體耗盡的影響
增加`query-queue-size`只會延遲問題 - 它無法解決容量問題：
+ 查詢在佇列中等待更久，增加end-to-end延遲
+ 使用者認為系統速度較慢，即使輸送量可能保持不變
+ 大型佇列可以遮罩基礎容量問題
+ **QueryRequestsTotal** queue\$1error rate 降低，但使用者體驗可能不會改善
增加`http-read-timeout`可防止過早取消查詢，但：
+ 長時間執行的查詢會耗用更長的資源，減少其他查詢的容量
+ 使用者在接收逾時錯誤之前等待更久
+ 可以隱藏應最佳化的低效率查詢
+ 如果累積許多慢查詢，可能會導致資源耗盡
**最佳實務：**查詢效能問題通常是由低效率的查詢造成，而不是資源不足。在增加資源配置之前：
1. **分析查詢模式：**
+ 檢閱 **QueryResponseVolume** 以識別傳回過多資料的查詢 (> 1MB)
+ 檢查 **QueryRequestsTotal** runtime\$1error 模式 - 造成失敗的原因為何？
+ 尋找狀態 = 499 （用戶端逾時） 的 **APIRequestRate** - 查詢太慢
+ 識別經常執行的昂貴查詢
1. **先最佳化查詢：**
常見查詢反模式：
+ 缺少時間範圍篩選條件 → 新增明確的時間範圍
+ 查詢所有系列 → 新增特定標籤篩選條件
+ 過度彙總時段 → 使用適當的間隔
+ SELECT 中不必要的欄位 → 僅請求所需的資料
+ 沒有 LIMIT 子句 → 新增合理的限制
1. **應用程式層級解決方案：**
+ 實作查詢結果快取 (Redis、Memcached)
+ 使用任務來預先彙總常見模式
+ 為大型結果集新增分頁
+ 實作每個使用者/儀表板的查詢速率限制
+ 使用縮減取樣的資料進行歷史查詢
1. **驗證資源可用性：**
+ 檢查 **CPUUtilization** - 如果已經 > 70%，增加並行將使情況變得更糟
+ 檢查 **MemoryUtilization** - 如果已經 > 70%，配置更多查詢記憶體將導致 OOM
+ 在增加查詢負載之前，確認 **TotalIOpsPerSec** 有 30% 的前端空間
**建議的方法：**
1. 首先最佳化前 10 個最昂貴的查詢 （依據 **QueryResponseVolume**)
1. 在應用程式層級實作查詢結果快取
1. 只有在查詢已最佳化且指標顯示總空間時，才能增加資源配置
1. 如果工作負載的目前容量已超過，則擴展到較大的執行個體類別
**硬體動作：**
+ 擴展您的運算容量，查詢受益於額外處理能力 vCPUs)
#### Flux 查詢中的 RegEx 效能缺陷
在 Flux 中篩選資料時，請避免將規則表達式用於完全相符或簡單的模式相符，因為這會導致嚴重的效能懲罰。Flux 中的 RegEx 操作是**單執行緒**，完全**略過基礎 TSM 索引**。RegEx 篩選條件不會利用 InfluxDB 的最佳化標籤索引進行快速查詢，而是強制查詢引擎從儲存體擷取所有相符的序列，並根據每個值依序執行文字比較。這在以下情況特別有問題：
+ **篩選確切的標籤值** - 使用等式運算子 (`==`) 或 `contains()`函數，而不是 RegEx 模式，例如 `/^exact_value$/`
+ **符合多個特定值** - 使用運算`in`子搭配一系列的值，而不是像 這樣的交替模式 `/(value1|value2|value3)/`
+ **簡單字首或尾碼相符** - 考慮使用 `strings.hasPrefix()`或 `strings.hasSuffix()`函數，這比 RegEx 錨點更有效率
對於需要多個模式相符的案例，請重組您的查詢，以使用與邏輯運算子結合的多個篩選條件述詞，或在套用更複雜的字串操作之前使用標籤等式預先篩選。僅針對需要真實模式比對的案例預留 RegEx，這些案例無法透過更簡單的比較運算子來表示。
### 寫入效能問題
**要監控的 CloudWatch 指標：**
+ **WriteTimeouts** （增加計數）
+ **WriteOpsPerSec** 和 **WriteThroughput**
+ 寫入端點的 **APIRequestRate** 狀態 = 500
+ **QueryRequestsTotal** 搭配寫入期間 results=runtime\$1error
**組態調整：**
**優先順序 1：最佳化 WAL 寫入**
+ storage-wal-max-concurrent-writes：12-16
+ storage-wal-max-write-delay：10m0s
+ http-write-timeout：60 秒
**優先順序 2：最佳化快取快照**
+ storage-cache-snapshot-memory-size：52，428，800 (50MB)
+ storage-cache-snapshot-write-cold-duration：10m0s
**優先順序 3：控制欄位驗證**
+ storage-no-validate-field-size：TRUE （如果資料來源受信任）
**重要考量事項：**
寫入效能調校涉及輸送量、可靠性和資源耗用量之間的謹慎權衡：
**WAL 組態權衡：**
增加`storage-wal-max-concurrent-writes`允許更多平行寫入操作，但：
+ 隨著更多寫入執行緒爭用 CPU，**CPUUtilization** 會增加
+ 在 WAL 排清之前，隨著記憶體中緩衝更多資料，**MemoryUtilization** 會增加
+ **WriteOpsPerSec** 將激增，可能超過您的 30% IOPS 空間
+ 磁碟 I/O 的爭用增加實際上可能會減慢個別寫入速度
+ 如果您超過磁碟 I/O 容量，則 **WriteTimeouts** 可能會增加而不是減少
增加`storage-wal-max-write-delay`表示寫入等待更長的時間才會逾時：
+ 透過讓寫入等待而非快速失敗來遮罩容量問題
+ 即使寫入最終成功，使用者的寫入回應時間也會變慢
+ 可能導致寫入佇列累積和記憶體壓力
+ 實際上不會增加容量 - 只是延遲逾時
增加`http-write-timeout`類似延遲逾時錯誤：
+ 允許較大的批次寫入完成
+ 但也允許慢速寫入耗用更長時間的資源
+ 可以隱藏基礎效能問題
+ 如果累積許多慢速寫入，可能會導致資源耗盡
**快取快照權衡：**
增加`storage-cache-snapshot-memory-size`表示在清除之前記憶體中累積更多資料：
+ **MemoryUtilization** 大幅增加
+ 如果執行個體在快照之前當機，資料遺失的風險會增加
+ 較大的快照需要更長的時間才能寫入，進而產生更大的 **WriteOpsPerSec** 峰值
+ 可以透過批次處理更多資料來改善寫入輸送量，但代價是記憶體和可靠性
增加`storage-cache-snapshot-write-cold-duration`延遲快照：
+ 隨著資料在快取中停留更久，進一步增加 **MemoryUtilization**
+ 增加資料遺失風險時段
+ 降低 **WriteOpsPerSec** 頻率，但在快照發生時產生更大的峰值
+ 重新啟動後的復原時間會增加，因為必須重新播放更多 WAL
**欄位驗證權衡：**
設定 會`storage-no-validate-field-size: TRUE`停用欄位大小驗證：
+ 略過驗證檢查以改善寫入輸送量
+ **重大風險：**允許寫入格式不正確或惡意的資料
+ 如果寫入包含無效的欄位大小，可能會導致資料損毀
+ 讓偵錯資料問題更加困難
+ **僅在您完全控制和信任資料來源時使用**
**最佳實務：**寫入效能問題通常表示容量限制或效率不佳的寫入模式。調校組態之前：
1. **分析寫入模式：**
+ 檢閱 **WriteThroughput** 和 **WriteOpsPerSec** 趨勢
+ 檢查 **WriteTimeouts** 與寫入負載的關聯性
+ 依狀態碼監控 **APIRequestRate** 是否有寫入端點
+ 識別寫入批次大小和頻率
1. **首先最佳化寫入操作：**
常見寫入反模式：
+ 寫入個別點 → 批次寫入 (5，000-10，000 點）
+ 寫入頻率太頻繁 → 緩衝區和批次
+ 同步寫入 → 實作非同步寫入佇列
+ 無限制的寫入爆量 → 實作速率限制
+ 撰寫不必要的精確度 → 適當的四捨五入時間戳記
1. **驗證 I/O 容量：**
+ 檢查 **TotalIOpsPerSec** - 如果已經 > 70%，增加 WAL 並行將使情況變得更糟
+ 在尖峰時段檢閱 **WriteOpsPerSec**
+ 在調校寫入設定之前，確保 30% IOPS 前端空間存在
+ 考慮 3K IOPS 是否足夠，或是否需要 12K IOPS 層
1. **應用程式層級改善：**
+ 使用可設定的批次大小實作寫入緩衝
+ 新增具有指數退避的寫入重試邏輯
+ 使用非同步寫入操作
+ 在尖峰時段實作寫入速率限制
+ 監控寫入佇列深度並套用背壓
**建議的方法：**
1. 首先最佳化應用程式層級的寫入批次大小 （每批次目標 5，000-10，000 點）
1. 實作寫入緩衝和非同步操作
1. 驗證 **TotalIOpsPerSec** 有足夠的空間
1. 如果持續超過 70% 的使用率，請升級至下一個儲存層 (3K IOPS → 12K IOPS → 16K IOPS)
1. 只有在寫入最佳化且 I/O 容量足夠時，才調整 WAL 設定
1. 除非您完全控制資料來源，否則**請勿**停用欄位驗證
**硬體動作：**
+ 升級到更高的 IOPS 儲存體 (3K → 12K → 16K)
+ 確保 I/O 標頭空間足夠
+ 如果 CPU 或記憶體受限，則擴展至較大的執行個體類別
## 監控最佳實務
### CloudWatch 警示組態
**關鍵警示 （需要立即動作）：**
**CPUUtilization：**
+ 閾值：> 90% 持續 5 分鐘
+ 動作：實作流量修補措施或運算擴展
**MemoryUtilization：**
+ 閾值：> 90% 持續 5 分鐘
+ 動作：實作流量修補措施或運算擴展
**DiskUtilization：**
+ 閾值：> 85%
+ 動作：嘗試透過刪除舊儲存貯體、更新保留組態或 Storage Scaling 來釋放空間
**TotalIOpsPerSec：**
+ 閾值：佈建 10 分鐘的 > 90%
+ 動作：實作流量修補措施或增加 IOPS
**SeriesCardinality：**
+ 閾值：> 10，000，000
+ 動作：檢閱您的資料模型，如果無法進行任何變更，請探索遷移至 InfluxDB 3 或碎片您的資料
**EngineUptime：**
+ 閾值：意外重設 (< 300 秒）
+ 動作：檢查是否與維護時段一致，如果未建立 Timestream 支援票證。
**警告警示 （需要調查）：**
**CPUUtilization：**
+ 閾值：> 70% 持續 15 分鐘
+ 動作：檢閱工作負載或流量的變更
**MemoryUtilization：**
+ 閾值：> 70% 持續 15 分鐘
+ 動作：檢閱工作負載或流量的變更
**DiskUtilization：**
+ 閾值：> 70%
+ 動作：檢閱保留政策
**TotalIOpsPerSec：**
+ 閾值：> 70% 的佈建 15 分鐘
+ 動作：檢閱工作負載或流量的變更
**QueryRequestsTotal (runtime\$1error)：**
+ 閾值：> 總查詢的 1%
+ 動作：檢閱工作負載或流量的變更
**WriteTimeouts：**
+ 閾值：> 1% 的寫入操作
+ 動作：檢閱工作負載或流量的變更
**SeriesCardinality：**
+ 閾值：> 5，000，000
+ 動作：檢閱資料模型最佳化
### 主動監控檢查清單
**每日：**
+ 檢閱 APIRequestRate 是否有錯誤峰值 (400、404、499、500)
+ 檢查 QueryRequestsTotal 的 runtime\$1error 和 queue\$1error 率
+ 驗證 WriteTimeouts 計數最少
+ 檢查是否有任何重要警示
+ 驗證 EngineUptime （沒有意外重新啟動）
**每週：**
+ 檢閱 CPUUtilization、MemoryUtilization 和 DiskUtilization 趨勢
+ 依結果類型分析 QueryRequestsTotal 模式
+ 檢查每個儲存貯體的 SeriesCardinality 成長速率
+ 檢閱 TotalIOpsPerSec 使用率趨勢
+ 確認組態參數為最佳
+ 檢閱 TaskExecutionFailures 模式
**每月：**
+ 容量規劃審查 （專案提前 3-6 個月）
+ 比較目前的指標與大小調整資料表
+ 檢閱和最佳化保留政策
+ 從 APIRequestRate 和 QueryResponseVolume 分析查詢模式
+ 檢閱 SeriesCardinality 和資料模型效率
+ 評估執行個體擴展或組態變更的需求
+ 檢閱 TotalBuckets 和整合機會
## 故障診斷指南
### 案例：突然效能降級
**調查步驟：**
**檢查最近的變更：**
+ AWS 管理主控台中的組態參數修改
+ 應用程式部署變更
+ 查詢模式變更
+ 資料模型修改
+ 基礎設施變更 （執行個體類型、儲存體）
**檢閱 CloudWatch 指標：**
+ **CPU 峰值？** → 檢查 CPUUtilization、QueryRequestsTotal
+ **記憶體壓力？** → 檢查 MemoryUtilization、HeapMemoryUsage、ActiveMemoryAllocation
+ **IOPS 飽和度？** → 檢查 TotalIOpsPerSec、ReadOpsPerSec、 WriteOpsPerSec
+ **系列基數跳躍？** → 檢查 SeriesCardinality 成長
+ **錯誤率增加？** → 檢查 QueryRequestsTotal (runtime\$1error)、APIRequestRate (Status=500)
+ **意外重新啟動？** → 檢查 EngineUptime
**啟用詳細記錄：**
組態變更：
+ 日誌層級：偵錯
+ flux-log-enabled：TRUE
監控 1-2 小時，然後檢閱日誌
返回日誌層級：調查後的資訊
**解決步驟：**
+ 根據調查結果套用適當的組態變更
+ 達到限制時擴展資源
+ 視需要最佳化查詢或資料模型
+ 如果負載突然增加，請實作速率限制
### 案例：記憶體耗盡
**徵狀：**
+ MemoryUtilization > 90%
+ HeapMemoryUsage 接近上限
+ QueryRequestsTotal 顯示 runtime\$1error （記憶體不足）
+ APIRequestRate 顯示 Status=500
**解決步驟：**
立即動作 （如果重要）：
1. 重新啟動執行個體以清除記憶體 （如果這樣做是安全的）
1. 暫時減少查詢並行
1. 如果可能，請消除長時間執行的查詢
組態變更：
**優先順序 1：減少快取記憶體**
+ storage-cache-max-memory-size：減少至 RAM 的 10%
+ 範例：32GB → 3，355，443，200 位元組
+ storage-cache-snapshot-memory-size：26，214，400 (25MB)
**優先順序 2：限制查詢記憶體**
+ query-memory-bytes：設定為總 RAM 的 60%
+ query-max-memory-bytes：比對 query-memory-bytes
+ query-initial-memory-bytes：query-memory-bytes的 10%
**優先順序 3：設定保護限制**
+ influxql-max-select-series：10000
+ influxql-max-select-point：100000000
+ query-concurrency：減少至 50% vCPUs
**長期解決方案：**
+ 最佳化資料模型以減少 **SeriesCardinality**
+ 在應用程式層級實作查詢結果大小限制
+ 新增查詢逾時強制執行
+ 檢閱最常見的查詢，以確保這些查詢遵循 章節中所述的最佳實務 [查詢效能問題](#query-performance-issues)
### 案例：高序列基數影響
**檢閱 CloudWatch 指標：**
+ **SeriesCardinality** > 5M
+ **MemoryUtilization** 高
+ **QueryRequestsTotal** 顯示增加的 Runtime\$1error
+ 由於查詢規劃額外負荷，**CPUUtilization** 提高
**調查步驟：**
**分析基數成長：**
+ SeriesCardinality 成長率 （每日/每週）
+ 投影至 10M閾值
+ 識別高基數的來源
+ 檢閱標籤設計和用量
**評估效能影響：**
+ 比較基數增加之前/之後的 **QueryRequestsTotal** 成功率
+ 檢閱 **MemoryUtilization** 相互關聯
+ 檢查 **CPUUtilization** 模式
+ 分析 **QueryResponseVolume** 趨勢
**識別基數來源：**
檢閱資料模型：
+ 哪些儲存貯體具有最高的 SeriesCardinality？
+ 哪些標籤具有較高的唯一值計數？
+ 是否有不必要的標籤？
+ 標籤值是否不受限制 (UUIDs、時間戳記等）？
**檢閱目前的組態：**
檢查最佳化參數：
+ storage-series-id-set-cache-size：目前值？
+ influxql-max-select-series：它是否限制失控查詢？
+ storage-max-index-log-file-size：適合基數？
**解決步驟：**
立即組態變更：
**優先順序 1：最佳化序列處理**
+ storage-series-id-set-cache-size：1500-2000
+ storage-series-file-max-concurrent-snapshot-compactions：6-8
+ storage-max-index-log-file-size：2，097，152 (2MB)
**優先順序 2：設定保護限制**
+ influxql-max-select-series：10000
+ influxql-max-select-buckets：1000
+ query-concurrency：如果記憶體受限，請減少
**優先順序 3：增加資源**
+ 擴展到下一個執行個體層
+ 增加記憶體配置
+ 考慮 12K IOPS 儲存層
**遷移規劃 （如果 > 10M 系列）：**
+ **InfluxDB 3.0 提供卓越的高基數效能**
+ 規劃遷移時間表 (2-3 個月）
+ 先使用資料子集進行測試
+ 準備應用程式以進行遷移
+ InfluxDB 3.0 使用針對數十億個系列最佳化的單欄式儲存
### 案例：查詢佇列建置
**檢閱 CloudWatch 指標：**
+ **QueryRequestsTotal**，結果 =queue\$1error 增加 （查詢遭到拒絕）
+ 狀態 = 429 或狀態 = 503 的 **APIRequestRate** （服務無法使用/請求太多）
+ **CPUUtilization** 可能升高 (> 70%)，表示資源飽和
+ **MemoryUtilization** 可能很高 (> 70%) 限制查詢容量
+ **QueryResponseVolume** 顯示大型回應大小 （需要過多資源的查詢）
**調查步驟：**
**分析佇列和並行指標：**
+ 依結果類型檢閱 **QueryRequestsTotal** 明細：
+ 高 queue\$1error count 表示查詢遭到拒絕
+ 比較成功率與基準 - 是否下降？
+ 檢查 runtime\$1error 是否增加 （查詢在啟動後失敗）
+ 監控 **APIRequestRate** 模式：
+ 尋找狀態 = 429 （太多請求） 或狀態 = 503 （服務無法使用）
+ 識別哪些端點遇到拒絕
+ 檢查一段時間內的請求率趨勢
**檢閱資源使用率：**
+ 高佇列期間的 **CPUUtilization**：
+ 如果 > 70%，查詢會受限於 CPU，且無法更快速地執行
+ 如果 < 50%，佇列限制可能會太嚴格
+ **MemoryUtilization** 關聯性：
+ 高記憶體可能會限制查詢並行
+ 檢查 **HeapMemoryUsage** 和 **ActiveMemoryAllocation** 的記憶體壓力
+ **TotalIOpsPerSec** 模式：
+ 高 I/O 可能會減慢查詢執行速度
+ 檢查查詢是否受到 I/O 限制
**識別查詢模式：**
+ 檢閱 **QueryResponseVolume**：
+ 查詢是否傳回過多資料 (> 1MB)？
+ 識別具有最大回應磁碟區的端點
+ 尋找昂貴查詢中的模式
+ 分析 **QueryRequestsTotal** 速率：
+ 每秒的查詢次數是多少？
+ 是否有高載模式或持續高負載？
+ 與大小調整資料表的執行個體容量比較
+ 依端點檢查 **APIRequestRate**：
+ 哪些查詢端點的流量最高？
+ 是否有重複或多餘的查詢？
**檢查資源可用性：**
+ 比較目前的指標與調整資料表建議大小：
+ **SeriesCardinality** 與執行個體類別容量
+ 查詢速率與建議的每秒查詢數
+ **CPUUtilization** 和 **MemoryUtilization** 前端空間
+ 驗證 IOPS 容量：
+ **TotalIOpsPerSec** 應該有 30% 的會議室
+ 檢查查詢是否正在等待磁碟 I/O
**解決步驟：**
組態變更：
**優先順序 1：增加佇列容量**
+ query-queue-size：4096 （從預設 1024)
**優先順序 2：增加並行 （如果資源允許）**
+ query-concurrency：增加至 vCPUs的 75%
+ 範例：16 vCPU → query-concurrency = 12
+ 變更後驗證 CPUUtilization 保持 < 80%
+ 驗證 MemoryUtilization 在變更後保持 < 80%
**優先順序 3：最佳化查詢執行**
+ query-memory-bytes：確保配置適當
+ storage-series-id-set-cache-size：1000-1500
+ http-read-timeout：120s （防止過早逾時）
**優先順序 4：設定保護限制**
+ influxql-max-select-series：10000
+ influxql-max-select-point：100000000
**應用程式層級解決方案：**
+ **實作查詢結果快取 **(Redis、Memcached)
+ 快取經常執行查詢的結果
+ 根據資料新鮮度要求設定適當的 TTLs
+ 監控快取命中率
+ **使用連續查詢**來預先彙總常見模式
+ 預先計算常見彙總
+ 查詢預先彙總的資料，而非原始資料
+ 為大型結果集**新增分頁**
+ 限制初始查詢大小
+ 隨需載入其他資料
+ 實作每個使用者/儀表板**的查詢速率限制**
+ 防止單一使用者壓倒系統
+ 設定公平使用配額
+ **將縮減取樣的資料**用於歷史查詢
+ 查詢較舊時間範圍的較低解析度資料
+ 保留最新資料的完整解析度查詢
**擴展決策：**
+ 如果 CPUUtilization > 70% 持續：擴展到更大的執行個體
+ 如果 MemoryUtilization > 70% 持續：擴展至記憶體最佳化執行個體
+ 如果查詢速率超過執行個體容量：每個大小調整表擴展到下一個層