Azure 托管 Redis 监视数据参考

本文包含此服务的所有监视参考信息。

指标

本部分列出了为此服务自动收集的所有平台指标。 这些指标也是 Azure Monitor 中支持的所有平台指标的全局列表的一部分。

有关指标保留的信息，请参阅 Azure Monitor 指标概述。

有关 Microsoft.Cache/redisEnterprise 支持的指标的详细信息和信息，请参阅以下部分。

Microsoft.Cache/redisEnterprise 支持的指标

下表列出了可用于 Microsoft.Cache/redisEnterprise 资源类型的指标。

表标题

• 指标 是该指标在 Azure 门户中的显示名称。
• Rest API 中的名称 - 在 REST API 中引用的指标名称。
• 单位 - 度量单位。
• 聚合 - 默认的聚合类型。 有效值：平均值、最小值、最大值、总计、计数。
• 维度 - 适用于指标的维度。
• 时间粒度 - 对指标采样的间隔。 例如，PT1M 表示该指标每分钟采样一次，PT30M 表示每 30 分钟一次，PT1H 表示每小时一次，以此类推。
• DS 导出 - 是否可通过诊断设置将指标导出到 Azure Monitor 日志。 要了解如何导出指标的信息，请参阅在 Azure Monitor 中创建诊断设置。

有关 Azure 托管 Redis 指标的详细信息

以下章节提供了支持的Microsoft Azure Monitor指标的更多信息和解释指导。缓存/redisEnterprise。 有关完整的指标及其单元和聚合类型，请参见 支持指标 表。

关于集群级指标的详细信息

下表提供了每个集群级指标的底层 Redis V1 Prometheus 源指标及额外解释指导。 关于源指标定义，请参见 Redis Enterprise Prometheus v1指标参考资料。

分片级指标

Azure Managed Redis现在可以公开分片级指标，提供每个分片对缓存行为的可视化。 这些指标来源于 Redis V2 Prometheus 端点（redis_server_* 指标）。

尺寸

每个分片级别度量支持以下维度：

关于分片级指标的详细信息

下表提供了每个分片级指标的底层Redis V2 Prometheus源指标及额外解释指导。 关于源度量定义，请参见 Redis Enterprise Prometheus v2度量参考资料。

大键指标

以下指标跟踪分片间密钥大小分布，帮助您在大密钥引发性能问题之前识别出问题。

字符串键（按内存大小）

按元素计数设置键

排序集键（按元素计数）

哈希键（按字段计数）

列表键（按元素计数）

分片级指标故障排除

以下章节描述了常见的分片级场景及其诊断方法：

• 识别复制链路故障
• 识别记忆失衡
• 诊断复制缓冲区生长
• 管理大密钥

识别复制链路故障

复制链路故障发生在主分片无法与其关联的副本分片建立复制连接，导致副本无法与主分片保持同步。 该指标仅由副本分片发出，因为只有副本有返回主节点的复制链路可报告，并报告该副本当前是否连接到主节点。 持续故障会移除受影响分片的高可用性保护，并在链路恢复前发生故障切换时增加数据丢失的风险。 话虽如此，复制链路在故障切换、分片迁移、扩展或维护事件中可能会暂时不健康，因此该指标可能会产生噪声。 这就是为什么在设置该指标的警报时，只应在持续一段时间内发出多个数据点，显示健康状况下降。

检测方法：

1. 将 分片复制链路 拆分为 Slots (Range)。 任何分片的值为0表示分片的复制链路已断开;1表示它已经升起。
2. 将长时间保持0（例如120分钟或更久）的链路视为持续故障，而非瞬时重连。 在正常维护或故障切换期间，可能会出现短暂的低谷。
3. 在同一分片上关联 Shard Memory Used 和 Shard Memory Client Replica ，以判断主节点的资源压力是否伴随故障。

常见原因：

• 大键是一个主要原因。 大密钥和集合使同步变得缓慢且成本高昂，可能导致副本停滞，最终使复制链路进入不健康状态。
• 主节点和副本节点之间的网络中断或高延迟。
• 主分片因写吞吐量过高或CPU饱和而过载，无法服务复制。
• 主节点的内存压力阻止了同步副本所需的后台操作。
• 由于慢速副本落后于复制积压，导致反复的全同步周期。

修复：

• 减少持续写吞吐量或扩展缓存以增加容量，使主分片不那么饱和。
• 识别并拆分大密钥，这些密钥会使受影响分片的复制和重新同步成本增加。
• 如果负载降低后链路仍然断开，请发起支持请求，让平台团队调查节点健康状况和内部复制积压。

识别记忆失衡

内存失衡发生在某些碎片使用明显更多的内存时，这可能导致特定碎片被逐出，而其他碎片则有充足的空闲内存。

检测方法：

1. 分片内存（字节）被Slots (Range)分割。 最大/最小比值大于2x表示有意义的不平衡。
2. 通过与分Slots (Range)相关联，判断不平衡是由于密钥数量增加还是特定分片值较大。

常见原因：

• 标签滥用，将大量密钥集中在同一分片上。
• 大密钥：在特定分片上少量非常大的数据结构。
• TTL策略不一致导致内存使用随时间出现差异。

修复：

