如需與 Amazon Timestream for LiveAnalytics 類似的功能，請考慮使用 Amazon Timestream for InfluxDB。它提供簡化的資料擷取和單一位數毫秒查詢回應時間，以進行即時分析。在這裡進一步了解。

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

InfluxDB 2 的 Timestream 監控和組態最佳化

概觀

有效的監控和組態最佳化對於在 Timestream for InfluxDB 部署中維持最佳效能、可靠性和成本效益至關重要。本指南提供 CloudWatch 指標、效能閾值和組態調校策略的完整指引，協助您主動管理您的 InfluxDB 執行個體。

CloudWatch 指標參考

Amazon CloudWatch 提供監控 Timestream for InfluxDB 執行個體的詳細指標。了解這些指標及其閾值對於維護系統運作狀態和效能至關重要。

資源使用率指標

I/O 操作指標

輸送量指標

API 效能指標

查詢執行指標

資料組織指標

系統運作狀態指標

任務管理指標

了解關鍵指標關係

IOPS 和輸送量關係

30% 的 Headroom 規則：在每秒的持續操作與佈建的 IOPS 之間，一律維持至少 30% 的 Headroom。這會為下列項目提供緩衝：

計算範例：

如果 TotalIOpsPerSec 持續超過 8，400：→ 升級儲存層或最佳化工作負載

監控公式：

IOPS 使用率 % = (ReadOpsPerSec + WriteOpsPerSec)/佈建 IOPS × 100

了解系列基數效能影響

系列基數對系統資源具有乘法效果：

為什麼 10M 是關鍵閾值：

執行個體大小和效能指導方針

下表提供根據您的系列基數和工作負載特性，適當調整執行個體大小的指引：

依指標的組態最佳化

高 CPU 使用率 (CPUUtilization > 70%)

徵狀：

組態調整：

優先順序 1：控制查詢並行

優先順序 2：限制查詢複雜性

優先順序 3：啟用查詢分析

重要考量事項：

減少 query-concurrency 會限制可同時執行的查詢數量，這可能會增加排入佇列的查詢，並在尖峰期間導致較高的查詢延遲。如果查詢需求超過減少的並行限制，使用者可能會遇到較慢的儀表板載入或報告逾時。

設定保護限制 (influxql-max-select-series、influxql-max-select-point) 會導致超出這些閾值的查詢在 QueryRequestsTotal 中因 compile_error 或 runtime_error 失敗。雖然這可保護系統免於資源耗盡，但可能會中斷先前運作的現有查詢。

最佳實務：套用這些變更之前，請使用 QueryResponseVolume 和 QueryRequestsTotal 指標分析查詢模式。首先識別和最佳化最昂貴的查詢 - 尋找沒有時間範圍篩選條件的查詢、跨越高基數序列的查詢，或請求過多資料點的查詢。在應用程式層級最佳化查詢，一律比強於強加可能破壞功能的硬性限制。

硬體動作：

高記憶體使用率 (MemoryUtilization > 70%)

徵狀：

組態調整：

優先順序 1：減少快取記憶體

優先順序 2：限制查詢記憶體

優先順序 3：最佳化系列快取

重要考量事項：

雖然這些變更會降低記憶體壓力，但對應用程式效能會有直接的負面影響。減少storage-cache-max-memory-size表示記憶體中快取的資料較少，強制讀取更多磁碟並增加查詢延遲 - 您可能會看到 ReadOpsPerSec 增加和 QueryResponseVolume 回應時間降低。

限制query-memory-bytes會導致 QueryRequestsTotal 中執行時間_錯誤導致記憶體密集型查詢失敗，特別是彙總大型資料集或傳回大量結果集的查詢。對於先前成功的查詢，使用者可能會遇到「記憶體不足」錯誤。

降低針對高基數資料的查詢效能storage-series-id-set-cache-size，因為系統必須更頻繁地重新計算序列結果，而不是從快取中擷取結果。這尤其會影響重複查詢相同序列組合的儀表板。

最佳實務：套用這些限制性變更之前，請先分析您的查詢模式並將其最佳化：

