Azure Cache for Redis基础层实例停机期间如何获取相关日志？

一、开发环境基础层停机原因日志获取 #

基础层为单节点架构，无SLA保障，默认指标/活动日志缺失情况下，可通过以下方式获取停机原因：

• 启用并查看资源日志：若此前已开启资源日志（需提前配置存储账户/Log Analytics），日志中包含节点状态变更、连接异常、主机级事件等信息，可定位停机根源。
• 提交Azure支持工单：即使基础层无SLA，Azure支持团队可查询后台主机级日志，排查硬件故障、主机重启、网络中断等底层问题。
• 检查服务健康：查看订阅下的服务健康通知，确认停机时段是否存在Redis所在区域的服务中断或维护事件。

二、生产环境高可用层级类似问题快速排查方向 #

高可用层级采用主从架构+自动故障转移，遇连接超时/停机时，按以下步骤快速定位：

• 指标分析：重点监控核心指标
  • 连接数：是否突增至实例上限（高可用层级有连接数配额）
  • 内存使用率：是否达到阈值触发键驱逐，或内存溢出导致节点重启
  • CPU使用率：是否持续过高（超过90%）导致服务无法响应
  • 故障转移指标：若存在故障转移事件，说明主节点异常触发了自动切换
• 资源日志排查：提前开启资源日志，重点关注
  • 故障转移事件日志：确认是否为主节点故障导致的切换
  • 连接错误日志：排查客户端连接被拒绝、超时的具体原因
  • 命令执行日志：是否有大量慢查询或高开销命令阻塞服务
• 客户端错误日志解析：以你遇到的StackExchange.Redis.RedisTimeoutException为例，关键字段解读：

  StackExchange.Redis.RedisTimeoutException
  Timeout awaiting response (outbound=0KiB, inbound=0KiB, 5432ms elapsed, timeout is 5000ms), command=HEXISTS, next: INFO, inst: 0, qu: 0, qs: 0, aw: False, bw: SpinningDown, rs: ReadAsync, ws: Idle, in: 0, last-in: 7721, cur-in: 0, sync-ops: 0, async-ops: 2202,
  

  • bw: SpinningDown：表示Redis节点正在下线，可能是主节点故障触发故障转移
  • async-ops: 2202：异步操作堆积，说明客户端请求无法及时得到响应
  • in: 0：无数据流入，服务端已停止响应
• 服务健康与维护检查：确认是否存在区域级服务中断、平台维护事件，高可用层级在维护期间可能出现短暂的切换延迟
• 客户端配置验证：
  • 检查连接超时设置是否合理，建议调整为与网络延迟匹配的值
  • 确认连接池大小是否足够，避免因连接耗尽导致请求阻塞
  • 验证重试策略是否启用，StackExchange.Redis需配置合理的重试次数与间隔，应对短暂的故障转移窗口
• 网络排查：
  • 检查VNet集成/NSG规则是否限制了Redis端口（6379/6380）
  • 验证防火墙规则是否允许客户端IP访问
  • 测试客户端与Redis实例的网络延迟，跨区域部署时延迟过高易引发超时

内容的提问来源于stack exchange，提问作者Praveen Nayak