要获得与亚马逊 Timestream 类似的功能 LiveAnalytics，可以考虑适用于 InfluxDB 的亚马逊 Timestream。适用于 InfluxDB 的 Amazon Timestream 提供简化的数据摄取和个位数毫秒级的查询响应时间，以实现实时分析。点击[此处](https://docs.aws.amazon.com//timestream/latest/developerguide/timestream-for-influxdb.html)了解更多信息。

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# InfluxDB 2 的时间流监控和配置优化
<a name="timestream-for-influx-monitoring-configuration-optimization"></a>

## 概述
<a name="monitoring-overview"></a>

有效的监控和配置优化对于在 InfluxDB 部署的 Timestream 中保持最佳性能、可靠性和成本效益至关重要。本指南提供了有关 CloudWatch 指标、性能阈值和配置调整策略的全面指导，以帮助您主动管理InfluxDB实例。

## CloudWatch 指标参考
<a name="cloudwatch-metrics-reference"></a>

亚马逊 CloudWatch 提供了详细的指标，用于监控您的 InfluxDB 实例的时间流。了解这些指标及其阈值对于维护系统运行状况和性能至关重要。

### 资源利用率指标
<a name="resource-utilization-metrics"></a>


| CloudWatch 指标名称 | Dimensions | 说明 | 单位 | 推荐阈值 | 
| --- | --- | --- | --- | --- | 
| CPUUtilization | DbInstanceName | 正在使用的 CPU 百分比 | 百分比 |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/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_cn/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_cn/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_cn/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_cn/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html)  | 

### I/O 操作指标
<a name="io-operations-metrics"></a>


| CloudWatch 指标名称 | Dimensions | 说明 | 单位 | 推荐阈值 | 
| --- | --- | --- | --- | --- | 
| ReadOpsPerSec | DbInstanceName | 每秒读取操作数 | 计数/秒 | 保持低于预配置 IOPS 的 30% 的余量示例：1.2K IOPS → 总共保持 < 8,400 IOPS | 
| WriteOpsPerSec | DbInstanceName | 每秒写入操作数 | 计数/秒 | 保持低于预配置 IOPS 的 30% 的余量示例：1.2K IOPS → 总共保持 < 8,400 IOPS | 
| 总计 IOps PerSec | DbInstanceName | 每秒总 I/O 操作数（读取\$1写入） | 计数/秒 | 保持低于预配置 IOPS 的 30% 的余量根据实例类的功能进行监控 | 

### 吞吐量指标
<a name="throughput-metrics"></a>


| CloudWatch 指标名称 | Dimensions | 说明 | 单位 | 推荐阈值 | 
| --- | --- | --- | --- | --- | 
| ReadThroughput | DbInstanceName | 数据读取吞吐量 | 字节/秒 | 根据存储吞吐量限制进行监控 | 
| WriteThroughput | DbInstanceName | 数据写入吞吐量 | 字节/秒 | 根据存储吞吐量限制进行监控 | 

### API 性能指标
<a name="api-performance-metrics"></a>


| CloudWatch 指标名称 | Dimensions | 说明 | 单位 | 推荐阈值 | 
| --- | --- | --- | --- | --- | 
| APIRequest费率 | DbInstanceName、终端节点、状态 | 向带有状态码（2xx、4xx、5xx）的特定端点发出 API 请求的速率 | 计数/秒 |  错误率： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/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_cn/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html)  | 

### 查询执行指标
<a name="query-execution-metrics"></a>


| CloudWatch 指标名称 | Dimensions | 说明 | 单位 | 推荐阈值 | 
| --- | --- | --- | --- | --- | 
| QueryRequestsTotal | DbInstanceName，结果 | 按结果类型（成功、runtime\$1error、compile\$1error、queue\$1error）分列的查询请求总数 | 计数 |  成功率：> 99% 错误率： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html)  | 

### 数据组织指标
<a name="data-organization-metrics"></a>


| CloudWatch 指标名称 | Dimensions | 说明 | 单位 | 临界阈值 | 
| --- | --- | --- | --- | --- | 
| SeriesCardinality | DbInstanceName，桶 | 存储桶中唯一时间序列的数量 | 计数 |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/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_cn/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html)  | 

### 系统健康指标
<a name="system-health-metrics"></a>


| CloudWatch 指标名称 | Dimensions | 说明 | 单位 | 推荐阈值 | 
| --- | --- | --- | --- | --- | 
| EngineUptime | DbInstanceName | InfluxDB 引擎运行的时间 | 秒 | 监控意外重启警报：正常运行时间意外重置 | 
| WriteTimeouts | DbInstanceName | 超时的写入操作数 | 计数 | 警报：> 0.1% 的写入操作关键：上升趋势 | 

### 任务管理指标
<a name="task-management-metrics"></a>


| CloudWatch 指标名称 | Dimensions | 说明 | 单位 | 推荐阈值 | 
| --- | --- | --- | --- | --- | 
| ActiveTaskWorkers | DbInstanceName | 活跃任务工作人员人数 | 计数 | 根据配置的任务工作者限制进行监控警报：始终处于最大值 | 
| TaskExecutionFailures | DbInstanceName | 任务执行失败次数 | 计数 | 警报：> 1% 的任务执行情况关键：失败率上升 | 

### 了解关键指标关系
<a name="understanding-key-metric-relationships"></a>

#### IOPS 和吞吐量关系
<a name="iops-throughput-relationship"></a>

**30% 的净空规则：**在每秒持续操作和预配置 IOPS 之间，始终保持至少 **30% 的余**量。这为以下内容提供了缓冲区：
+ 压缩操作（可能会显著增加 IOPS）
+ 任何数据库都要重启才能顺利运行
+ 使用高峰期间的查询突发事件
+ 从批量摄取中写入峰值
+ 索引维护操作

**计算示例：**
+ 预配置 IOPS：12,000
+ 目标最大持续 IOPS（总计 IOpsPerSec）：8,400（利用率为 70%）
+ 预留空间：3,600 IOPS (30%)

如果总数IOpsPerSec 持续超过 8,400：→ 升级存储层或优化工作负载

**监控公式：**

IOPS 利用率% = (ReadOpsPerSec \$1 WriteOpsPerSec)/预配置 IOPS × 100
+ 目标：保持 IOPS 利用率低于 70%
+ 警告：IOPS 利用率 > 70%
+ 关键：IOPS 利用率> 90%

### 了解系列基数性能影响
<a name="series-cardinality-performance-impact"></a>

序列基数对系统资源具有乘法效应：


| **系列数** | **记忆影响** | **查询性能影响** | **索引大小影响** | **建议** | 
| --- | --- | --- | --- | --- | 
| < 100K | Minimal | 可以忽略不计 | Small | 标准配置 | 
| 100K-1M | 中 | 速度减慢 10-20% | 中 | 调整缓存设置 | 
| 1M-5M | 意义重大 | 速度减慢 30-50% | 大型 | 需要积极优化 | 
| 5M-10M | 高 | 速度减慢 50-70% | 非常大 | 最大限度地进行调整，考虑重新设计 | 
| > 10M | 严重 | 慢了 70% 以上 | 过度 | 迁移到 InfluxDB 3.0 | 

**为什么 10M 是临界阈值：**
+ InfluxDB 2.x 架构使用内存中索引
+ 超越1000万系列，指数操作变得昂贵得令人望而却步
+ 内存需求以非线性方式增长
+ 查询计划开销急剧增加
+ InfluxDB 3.0 使用专为高基数而设计的列式存储引擎

## 实例大小和性能指南
<a name="instance-sizing-guidelines"></a>

下表根据您的系列基数和工作负载特征提供了有关适当调整实例规模的指导：


| **最大系列数** | **写入（行/秒）** | **读取（查询次数/秒）** | **推荐实例** | **存储类型** | **使用场景** | 
| --- | --- | --- | --- | --- | --- | 
| < 100K | \$150000 | < 10 | db.influx.large | 已包含 3K 的 Influx IO | 小型部署、开发、测试 | 
| < 1M | \$1150000 | < 25 | db.influx.2xlarge | 已包含 3K 的 Influx IO | 中小型生产工作负载 | 
| 大约 1M | \$1200000 | \$125 | db.influx.4xlarge | 已包含 3K 的 Influx IO | 中等生产工作负载 | 
| < 5M | \$1250000 | \$135 | db.influx.4xlarge | 已包含 12K 的 Influx IO | 大型生产工作负载 | 
| < 10M | \$1500000 | \$150 | db.influx.8xlarge | 已包含 12K 的 Influx IO | 非常大的生产工作负载 | 
| 大约 10M | < 750,000 | < 100 | db.influx.12xlarge | 已包含 12K 的 Influx IO | InfluxDB 的最大容量 2.x | 
| > 10M | 不适用 | 不适用 | 迁移到 InfluxDB 3.0 | 不适用 | 超越 InfluxDB 2.x 最佳范围 | 

## 按指标进行配置优化
<a name="configuration-optimization-by-metric"></a>

### CPU 利用率高 (CPUUtilization > 70%)
<a name="high-cpu-utilization"></a>

**症状：**
+ **CPUUtilization**超过 70% 的持续
+ **QueryRequestsTotal**（查询量大或查询速度慢）
+ **ActiveTaskWorkers**（高任务负载）

**配置调整：**

