如需與 Amazon Timestream for LiveAnalytics 類似的功能，請考慮使用 Amazon Timestream for InfluxDB。它提供簡化的資料擷取和單一位數毫秒查詢回應時間，以進行即時分析。[在這裡](https://docs.aws.amazon.com//timestream/latest/developerguide/timestream-for-influxdb.html)進一步了解。
本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 管理資料庫執行個體
本節涵蓋管理 Amazon Timestream for InfluxDB 執行個體以確保最佳效能、可用性和監控功能的各種層面。它提供更新資料庫執行個體組態、處理多可用區域部署和容錯移轉程序的指引。它還說明如何刪除資料庫執行個體並設定 InfluxDB 執行個體的日誌檢視。
**Topics**
+ [更新資料庫執行個體](timestream-for-influx-managing-modifying-db.md)
+ [維持資料庫執行個體](timestream-for-influx-managing-maintaining-db.md)
+ [刪除資料庫執行個體](timestream-for-influx-managing-deleting-db.md)
+ [將資料庫執行個體重新開機](timestream-for-influx-managing-rebooting-db.md)
+ [多可用區域資料庫執行個體部署](timestream-for-influx-managing-multi-az-instance-deployments.md)
+ [在 Timestream Influxdb 執行個體上檢視 InfluxDB 日誌的設定](timestream-for-influx-managing-view-influx-logs.md)
+ [InfluxDB 2 的 Timestream 監控和組態最佳化](timestream-for-influx-monitoring-configuration-optimization.md)
# 更新資料庫執行個體
您可以更新 Timestream for InfluxDB 執行個體的下列組態參數：
+ 執行個體類別
+ 儲存體類型
+ 配置的儲存體 （僅增加）
+ 部署類型
+ 參數群組
+ 日誌交付組態
**重要**
我們建議您在修改生產執行個體之前測試測試執行個體上的所有變更，以了解其影響，尤其是在升級資料庫版本時。更新設定之前，請先檢閱對資料庫和應用程式的影響。有些修改需要重新啟動資料庫執行個體，導致停機時間。
**使用 AWS 管理主控台**
1. 登入 AWS 管理主控台 並開啟 [Amazon Timestream for InfluxDB 主控台](https://console.aws.amazon.com/timestream/)。
1. 在導覽窗格中，選擇 **InfluxDB 資料庫**，然後選擇您要修改的資料庫執行個體。
1. 選擇 **Modify** (修改)。
1. 在**修改資料庫執行個體**頁面上，進行所需的變更。
1. 選擇 **Continue (繼續)**，並檢查修改的摘要。
1. 選擇**下一步**。
1. 檢閱您的變更。
1. 選擇**修改執行個體**以套用您的變更。
**注意**
這些修改需要重新啟動 Influx 資料庫執行個體，在某些情況下可能會導致中斷。
**使用 AWS Command Line Interface**
若要使用 更新資料庫執行個體 AWS Command Line Interface，請呼叫 `update-db-instance`命令。指定資料庫執行個體識別符，以及您要修改選項的值。如需每個選項的詳細資訊，請參閱[資料庫執行個體的設定](timestream-for-influx-configuring.md#timestream-for-influx-configuring-create-db-settings)。
**Example 範例**
下列程式碼透過設定不同的 來修改 *my-db-instance*`db-parameter-group-name`。將每個*使用者輸入預留位置*替換為自己的資訊。變更會立即套用。
針對 Linux、macOS 或 Unix：
```
aws timestream-influxdb update-db-instance \
--identifier my-db-instance \
--db-storage-type desired-storage-type \
--allocated-storage desired-allocated-storage \
--db-instance-type desired-instance-type \
--deployment-type desired-deployment-type \
--db-parameter-group-name new-param-group \
--port 8086
```
針對 Windows：
```
aws timestream-influxdb update-db-instance ^
--identifier my-db-instance ^
--db-storage-type desired-storage-type ^
--allocated-storage desired-allocated-storage ^
--db-instance-type desired-instance-type ^
--deployment-type desired-deployment-type ^
--db-parameter-group-name new-param-group
--port 8086
```
# 維持資料庫執行個體
Amazon Timestream for InfluxDB 會定期在 Amazon Timestream for InfluxDB 資源上執行維護。維護通常涉及資料庫執行個體中下列資源的更新：
+ 基礎硬體
+ 基礎作業系統 (OS)
+ 資料庫引擎版本
作業系統更新大多是因為安全性問題。
某些維護項目需要 Amazon Timestream for InfluxDB 將您的資料庫執行個體短暫離線。需要資源離線的維護項目包括必要的作業系統或資料庫修補。所需的修補程式僅會針對與安全性和執行個體可靠性相關的修補程式自動安排。這類修補不常發生，通常每隔幾個月進行一次。維護僅需片刻的時間即可完成。
+ 維護時段設定為每天在本機時間凌晨 12 點到凌晨 4 點之間，針對您執行個體託管的 區域進行。
+ 客戶資源每週可能會在一週的七個維護時段中的任何一個進行修補。
# 刪除資料庫執行個體
刪除資料庫執行個體會影響執行個體可復原性和快照可用性。請考慮以下問題：
+ 如果您想要刪除 InfluxDB 資源的所有 Timestream，請注意，資料庫執行個體資源會產生帳單費用。
+ 刪除資料庫執行個體的狀態時，其 CA 憑證值不會出現在 Timestream for InfluxDB 主控台中，也不會出現在輸出中的 AWS Command Line Interface 命令或 Timestream API 操作中。
+ 刪除資料庫執行個體所需的時間取決於刪除的資料量，以及是否拍攝最終快照。
您可以使用 AWS Command Line Interface、 或 Timestream API AWS 管理主控台刪除資料庫執行個體。您必須提供資料庫執行個體的名稱：
**使用 AWS 管理主控台**
1. 登入 AWS 管理主控台 並開啟 [Amazon Timestream for InfluxDB 主控台](https://console.aws.amazon.com/timestream/)。
1. 在導覽窗格中，選擇 **InfluxDB 資料庫**，然後選擇您要刪除的資料庫執行個體。
1. 選擇 **刪除**。
1. 在方塊中輸入*確認*。
1. 選擇 **刪除**。
**使用 AWS Command Line Interface**
若要尋找您帳戶中資料庫執行個體IDs，請呼叫 `list-db-instances`命令：
```
aws timestream-influxdb list-db-instances \
--endpoint-url YOUR_ENDPOINT \
--region YOUR_REGION
```
若要使用 CLI AWS 刪除資料庫執行個體，請使用下列選項呼叫 `delete-db-instance`命令：
```
aws timestream-influxdb list-db-instances \
--identifier YOUR_DB_INSTANCE \
```
**Example 範例**
針對 Linux、macOS 或 Unix：
```
aws timestream-influxdb delete-db-instance \
--identifier mydbinstance
```
針對 Windows：
```
aws timestream-influxdb delete-db-instance ^
--identifier mydbinstance
```
# 將資料庫執行個體重新開機
您可以使用 AWS Command Line Interface、 或 Timestream API AWS 管理主控台重新啟動資料庫執行個體。您必須提供資料庫執行個體的 ID：
**使用 AWS 管理主控台**
1. 登入 AWS 管理主控台 並開啟 [Amazon Timestream for InfluxDB 主控台](https://console.aws.amazon.com/timestream/)。
1. 在導覽窗格中，選擇 **InfluxDB 資料庫**，然後選擇您要重新啟動的資料庫執行個體。
1. 選擇**重新啟動資料庫**。
1. 選擇**確認並重新啟動**。
**使用 AWS Command Line Interface**
若要使用 CLI AWS 重新啟動資料庫執行個體，請使用下列選項呼叫 `reboot-db-instance`命令：
**Example 命令**
針對 Linux、macOS 或 Unix：
```
aws timestream-influxdb reboot-db-instance \
--region YOUR_REGION \
--identifier YOUR_INSTANCE_ID
```
針對 Windows：
```
aws timestream-influxdb reboot-db-instance ^
--region YOUR_REGION ^
--identifier YOUR_INSTANCE_ID
```
# 多可用區域資料庫執行個體部署
Amazon Timestream for InfluxDB 使用具有單一待命資料庫執行個體的異地同步備份部署，為資料庫執行個體提供高可用性和容錯移轉支援。這種類型的部署稱為多可用區域資料庫執行個體部署。Amazon Timestream for InfluxDB 使用 Amazon 容錯移轉技術。
在多可用區域資料庫執行個體部署中，Amazon Timestream 會自動在不同的可用區域中佈建和維護同步待命複本。主要資料庫執行個體會在待命複本的可用區域間進行同步複製，以提供資料備援。在資料庫執行個體故障和可用區域中斷期間，執行高可用性的資料庫執行個體可以增強可用性。如需 的詳細資訊，請參閱 [AWS 區域 和可用區域](timestream-for-influxdb.md#timestream-for-influx-dbi-regions)。
**注意**
高可用性選項不是唯讀案例的擴展解決方案。您無法使用待命複本來提供讀取流量。
使用 Amazon Timestream 主控台，您只需在建立資料庫執行個體時**，在可用性和耐久性組態區段中指定建立待命執行個體**選項，即可建立多可用區域資料庫執行個體部署。 ****您也可以使用 AWS Command Line Interface 或 Amazon Timestream API 指定多可用區域資料庫執行個體部署。使用 `create-db-instance`或 CLI 命令，或 `CreateDBInstance` API 操作。
相較於單一可用區域部署，使用多可用區域資料庫執行個體部署的資料庫執行個體會有增加的寫入和遞交延遲。這可能是因為發生的同步資料複寫。如果您的部署容錯移轉到待命複本，則延遲可能會有所變更，雖然 AWS 是以 之間的低延遲網路連線進行設計。對於生產工作負載，我們建議您使用 IOPS 包含儲存 12K 或 16K IOPS，以獲得快速、一致的效能。如需資料庫執行個體類別的詳細資訊，請參閱 [資料庫執行個體類別](timestream-for-influxdb.md#timestream-for-influx-dbi-classes)。
# 設定和管理多可用區部署
InfluxDB 多可用區部署的 Timestream 只能有一個待命。當部署具有一個備用資料庫執行個體時，稱為多可用區域資料庫執行個體部署。多可用區域資料庫執行個體部署有一個待命資料庫執行個體，可提供容錯移轉支援，但是不提供讀取流量。
**重要**
您的執行個體必須至少有兩個與其相關聯的子網路，才能執行單一可用區到多可用區更新。執行個體建立後，您就無法將其部署模式從單一可用區 修改為多可用區 。
您可以使用 AWS 管理主控台 來判斷資料庫執行個體是單一可用區還是多可用區部署。
**使用 AWS 管理主控台**
1. 登入 AWS 管理主控台 並開啟 [Amazon Timestream for InfluxDB 主控台](https://console.aws.amazon.com/timestream/)。
1. 在導覽窗格中，選擇 **InfluxDB 資料庫**，然後選擇**資料庫識別符**。
多可用區域資料庫執行個體部署具有以下特徵：
+ 資料庫執行個體只有一行。
+ Role (角色) 的值為 Instance (執行個體) 或 Primary (主要)。
+ Multi-AZ (多可用區域) 的值為 Yes (是)。
# Amazon Timestream 的容錯移轉程序
如果因基礎設施瑕疵而導致資料庫執行個體的計劃或非計劃中斷，如果您已開啟異地同步備份，Amazon Timestream for InfluxDB 會自動切換到另一個可用區域中的待命複本。完成容錯移轉所需的時間取決於主要資料庫執行個體失效時的資料庫活動和其他條件。通常容錯移轉時間是 60–120 秒。不過，大型交易或冗長復原程序可能會增加容錯移轉時間。當容錯移轉完成時，Timestream 主控台可能需要額外的時間來反映新的可用區域。
**注意**
Amazon Timestream 會自動處理容錯移轉，因此您可以盡快恢復資料庫操作，而無需管理介入。如果發生下表所述的任何條件，主要資料庫執行個體會自動切換至待命複本。
****
| 容錯移轉原因 | Description |
| --- | --- |
| Timestream 資料庫執行個體基礎的作業系統正在離線操作中修補。 | 作業系統修補或安全更新的維護期間觸發容錯移轉。 |
| Timestream 多可用區執行個體的主要主機運作狀態不佳。 | 多可用區域資料庫執行個體部署偵測到主要資料庫執行個體受損並容錯移轉。 |
| 由於網路連線中斷，無法連線 Timestream Multi-AZ 執行個體的主要主機。 | Timestream 監控偵測到主要資料庫執行個體的網路連線能力失敗，並觸發容錯移轉。 |
| Timestream 執行個體已由客戶修改。 | InfluxDB 資料庫執行個體修改的 Timesteam 觸發了容錯移轉。如需詳細資訊，請參閱[更新資料庫執行個體](timestream-for-influx-managing-modifying-db.md)。 |
| Timestream 多可用區主要執行個體忙碌且沒有回應。 | 主要資料庫執行個體沒有回應。建議您執行下列動作：\$1 檢查事件是否有過多的 CPU、記憶體或交換空間使用量。\$1 評估工作負載，以判斷您是否使用適當的資料庫執行個體類別。如需更多詳細資訊，請參閱資料庫執行個體類別。 |
| Timestream 多可用區執行個體主要主機基礎的儲存磁碟區發生故障。 | 多可用區域資料庫執行個體部署在主要資料庫執行個體上偵測到儲存問題並容錯移轉。 |
# 設定 DNS 名稱查詢的 JVM TTL
容錯移轉機制會自動將資料庫執行個體的網域名稱系統 (DNS) 記錄變更為指向待命資料庫執行個體。因此，您必須重新建立資料庫執行個體任何現有的連線。在 Java 虛擬機器 (JVM) 環境中，基於 Java DNS 快取機制的運作方式，您可能需要重新配置 JVM 設定。
JVM 會快取 DNS 名稱查詢。當 JVM 將主機名稱解析為 IP 地址時，它會在指定的時間段內快取 IP 地址，稱為*存留時間* (TTL)。
由於 AWS 資源使用偶爾變更的 DNS 名稱項目，建議您將 JVM 設定為不超過 60 秒的 TTL 值。如此可確保當資源的 IP 位址變更時，您的應用程式可以透過重新查詢 DNS 來接收並使用資源的新 IP 位址。
在一些 Java 組態上，則會設定 JVM 預設 TTL，以便其在重新啟動 JVM 之前絕對不會重新整理 DNS 項目。因此，如果您的應用程式仍在執行時 AWS ，資源的 IP 地址變更，則在您手動重新啟動 JVM 並重新整理快取的 IP 資訊之前，都無法使用該資源。在此情況下，設定 JVM 的 TTL 至為關鍵，以便其定期重新整理其快取的 IP 資訊。
您可以擷取 `networkaddress.cache.ttl` 屬性值來取得 JVM 預設 TTL：
```
String ttl = java.security.Security.getProperty("networkaddress.cache.ttl");
```
**注意**
預設 TTL 可能會視 JVM 的版本以及是否已安裝安全管理員而異。許多 JVM 提供的預設 TTL 少於 60 秒。如果您使用此類 JVM (而非安全管理員)，則可忽略本主題的其餘內容。
若要修改 JVM 的 TTL，請設定 networkaddress.cache.ttl 屬性值。根據您的需求，使用下列其中一種方法：
若要為使用 JVM 的所有應用程式全域設定屬性值，請在 `networkaddress.cache.ttl` 檔案中設定 `$JAVA_HOME/jre/lib/security/java.security`。
```
networkaddress.cache.ttl=60
```
若要僅針對您的應用程式進行適當的本機設定，請在建立任何網路連線之前，在您應用程式的初始化程式碼中設定 `networkaddress.cache.ttl`。
```
java.security.Security.setProperty("networkaddress.cache.ttl" , "60");
```
# 在 Timestream Influxdb 執行個體上檢視 InfluxDB 日誌的設定
根據預設，InfluxDB 會產生前往 stdout 的日誌。如需詳細資訊，請參閱[管理 InfluxDB 日誌](https://docs.influxdata.com/influxdb/v2/admin/logs)
若要檢視您透過 Timestream InfluxDB 建立的執行個體所產生的 InfluxDB 日誌，我們提供提供每小時日誌的機會。這些日誌將移至您在建立執行個體之前必須建立的指定 S3 儲存貯體。
+ 在建立執行個體之前，提供的 Amazon S3 儲存貯體也必須提供 Timestream-InfluxDB 許可，以向 Timestream InfluxDB Service Principal 提供儲存貯體政策，如下所示 （將 *\$1BUCKET\$1NAME\$1* 取代為您的 Amazon S3 儲存貯體實際名稱：
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "PolicyForInfluxLogs",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "timestream-influxdb.amazonaws.com"
},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::{BUCKET_NAME}/InfluxLogs/*"
}
]
}
```
------
+ 提供的儲存貯體必須位於您建立的 Timestream InfluxDB 執行個體的相同帳戶和相同區域
以下是您可以呼叫 讓執行個體接收流入日誌的命令：
```
aws timestream-influxdb create-db-instance \
--name myinfluxDbinstance \
--allocated-storage 400 \
--db-instance-type db.influx.4xlarge \
--vpc-subnet-ids subnetid1 subnetid2
--vpc-security-group-ids mysecuritygroup \
--username masterawsuser \
--password \
--db-storage-type InfluxIOIncludedT2
```
以下是此參數的格式。
```
-- log-delivery-configuration
{
"S3Configuration": {
"BucketName": "string",
"Enabled": true|false
}
}
```
+ 此欄位並非必要欄位，且預設不會啟用記錄。
+ 不設定此欄位與未啟用日誌相同。
+ 日誌會傳送到字首為 的指定儲存貯體`InfluxLogs/`。
+ 建立執行個體之後，您可以使用 `update-db-instance` API 命令修改日誌交付組態。
InfluxDB 提供不同類型的日誌。您可以透過設定 InfluxDB 參數來設定這些參數。使用flux-log-enabled和日誌層級參數來設定從執行個體發出的日誌類型。如需詳細資訊，請參閱[支援的參數和參數值](timestream-for-influx-db-connecting.md#timestream-for-influx-parameter-groups-overview-supported-parameters)。
# 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% 的 Headroom 規則：**在每秒的持續操作與佈建的 IOPS 之間，一律維持至少 **30% 的 Headroom**。這會為下列項目提供緩衝：
+ 壓縮操作 （可大幅激增 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 | 非常大型的生產工作負載 |
| \$11，000 萬 | < 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：**
+ 閾值：> 佈建 15 分鐘的 70%
+ 動作：檢閱工作負載或流量的變更
**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% 持續：擴展至記憶體最佳化執行個體
+ 如果查詢速率超過執行個體容量：每個大小調整表擴展到下一個層