16 个调制解调器、4 个蜂窝运营商 = 传出速度 933.45 Mbit/s
介绍
你好！ 这篇文章是关于我们如何为自己编写一个新的监控系统的。 它与现有的不同之处在于它能够获取高频同步指标并且资源消耗非常低。 轮询速率可达0.1毫秒，指标之间的同步精度为10纳秒。 所有二进制文件占用 6 MB。
关于项目
我们有一个相当具体的产品。 我们提供了一个全面的解决方案来总结数据传输通道的吞吐量和容错能力。 这是当有多个通道时，假设 Operator1 (40Mbit/s) + Operator2 (30Mbit/s)+ Something else (5 Mbit/s)，结果是一个稳定且快速的通道，其速度将类似于这个：(40+30+5)x0.92=75×0.92=69Mbit/s。
当任何一个通道的容量不足时，就需要这样的解决方案。 例如，交通、视频监控系统和实时视频流、直播电视和广播广播、电信运营商中只有四大代表且单个调制解调器/通道的速度不够的任何郊区设施。
对于每个领域，我们都生产单独的设备系列，但它们的软件部分几乎相同，高质量的监控系统是其主要模块之一，如果没有正确的实施，该产品就不可能实现。
经过几年的时间，我们成功创建了一个多层次、快速、跨平台、轻量级的监控系统。 这就是我们想要与我们尊敬的社区分享的内容。
制定问题
监控系统提供两个根本不同类别的指标：实时指标和所有其他指标。 监控系统仅具有以下要求：
- 高频同步采集实时指标并无延迟地从通信管理系统传输。
不同指标的高频和同步不仅重要，对于分析数据传输通道的熵也至关重要。 如果在一个数据传输通道中平均延迟为 30 毫秒，则其余度量之间仅 5 毫秒的同步误差将导致最终通道的速度下降大约 1%。 如果我们在 4 个通道上错时 30 毫秒，速度下降很容易下降到 0.5%。 此外，通道中的熵变化非常快，因此如果我们测量它的频率少于每 500 毫秒一次，那么在延迟较小的快速通道上，我们将得到高速退化。 当然，并非所有指标和所有条件都需要这样的准确性。 当通道中的延迟为 1 毫秒时，并且我们使用这样的延迟，那么 2 毫秒的误差几乎不会被注意到。 另外，对于生命支持系统指标，我们有足够的XNUMX秒轮询和同步速率，但监控系统本身必须能够支持超高轮询速率和超精确的指标同步。 - 最少的资源消耗和单个堆栈。
终端设备可以是功能强大的车载综合体，可以分析道路情况或对人员进行生物识别记录，也可以是手掌大小的单板计算机，特种部队士兵佩戴在防弹衣下，用于传输视频在通信条件较差的情况下实现实时。 尽管架构和计算能力多种多样，但我们希望拥有相同的软件堆栈。 - 伞式架构
指标必须在终端设备上收集和聚合、本地存储，并实时和回顾性地可视化。 如果有连接，则将数据传输到中央监控系统。 当没有连接时，发送队列应该累积并且不消耗RAM。 - 用于集成到客户监控系统中的API，因为没有人需要许多监控系统。 客户必须将来自任何设备和网络的数据收集到单个监控中。
发生了什么
为了不给已经令人印象深刻的长读带来负担，我不会给出所有监控系统的示例和测量结果。 这将导致另一篇文章。 我只想说，我们无法找到一个能够同时获取两个指标且误差小于 1 毫秒的监控系统，并且在具有 64 MB RAM 的 ARM 架构和具有 86 MB RAM 的 x64_32 架构上同样有效地工作。 GB 内存。 因此，我们决定自己编写，它可以完成这一切。 这是我们得到的：
总结不同网络拓扑的三个通道的吞吐量
一些关键指标的可视化
建筑
我们在设备和数据中心都使用 Golang 作为主要编程语言。 它通过实现多任务处理以及为每项服务获取一个静态链接的可执行二进制文件的能力，极大地简化了生活。 因此，我们显着节省了将服务部署到终端设备的资源、方法和流量、开发时间和代码调试。
该系统按照经典的模块化原理实现，包含多个子系统：
- 指标注册。
每个指标都由其自己的线程提供服务并跨通道同步。 我们能够实现高达 10 纳秒的同步精度。 - 指标存储
我们正在选择编写自己的时间序列存储或使用已经可用的东西。 该数据库需要用于后续可视化的回顾性数据，即不包含通道中每0.5毫秒的延迟数据或传输网络中的错误读数，但包含每个接口每500毫秒的速度。 除了跨平台要求高、资源消耗低之外，处理能力对我们来说也是极其重要的。 数据是它存储的地方。 这节省了大量的计算资源。 自 2016 年以来，我们一直在该项目中使用 Tarantool DBMS，到目前为止，我们还没有看到它的替代品。 灵活，具有最佳的资源消耗，充足的技术支持。 Tarantool 还实现了 GIS 模块。 当然，它不如 PostGIS 那么强大，但对于我们存储一些与位置相关的指标（与交通相关）的任务来说已经足够了。 - 指标可视化
这里一切都比较简单。 我们从仓库获取数据并实时或回顾性地显示它。 - 与中央监控系统数据同步。
中央监控系统接收来自所有设备的数据，将其存储在指定的历史记录中，并通过 API 将其发送到客户的监控系统。 与“头部”四处走动并收集数据的经典监控系统不同，我们有相反的方案。 当存在连接时，设备本身会发送数据。 这是非常重要的一点，因为它允许您在设备不可用的时间段内从设备接收数据，并且在设备不可用时不加载通道和资源。 我们使用Influx监控服务器作为中央监控系统。 与它的类似物不同，它可以导入回顾性数据（即，具有与接收指标时不同的时间戳）。收集的指标由 Grafana 可视化，并使用文件进行修改。 选择此标准堆栈的另一个原因是它具有与几乎所有客户监控系统的现成 API 集成。 - 与中央设备管理系统的数据同步。
设备管理系统实现零接触配置（更新固件、配置等），并且与监控系统不同，它仅接收每个设备的问题。 这些是板载硬件看门狗服务操作和生命支持系统所有指标的触发器：CPU 和 SSD 温度、CPU 负载、可用空间和磁盘上的 SMART 运行状况。 子系统存储也是基于 Tarantool 构建的。 这使我们能够以显着的速度聚合数千个设备上的时间序列，并且还彻底解决了与这些设备同步数据的问题。 Tarantool 拥有出色的排队和有保障的交付系统。 我们开箱即用了这个重要的功能，太棒了！
网络管理系统
接下来是什么
到目前为止，我们最薄弱的环节是中央监控系统。 它在标准堆栈上实现了 99.9%，但有许多缺点：
- 断电时，InfluxDB 会丢失数据。 通常，客户会立即收集来自设备的所有内容，并且数据库本身不包含超过 5 分钟的数据，但将来这可能会变得很痛苦。
- Grafana 在数据聚合和显示同步方面存在许多问题。 最常见的问题是，当数据库包含从 2:00:00 开始、间隔为 00 秒的时间序列时，Grafana 从+1 秒开始显示聚合数据。 结果，用户看到了一个跳舞的图。
- 与第三方监控系统的API集成代码量过多。 它可以变得更加紧凑，当然可以用 Go 重写）
我想你们都已经清楚地看到了 Grafana 的样子，并且即使没有我也知道它的问题，所以我不会在帖子中放太多图片。
结论
我故意不描述技术细节，而只描述这个系统的基本设计。 首先，为了从技术上全面描述该系统，需要另一篇文章。 其次，并不是所有人都会对此感兴趣。 在评论中写下您想了解的技术细节。
如果有人有超出本文范围的问题，可以写信给我：[email protected]
来源： habr.com