查詢最佳化應該永遠是您的第一個方法 - 最佳化不足時，組態限制應該是最後一個手段。

硬體動作：

高儲存使用率 (DiskUtilization > 70%)

要監控的 CloudWatch 指標：

組態調整：

優先順序 1：檢查記錄組態

優先順序 2：積極保留

優先順序 3：最佳化壓縮

優先順序 4：減少索引大小

重要考量事項：

關鍵第一步驟 - 檢查您的記錄組態：進行任何其他變更之前，請先驗證您的記錄設定。偵錯記錄和 Flux 查詢日誌可能會耗用比實際時間序列資料更多的磁碟空間，這是非預期儲存體耗盡的最常見原因之一。

記錄影響：

日誌大型時的立即動作：

壓縮組態權衡：

這些組態變更專為具有高擷取輸送量和短期保留時段的工作負載而設計，其中磁碟用量會大幅波動。它們強制壓縮引擎更積極地工作，這只有在特定案例中才有用。

關鍵權衡：增加壓縮頻率將大幅增加資源消耗：

這些變更可能會產生層疊效能問題，其中積極的壓縮會耗用查詢和寫入操作所需的資源，即使減少磁碟使用量，也會降低整體系統效能。

最佳實務：調整壓縮設定之前，專注於資料和記錄管理：

替代方法：

只有在您已最佳化資料管理並確認執行個體有足夠的 CPU、記憶體和 IOPS 空間來處理增加的負載時，才套用積極的壓縮設定。

硬體動作：