**优先级 1：控制查询并发性**
+ 查询并发度：设置为 vCPU 计数的 50-75%
+ 示例：8 个 vCPU 实例 → 查询并发 = 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`) 将导致超过这些阈值的查询失败，并显示 **compile\$1error 或 runtime\$1error**。**QueryRequestsTotal****虽然这可以保护系统免受资源耗尽的影响，但它可能会中断以前有效的现有查询。

**最佳实践：**在应用这些更改之前，请使用**QueryResponseVolume**和**QueryRequestsTotal**指标分析您的查询模式。首先确定并优化最昂贵的查询——查找没有时间范围筛选器的查询、跨越高基数序列的查询或请求过多数据点的查询。在应用程序级别优化查询总是比施加可能破坏功能的硬限制更可取。

**硬件操作：**
+ 使用更多 v 扩展到下一个实例类 CPUs
+ 查看查询模式以寻找优化机会

### 高内存利用率 (MemoryUtilization > 70%)
<a name="high-memory-utilization"></a>

**症状：**
+ **MemoryUtilization**超过 70% 的持续
+ **HeapMemoryUsage**呈上升趋势
+ **ActiveMemoryAllocation**显示尖刺
+ **SeriesCardinality**（高基数会增加内存使用量）

**配置调整：**

**优先级 1：减少缓存内存**
+ storage-cache-max-memory-大小：设置为总内存的 10-15%
+ 示例：32GB 内存 → 3,355,443,200 到 5,033,164,800 字节
+ storage-cache-snapshot-memory-大小：26,214,400 (25MB)

**优先级 2：限制查询内存**
+ query-memory-bytes: 设置为总内存的 60-70%
+ query-max-memory-bytes: 与 query-memory-bytes
+ query-initial-memory-bytes: 10% 的折扣 query-memory-bytes

**优先级 3：优化系列缓存**
+ storage-series-id-set-cache-size：如果基数高，则减小
+ 高内存：100-200
+ 正常：500-1000

**重要注意事项：**

虽然这些更改将减轻内存压力，但会对应用程序性能产生直接的负面影响。减少`storage-cache-max-memory-size`意味着内存中缓存的数据更少，从而强制执行更多的磁盘读取并增加查询延迟——你可能会看到延迟**ReadOpsPerSec**增加，**QueryResponseVolume**响应时间会缩短。

限制`query-memory-bytes`将导致内存密集型查询失败，并显示 **runtime\$1error **QueryRequestsTotal****，尤其是聚合大型数据集或返回大量结果集的查询。对于先前成功的查询，用户可能会遇到 “内存不足” 错误。

降低对高基数数据的查询性能会`storage-series-id-set-cache-size`降低，因为系统必须更频繁地重新计算序列结果，而不是从缓存中检索序列结果。这尤其会影响反复查询相同系列组合的仪表板。

**最佳实践：**在应用这些限制性更改之前，请先分析您的查询模式并对其进行优化：
+ 查看**QueryResponseVolume**以识别返回过多数据的查询
+ 用于**QueryRequestsTotal**查找可以从优化中受益的经常执行的查询
+ 添加时间范围筛选器，将数据扫描减少到工作负载所需的范围
+ 在应用程序级别实现查询结果缓存
+ 考虑使用降采样任务对数据进行预聚合
+ 查看**SeriesCardinality**和优化您的数据模型以减少不必要的标签

查询优化应始终是您的第一种方法——当优化不足时，配置限制应该是最后的手段。

**硬件操作：**
+ 增加实例大小以获得更多 RAM

### 存储利用率高 (DiskUtilization > 70%)
<a name="high-storage-utilization"></a>

**CloudWatch 要监控的指标：**
+ **DiskUtilization**> 70%
+ **WriteThroughput**图案
+ **TotalBuckets**（许多存储桶会增加开销）

**配置调整：**

**优先级 1：检查日志配置**
+ 日志级别：确保设置为 “信息”（不是 “调试”）
+ flux-log-enabled: 除非主动调试，否则设置为 FALSE

**优先级 2：积极留存**
+ storage-retention-check-interval: 15ms（更频繁的清理）

**优先级 3：优化压实**
+ storage-compact-full-write-寒冷持续时间：2h0m0s（频率更高）
+ storage-cache-snapshot-write-寒冷持续时间：5m0s

**优先级 4：减小索引大小**
+ storage-max-index-log-文件大小：524,288（512KB 用于更快的压缩）

**重要注意事项：**

**关键的第一步-检查您的日志配置：**在进行任何其他更改之前，请验证您的日志设置。**调试日志和 Flux 查询日志消耗的磁盘空间可能与实际时间序列数据一样多或更多**，这是导致存储空间意外耗尽的最常见原因之一。

**日志影响：**
+ `log-level: debug`生成极其冗长的日志，可能每小时数百 MB
+ `flux-log-enabled: TRUE`记录每次 Flux 查询执行的全部细节，从而创建大量日志文件
+ 这些日志积累得很快，在容量规划过程中经常被忽视
+ 日志文件填满磁盘空间的速度比数据摄取更快，尤其是在较小的实例上
+ 与时间序列数据不同，日志在删除之前会在本地存储中保存 24 小时

**如果日志很大，请立即采取行动：**

1. 设置`log-level: info`（来自调试）

1. Set `flux-log-enabled: FALSE`

1. 监控即**DiskUtilization**时改进

**压缩配置的权衡取舍：**

这些配置更改是专门为具有**高摄入吞吐量和较短保留期且**磁盘使用量波动较大的工作负载而设计的。它们迫使压实发动机更积极地工作，这仅在特定情况下才有益。

**关键权衡：**提高压实频率将显著增加资源消耗：
+ **CPUUtilization**会随着压缩操作消耗 CPU 周期而上升
+ **MemoryUtilization**在压缩过程中会随着数据的加载和处理而增加
+ **WriteOpsPerSec**并且**WriteThroughput**会在压缩窗口期间达到峰值，可能超过你的 30% 的 IOPS 净空空间
+ **WriteTimeouts**如果压缩与应用程序写入 I/O 竞争，则可能会增加

这些更改可能会造成级联性能问题，即激进的压缩会消耗查询和写入操作所需的资源，即使在减少磁盘使用量的同时也会降低整体系统性能。

**最佳实践：**在调整压缩设置之前，请重点关注数据和日志管理：

1. **首先检查日志记录（最常见的问题）：**验证日志级别是否为 “信息” 且 flux-log-enabled为 FALSE

1. **查看您的数据模型：**您是否正在编写实际上并不需要的数据？ 你能减少测量或场粒度吗？

1. **优化保留策略：**检查**TotalBuckets**并查看每个存储桶的保留设置

1. **监控压实影响：**基准你的**CPUUtilization**MemoryUtilization****、和变更**WriteOpsPerSec**之前的

**替代方法：**
+ 增加存储容量（通常更简单、更具成本效益）
+ 实施数据降采样或聚合策略
+ 整合存储桶（减少 **TotalBuckets**）以减少开销
+ 更严格地审查和执行保留政策

只有在您已优化数据管理并确认您的实例有足够的 CPU、内存和 IOPS 余量来处理增加的负载时，才应用激进的压缩设置。

**硬件操作：**
+ 增加存储容量

### 高 IOPS 利用率（超过ReadIOPS/WriteIOPS/TotalOperationsPerSecond预配置的 70%）
<a name="high-iops-utilization"></a>

**CloudWatch 要监控的指标：**
+ **ReadOpsPerSec**\$1 **WriteOpsPerSec**= **总计 IOps PerSec**
+ **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-写道：8-12
+ storage-wal-max-write-延迟：5m0s

**优先级 3：调整快照时间**
+ storage-cache-snapshot-write-冷藏持续时间：15m0s（频率较低）
+ storage-compact-full-write-冷藏持续时间：6h0m0s（频率较低）

**重要注意事项：**

这些变化在 I/O 利用率和系统性能之间进行了显著的权衡：

**限制压缩 I/O：**
+ 减少`storage-max-concurrent-compactions`会减慢压缩操作的速度，从而导致 TSM 文件积累并**DiskUtilization**更快地增加
+ 较低会`storage-compact-throughput-burst`延长压实时间，使压实机保持更长的活动时间，并有可能阻塞其他操作
+ 压缩速度较慢意味着查询性能会随着时间的推移而降低，因为存储引擎必须从更多、更小的 TSM 文件而不是整合文件中读取
+ 你可能会看到 **QueryRequestsTotal**runtime\$1error 的速率随着等待 I/O 时查询超时而增加

**降低快照频率：**
+ 增加`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, analyze I/O模式之前，在限制之前进行优化。

