logo
logo
可观测性实战:快速定位 Redis 应用高时延问题
应用连接 Redis 的最佳实践是使用连接池,然而连接池通常会引入很多繁杂的配置。不合理的配置往往会造成性能隐患,并进而导致生产故障。当应用缺乏可观测性时,无法在故障发生前发现隐患,也难以在故障发生时快速定位。本文从一个普通的应用高时延入手,讲述如何使用 DeepFlow 快速定位问题根因。
可观测性实战:快速定位 K8s CNI 端口冲突问题
某车企的车控业务访问账户系统时无规律偶发连接超时(connection timeout),本案例分享利用 DeepFlow 深度剖析如何分钟级定位 K8s CNI 的 SNAT (Source Network Address Translation) 触发 Node 节点源端口冲突,导致连接服务端异常。
可观测性实战:快速定位云服务时延瓶颈
本次案例为某智能汽车公司,业务监控告警发现某充电核心服务 SQL 查询时间偶现超过 200ms,对前方用户影响明显。此问题涉及多团队,仅问题定位就持续了将近 1 个星期未有结论,通过 DeepFlow 的调用日志及分布式调用链追踪的能力,快速定位瓶颈点为云网络抖动导致的,进而直接向云厂商提交工单并附带令人信服的证据。
可观测性实战:快速定位 K8s 应用的时延瓶颈
本次案例为某物流公司在今年 4 月份左右,SRE 通过监控 Nginx 日志,发现一个域名在每天晚上 12 点后存在大量持续 1s 的超时情况,这个问题困扰了用户近一个月。通过查看 DeepFlow 的调用日志,立即排除了业务响应慢的可能性,最终发现问题是 Nginx 自身配置问题导致的。这个案例展示了如何快速的定位 7 层网关时延瓶颈点。
应用响应时延背后深藏的网络时延
应用异常时,基本可以分为服务访问不通和服务响应慢两个大类。其中服务响应慢的问题定位非常棘手,很多无头案。应用团队有日志和追踪,对于自认为的不可能不合理的事情都会甩给基础设施团队,又由于基础设施团队现有的监控数据缺乏应用的观测视角,通常成为一切「不是我的问题」超自然现象的终极背锅侠,其中以网络团队尤为严重。
可观测性实战:快速定位 K8s 应用故障
故障发生在2023春节前两天,DeepFlow 团队内部访问工单系统出现问题,影响了所有北京区的同事,这篇文章将详细记录如何利用 DeepFlow 定位到对这次问题根因(网关 MSS 误变更导致报文大于 MTU,大数据报文被丢弃)。
K8s 服务异常排障过程全解密
K8s 让应用发布更加快速安全,让应用部署也更加灵活,但在带来这些便利性的同时,也给应用排障增加了 K8s 平台层面的复杂度,本篇文章将以常见的服务异常入手,来详细拆解 K8s 服务访问方式,以及如何利用现有的可观测体系来对 k8s 平台和应用服务进行快速排障。