为什么 ClickHouse 和 AI Agent 是绝配

在exe，我们收集大量关于系统性能的遥测数据。我们使用Grafana、Prometheus，还有各种图表和警报。这很棒，但它并不能说明业务财务方面发生了什么——流失率、ARR。

这些通常不会让工程师关注。

最明显的答案是Stripe Sigma。这是一个很可靠的工具。我在1Password时用过它。但它也很贵且不完整。Sigma只能看到Stripe内部发生的事情，而我们也通过应用商店和云市场计费。另外，我们的很多遥测数据都是建立在ClickHouse上的。

负责会计的Vidrik需要三种类型的报表。按套餐、使用超额和代币传递（客户购买代币，我们支付LLM提供商费用）的月收入。

为了解决这个问题，我开发了一个叫exe-finops的工具。你输入提示词，就能得到一份报告。它的运作方式相当简单。

Stripe 允许你配置 webhooks，并指定你想接收的事件。对于我们的主服务，我们订阅特定的集合，因为这些是它需要响应的。另外，我们运行一个“firehose”：一个终端，订阅 Stripe 发送的所有内容，无论产品中是否有任何部分响应。

我们对其他计费提供商也是这样做的。接收端除了把事件写入 ClickHouse，除此之外没做太多。

Exe-finops 就是建立在这些基础上的。它会把事件从 ClickHouse 导出，放进自己的 SQLite 数据库。Provider webhook 包含大量信息，但如果报告需要更多信息（比如完整的客户对象），它会回到 Stripe 的 API 获取。

历史上，达到这一步需要真正的流水线。有人构建了ETL，Databricks参与其中，还有Snowflake。换句话说，有这么多东西需要被构建。

exe-finops不做这些。它有事件和报告层。Vidrik想要的三个报告现在都是提示。

Exe-finOps 还支持自定义报表，这在你有问题时很有用，比如月度增长，或者哪些日最忙于计费交易（我几天前查了一下，是周三和周日，不知道为什么）。

我为这些报告编写了exe-finops，但这条“firehose”也相当实用。计费中最耗时间的部分是从提供者的仪表盘重建发生了什么。

这里有一个最近的例子：两个账户由两个不同但相关的客户创建。他们共享了一种支付方式。客户A告诉我们该共享未经授权。客户B完全不知道客户A在说什么。

双方都因为法律纠纷而要求立即得到答案。以前我得在Stripe里四处查找联系。但我给了客服两个Stripe客户ID和理赔（“有人说某个支付方式在这些账户之间被无意中共享”）。

它读取了ClickHouse的webhook事件并找出了原因。果然，exe-finops追踪到了问题：客户B不小心用客户A的付款方式订阅了。exe-finops指出客户B在浏览器中打开了两个标签页，很可能是肇事者。

我把我们数据中看到的内容发给了客户，他们都很满意（也对我提供的细节水平感到惊讶）。难怪代理们在ClickHouse上写SQL比我好得多。

从根本上说，这让我的工作变得更轻松。当有支持问题进来，或者我需要查看财务数据的动态时，我不需要在Stripe界面或CLI里摸索重建。