引言 日志是可观测性三大支柱中数据量最大、存储成本最高的信号。与指标（Metrics）的固定数值结构不同，日志的变长文本和半结构化特性使得存储设计面临独特挑战：既要支持全文检索，又要控制存储成本。

上一篇介绍了频率域的图像处理方法——通过傅里叶变换将图像转换到频域，然后进行滤波、复原等操作。但频率域方法有时不太直观，尤其是我们更习惯直接操作像素。

引言 时序数据库（TSDB）是可观测性存储的基石。上一篇总览了存储演进主线，本篇聚焦时序数据库这一类——对比 InfluxDB、Prometheus、VictoriaMetrics、TimescaleDB 四大主流 TSDB 的存储引擎。无论使用 Prometheus 还是评估 VictoriaMetrics，理解底层存储引擎的设计取舍，有助于更高效地选型与使用。

为什么需要了解这四个阶段？ AI 工程领域在 2022 年到 2026 年的四年间经历了四次范式跃迁。如果你只掌握了提示工程（Prompt Engineering），实际上只覆盖了其中一个阶段。

Zhi 主题 发布了 v0.2.0——这是从 4 月份 初次发布 后最重要的功能更新。这次发布的三个重头功能——多语言切换、文章系列（Series）分类法、Mermaid v11+ 升级——都是在自己使用过程中逐步积累的需求。

引言 可观测性（Observability）是云原生基础设施的核心组件之一。Metrics、Logs、Traces、RUM、Profiling 五大信号各自产生海量数据，其存储效率直接决定了平台的成本边界和查询性能。在采集侧，eBPF 正在重塑数据获取方式；在存储侧，存储架构的演进是支撑可观测性规模化落地的底层基石。

v0.6.0 把延时摄影管道搭起来之后，社区反馈很快就指出了几个硬伤：JPEG 序列要吃掉太多存储、H.265 摄像头生成的延时片段播放不了、双摄小米设备只能抓到主镜头、偶尔还会出现 H.265 HLS 直接 panic 的崩溃。这些都不是边缘场景——双摄 CW500 和室外摄像头 4 在国内出货量很大，H.265 已经是中高端摄像头的事实标准。v0.7.0 的主线就是围绕这些反馈展开的。

前几篇文章展示了如何使用 eBPF 追踪 OOM 事件。但这还不够——我们只是在"看"，不能"管"。内核的 OOM Killer 选谁杀谁，由 oom_badness() 算法决定，用户无法干预。

为什么在频域做恢复 上一篇我们建立了图像退化模型：观测图像 $g(x,y)$ 是原始图像 $f(x,y)$ 经过退化函数 $h(x,y)$ 卷积并叠加噪声 $n(x,y)$ 后的结果： $$g(x,y) = h(x,y) * f(x,y) + n(x,y)$$恢复的任务是：已知 $g$ 和 $h$，尽可能还原 $f$。

前两篇文章覆盖了 eBPF 基础概念和 OOM Killer 事件追踪。这篇文章进入更深的层次：容器级别的 OOM 定位、内存分配速率的实时追踪，以及用 Rust Aya 框架来实现同样的功能。 容器级 OOM 定位 在 Kubernetes 环境中，“某个 Pod OOM 了"实际上是一个模糊的描述。Pod 由多个容器组成，容器可能属于不同的 cgroup。eBPF 可以穿透这一层，精确地定位到"是哪个容器里的哪个进程"导致了 OOM。