<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Observability - 分类 - Shengxu · Cloud Architecture &amp; DevOps</title><link>https://shengxu.pages.dev/categories/observability/</link><description>Shengxu 的云架构 &amp; DevOps 技术博客：Kubernetes、Cilium、可观测性、LLM 基础设施、Agent 工程化等。</description><generator>Hugo 0.153.2 &amp; FixIt v0.4.0-alpha.3-20251225101113-8ffb9a95</generator><language>zh-CN</language><lastBuildDate>Fri, 17 Apr 2026 19:40:00 +0800</lastBuildDate><atom:link href="https://shengxu.pages.dev/categories/observability/index.xml" rel="self" type="application/rss+xml"/><item><title>从 Azure SRE Agent 到 HolmesGPT：多云 Kubernetes 环境下的 AI 运维实践</title><link>https://shengxu.pages.dev/posts/azure-sre-agent-to-holmesgpt/</link><pubDate>Fri, 17 Apr 2026 19:40:00 +0800</pubDate><guid>https://shengxu.pages.dev/posts/azure-sre-agent-to-holmesgpt/</guid><category domain="https://shengxu.pages.dev/categories/ai/">AI</category><category domain="https://shengxu.pages.dev/categories/kubernetes/">Kubernetes</category><category domain="https://shengxu.pages.dev/categories/devops/">DevOps</category><category domain="https://shengxu.pages.dev/categories/observability/">Observability</category><description>&lt;p&gt;多云 Kubernetes 时代，SRE 的痛点已经不只是“告警太多”，而是调查链路太长、上下文太分散、跨云排障成本太高。真正消耗人的，不是看一眼图表，而是在多个云平台、日志系统、部署记录和工单系统之间反复切换。&lt;/p&gt;</description></item><item><title>Cilium 2026（续）：统一数据平面正在怎样改变 Kubernetes 的平台结构</title><link>https://shengxu.pages.dev/posts/cilium-2026-part-2-unified-dataplane/</link><pubDate>Sat, 21 Mar 2026 14:31:56 +0800</pubDate><guid>https://shengxu.pages.dev/posts/cilium-2026-part-2-unified-dataplane/</guid><category domain="https://shengxu.pages.dev/categories/kubernetes/">Kubernetes</category><category domain="https://shengxu.pages.dev/categories/devops/">DevOps</category><category domain="https://shengxu.pages.dev/categories/observability/">Observability</category><category domain="https://shengxu.pages.dev/categories/security/">Security</category><category domain="https://shengxu.pages.dev/categories/ai/">AI</category><description>&lt;p&gt;在&lt;a href="https://shengxu.pages.dev/posts/cilium-2026/"&gt;上一篇关于 Cilium 的文章&lt;/a&gt;中，我们探讨了 2026 年迁移潮背后的真实原因：它不再仅仅是“一个更快的 CNI”，而是将 Kubernetes 网络、安全、可观测与多集群能力，重新组织成了一套更统一的基础设施底座，并理清了它与 Istio 的分工协作边界。&lt;/p&gt;</description></item><item><title>Cilium在 2026 年到底能为我们带来什么</title><link>https://shengxu.pages.dev/posts/cilium-2026/</link><pubDate>Sun, 08 Mar 2026 10:30:00 +0800</pubDate><guid>https://shengxu.pages.dev/posts/cilium-2026/</guid><category domain="https://shengxu.pages.dev/categories/kubernetes/">Kubernetes</category><category domain="https://shengxu.pages.dev/categories/devops/">DevOps</category><category domain="https://shengxu.pages.dev/categories/observability/">Observability</category><description>&lt;h2 class="heading-element" id="它到底带来了什么有意义的改变以及该如何与-istio-分工协作"&gt;&lt;span&gt;——它到底带来了什么有意义的改变，以及该如何与 Istio 分工协作&lt;/span&gt;
 &lt;a href="#%e5%ae%83%e5%88%b0%e5%ba%95%e5%b8%a6%e6%9d%a5%e4%ba%86%e4%bb%80%e4%b9%88%e6%9c%89%e6%84%8f%e4%b9%89%e7%9a%84%e6%94%b9%e5%8f%98%e4%bb%a5%e5%8f%8a%e8%af%a5%e5%a6%82%e4%bd%95%e4%b8%8e-istio-%e5%88%86%e5%b7%a5%e5%8d%8f%e4%bd%9c" class="heading-mark"&gt;
 &lt;svg class="octicon octicon-link" viewBox="0 0 16 16" version="1.1" width="16" height="16" aria-hidden="true"&gt;&lt;path d="m7.775 3.275 1.25-1.25a3.5 3.5 0 1 1 4.95 4.95l-2.5 2.5a3.5 3.5 0 0 1-4.95 0 .751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018 1.998 1.998 0 0 0 2.83 0l2.5-2.5a2.002 2.002 0 0 0-2.83-2.83l-1.25 1.25a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042Zm-4.69 9.64a1.998 1.998 0 0 0 2.83 0l1.25-1.25a.751.751 0 0 1 1.042.018.751.751 0 0 1 .018 1.042l-1.25 1.25a3.5 3.5 0 1 1-4.95-4.95l2.5-2.5a3.5 3.5 0 0 1 4.95 0 .751.751 0 0 1-.018 1.042.751.751 0 0 1-1.042.018 1.998 1.998 0 0 0-2.83 0l-2.5 2.5a1.998 1.998 0 0 0 0 2.83Z"&gt;&lt;/path&gt;&lt;/svg&gt;
 &lt;/a&gt;
