如何节省日志费用而不被 Splunk 账单逼疯

最近发现了一个有趣的项目叫 SigLens。这帮人决定挑战一些神圣不可侵犯的东西——取代 Splunk 和 ElasticSearch，并承诺可以节省十倍的资源。这听起来像是典型的营销噱头，但有一个「但是」：该项目最近被归档了，转为 Apache 2.0 许可证，现在作为开源项目开放给任何人使用，任何人都可以在此基础上构建自己的可观测性系统，而不必被高昂的成本所困扰。

顺便说一句，SigLens 开发者声称他们的解决方案比 Splunk 效率高 100 倍。我对这类数字总是持怀疑态度，但团队的技术背景（服务过 10,000+ 工程师）让人想要仔细看看细节。

当前解决方案的主要痛点是什么

如果你在大项目中处理过日志，就会知道这种情况。首先你搭建了 ElasticSearch，生活很美好，然后六个月后你发现集群已经膨胀到了离谱的规模，需要管理员持续关注，而且内存消耗像没有明天一样。Grafana Loki 看起来像是救星，直到复杂查询出现——性能有时像乌龟一样慢。

SigLens 就是为了解决这些痛点而诞生的。它是一个 Go 二进制文件，将日志、指标和追踪结合在一个包中。无需外部依赖。你可以在普通的笔记本电脑上运行它，而且根据作者的说法，每天可以处理高达 8 TB 的数据。

这个工具能做什么

这个项目最有趣的地方在于其「一体化」架构。你不需要在不同的工具之间跳转，而是获得一个单一的入口。

支持熟悉的查询语言

这可能是它最强的一面。如果你的团队已经用 Splunk SPL 写了好几年代码，就不需要重新培训。SigLens 理解 SPL 和标准 SQL。这大大降低了迁移的门槛。

数据接入的灵活性

这个工具不会强迫你重写日志传输管道。它可以接受 OpenTelemetry、Elastic、Splunk HEC 甚至 Loki 格式的数据。从本质上讲，你可以把它插入到现有后端的位置，你的大多数代理（如 Fluentbit 或 Vector）甚至不会注意到这个切换。

实际数字的性能表现

作者的博客有一个案例研究，他们一天内处理了 1 PB 的数据。为此，他们只需要 32 台 EC2 实例。作为对比：Splunk 或 Elastic 处理同样的任务大约需要 3,000 台机器。基础设施成本的差异是巨大的。

技术方面

SigLens 是用 Go 编写的，这解释了它轻量的特性。这里的主要亮点是存储引擎，针对时间序列和非结构化日志的特性进行了优化。与 Elastic 不同，Elastic 在每个字段上构建重型倒排索引，而 SigLens 使用更高效的压缩和搜索方法。

有趣的是，该项目开箱即用地提供内置仪表盘和告警系统。你不一定需要额外接入 Grafana，尽管通过 API 可能具备这种能力。

谁现在可以从中受益

由于该项目已进入归档模式，这是一把双刃剑。一方面，你不应该期待原始团队会有积极开发。另一方面，Apache 2.0 许可证给了你完全的自由。

我看到几个 SigLens 可以「起飞」的场景：

1. 初创公司的内部监控工具，在基础设施预算有限但已有大量数据的情况下。
2. 本地调试。由于是单一二进制文件，在 Docker 容器中启动非常容易，开发者的机器上可以实时分析追踪和日志。
3. 创建自己专有数据分析解决方案的基础。

值得一试吗

如果你厌倦了为 Splunk 支付数千美元，或者为维护庞大的 Elasticsearch 集群而挣扎，SigLens 是一个很好的探索候选者。是的，该项目已被归档，但其中的 Go 代码相当成熟和功能完整。

为了快速入门，他们有现成的 Helm charts 和 Docker 镜像。你可以在五分钟内部署系统，看看它如何处理你的日志流。也许这正是那种「被抛弃」的开源可以为一个公司节省一年云预算的情况。

在我的实践中，这些窄而专业的引擎通常比通用的多合一解决方案表现更好。最重要的是要明白，你现在必须自己或通过决定 fork 该项目的社区来提供支持。