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

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

bpftrace 适合快速探查和临时调试，但如果要构建持续运行的生产级监控工具，就需要完整的 eBPF 程序了。典型的架构分两层： 内核态：用 C 编写 eBPF 程序，挂载到 hook 点，采集事件数据 用户态：用 Go（或 Rust / libbpf C）编写 loader，加载 eBPF 程序并读取事件 这个模式在行业里已经非常成熟——Pixie、Parca、Cilium 等开源项目都遵循这个架构。

eBPF（Extended Berkeley Packet Filter）最初是网络包过滤工具，经过近十年发展，已经成为 Linux 内核最强大的可观测性框架。它允许你在不修改内核源码、不加载内核模块的前提下，安全地注入并执行自定义程序。

MiBeeNvr 连续跑了几周录像后，存储最先告急。单路 1080p 摄像头每天要写几十 GB，30 天留存一件 1TB 硬盘就没了大半。社区里不少朋友反馈了同样的问题，讨论中延时摄影和转码保存的方案呼声最高——画面大部分时间静止，用 timelapse 压缩后同样时长只需要 5% 的空间。

同期发布的 MiBeeNvr v0.6.0 带来了延时摄影、视频转码、ONVIF 增强等大功能，光靠单元测试远远不够，必须在真实摄像头环境下跑完整流程。为了给这个版本提供靠谱的测试机器，6 月 5 日同一天更新了三个摄像头项目——既是给 NVR 提供测试环境，也顺手解决了一些嵌入式开发中比较典型的工程问题。

v0.4.0 发布不到一周，又肝了 31 个提交。v0.5.0 是一个功能密度很高的版本：ONVIF 全协议支持（Device/Media/PTZ/Imaging/Event 五大服务全覆盖）、硬件转码（H.265 → H.264）、录制器重连优化。127 个文件变更，+24,509 / -730 行。完整更新列表见 GitHub Release Notes。

第 9 章：Rust 使用 YOLO 完整教程 Rust 凭借内存安全、零成本抽象、极致性能三大特性，成为 YOLO 生产级部署的终极选择。在边缘计算、高并发场景下，Rust 的性能优势尤为显著。

第 8 章：Golang 使用 YOLO 完整教程 Go 语言凭借其高性能、低内存占用、原生并发特性，成为工业级 YOLO 部署的首选语言之一。本章将详细介绍 Go 生态中 YOLO 的完整实现方案。

做运维出身，后来转开发，维护的项目越来越多。各种中间件、数据库、监控组件……每次升级版本都是一场体力活：去官网找下载链接、比对版本号、手动下载到内网、再分发到各台机器。以前写了一堆 Shell 脚本定期拉取最新版本到局域网，能用但不好用——脚本散落在各处，加新软件得手写解析逻辑，出错了也没什么日志可查。