Hyperfeed是FlightAware的核心航班跟踪引擎。它的输出为公司最突出的产品提供了动力：网站上的航班页面，Firehose，FlightXML和航班警报。
Hyperfeed是一个分布式系统，由分布于多台机器上的十几个组件和子系统组成，以提高性能和容错能力。它的子系统包括许多其他知名服务：Postgres，Zookeeper，Kafka和RabbitMQ。
Zabbix一直是FlightAware的主要监视和警报框架。它在整个公司中都使用，并不特定于任何软件。当应用于Hyperfeed时，Zabbix监视运行该应用程序的服务器的一些关键特征，例如CPU，内存，磁盘和网络使用情况。此外，上述自定义工具将其数据输入到Zabbix中，以便在发生问题时可以将其用于警告工程师。
最重要的是，Zabbix为我们提供了一个基本的Web界面，用于查看以图形格式收集的数据。当Hyperfeed紧密地安装在单个服务器上时，这种监视对我们很有帮助：Zabbix是一站式商店，可进行所有监视。但是，随着对Hyperfeed的需求增加，其操作复杂性也随之增加。
最终，单机架构不足以处理Hyperfeed输入量的增加，这是由于FlightAware获取新数据源并扩展其现有数据源而导致的。为了适应这种规模的变化，有必要在多台计算机之间分配Hyperfeed。发生这种情况时，我们继续使用（并且仍然使用）自定义工具和Zabbix进行监视。但是，我们的自定义工具以及我们发送到Zabbix的数据也必须扩展。尽管必须在多台计算机之间分配Hyperfeed并改善系统的性能和可靠性，但它也带来了新的挑战和困难，尤其是在监视方面
使用Prometheus和Grafana升级监控
在航班跟踪的情况下，一些示例性的时间序列指标可能是：
- 每秒出发
- 每天到达
- 每分钟取消
- 每小时转移
- 每秒创建的飞行计划
- 每秒处理的输入消息
- 每秒生成的输出消息
- 最近6个月处理ADS-B职位所花费时间的99％
为了使捕获的数据量易于管理，触发这些事件中的每一个的输入消息的内容都被汇总。
Prometheus的主要卖点之一是，它提供了功能强大且概念上简单明了的数据模型，用于从目标系统中提取指标并跟踪其随时间的变化率。Prometheus跟踪的每个时间度量标准都包含以下信息：
- 指标名称：一个字符串，指示指标的用途，例如hyperfeed_departures_total。
- 帮助文档：一个字符串，描述指标的用途或来源。
- 度量类型：提供了四种类型，但是其中两种提供了其他类型的原子构造块。基本类型是只能上升或复位的计数器，以及可以设置为任何值的仪表。
- 标签：将附加维度附加到指标的键/值对。标签提供了一种比单单通过名称传达更多细节的方式。典型的示例是用于度量Web服务器响应时间的度量标准的URL路径。使用路径标签，可以跟踪特定URL的响应时间，也可以汇总所有标签并查看任何路径的响应时间。标签为指标提供了更多的粒度，并在查询时提供了强大的功能。
- 指标值：一个float64值。这是随时间推移跟踪的值。
- 获取度量的特定值的时间戳。
有了Prometheus数据模型，下一个主要卖点是相对容易地直接从其监视的应用程序或系统中公开白盒指标。通常，这是通过使用被监视系统的语言中的Prometheus客户端库来完成的。所有最流行的语言都已经有一个库，但是FlightAware是Tcl的重度用户，根据TIOBE索引，Tcl是一种较少使用的语言。不得不编写一个库，以利用Prometheus所提供的功能。
将数据从客户端库获取到Prometheus要求一个进程通过HTTP公开其指标，并且Prometheus知道可以在其上请求指标的主机名和端口。一旦数据到达Prometheus，就可以使用Grafana对其进行可视化，使用Prometheus项目维护的单独组件进行警告，查询和浏览。就计算和内存而言，使用Prometheus库对应用程序进行检测是相对便宜的操作。由于指标会随着时间的推移聚合值，而不是建立要分批发送的值序列，因此给定的一组指标存在不变的内存成本；尽管不是免费的，但计算成本却很小
预测技术概述
预测技术团队的主要目标是针对着陆时间（EON）和登机口到达时间（EIN）生成飞行ETA预测。对于任何给定的机场，我们训练两种模型，一种用于EON，另一种用于EIN，这些模型可以预测飞往该机场的航班。
由于该软件中大量使用了机器学习，因此监控变得比平时更为重要。您不仅需要管理典型的软件条件，例如系统是运行，挂起还是停止，还需要跟踪机器学习模型本身的准确性。模型可能会出现短暂的不准确性，例如，如果它们无法预期巨大风暴的影响；随着现实生活中行为的改变，它们也会随着时间的推移缓慢漂移。意识到这两种类型的变化对于对您的预测充满信心至关重要。
当我们赢得了要求我们对600个机场进行预测的客户时，这种情况突然变得不足。高可用性是服务的关键组成部分，为了帮助实现这一点，我们选择了冗余运行模型。总体而言，这将我们的生产基础架构从几台主机扩展到了24台主机，当我们需要在Hyperfeed中引入预测速率限制以确保客户不会因仅几秒钟更新ETA的消息而感到不知所措时，就增加了软件复杂性。
新监控解决方案的目标
我们希望确保包含新功能的几个功能可以解决我们的痛点：
- 根据每个机场的时间跟踪错误
- 跟踪误差在每次飞行过程中都会发生变化：例如，飞行着陆前两个小时的预测误差是多少？航班降落前一小时？
- 自动发现指标：例如，当机场作为键key传递时，如果之前未曾看到过该机场，则会添加一系列
- 查询和显示反映预测误差的图形
- 对高（或高于正常）错误发出警报
用Grafana监控
Prometheus是一个纯时间序列数据库。它不支持关系查询（SQL JOIN）。我们最终选择了TimescaleDB作为数据库后端。TimescaleDB是PostgreSQL的时间序列扩展：它在背后隐藏了时间序列表，与纯Postgres相比，查询性能得到了很好的提升。在所有其他方面，它都是“仅” Postgres，这是理想的，不仅是因为它支持关系查询，而且还因为FlightAware已经在大多数数据库中使用了Postgres。我们已经对如何设置，配置，调整等等有很多机构知识和熟悉度，这使得它很容易采用。
关系查询使我们可以将到达时间存储在一张表中，并将根据我们的机器学习模型和第三方估算值预测的ETA记录在另一张表中。借助Grafana，我们会在每个机场，每个航空公司和每个超时时间提醒高ETA错误；我们可以将我们的预计ETA直接与第三方估算值进行比较。它使我们对我们的预测充满信心，并为改进提供了方向。