**硬件操作：**
+ 升级到更高的 IOPS 存储层（3K → 12K）
+ 确保保持 30% 的 IOPS 余量

### 高系列基数 (SeriesCardinality > 1M)
<a name="high-series-cardinality"></a>

**CloudWatch 要监控的指标：**
+ **SeriesCardinality**每桶和总计
+ **MemoryUtilization**（随着基数的增加而增加）
+ **CPUUtilization**（查询计划开销）
+ **QueryRequestsTotal**（运行时错误率可能会增加）

**配置调整：**

**优先级 1：优化系列操控性**
+ storage-series-id-set-缓存大小：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-文件大小：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`为较小的值会增加索引压实频率，**WriteOpsPerSec**随着系统执行更频繁的索引**CPUUtilization**维护，该频率也会提高。

**批判性理解：**

当**SeriesCardinality**超过 500 万时，您将接近 InfluxDB 2.x 的架构极限。在 10M\$1 系列中，无论配置如何，性能都会呈指数级下降：
+ 查询计划变得昂贵得令人望而却步（高 **CPUUtilization**）
+ 内存需求非线性增长（高）**MemoryUtilization**
+ 索引操作占据主导地位 I/O (**ReadOpsPerSec**, **WriteOpsPerSec**)
+ **QueryRequestsTotal**runtime\$1error 率会随着查询超时或内存耗尽而增加

**最佳实践：**配置更改是临时创可贴。你必须解决根本原因：

1. **分析您的数据模型：**
   + 查看**SeriesCardinality**每个存储桶以确定问题区域
   + 确定哪些标签的唯一值计数较高
   + 寻找无限的标签值（UUIDs、时间戳、用户 IDs、会话） IDs
   + 查找本应改为字段的标签

**数据模型操作：**
+ 审查标签设计以减少不必要的基数
+ 考虑整合类似系列
+ **如果大于 10M 系列：**计划迁移到 InfluxDB 3.0

### 查询性能问题
<a name="query-performance-issues"></a>

**CloudWatch 要监控的指标：**
+ **QueryRequestsTotal**按结果类型（成功、运行时错误、编译错误、队列错误）
+ APIRequest状态@@ **为 500 或状态为 499 时的费率**
+ **QueryResponseVolume**（回复量大表示查询费用昂贵）

**配置调整：**

**优先级 1：增加查询资源**
+ 查询并发：增加到 v 的 75% CPUs
+ query-memory-bytes: 分配总内存的 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 率降低，但用户体验可能无法改善

增加`http-read-timeout`可以防止查询过早取消，但是：
+ 长时间运行的查询消耗资源的时间更长，从而减少了其他查询的容量
+ 用户等待更长时间才会收到超时错误
+ 可以隐藏应该优化的低效查询
+ 如果累积了许多慢速查询，可能会导致资源耗尽

**最佳实践：**查询性能问题通常是由查询效率低下而不是资源不足引起的。在增加资源分配之前：

1. **分析查询模式：**
   + 查看**QueryResponseVolume**以确定返回过多数据 (> 1MB) 的查询
   + 检查 **QueryRequestsTotal**runtime\$1error 模式——是什么原因导致了故障？
   + 查找状态为 499 的**APIRequest速率**（客户端超时）-查询速度太慢
   + 识别经常执行的昂贵查询

1. **首先优化查询：**

   常见的查询反模式：
   + 缺少时间范围过滤器 → 添加明确的时间范围
   + 查询所有系列 → 添加特定标签过滤器
   + 聚合窗口过多 → 使用适当的间隔
   + SELECT 中不必要的字段 → 只请求所需的数据
   + 无限制条款 → 添加合理的限制

1. **应用程序级解决方案：**
   + 实现查询结果缓存（Redis、Memcached）
   + 使用任务预先汇总常见模式
   + 为大型结果集添加分页
   + 对每个用户/仪表板实施查询速率限制
   + 使用降采样数据进行历史查询

1. **验证资源可用性：**
   + 检查 **CPUUtilization**-如果已经> 70%，则增加并发会使情况变得更糟
   + 检查 **MemoryUtilization**-如果已经大于 70%，则分配更多查询内存将导致 OOM
   + 在增加查询负载之前，请验证 T **otal IOps PerSec** 有 30% 的余量

**推荐的方法：**

1. 首先优化前 10 个最昂贵的查询（由 **QueryResponseVolume**）

1. 在应用程序级别实现查询结果缓存

1. 只有在查询经过优化且指标显示余量时，才会增加资源分配

1. 如果工作负载已超过当前容量，则可扩展到更大的实例类别

**硬件操作：**
+ 扩展您的计算容量，查询将受益于额外的处理能力 (vCPUs)

#### RegEx Flux 查询中的性能陷阱
<a name="regex-performance-pitfalls"></a>

在 Flux 中筛选数据时，请避免使用正则表达式进行精确匹配或简单模式匹配，因为这会带来严重的性能损失。 RegEx Flux 中的操作是**单线程**的，可以**完全绕过底层 TSM 索引**。 RegEx 过滤器不是利用InfluxDB优化的标签索引进行快速查找，而是强制查询引擎从存储中检索所有匹配的系列，并按顺序对每个值进行文本比较。在以下情况下，这会变得特别成问题：
+ **根据确切的标签值进行筛选**-使用相等运算符 (`==`) 或`contains()`函数代替类似的 RegEx 模式 `/^exact_value$/`
+ **匹配多个特定值**-使用带有值数组的`in`运算符，而不是像这样的交替模式 `/(value1|value2|value3)/`
+ **简单的前缀或后缀匹配**-考虑使用 o `strings.hasPrefix()` `strings.hasSuffix()` r 函数，它们比 RegEx 锚更有效

对于需要多个模式匹配的场景，请重构查询以使用多个过滤器谓词和逻辑运算符组合，或者在应用更复杂的字符串操作之前使用标签相等性进行预过滤。 RegEx 专为需要真实模式匹配但无法通过更简单的比较运算符表达的案例进行保留。

### 写入性能问题
<a name="write-performance-issues"></a>

**CloudWatch 要监控的指标：**
+ **WriteTimeouts**（计数增加）
+ **WriteOpsPerSec** 和 **WriteThroughput**
+ APIRequest写入端点的状态为 500 时的@@ **速率**
+ **QueryRequestsTotal**写入时结果=runtime\$1error

**配置调整：**

**优先级 1：优化 WAL 写入**
+ storage-wal-max-concurrent-写道：12-16
+ storage-wal-max-write-延迟：10m0s
+ http-write-timeout: 60

**优先级 2：优化缓存快照**
+ storage-cache-snapshot-memory-大小：52,428,800 (50MB)
+ storage-cache-snapshot-write-寒冷持续时间：10m0s

**优先级 3：控制字段验证**
+ storage-no-validate-field-size：TRUE（如果数据源可信）

**重要注意事项：**

写入性能调整涉及在吞吐量、可靠性和资源消耗之间进行谨慎的权衡：

**WAL 配置的权衡取舍：**

增加`storage-wal-max-concurrent-writes`允许更多的并行写入操作，但是：
+ **CPUUtilization**随着越来越多的写入线程争夺 CPU 而增加
+ **MemoryUtilization**在 WAL 刷新之前，随着更多数据在内存中缓冲而上升
+ **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**与写入负载的相关性
   + 通过状态码监控写入端点的**APIRequest速率**
   + 确定写入批量大小和频率

1. **首先优化写入操作：**

   常见的写入反模式：
   + 写入个人积分 → Batch 写入（5,000-10,000 个积分）
   + 写入频率过高 → 缓冲和批处理
   + 同步写入 → 实现异步写入队列
   + 无界写入突发 → 实施速率限制
   + 写入不必要的精度 → 适当地舍入时间戳

1. **验证 I/O 容量：**
   + 检查**总计 IOps PerSec**-如果已经> 70%，则增加 WAL 并发度会使情况变得更糟
   + **WriteOpsPerSec**在高峰期复习
   + 在调整写入设置之前，请确保存在 30% 的 IOPS 余量
   + 考虑 3K IOPS 是否足够或者是否需要 12K IOPS 等级

1. **应用程序级改进：**
   + 使用可配置的批量大小实现写入缓冲
   + 添加带有指数退避功能的写入重试逻辑
   + 使用异步写入操作
   + 在高峰时段实施写入速率限制
   + 监控写入队列深度并施加背压

**推荐的方法：**

1. 首先在应用程序级别优化写入批次大小（目标是每批获得 5,000-10,000 个积分）

1. 实现写入缓冲和异步操作

1. 验证 T **otal** 是否IOpsPerSec有足够的净空空间

1. 如果利用率一直高于 70%，则升级到下一个存储层（3K IOPS → 12K IOPS → 16K IOPS）

1. 只有在写入经过优化且 I/O 容量足够的情况下，才可调整 WAL 设置

1. 除非您可以完全控制数据源，否则@@ **切勿**禁用字段验证

**硬件操作：**
+ 升级到更高的 IOPS 存储空间（3K → 12K → 16K）
+ 确保有 I/O 足够的净空空间
+ 如果 CPU 或内存受限，则可扩展到更大的实例类

## 监控最佳实践
<a name="monitoring-best-practices"></a>

### CloudWatch 警报配置
<a name="cloudwatch-alarms-configuration"></a>

**严重警报（需要立即采取行动）：**

**CPUUtilization:**
+ 阈值：大于 90%，持续 5 分钟
+ 操作：实施流量补救措施或计算扩展

**MemoryUtilization:**
+ 阈值：大于 90%，持续 5 分钟
+ 操作：实施流量补救措施或计算扩展

**DiskUtilization:**
+ 阈值：> 85%
+ 操作：尝试通过删除旧存储桶、更新保留配置或存储扩展来释放空间

**总计 IOpsPerSec：**
+ 阈值：大于 90% 的预置时间为 10 分钟
+ 操作：实施流量补救措施或提高 IOPS

**SeriesCardinality:**
+ 阈值：> 10,000,000
+ 操作：检查您的数据模型，如果无法更改，请探索、迁移到 InfluxDB 3 或对数据进行分片

**EngineUptime:**
+ 阈值：意外重置（< 300 秒）
+ 操作：检查它是否与维护时段相吻合，如果没有，请向 Timestream 支持部门创建票证。

**警告警报（需要调查）：**

**CPUUtilization:**
+ 阈值：大于 70%，持续 15 分钟
+ 操作：查看工作量或流量的变化

**MemoryUtilization:**
+ 阈值：大于 70%，持续 15 分钟
+ 操作：查看工作量或流量的变化

**DiskUtilization:**
+ 阈值：> 70%
+ 操作：查看保留政策

**总计 IOpsPerSec：**
+ 阈值：超过 70% 的预置时间为 15 分钟
+ 操作：查看工作量或流量的变化

**QueryRequestsTotal （runtime\$1error）：**
+ 阈值：>占查询总数的 1%
+ 操作：查看工作量或流量的变化

**WriteTimeouts:**
+ 阈值：> 1% 的写入操作
+ 操作：查看工作量或流量的变化

**SeriesCardinality:**
+ 阈值：> 500 万个
+ 操作：查看数据模型优化

### 主动监控清单
<a name="proactive-monitoring-checklist"></a>

**每日：**
+ 错误峰值的审查 APIRequest率（400、404、499、500）
+ 检查运行时错误率 QueryRequestsTotal 和队列错误率
+ 验证 WriteTimeouts 次数最少
+ 检查是否有任何严重警报
+ 验证 EngineUptime （没有意外重启）

**每周：**
+ 回顾 CPUUtilization MemoryUtilization、和 DiskUtilization 趋势
+ 按结果类型分析 QueryRequestsTotal 模式
+ 查看每桶的 SeriesCardinality 增长率
+ 查看总IOpsPerSec 利用率趋势
+ 验证配置参数是否最佳
+ 评论 TaskExecutionFailures 模式

**每月：**
+ 容量规划审查（项目提前 3-6 个月）
+ 将当前指标与尺码表进行比较
+ 审查和优化保留政策
+ 从 Rate 和 r APIRequest ate 中分析查询模式 QueryResponseVolume
+ 审查 SeriesCardinality 和数据模型效率
+ 评估对实例扩展或配置更改的需求
+ 审查 TotalBuckets 和整合机会

## 问题排查指南
<a name="troubleshooting-guide"></a>

### 场景：性能突然下降
<a name="sudden-performance-degradation"></a>

**调查步骤：**

**查看最近的更改：**
+ 在 AWS 管理控制台中修改配置参数
+ 应用程序部署变更
+ 查询模式更改
+ 数据模型修改
+ 基础架构变更（实例类型、存储）

**查看 CloudWatch 指标：**
+ **CPU 峰值？** → 检查一下 CPUUtilization， QueryRequestsTotal
+ **记忆压力？** → 检查一下 MemoryUtilization， HeapMemoryUsage， ActiveMemoryAllocation
+ **IOPS 饱和度？** → 查看合计 IOpsPerSec， ReadOpsPerSec， WriteOpsPerSec
+ **系列赛基数跳跃？** → 查看 SeriesCardinality 增长情况
+ **错误率增加？** → 检查 QueryRequestsTotal (runtime\$1error)、Rate (Status=50 APIRequest 0)
+ **意外重启？** → 查看 EngineUptime

**启用详细日志：**

配置更改：
+ 日志级别：调试
+ flux-log-enabled: 没错

监控 1-2 小时，然后查看日志

返回日志级别：调查后的信息

**解决步骤：**
+ 根据调查结果应用适当的配置更改
+ 如果达到限制，则扩展资源
+ 必要时优化查询或数据模型
+ 如果负载突然增加，则实施速率限制

### 场景：内存耗尽
<a name="memory-exhaustion"></a>

**症状：**
+ MemoryUtilization > 90%
+ HeapMemoryUsage 接近最大值
+ QueryRequestsTotal 显示 runtime\$1error（内存不足）
+ APIRequest显示状态的费率 =500

**解决步骤：**

立即采取行动（如果很重要）：

1. 重启实例以清除内存（如果可以安全地这样做）

1. 暂时减少查询并发度

1. 尽可能消除长时间运行的查询

配置更改：

**优先级 1：减少缓存内存**
+ storage-cache-max-memory-大小：减少到 10% 的内存
+ 示例：32GB → 3,355,443,200 字节
+ storage-cache-snapshot-memory-大小：26,214,400 (25MB)

**优先级 2：限制查询内存**
+ query-memory-bytes: 设置为总内存的 60%
+ query-max-memory-bytes: 匹配 query-memory-bytes
+ query-initial-memory-bytes: 10% 的折扣 query-memory-bytes

**优先级 3：设置保护限制**
+ influxql-max-select-series: 10000
+ influxql-max-select-point: 100000000
+ 查询并发：减少到 v 的 50% CPUs

**长期解决方案：**
+ 优化数据模型以减少 **SeriesCardinality**
+ 在应用程序级别实施查询结果大小限制
+ 添加查询超时强制执行
+ 查看最常见的问题，确保这些问题遵循本节中提到的最佳实践 [查询性能问题](#query-performance-issues)

### 场景：高系列基数影响
<a name="high-series-cardinality-impact"></a>

**查看 CloudWatch 指标：**
+ **SeriesCardinality**> 5M
+ **MemoryUtilization**高
+ **QueryRequestsTotal**显示运行时错误增加
+ **CPUUtilization**由于查询计划开销而提高

**调查步骤：**

**分析基数增长：**
+ SeriesCardinality 增长率（每日/每周）
+ 投影到 100M 阈值
+ 确定高基数的来源
+ 查看标签的设计和使用情况

**评估性能影响：**
+ 比较**QueryRequestsTotal**成功率 before/after 基数增加
+ 评论**MemoryUtilization**关联
+ 检查**CPUUtilization**图案
+ 分析**QueryResponseVolume**趋势

**识别基数来源：**

查看数据模型：
+ 哪些桶最高？ SeriesCardinality
+ 哪些标签的唯一值计数很高？
+ 有不必要的标签吗？
+ 标签值是否不受限制（UUIDs、时间戳等）？

**查看当前配置：**

检查优化参数：
+ storage-series-id-set-cache-size：当前值？
+ influxql-max-select-series: 它限制了失控的查询吗？
+ storage-max-index-log-文件大小：适合基数？

**解决步骤：**

立即更改配置：

**优先级 1：优化系列操控性**
+ storage-series-id-set-缓存大小：1500-2000
+ storage-series-file-max-concurrent-snapshot-compactions: 6-8
+ storage-max-index-log-文件大小：2,097,152 (2MB)

**优先级 2：设置保护限制**
+ influxql-max-select-series: 10000
+ influxql-max-select-buckets: 1000
+ 查询并发：如果内存受限，则减少

**优先级 3：增加资源**
+ 扩展到下一个实例等级
+ 增加内存分配
+ 考虑一下 12K IOPS 存储层

**迁移规划（如果大于 10M 系列）：**
+ **InfluxDB 3.0 提供卓越的高基数性能**
+ 规划迁移时间表（2-3 个月）
+ 先用数据子集进行测试
+ 为迁移准备应用程序
+ InfluxDB 3.0 使用针对数十亿个系列进行了优化的列式存储

### 场景：查询队列积累
<a name="query-queue-buildup"></a>

**查看 CloudWatch 指标：**
+ **QueryRequestsTotal**随着 result=queue\$1error 的增加（查询被拒绝）
+ APIRequest状态=429或状态为503的@@ **费率**（为许多请求提供服务） unavailable/too 
+ **CPUUtilization**可能升高 (> 70%)，表示资源饱和
+ **MemoryUtilization**可能很高 (> 70%) 限制了查询容量
+ **QueryResponseVolume**显示较大的响应大小（查询占用了过多的资源）

**调查步骤：**

**分析队列和并发指标：**
+ 按结果类型查看**QueryRequestsTotal**细分：
  + queue\$1error 计数过高表示查询被拒绝了
  + 将成功率与基线进行比较——成功率下降了吗？
  + 检查 runtime\$1error 是否增加（启动后查询失败）
+ 监视器**APIRequest速率**模式：
  + 查找 “状态” =429（请求过多）或 “状态” =503（服务不可用）
  + 确定哪些端点遭到了拒绝
  + 查看一段时间内的请求速率趋势

**查看资源利用率：**
+ **CPUUtilization**在排队人数众多的时间段：
  + 如果大于 70%，则查询将受到 CPU 限制，无法更快地执行
  + 如果 < 50%，则队列限制可能过于严格
+ **MemoryUtilization**相关性：
  + 内存过高可能会限制查询并发性
  + 检查**HeapMemoryUsage**和是否**ActiveMemoryAllocation**存在内存压力
+ IOpsPerSec模式@@ **总数**：
  + High I/O 可能会减慢查询的执行速度
  + 检查查询是否已 I/O 绑定

**识别查询模式：**
+ 评论 **QueryResponseVolume**：
  + 查询返回的数据是否过多（> 1MB）？
  + 识别响应量最大的端点
  + 在昂贵的查询中寻找模式
+ 分析**QueryRequestsTotal**率：
  + 每秒的查询率是多少？
  + 是否存在爆发模式或持续的高负荷？
  + 与规模调整表中的实例容量进行比较
+ 按端点查看**APIRequest费率**：
  + 哪些查询端点的流量最高？
  + 是否存在重复或冗余的查询？

**检查资源可用性：**
+ 将当前指标与尺码表建议进行比较：
  + **SeriesCardinality**与实例类容量对比
  + 查询速率与每秒推荐查询次数的对比
  + **CPUUtilization**和**MemoryUtilization**净空
+ 验证 IOPS 容量：
  + **总**净空IOpsPerSec空间应为 30%
  + 检查查询是否正在等待磁盘 I/O

**解决步骤：**

配置更改：

**优先级 1：增加队列容量**
+ query-queue-size: 4096（从默认值 1024 开始）

**优先级 2：提高并发度（如果资源允许）**
+ 查询并发：增加到 v 的 75% CPUs
+ 示例：16 个 vCPU → 查询并发 = 12
+ 更改后验证 CPUUtilization 保持在 < 80%
+ 更改后验证 MemoryUtilization 保持在 < 80%

**优先级 3：优化查询执行**
+ query-memory-bytes: 确保拨款充足
+ storage-series-id-set-缓存大小：1000-1500
+ http-read-timeout: 120 秒（防止过早超时）

**优先级 4：设置保护限制**
+ influxql-max-select-series: 10000
+ influxql-max-select-point: 100000000

**应用程序级解决方案：**
+ **实现查询结果缓存**（Redis、Memcached）
  + 缓存经常执行的查询的结果
  +  TTLs 根据数据新鲜度要求进行适当设置
  + 监控缓存命中率
+ **使用连续查询**来预先汇总常见模式
  + 预先计算常用聚合
  + 查询预先聚合的数据而不是原始数据
+ 为大型结果集@@ **添加分页**
  + 限制初始查询大小
  + 按需加载其他数据
+ 对每个用户/仪表板@@ **实施查询速率限制**
  + 防止单个用户使系统不堪重负
  + 设定合理使用配额
+ **使用降采样数据进行历史**查询
  + 查询较旧时间段的低分辨率数据
  + 为最新数据保留全分辨率查询

**缩放决策：**
+ 如果持续 CPUUtilization > 70%：扩展到更大的实例
+ 如果持续 MemoryUtilization > 70%：扩展到内存优化型实例
+ 如果查询速率超过实例容量：根据大小调整表扩展到下一层