深入Minerva：为eBay变现平台构建可扩展的可观测性
内容提要
eBay构建Minerva可观测性平台，以解决收费系统的监控缺口。该平台通过本地队列异步采集监控记录，经数据丰富后存入ClickHouse，支持可配置的仪表盘与告警，在不影响实时收费的前提下，及时发现并定位收费异常。
延伸解读
异步采集与有损设计：可用性优先的权衡
Minerva将监控记录先写入本地队列，由后台生产者异步发布，避免远程调用拖慢收费请求。但队列有容量和记录年龄上限，积压时可能丢弃或覆盖旧记录，形成监控数据缺口。这种设计明确以收费可用性优先，监控数据并非交易真相源，因此下游中断不会影响已完成的费用计算。
ClickHouse选型与早期验证的局限
Minerva选择ClickHouse作为分析存储，因其列式存储和MergeTree引擎适合对少量字段进行大规模聚合。早期概念验证在6 vCPU、44 GB内存上测试约11亿行数据，查询耗时约0.11至0.72秒。但文章指出这并非生产基准，未记录重复运行、缓存状态、并发和压缩等因素，读者需谨慎看待其性能结论。
可配置监控：从数据到信号的灵活路由
Minerva将监控流程分为查询执行、用例处理和通知投递三个模块。查询执行协调多实例避免重复评估；用例处理器计算偏差、比较计数或结合促销数据解释峰值，并分配严重级别；通知模块支持PagerDuty、邮件或Slack，且可针对规则或数据段覆盖全局设置。新增用例无需改动收费服务或采集管道。
数据建模的领域权衡：扁平化与规范化
收费数据包含基础费用和多个促销调整，建模时需在扁平化与规范化之间取舍。扁平化简化扫描但重复上下文，规范化避免重复却增加查询时连接工作。Minerva消费上游费用和促销决策，不重新实现计费规则，其角色是观察结果而非成为第二个计费引擎，这有助于保持职责清晰。
Q&A
eBay为什么要构建Minerva可观测性平台？
eBay的变现团队缺乏专门的观测平台来整合费用决策的上下文信息。此前，数据仓库（HDFS）的数据到达太晚，无法支持及时的发布监控；调查需要手动查询多个数据源；问题检测不是实时的，通常通过客户投诉或事后分析才发现。Minerva旨在填补这一观测缺口，同时不增加核心收费服务的延迟或可用性风险。
Minerva如何在不影响实时收费的情况下采集监控数据？
Minerva让收费处理服务在本地队列中放置一条包含标识符的小记录，后台生产者异步地将记录发布到事件流。正常情况下，请求不等待网络发布、丰富、分析存储或告警评估。本地队列有容量和记录年龄限制，采用环形缓冲区策略，优先保证收费处理可用性而非无损监控交付。
Minerva为什么选择ClickHouse作为分析存储？
Minerva的常见查询需要跨数百万条记录（每条记录近250列）聚合少量字段，如费用金额、站点、费用类型、促销和时间。事务数据库不适合这种重复的历史扫描。ClickHouse按列存储，查询只需读取所需字段，其MergeTree表引擎提供排序和分区控制，可对齐常见监控访问模式。早期概念验证在6个vCPU和44GB内存的机器上测试约11亿行数据，样本查找和聚合在1秒内完成。
Minerva的数据丰富过程是怎样的？
初始记录只包含标识符，后台消费者随后查询事务读数据库，从事务源中检索相关的费用、列表、账户和促销属性。丰富后的记录支持仪表盘和监控查询，无需重复连接多个操作存储。这种异步丰富使监控最终一致：数据在费用决策后可用，而收费处理请求与分析工作隔离。
Minerva如何将存储的数据转化为可操作的信号？
Minerva通过三个阶段处理ClickHouse历史数据：查询执行、用例处理和通知交付。查询执行模块识别符合条件的查询并检查其节奏，多个监控实例协调确保只有一个实例评估每个计划查询。用例处理器应用逻辑（如计算费用偏差、比较交易数量、结合费用和促销数据），评估指标、分配严重性并创建通知模型。通知模块选择配置的目标（PagerDuty、电子邮件或Slack）并构建特定于通道的有效负载。
Minerva的架构如何支持新监控用例的扩展？
Minerva将费用决策与解释行为分离，新用例可以添加查询、处理逻辑和通知，而无需更改收费处理服务或摄取管道。设置可以广泛定义，然后针对特定监控规则或数据段覆盖，例如将高严重性的国家级费用偏差路由到PagerDuty，而将低严重性趋势通过电子邮件发送。这种分离使平台能够与eBay的变现系统一起演进。
