<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>SLS on Chen Kai Blog</title><link>https://www.chenk.top/zh/tags/sls/</link><description>Recent content in SLS 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/sls/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>Terraform 实战（七）：可观测与成本告警</title><link>https://www.chenk.top/zh/terraform-agents/07-observability-and-cost-control/</link><pubDate>Tue, 24 Mar 2026 09:00:00 +0000</pubDate><guid>https://www.chenk.top/zh/terraform-agents/07-observability-and-cost-control/</guid><description>&lt;p>Agent 具备非确定性、多步骤执行特性，并频繁调用高成本 API。这三者叠加意味着：若未在上线首日完成可观测性埋点，故障发生后将极难定位与调试。本文通过 Terraform 打通日志、链路追踪和指标三条管线，全部汇聚至统一仪表盘，并配套六个可直接用于排查真实故障的 SLS 查询，以及四个已在生产环境中成功拦截事故的钉钉告警。&lt;/p></description></item></channel></rss>