&lt;/h2&gt;&lt;p&gt;到了 2026 年，很多团队讨论 Cilium，已经不是在问“它值不值得试试”，而是在问：“我们什么时候该迁过去？”
真正推动迁移的原因，通常不是单一的性能数字，而是 Cilium 把 Kubernetes 网络、安全、可观测性和多集群能力，重新组织成了一套更统一的基础设施底座。&lt;/p&gt;</description></item><item><title>周末造轮子：写了一个 LLM API Key 本地负载均衡器</title><link>https://shengxu.pages.dev/posts/llm-api-load-balancer/</link><pubDate>Sat, 14 Feb 2026 10:18:00 +0800</pubDate><guid>https://shengxu.pages.dev/posts/llm-api-load-balancer/</guid><category domain="https://shengxu.pages.dev/categories/ai/">AI</category><category domain="https://shengxu.pages.dev/categories/devops/">DevOps</category><category domain="https://shengxu.pages.dev/categories/observability/">Observability</category><description>&lt;p&gt;最近因为一直在高强度使用各种 LLM 服务（OpenAI, Gemini, DeepSeek 等），遇到了一个很现实的痛点：&lt;strong&gt;贫穷&lt;/strong&gt;。&lt;/p&gt;
&lt;p&gt;为了省钱，我申请了多个免费的 API Key（比如 Google Gemini 的 Free Tier，或者 DeepSeek 的赠送额度），但这些免费 Key 往往有严格的速率限制（RPM/TPM）。写代码写得正嗨，突然弹出一个 &lt;code&gt;429 Too Many Requests&lt;/code&gt;，思路瞬间被打断，非常搞心态。&lt;/p&gt;</description></item><item><title>实战 · 打造会记忆的AI 写作搭档（四）：可观察性（Metrics + Logs + Trace + Cost）</title><link>https://shengxu.pages.dev/posts/fantasy-novel-agent-observability/</link><pubDate>Thu, 05 Feb 2026 16:00:00 +0800</pubDate><guid>https://shengxu.pages.dev/posts/fantasy-novel-agent-observability/</guid><category domain="https://shengxu.pages.dev/categories/ai/">AI</category><category domain="https://shengxu.pages.dev/categories/devops/">DevOps</category><category domain="https://shengxu.pages.dev/categories/observability/">Observability</category><description>&lt;p&gt;在上一篇中，我们讨论了 RAG 系统的安全性与 Prompt 注入防护。今天我们来聊聊另一个工程化深水区：&lt;strong&gt;可观察性（Observability）&lt;/strong&gt;。&lt;/p&gt;
&lt;p&gt;当系统从“能跑”走向“长期可用”，你一定会遇到三类问题：&lt;/p&gt;</description></item><item><title>实战 · 打造会记忆的AI 写作搭档（三）：安全架构（RAG 防护、事实守卫与 BYOK）</title><link>https://shengxu.pages.dev/posts/fantasy-novel-agent-security/</link><pubDate>Wed, 04 Feb 2026 10:00:00 +0800</pubDate><guid>https://shengxu.pages.dev/posts/fantasy-novel-agent-security/</guid><category domain="https://shengxu.pages.dev/categories/ai/">AI</category><category domain="https://shengxu.pages.dev/categories/security/">Security</category><category domain="https://shengxu.pages.dev/categories/devops/">DevOps</category><category domain="https://shengxu.pages.dev/categories/observability/">Observability</category><description>&lt;p&gt;在前面2.5篇里，我已经把 &lt;a href="https://shengxu.pages.dev/posts/fantasy-novel-agent-architecture-evolution/"&gt;FantasyNovelAgent&lt;/a&gt; 的主干讲清楚了：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;&lt;a href="https://shengxu.pages.dev/posts/fantasy-novel-agent-architecture-evolution/"&gt;实战 · 打造会记忆的AI 写作搭档（一）：多 Agent 架构进化&lt;/a&gt;&lt;/strong&gt;&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;&lt;a href="https://shengxu.pages.dev/posts/fantasy-novel-agent-database-evolution/"&gt;实战 · 打造会记忆的AI 写作搭档（二）：数据库篇&lt;/a&gt;&lt;/strong&gt;&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;&lt;a href="https://shengxu.pages.dev/posts/fantasy-novel-agent-retrieval-evolution/"&gt;实战 · 打造会记忆的AI 写作搭档（坤）：检索系统篇&lt;/a&gt;&lt;/strong&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;这一篇我们深入探讨 AI 系统最容易被忽视、但至关重要的环节：&lt;strong&gt;安全性（Security）&lt;/strong&gt;。&lt;/p&gt;</description></item><item><title>从流量守门到质量内窥：2026 年企业级 LLM 可观察性体系构建指北</title><link>https://shengxu.pages.dev/posts/llm-observability-guide-2026/</link><pubDate>Mon, 19 Jan 2026 15:00:00 +0800</pubDate><guid>https://shengxu.pages.dev/posts/llm-observability-guide-2026/</guid><category domain="https://shengxu.pages.dev/categories/ai/">AI</category><category domain="https://shengxu.pages.dev/categories/observability/">Observability</category><description>&lt;p&gt;随着大语言模型（LLM）从“尝鲜玩具”全面转变为企业的“生产力底座”，一个被所有技术管理者反复拷问的问题浮出水面：&lt;strong&gt;当 API 调用黑盒化之后，我们该如何像管理数据库或微服务那样，去管理这些庞大而昂贵的 AI 模型？&lt;/strong&gt;&lt;/p&gt;</description></item><item><title>从改良到重塑：解构 Prometheus 监控架构的三种哲学与选型真相</title><link>https://shengxu.pages.dev/posts/prometheus-monitoring-architecture-evolution/</link><pubDate>Sun, 04 Jan 2026 17:00:00 +0800</pubDate><guid>https://shengxu.pages.dev/posts/prometheus-monitoring-architecture-evolution/</guid><category domain="https://shengxu.pages.dev/categories/observability/">Observability</category><description>&lt;p&gt;回望过去几年在可观察性领域的摸爬滚打，尤其是围绕 Metrics 体系的建设，感觉就像是一场漫长的架构修行。从最开始守着单机 Prometheus 还要担心磁盘爆满，到后来引入 Thanos 试图做“无限存储”，再到如今用 Mimir 重构整个监控中枢，这些经历散落在记忆里，甚至有些细节已经开始模糊。&lt;/p&gt;</description></item></channel></rss>