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 层网关时延瓶颈点。
使用全景拓扑持续跟踪云原生应用的压测性能瓶颈
测试小姐姐正在对云原生的电商应用进行压测,但是如何对压测结果进行持续的观测呢?这一直是比较头痛的事情,本文将介绍如何利用 DeepFlow 的全景拓扑帮助小姐姐快速找到瓶颈点。DeepFlow 全景拓扑无需业务修改代码、配置或者重启服务,利用 BPF/eBPF 技术通过对业务零侵扰的方式构建而来,这是一种很便捷且低成本的方式来观测全链路压测的结果。
应用响应时延背后深藏的网络时延
应用异常时,基本可以分为服务访问不通和服务响应慢两个大类。其中服务响应慢的问题定位非常棘手,很多无头案。应用团队有日志和追踪,对于自认为的不可能不合理的事情都会甩给基础设施团队,又由于基础设施团队现有的监控数据缺乏应用的观测视角,通常成为一切「不是我的问题」超自然现象的终极背锅侠,其中以网络团队尤为严重。
可观测性实战:快速定位 K8s 应用故障
故障发生在2023春节前两天,DeepFlow 团队内部访问工单系统出现问题,影响了所有北京区的同事,这篇文章将详细记录如何利用 DeepFlow 定位到对这次问题根因(网关 MSS 误变更导致报文大于 MTU,大数据报文被丢弃)。
K8s 服务异常排障过程全解密
K8s 让应用发布更加快速安全,让应用部署也更加灵活,但在带来这些便利性的同时,也给应用排障增加了 K8s 平台层面的复杂度,本篇文章将以常见的服务异常入手,来详细拆解 K8s 服务访问方式,以及如何利用现有的可观测体系来对 k8s 平台和应用服务进行快速排障。
使用 DeepFlow 开启 DNS 可观测性
我们基于 DeepFlow 构建了对一个高效、可配置、无侵入、面向应用的 DNS 监控面板,可监控 DNS 服务的网络异常、吞吐、时延,以及访问日志,以快速定位性能瓶颈和排查故障原因