高 IOPS 使用率 (ReadIOPS/WriteIOPS/TotalOperationsPerSecond > 70% 的佈建）

要監控的 CloudWatch 指標：

組態調整：

優先順序 1：控制壓縮 I/O

優先順序 2：最佳化寫入操作

優先順序 3：調整快照計時

重要考量事項：

這些變更會在 I/O 使用率和系統效能之間產生重大權衡：

限制壓縮 I/O：

降低快照頻率：

寫入操作調校：

最佳實務：高 IOPS 使用率通常表示您已超出儲存層，而不是組態問題。在限制 I/O 之前，請分析 I/O 模式並在限制之前進行最佳化。

硬體動作：

高序列基數 (SeriesCardinality > 1M)

要監控的 CloudWatch 指標：

組態調整：

優先順序 1：最佳化序列處理

優先順序 2：設定保護限制

優先順序 3：最佳化索引操作

重要考量事項：

高序列基數基本上是資料建模問題，而不是組態問題。組態變更只能緩解症狀 - 它們無法解決基礎問題。

組態權衡：

增加 storage-series-id-set-cache-size將透過快取序列查詢來改善查詢效能，但代價是增加 MemoryUtilization。每個快取項目都會耗用記憶體，而且有數百萬個序列，這可能很重要。進行此變更後，請監控 HeapMemoryUsage 和 ActiveMemoryAllocation。

如果合法查詢超過這些閾值，設定保護限制 (influxql-max-select-series、influxql-max-select-buckets) 會導致 QueryRequestsTotal 中的 compile_error 失敗。先前運作的儀表板可能會中斷，使用者將需要修改其查詢。這對於以下方面特別有問題：

調整storage-max-index-log-file-size為較小的值會增加索引壓縮頻率，這會在系統執行更頻繁的索引維護時提高 CPUUtilization 和 WriteOpsPerSec。

關鍵了解：

當 SeriesCardinality 超過 5M 時，您將接近 InfluxDB 2.x 的架構限制。在 10M+ 系列，無論組態為何，效能都會呈指數下降：

最佳實務：組態變更是臨時頻帶輔助。您必須解決根本原因：

資料模型動作：

查詢效能問題

要監控的 CloudWatch 指標：

組態調整：

優先順序 1：增加查詢資源

優先順序 2：最佳化查詢執行

優先順序 3：設定合理的限制

重要考量事項：

增加查詢資源會造成資源競爭和潛在的系統不穩定：

資源分配權衡：

增加query-concurrency允許更多查詢同時執行，但每個查詢都會競爭 CPU 和記憶體：

配置更多query-memory-bytes表示快取和其他操作可用的記憶體較少：

增加query-queue-size只會延遲問題 - 它無法解決容量問題：

增加http-read-timeout可防止過早取消查詢，但：

最佳實務：查詢效能問題通常是由低效率的查詢造成，而不是資源不足。在增加資源配置之前：

建議的方法：

硬體動作：

Flux 查詢中的 RegEx 效能缺陷

在 Flux 中篩選資料時，請避免將規則表達式用於完全相符或簡單的模式相符，因為這會導致嚴重的效能懲罰。Flux 中的 RegEx 操作是單執行緒，完全略過基礎 TSM 索引。RegEx 篩選條件不會利用 InfluxDB 的最佳化標籤索引進行快速查詢，而是強制查詢引擎從儲存體擷取所有相符的序列，並根據每個值依序執行文字比較。這在以下情況特別有問題：

對於需要多個模式相符的案例，請重組您的查詢，以使用與邏輯運算子結合的多個篩選條件述詞，或在套用更複雜的字串操作之前使用標籤等式預先篩選。僅針對需要真實模式比對的案例預留 RegEx，這些案例無法透過更簡單的比較運算子來表示。

寫入效能問題

要監控的 CloudWatch 指標：

組態調整：

優先順序 1：最佳化 WAL 寫入

優先順序 2：最佳化快取快照

優先順序 3：控制欄位驗證

重要考量事項：

寫入效能調校涉及輸送量、可靠性和資源耗用量之間的謹慎權衡：

WAL 組態權衡：

增加storage-wal-max-concurrent-writes允許更多平行寫入操作，但：

增加storage-wal-max-write-delay表示寫入等待更久才逾時：

增加http-write-timeout類似的延遲逾時錯誤：

快取快照權衡：

增加storage-cache-snapshot-memory-size表示在清除之前，更多資料累積在記憶體中：

增加storage-cache-snapshot-write-cold-duration延遲快照：

欄位驗證權衡：

設定 會storage-no-validate-field-size: TRUE停用欄位大小驗證：

最佳實務：寫入效能問題通常表示容量限制或效率不佳的寫入模式。調校組態之前：

建議的方法：

硬體動作：

監控最佳實務

CloudWatch 警示組態

關鍵警示 （需要立即動作）：

CPUUtilization：

MemoryUtilization：

DiskUtilization：

TotalIOpsPerSec：

SeriesCardinality：

EngineUptime：

警告警示 （需要調查）：

CPUUtilization：

MemoryUtilization：

DiskUtilization：

TotalIOpsPerSec：

QueryRequestsTotal (runtime_error)：

WriteTimeouts：

SeriesCardinality：

主動監控檢查清單

每日：

每週：

每月：

故障診斷指南

案例：突然效能降級

調查步驟：

檢查最近的變更：

檢閱 CloudWatch 指標：

啟用詳細記錄：

組態變更：

監控 1-2 小時，然後檢閱日誌

返回日誌層級：調查後的資訊

解決步驟：

案例：記憶體耗盡

徵狀：

解決步驟：

立即動作 （如果重要）：

組態變更：

優先順序 1：減少快取記憶體

優先順序 2：限制查詢記憶體

優先順序 3：設定保護限制

長期解決方案：

案例：高序列基數影響

檢閱 CloudWatch 指標：

調查步驟：

分析基數成長：

評估效能影響：

識別基數來源：

檢閱資料模型：

檢閱目前的組態：

檢查最佳化參數：

解決步驟：

立即組態變更：

優先順序 1：最佳化序列處理

優先順序 2：設定保護限制

優先順序 3：增加資源

遷移規劃 （如果 > 10M 系列）：

案例：查詢佇列建置

檢閱 CloudWatch 指標：

調查步驟：

分析佇列和並行指標：

檢閱資源使用率：

識別查詢模式：

檢查資源可用性：

解決步驟：

組態變更：

優先順序 1：增加佇列容量

優先順序 2：增加並行 （如果資源允許）

優先順序 3：最佳化查詢執行

優先順序 4：設定保護限制

應用程式層級解決方案：

擴展決策：