<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Observability on Chen Kai Blog</title><link>https://www.chenk.top/zh/tags/observability/</link><description>Recent content in Observability on Chen Kai Blog</description><generator>Hugo</generator><language>zh-CN</language><lastBuildDate>Mon, 04 May 2026 09:00:00 +0000</lastBuildDate><atom:link href="https://www.chenk.top/zh/tags/observability/index.xml" rel="self" type="application/rss+xml"/><item><title>阿里云全栈实战（七）：SLS 打造可观测性体系</title><link>https://www.chenk.top/zh/aliyun-fullstack/07-observability/</link><pubDate>Mon, 04 May 2026 09:00:00 +0000</pubDate><guid>https://www.chenk.top/zh/aliyun-fullstack/07-observability/</guid><description>&lt;p>我职业生涯中最严重的一次生产事故，排查整整花了三个小时。当时一个 Node.js 服务间歇性返回 502 错误，大约 5% 的请求受影响，而我手头几乎没有任何工具：没有集中式日志（每台 ECS 实例都有自己的 &lt;code>/var/log/&lt;/code>，我只能一台台 SSH 登录查看）；没有监控大盘（只能在终端里反复执行 &lt;code>top&lt;/code> 和 &lt;code>df -h&lt;/code>）；也没有链路追踪（只能靠手动添加 &lt;code>console.log&lt;/code> 时间戳，试图定位哪个下游调用卡住了）。三小时后，问题终于浮出水面：一个被遗忘的定时任务占着数据库连接不释放，导致 RDS 连接池在高负载下耗尽。修复只需两行代码，但诊断过程却耗费了整整三小时——只因系统毫无可观测性可言。&lt;/p></description></item><item><title>Docker 与容器（六）：调试与日志——当‘盒子’内部出问题时</title><link>https://www.chenk.top/zh/docker-containers/06-debugging-and-logging/</link><pubDate>Wed, 21 Jun 2023 09:00:00 +0000</pubDate><guid>https://www.chenk.top/zh/docker-containers/06-debugging-and-logging/</guid><description>&lt;p>正常运行的容器近乎‘隐形’，而一旦出问题，它就立刻变成一个密不透风的‘黑盒’。容器化的核心优势在于隔离，但恰恰是这种隔离，让调试变得棘手——你没法像对待普通服务器那样直接 &lt;code>ssh&lt;/code> 进去，也无法从宿主机随意浏览容器内部的文件系统。好在 Docker 提供了一整套专用工具，帮助你检查、诊断并理解运行中（甚至已崩溃）容器内部究竟发生了什么。&lt;/p></description></item></channel></rss>