本文共 1353 字，大约阅读时间需要 4 分钟。

Plaid.com 已实现与超过 9600 家金融机构的集成，这些集成关系中的异构性以及数量巨大，使得数据监控和报警系统面临诸多挑战。为应对可扩展性和低延迟的需求，Plaid 选择了基于 AWS Kinesis、Prometheus、Alertmanager 和 Grafana 的监控方案。

在前期的监控体系中，Plaid 依赖 Elasticsearch（ES）日志系统，通过 Nagios 查询 ES 集群并将报警推送至 PagerDuty。然而，这种体系存在诸多缺陷：缺乏用户定制能力、ES 存储周期受数据规模限制、对日志变更的脆弱依赖，以及无法提供历史数据查看视图。鉴于此，Plaid 的团队重新审视了监控方法，基于具体用例确定需要监控的度量，并制定了功能和技术需求。

在新体系中，团队选择了 Prometheus 作为时序数据库、Kinesis 作为事件流处理器，并将 Alertmanager 用于报警功能，同时用 Grafana 实现可视化。这种选择主要考虑了系统的灵活性和 Promethus 与 Grafana 的良好兼容性。此外，团队重新设计了监控流水线，使得能够直接使用标准流水线导出度量，而其他服务则将事件推送至 Kinesis，由事件消费者拉取并生成度量。这种设计确保了流水线的其他部分保持不变，且在正常情况下，事件可在 5 秒内生成度量。

尽管如此，使用 Prometheus 的架构可能会带来一些挑战，特别是新集成的加速是否会导致配置维护问题。InfoQ 联系了 Plaid 的软件工程师以获取更多细节。工程师指出，Alertmanager 的手工配置并非大问题，因为可以根据警报类别设定规则（例如，高优先级警报由 PagerDuty 处理，低优先级警报由 Slack 处理）。然而，Prometheus 的配置确实是一个挑战，团队正在开发从 JS 代码生成配置文件的工具，减少手动复制粘贴的需求。

在实现易用性方面，Plaid 已取得显著进展：45 名工程师中有 31 人参与监控配置工作。标准流水线无需额外仪表显示，度量由代码库间共享的软件库自动导出。Zhang 解释了他们如何通过共享库实现标准化度量命名：共享库控制度量命名，各服务仅需为自身指定标签，并可通过 ProtoBuf 枚举值进一步标准化。目前可发现性主要依赖于针对各服务的关键度量构建 Grafana 仪表板。

对于历史数据的问题，Plaid 使用 Prometheus 存储即时报警数据，但仅保存数月历史数据。随着对历史分析用例的增加，Plaid 计划在近期上线一个项目，将 Prometheus 度量导出至长期数据仓库（基于 AWS Redshift）。

在流数据处理方面，Kinesis 帮助 Plaid 维持数据的有序性，即便在消费者宕机或网络延迟的情况下。Zhang 还提到，Kinesis 的并行读取器提供了一个预生产监控环境，能够全面测试监控的变化，同时保证监控环境的稳定性。

最后，监控在部署流水线中发挥着重要作用：代码推送至内部预生产环境后，开发人员需检查预生产监控情况，随后才会将代码部署至生产环境。

这种全面的监控体系不仅解决了前期系统的各项痛点，还为未来的扩展和维护奠定了坚实基础。