标签: #observability
关于 GPU、LLM、MLOps、Kubernetes 以及心态的文章 · 29 篇
访客统计里只看得见 0.5% 的流量 —— 防机器人要看来源，而不是自我声明
以一个 150 万页面的站点抵御爬虫一整年的记录为依据，梳理应对机器人流量的原则。基于 JavaScript 的分析工具数不到机器人，所以必须去看服务器日志；规则也不能建立在 User-Agent 这类自我声明的值上，而要建立在 ASN、地理位置、是否为经密码学验证的机器人这些难以伪造的来源信息上。文中还会谈到每次抓取带来多少访客这个指标、Cloudflare 公布的比率与单站实测值为何会分歧、防御装置本身吃掉性能预算的案例，以及在住宅
2026-08-09 · 17 分钟阅读 #network#bot#cloudflare#waf#scraping把观测数据放进 ClickHouse 意味着什么 — schema、rollup、TTL 与职责划分
当 trace 和日志每天膨胀到数 TB 规模，单靠一个搜索引擎或时序数据库就很难撑住了。本文从列式存储、压缩与排序键的角度，梳理 ClickHouse 为什么适合观测数据，并用真实的 DDL 设计 trace 表和日志表。文中讲清属性该用 Map 还是 JSON 类型的判断标准、如何用物化视图做 rollup、如何用分区和 TTL 控制成本。最后整理在已经用着 Prometheus 和 OpenSearch 的前提下，三者的职责该怎么
2026-08-02 · 22 分钟阅读 #observability#clickhouse#opentelemetry#data-modeling#cost会被读的仪表盘与值得呼人的告警 — 定义问题、组织变量、SLO 与告警疲劳
仪表盘的价值不在于好看，而在于能按顺序回答一组固定的问题。本文讲在动手做面板之前先写下要回答的问题，再讲数据源和变量该怎么组织，才能让一个仪表盘在多个环境里复用。文中用案例说明为什么告警该挂在症状而不是原因上，并把 SLO、错误预算、多窗口燃烧率告警写成真实的规则。最后整理出减少告警疲劳的规则，以及把仪表盘当作代码来管理的方法。内容以 Grafana 12 系列和 Prometheus 3.13 LTS 为准。
2026-08-02 · 21 分钟阅读 #observability#grafana#alerting#slo#dashboards设计能回答问题的 Prometheus 指标 —— 类型选择、基数预算，以及 rate 和分位数的陷阱
指标不是越多越好，能回答问题才有价值。本文先讲清楚 Counter、Gauge、Histogram 各自回答什么问题，选错了会让哪些计算在原理上变得不可能。接着讲怎么用数字而不是直觉给标签基数定预算，rate 和 histogramquantile 在什么条件下会悄悄给出错误答案，以及什么时候该建 recording rule、该起什么名字。最后留下五个在做面板之前应该问自己的问题。内容以 Prometheus 3.13 LTS 为准验
2026-08-02 · 24 分钟阅读 #observability#prometheus#promql#metrics#cardinality让日志可搜索，同时别把公司搜穷 — 结构化、映射爆炸、保留期与真实成本
日志成本超过计算成本的那一天，会降临在大多数组织身上。真正决定这一天能推迟多久的，不是压缩率，而是「把什么定义成字段」这个决策。本文讲结构化日志的字段设计、OpenSearch 映射爆炸拖垮集群的真实路径、用索引模板和 ISM 控制生命周期的方法，以及有原则的采样和保留分层。最后用数字算一算，用日志去模拟指标到底要付出多大代价。内容以 OpenSearch 3.5 和 OpenTelemetry Collector v0.157.0 为
2026-08-02 · 21 分钟阅读 #observability#logging#opensearch#elasticsearch#cost给应用接上 OpenTelemetry —— 从自动埋点到手动 span，以及为什么要放一个 collector
埋点不是安装一个 SDK 那么简单，而是要遵守一个顺序。本文用自动埋点在一天内搭好骨架，先把 resource 属性定下来，再讲清只在 self time 大的区间加手动 span 这个顺序，全程用一个真实服务从头到尾地埋点做示范。文中还原并修复了上下文传播断裂的四个地方：线程池、消息队列、后台任务，以及会剥掉请求头的代理。最后整理出把 collector 放在应用和后端之间的五个理由，并盘点埋点反而把应用搞坏的那些失效模式。
2026-08-02 · 22 分钟阅读 #observability#opentelemetry#instrumentation#otel-collector#tracing平均值什么也说明不了——如何用分布调试延迟
2026 年 7 月 27 日发布、登上 Hacker News 榜首的 Farid Zakaria 文章《The mean means nothing》，讨论了这样一种情形：部署缓存层之后，平均延迟从 112ms 恶化到 122ms，上升了 9%。而在同一份数据中，p50 从 99ms 改善到 54ms，下降了 46%；p99 则从 309ms 恶化到 678ms，上升了 119%。同一份数据之所以能同时支持两个截然相反的结论，是因为
2026-07-31 · 22 分钟阅读 #observability#latency#performance#histogram#percentile在生产环境里运维 AI 智能体 — 幂等性、预算，以及自信满满的错误答案
把智能体从原型搬到生产环境时，有一片会被很晚才发现的运维表面：被重试的工具调用的幂等性、预算与步数上限、非确定性控制流的可观测性、按工具划分的权限边界，以及智能体自信满满地答错时的升级路径。最近发到 GeekNews Ask GN 上的一份分析，在 6,780 条基准测试轨迹里找到了 8,042 次重复工具执行，其中 159 次是改变状态的工具真的创建出了重复资源。本文以那份数据为起点，梳理该记录什么、该对什么设告警，以及在像第三方 A
2026-07-31 · 24 分钟阅读 #ai#agents#observability#reliability#mcp平均响应时间为什么在撒谎 — 正确读懂 p50、p95 与 p99
平均响应时间只有 80ms 的服务，用户却要等上 3 秒，这种事很常见。本文用数字说明：在长尾分布中平均值究竟隐藏了什么，p50、p95、p99、p99.9 各自回答哪个问题，以及 p99 为什么不是「一百个人里有一个」。文中讲清百分位无法求平均这一决定性事实、由此必须使用直方图的理由，以及 Prometheus histogramquantile 的线性插值误差与选择桶边界的标准。最后整理出应把延迟 SLO 定义为比率而非百分位的实务
2026-07-26 · 15 分钟阅读 #observability#percentile#prometheus#histogram#slo分布式追踪真正回答的问题 — 跨度、采样，以及时间到底花在哪里
当「慢」的反馈不断进来、却不知道十个服务里谁是凶手时，你需要的就是追踪。本文从追踪、跨度与上下文传播的结构讲起，梳理出日志和指标在原理上回答不了的问题是什么。文中结合采集器配置，讲清自动埋点覆盖到哪里、哪些位置必须补上手动跨度、头部采样为什么会优先丢掉你最需要的追踪，以及尾部采样如何解决这一点、代价又是什么。接着讲跨消息队列传播上下文时为什么要用链接而不是父子关系，最后给出在真实追踪界面上到底该找什么的排查顺序。
2026-07-26 · 21 分钟阅读 #observability#distributed-tracing#opentelemetry#tail-sampling#performance结构化日志设计 — 做出故障时真正派得上用场的日志
如果你曾在故障正中间 grep 日志 grep 到放弃，那说明日志设计错了。本文讲如何把给人看的日志和给机器看的日志分开，确定每一行都必须包含的字段，并立起判断日志级别的唯一标准。文中用真实代码整理了用 W3C traceparent 跨服务边界追踪请求的方法、把个人信息与密钥过滤掉的脱敏配置、不会把故事切碎的请求级采样，以及基数与成本的计算。最后给出日志、指标、追踪各自应该在什么时候看的顺序。
2026-07-26 · 16 分钟阅读 #observability#logging#structured-logging#opentelemetry#incident-response凌晨三点不会把你叫醒的告警设计 — 症状告警与燃烧率实战
on-call 之所以崩溃，不是因为告警太少，而是因为太多。本文从告警疲劳如何让人错过真实事故的机制讲起，讲清「只对症状呼叫、把原因留在仪表盘上」这一原则，以及从 SLO 与错误预算倒推阈值的方法。文中用 Prometheus 规则和 promtool 测试展示：把短窗口与长窗口用 AND 串起来的多窗口燃烧率告警如何同时兼顾灵敏度与误报，以及 for 子句防止抖动的原理是什么。最后整理出在 CI 里强制 runbook 链接、并定期删
2026-07-26 · 18 分钟阅读 #observability#alerting#slo#error-budget#prometheusAI 智能体在生产环境中是如何失败的 — 14 种失败模式，以及重试为何不安全
把智能体放上生产环境，会有三处疼。第一，失败大多不是出在模型，而是出在系统设计 — UC 伯克利的 MAST 研究对 1642 条执行轨迹做了分类，提炼出 14 种失败模式，其中 44.2% 属于系统设计问题。第二，最常见的两种失败模式(步骤重复 15.7%、未意识到终止条件 12.4%)会直接变成 token 账单。第三，恰恰是这两种模式制造了重试/幂等性问题 — 非确定性的调用方在驱动真实副作用，而 MCP 只给了 idempote
2026-07-17 · 32 分钟阅读 #ai#agents#observability#reliability#mcp原生直方图已经 stable 了，为什么还不能打开
2022年11月在 v2.40 中以实验特性登场的 Prometheus 原生直方图(native histograms)，于2025年12月的 3.8.0 版本中转为 stable，而2026年7月1日发布的 3.13 是第一个以 stable 状态收录该特性的 LTS 版本。现有的 3.5 LTS 将于2026年7月31日停止支持，因此对走 LTS 路线的组织来说，现在正是真正需要做决定的时候。不过「stable」这个词所保证的范围
2026-07-16 · 26 分钟阅读 #prometheus#observability#native-histograms#metrics#monitoringOTel 的 Kubernetes 属性变成 stable 了 — 在 k8sattributes 默认值翻转之前要做的事
OpenTelemetry 的 Kubernetes 语义约定已经在 2026 年 6 月 12 日的 semconv v1.42.0 中晋升为 stable。但 Collector 的 k8sattributes 处理器目前默认值仍是旧模式(v0)，所以大多数人什么都没感觉到。问题在于这不是永久的 — 按照 Collector RFC 制定的推进路线，一旦特性开关升到 beta，默认行为就会翻转为仅 v1，k8s.pod.labels
2026-07-16 · 18 分钟阅读 #opentelemetry#observability#kubernetes#semantic-conventions#telemetry-pipeline可观测性完全指南：日志、链路追踪与 LLM 监控
从日志、指标、链路追踪这三大支柱出发，梳理它们如何通过 traceid 相互关联，再对比 Loki 与 OpenSearch 的日志策略差异、以 OpenTelemetry 为中心的分布式链路追踪(Jaeger、Tempo)，最后延伸到以 Langfuse 为代表的 LLM 可观测性。逐项对照实务中该如何搭建技术栈、又该如何取舍。
2026-07-03 · 22 分钟阅读 #observability#opentelemetry#tracing#logging#llm像侦探一样读懂日志和堆栈跟踪
堆栈跟踪是案发现场，日志是目击者证词。从上到下读懂堆栈跟踪的方法(一端是出事的地方，一端是起因)、追踪 "caused by" 链条、结构化·JSON 日志、关联 ID 与 traceid、用 grep·jq·ripgrep 挖掘日志，直到日志级别与采样。把日志和跟踪当作证据来对待的侦探技术。
2026-06-28 · 19 分钟阅读 #logging#debugging#stack-trace#observabilityeBPF 正在吞噬可观测性
在内核中安全运行沙箱化程序的想法，正在颠覆可观测性的格局。用 kprobe、uprobe、tracepoint、XDP 在任意位置挂钩，verifier 保证安全，不改一行应用代码就能追踪。本文从实务角度梳理 Cilium、Falco、Pixie、bpftrace 为什么能取代 sidecar，以及 eBPF 做不到的事情是什么。
2026-06-11 · 20 分钟阅读 #ebpf#observability#linux#kernelObservability 2025 完全指南：OpenTelemetry、Grafana / Datadog / Honeycomb / SigNoz、SLO 与 Error Budget、LLM 可观测性（2025）
Season 5 Ep 8。没有可观测性就没有运维，没有运维就没有产品。OpenTelemetry 三大信号（Metric、Log、Trace）的统一，Grafana 技术栈（Prometheus、Loki、Tempo、Mimir）与 Datadog、New Relic、Splunk 的比较，SigNoz、Honeycomb、Axiom 这一新世代，SLO、SLI、Error Budget 的运营，LLM 可观测性（LangFuse、L
2026-04-15 · 15 分钟阅读 #observability#opentelemetry#grafana#datadog#honeycombPydanticAI 实战指南：2026 年 Python 团队为什么在生产级智能体中采用它
面向需要 Python 优先的智能体系统、模型可移植性、持久化工作流、可观测性与评估体系的团队的 PydanticAI 实战指南。
2026-04-12 · 10 分钟阅读 #pydantic#pydantic-ai#python#ai-agent#mcp