Kula：一个自包含的 Linux 监控工具，把数据塞进环形缓冲区

它解决什么问题：单机监控的部署痛点

大多数监控工具要么依赖外部数据库（如 Prometheus 搭配 TSDB），要么需要安装多个组件（agent、server、前端）。Kula 把这一切压缩成一个二进制文件，直接读取 Linux 内核的 /proc 和 /sys 接口，每秒采集一次数据，存储在内置的环形缓冲区中，并通过内嵌的 Web 界面和 TUI 展示。它的目标用户是那些不想折腾依赖、只想在服务器上快速看到 CPU、内存、网络、磁盘等实时指标的人。对于临时排查问题或小规模环境，这种自包含设计确实省事，但代价是你必须接受它的存储模型和功能边界。

数据流：从内核文件到图表，中间只有环形缓冲区

Kula 的工作流程在 README 的架构图中很清晰：采集器每秒从 /proc/stat、/proc/meminfo、/sys 等路径读取原始数据，然后写入一个自定义的环形缓冲区存储引擎。这个引擎把指标直接写入固定大小的二进制文件，文件写满后新数据覆盖最旧的数据。存储分为三个层级：Tier 1 保留原始 1 秒采样（默认 250 MB），Tier 2 聚合为 1 分钟平均值、最小值和最大值（默认 150 MB），Tier 3 聚合为 5 分钟数据（默认 50 MB）。启动时，Kula 会恢复最新采样缓存并重建未完成的聚合缓冲区，以便继续提供近期数据。这种设计意味着你不需要单独管理数据库，但历史数据量被严格限制在 450 MB 以内，超过这个容量后最旧的数据会被永久覆盖。

安装与启动：三条路径，都绕不开权限问题

安装方式有四种：引导脚本、独立二进制、Docker 和 .deb 包。引导脚本的安装命令是 bash -c "$(curl -fsSL https://raw.githubusercontent.com/c0m4r/kula/refs/heads/main/addons/install_v2.sh)"，README 还提供了校验脚本 SHA256 的步骤。独立二进制方式需要从 GitHub Releases 下载对应架构的 tar.gz，解压后直接运行 ./kula。Docker 方式需要挂载宿主机的 /proc 目录，并指定 --pid host 和 --network host，例如 docker run --rm -it --name kula --pid host --network host -v /proc:/proc:ro c0m4r/kula:latest。注意，Docker 命令中 --pid host 意味着 Kula 能看到宿主机上所有进程，这带来监控便利，但同时也意味着容器逃逸风险更高。如果只需要临时运行，可以不加持久化卷，但数据不会保存。无论哪种方式，都需要 root 或至少对 /proc 和 /sys 有读取权限，否则部分指标（如其他进程的 CPU 使用率）会缺失。

存储引擎的取舍：环形缓冲区的代价

Kula 的核心创新是内置的环形缓冲区，但这也是它的最大限制。默认配置下，原始 1 秒数据只能保留约 250 MB，按每秒一条记录估算，大概只能覆盖几天到一周的数据，具体取决于指标数量和采样大小。Tier 2 和 Tier 3 的聚合数据虽然能提供更长时间的趋势，但仍然是固定容量。如果你需要追溯一个月前的某个异常点，Kula 很可能已经把它覆盖了。相比之下，Prometheus 使用基于时间序列的压缩算法，可以保留更长时间的数据，但需要单独管理存储。Kula 的选择是牺牲历史深度换取零外部依赖。对于实时监控和短期排障，这个权衡可以接受；但对于容量规划或审计需求，它就不够用。

HTTP 与安全：可选认证，但默认是裸奔

HTTP 服务器提供 REST API 和 WebSocket 端点，前端通过 WebSocket 实时更新，历史数据则回退到 HTTP API。认证是可选的，默认关闭。当启用时，Kula 使用 Argon2id 密码哈希、安全会话 cookie、仅令牌的会话验证（带滑动过期）以及哈希持久化会话。这意味着如果你在公网部署且不开启认证，任何人都能访问你的监控数据，包括网络吞吐、磁盘 I/O 甚至进程列表。README 没有说明如何启用认证，只描述了机制，所以你需要查看配置文件或文档来找到 auth 相关的键。另外，AI 助手功能通过 Ollama 本地模型运行，所有推理都在本地，这避免了数据外泄，但你需要额外安装 Ollama 并在 config.yaml 中启用。

监控范围：从 CPU 到容器，但 GPU 和自定义指标有坑

Kula 覆盖的指标相当全面：CPU 细分为 user、system、iowait、irq、softirq、steal，网络按接口统计吞吐量和错误，磁盘按设备统计 IOPS 和字节，还有热传感器、电池状态、Docker 和 podman 容器，甚至 PostgreSQL、MySQL、nginx 和 apache2 的应用指标。但两个地方需要留意。其一，NVIDIA GPU 监控需要额外设置，README 明确提示“可能需要额外设置”，并链接到 wiki 页面，但没有给出具体步骤。其二，自定义指标功能听起来很灵活，但 README 只写了“监控任何东西”，没有提供配置示例或 API 说明。如果你依赖自定义指标，可能需要深入源码或 wiki 才能找到用法。

前端与集成：WebSocket 实时性，Prometheus 导出是亮点

前端是内嵌在二进制中的单页应用，基于 Chart.js 和自定义 SVG 仪表盘。它支持拖拽缩放（会自动暂停实时流）、焦点模式、手动 Y 轴范围、设备选择器（网络、磁盘、热传感器）、网格或堆叠列表布局，以及深色主题。告警系统覆盖时钟同步、低熵和系统过载，但没有提到自定义告警规则。对于已有监控栈的用户，Kula 提供了 Prometheus 导出端点，可以接入现有的 Prometheus 实例，这缓解了存储容量限制，因为你可以把数据抓取到外部长期存储中。不过，这意味着你仍然需要部署 Prometheus，Kula 的零依赖优势在混合架构中会打折扣。

维护与许可：AGPL-3.0 和活跃的发布节奏

项目最近一次提交在 2026 年 7 月 29 日，版本 0.18.8 于同一天发布，此前 0.18.7 在 7 月 26 日，0.18.6 在 7 月 11 日，说明开发节奏相当快。但快节奏也意味着 API 或配置格式可能不稳定，升级时需要关注 changelog。许可采用 AGPL-3.0，这是一个强 copyleft 许可。如果你把 Kula 集成到自己的产品中并通过网络提供服务，AGPL 要求你公开修改后的源码。对于内部使用，通常影响不大，但如果你计划分发修改版或提供 SaaS 服务，需要咨询法律意见。README 中没有提到升级路径或数据迁移工具，所以升级时可能需要接受旧数据丢失的风险。

编辑结论

Kula 适合那些想要在单台 Linux 服务器上快速部署监控、且不愿引入外部数据库或复杂依赖链的个人开发者或小型运维团队。它不适合需要长期历史数据保留、多节点集中管理或严格合规审计的场景，因为环形缓冲区会覆盖旧数据，且 AGPL-3.0 许可对商业闭源集成有约束。在采用前，你应验证两点：其一，确认你的内核版本和硬件（尤其是 NVIDIA GPU）是否满足 README 中提到的额外设置要求；其二，检查自定义指标和告警功能是否覆盖你的核心监控需求，因为目前文档只列出了指标类型，没有给出自定义指标的具体配置语法。如果你需要的是一个能保留数年数据、支持分布式查询的监控系统，Kula 的存储模型就不是正确的选择。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes