金融技术企业Plaid.com已实现与9600多家金融机构的集成，从这些机构供企业后期使用。由于集成的异构本质以及所集成机构的数量，并且同一度量在不同的集成可能会有不同的解释，需要报警的度量也不同，所以实现监控集成是一个挑战。为解决在可扩展性和低延迟要求上的挑战，Plaid使用AWS Kinesis、Prometheus、Alertmanager和。

Plaid前期实现的监控系统严重依赖于（ES）的日志系统。其中由Nagios查询ES集群，并将所有的报警发送给PagerDuty。该系统不仅缺乏用户定制能力，而且由于ES的存储周期会因为日志规模的增加而降低，系统无法随不断增加的流量而扩展。鉴于旧系统缺乏对度量的历史查看视图、需手工配置报警，以及对日志更改具有脆弱的依赖性，因此团队重新考虑了监控的方法。他们从分析企业的需求着手，根据特定的用例确定需要监控哪些度量，以及如何监控这些度量。功能需求中包括基于客户的影响和实现仪表显示的代价，确定度量的优先级别，实现技术则聚焦于可扩展性、低延迟查询、支持高基数，以及开发人员使用系统的易用性。

团队选定作为时序数据库、作为事件流处理器、Alertmanager实现报警功能，并用Grafana实现可视化。其中，选定后三者主要考虑到这些系统的灵活性，并且Prometheus和Grafana相互间工作良好。团队重新设计了监控流水线，使得实现导出标准度量的服务可直接使用标准的流水线，其它服务则发送事件到Kinesis并由事件消费者拉取事件生成度量。两类服务最终都在Prometheus生成度量，这可使流水线的其余部分保持不变。在通常情况下，一个事件可在5秒内生成度量。

作为Prometheus项目的组成部分，中存在一些基于文件的配置。新集成（进而导致新度量）的加速是否会成为系统维护的一个潜在挑战？InfoQ就此问题的细节联系了Plaid的软件工程师。

\

我们可以根据警报类别而不是单个警报设置规则，因此Alertmanager的手工配置文件并非一个大问题。例如，我们可以通过设定规则，让系统通知Pagerduty处理所有高优先级的警报，而由Slack处理优先级较低的警报。另一方面，考虑到系统面对如此数量的集成，Prometheus配置对我们来说无疑是一个挑战。我们初步实现的监控依赖于手工配置文件，而后续项目正在构建从JS代码生成配置文件的工具，不再需要根据照每个集成规则做复制粘贴。

\

目前看来，团队在实现易用性的目标上取得了很好的进展。团队的45位工程师中，有31人对监控配置做出了贡献。标准的流水线并不需要任何仪表显示（instrumentation），由代码库间共享的软件库自动导出度量。Zhang详细介绍了他们是如何实现标准化度量间的转化：

\

共享库有助于强化通用度量命名，因为此时命名是由软件库控制的，而所有调用服务需要做的是为自身指定一个标签。对某些标签使用ProtoBuf枚举值，这进一步有助于我们实现标准化。但我们尚未针对自定义的每项服务度量给出一种强大的命名约定，因为当前很难在Prometheus中发现未命名的度量。目前，我们采用的可发现性解决方案主要是使用一些针对各个服务的最重要Prometheus度量构建Grafana仪表板。

\

Plaid以方式运行Prometheus，对度量值做。但在Zhang看来，这对于历史数据而言不是一个挑战，“我们最初使用Prometheus，即聚焦于即刻报警功能，因此只保存数个月的历史，这并非一个大问题。我们看到，更多用例需要使用对度量的历史分析。因此，我们将于近期上线一个后续项目，实现将Prometheus度量导出到我们的长期数据仓库（在AWS Redshift上）”。

由于网络延迟或重排序，流数据可能存在抵达问题，或是在客户端产生延迟的问题。据Zhang介绍，Plaid使用Kinesis处理该问题：

\

使用Kinesis使我们可以维持流数据的次序，即便是出现Kinesis消费者宕机的情况。我们已经看到，事件消费者会由于网络延迟而产生几分钟的滞后，进而奋起直追，最终会生成1到2个虚假页面。使用Kinesis的另一个优点是能够使用并行读取器，这样我们可具有一个并行的“预生产”监控环境。由于该环境也从同一事件流中读取，因此我们可在该环境中全面测试监控的变化。通常从事件消费者角度看，我们可看到非常好的稳定性。

\

监控也将在部署流水线中发挥作用。代码在推送到生产环境之前，将首先推送到一个内部的预生产（Staging）环境。在将部署交付后续环境之前，Plaid当前的工作流通常需要开发人员检查仪表板（包括监控度量）的情况。

查看英文原文：