• 通过审查和调整标签的使用方式来重新分发密钥。
• 利用大键指标识别并拆分大密钥，定位受影响的分片。
• 查看高内存分片密钥的TTL政策。

诊断复制缓冲区生长

每个主分片都为其副本维护一个输出缓冲区，副本尚未应用写入队列。 当副本无法跟上时，这个缓冲区会增长并消耗分片上的内存。 如果它在无限制的情况下增长，副本可能会被断开连接并强制进行完全重新同步，这成本高昂，可能导致反复的重新同步循环，甚至导致复制同步变得不健康。 由于每个碎片都有自己的复制缓冲区，成长通常被隔离在特定的碎片上。

检测方法：

1. 将分片内存客户端副本（字节）Slots (Range)按分割，观察任何分片在15分钟或更长时间内持续上升的趋势，而不是单次高读数。 稳定增长才是信号，而不是短暂的激增。
2. 与同一分片上的分 片复制链接 相关联。 缓冲区增长以链路降至0结束，表示副本已被断开连接，且很可能进行重新同步。
3. 与写入密集活动（集群层面的集合 和 总运算 ）相关，以判断写入突发是否推动了增长。

常见原因：

• 持续的写突发产生的变化速度超过副本应用的速度。
• 一个缓慢的复制品，资源争夺，落后于主级。
• 反复进行完整的重新同步循环，反复填充缓冲区。
• 大键让单个复制操作变得庞大且传输缓慢。

修复：

• 尽可能平滑或减少写突发，或者通过扩展缓存来增加容量。
• 识别并拆分大密钥，以减少单个复制操作的规模。
• 如果缓冲区持续增长且副本反复断开连接，请发起支持请求，让平台团队检查副本的健康和缓冲区大小，这些由服务管理。

管理大密钥

大密钥和大集合会增加单个分片的内存压力，使复制成本增加。 为了获得最佳的数据路径性能，应将单个键/值大小控制在512 KB以下。 这是性能建议，不是强制限制。

大型密钥指标桶仅监控边界——它们不是推荐或认可的密钥大小。 例如，“分片字符串大小低于128 MB”桶仅统计小于128 MB的字符串密钥，以便观察增长;这并不意味着 Azure 建议密钥存储在接近 128 MB 的位置。 同样，元素计数桶（1M、8M）是检测超大集合的阈值，而非目标大小。 始终以最小实用的密钥尺寸为目标（理想情况下低于512 KB），并且把任何进入更高层级的密钥都当作调查对象。

大键将桶键按大小范围测量，这样你能在问题出现前发现增长。 对于集合，第一个桶代表正常范围内的键，因此应将第二个或第三个桶中出现的键视为值得调查的键。 对于字符串密钥，只有小于 128 MB 的桶会被暴露，因此任何接近或超过 128 MB 的字符串值都应被视为关注点。

为什么大键很重要：

• 复制成本：大密钥使得高可用复制和主动地理复制（CRDB）成本更高。 效果并非立竿见影;它通常在完全重新同步时出现，该重同步由后续故障或重新连接触发。
• 闪存优化缓存影响：在闪存优化SKU中，如果密钥较大，密钥会保留在RAM中，不会卸载到闪存，这可能导致内存外（OOM）错误，即使闪存磁盘空间仍然可用。 相对于键名非常小的值也难以卸载。

检测方法：

1. 根据每个大键的指标 Slots (Range) 来拆分，看看哪些碎片里有大键。
2. 对于集合，重点关注第二和第三个元素计数桶（1M到8M及超过8M）。 第三桶代表最极端的调性。 对于字符串，只有“ 分片字符串大小低于128 MB ”桶暴露，因此任何字符串值在128 MB或以上都应视为关注点。
3. 与 分片内存 相关，用于 Slots (Range) 确认大键是否导致特定分片内存失衡。

修复：

• 将值大小向第一个桶或512 KB减小，作为最佳实践。 常见策略包括将大值拆分或分块到多个键，以及压缩或重新格式化序列化值。
• 对于随着时间增长无界的集合（列表、集合、排序集合和哈希），可以将集合拆分到多个键或定期修剪。
• 目标是减少单个密钥和集合的大小。 最佳方法取决于你的应用设计和数据类型。

分片级指标的警示建议

资源日志

本部分列出了可为此服务收集的资源日志类型。 本部分拉取自 Azure Monitor 支持的所有资源日志类别类型列表。

Microsoft.Cache/redisEnterprise/databases 支持的资源日志

Azure Monitor 日志表

本部分列出了与此服务相关的 Azure Monitor 日志表，日志分析可使用 Kusto 查询来查询这些表。 这些表包含资源日志数据，此外还可能包含其他数据，具体取决于所收集并路由到这些表的内容。

Azure 托管的 Redis

Microsoft.Cache/redisEnterprise

• REDConnectionEvents

活动日志

链接表列出了可在此服务的活动日志中记录的操作。 这是活动日志中所有可能的资源提供程序操作的子集。

有关活动日志条目架构的详细信息，请参阅活动日志架构。

• Microsoft.Cache 资源提供程序作

相关内容

• 请参阅使用 Azure Monitor 监视 Azure 资源，详细了解如何监视 Azure 资源。