Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

要获得与亚马逊 Timestream 类似的功能 LiveAnalytics，可以考虑适用于 InfluxDB 的亚马逊 Timestream。适用于 InfluxDB 的 Amazon Timestream 提供简化的数据摄取和个位数毫秒级的查询响应时间，以实现实时分析。点击此处了解更多信息。

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

InfluxDB 2 的时间流监控和配置优化

概述

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

CloudWatch 指标参考

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

资源利用率指标

I/O 操作指标

吞吐量指标

API 性能指标

查询执行指标

数据组织指标

系统健康指标

任务管理指标

了解关键指标关系

IOPS 和吞吐量关系

30% 的净空规则：在每秒持续操作和预配置 IOPS 之间，始终保持至少 30% 的余量。这为以下内容提供了缓冲区：

计算示例：

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

监控公式：

IOPS 利用率% = (ReadOpsPerSec + WriteOpsPerSec)/预配置 IOPS × 100

了解系列基数性能影响

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

为什么 10M 是临界阈值：

实例大小和性能指南

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

按指标进行配置优化

CPU 利用率高 (CPUUtilization > 70%)

症状：

配置调整：

优先级 1：控制查询并发性

优先级 2：限制查询复杂性

优先级 3：启用查询分析

重要注意事项：

减少query-concurrency会限制可以同时执行的查询数量，这可能会增加排队的查询，并在高峰时段导致更高的查询延迟。如果查询需求超过降低的并发限制，用户可能会遇到仪表板加载速度较慢或报告超时的情况。

设置保护限制 (influxql-max-select-series,influxql-max-select-point) 将导致超过这些阈值的查询失败，并显示 compile_error 或 runtime_error。QueryRequestsTotal虽然这可以保护系统免受资源耗尽的影响，但它可能会破坏以前有效的现有查询。

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

硬件操作：

高内存利用率 (MemoryUtilization > 70%)

症状：

配置调整：

优先级 1：减少缓存内存

优先级 2：限制查询内存

优先级 3：优化系列缓存

重要注意事项：

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

限制query-memory-bytes将导致内存密集型查询失败，并显示 runtime_error 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, analyze 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为较小的值会增加索引压实频率，WriteOpsPerSec随着系统执行更频繁的索引CPUUtilization维护，该频率也会提高。

批判性理解：

当SeriesCardinality超过 500 万时，您将接近 InfluxDB 2.x 的架构极限。在 10M+ 系列中，无论配置如何，性能都会呈指数级下降：

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

数据模型操作：

查询性能问题

CloudWatch 要监控的指标：

配置调整：

优先级 1：增加查询资源

优先级 2：优化查询执行

优先级 3：设定合理的限制

重要注意事项：

查询资源的增加会导致资源竞争和潜在的系统不稳定：

资源分配权衡取舍：

增加query-concurrency允许同时运行更多查询，但每个查询都会争夺 CPU 和内存：

分配更多query-memory-bytes意味着可用于缓存和其他操作的内存更少：

增加query-queue-size只会延迟问题——它并不能解决容量问题：

增加http-read-timeout可以防止查询过早取消，但是：

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

推荐的方法：

硬件操作：

RegEx Flux 查询中的性能陷阱

在 Flux 中筛选数据时，请避免使用正则表达式进行精确匹配或简单模式匹配，因为这会带来严重的性能损失。 RegEx Flux 中的操作是单线程的，可以完全绕过底层 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:

总计 IOpsPerSec：

SeriesCardinality:

EngineUptime:

警告警报（需要调查）：

CPUUtilization:

MemoryUtilization:

DiskUtilization:

总计 IOpsPerSec：

QueryRequestsTotal （runtime_error）：

WriteTimeouts:

SeriesCardinality:

主动监控清单

每日：

每周：

每月：

问题排查指南

场景：性能突然下降

调查步骤：

查看最近的更改：

查看 CloudWatch 指标：

启用详细日志：

配置更改：

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

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

解决步骤：

场景：内存耗尽

症状：

解决步骤：

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

配置更改：

优先级 1：减少缓存内存

优先级 2：限制查询内存

优先级 3：设置保护限制

长期解决方案：

场景：高系列基数影响

查看 CloudWatch 指标：

调查步骤：

分析基数增长：

评估性能影响：

识别基数来源：

查看数据模型：

查看当前配置：

检查优化参数：

解决步骤：

立即更改配置：

优先级 1：优化系列操控性

优先级 2：设置保护限制

优先级 3：增加资源

迁移规划（如果大于 10M 系列）：

场景：查询队列积累

查看 CloudWatch 指标：

调查步骤：

分析队列和并发指标：

查看资源利用率：

识别查询模式：

检查资源可用性：

解决步骤：

配置更改：

优先级 1：增加队列容量

优先级 2：提高并发度（如果资源允许）

优先级 3：优化查询执行

优先级 4：设置保护限制

应用程序级解决方案：

扩展决策：