基于时序数据库服务监控系统的设计与实现

冯占利 安进朝

摘要：在大型系统软件中，需要众多异步工作的节点参与提供服务，各节点要生成大量在空间上离散而时间上又相关的数据，运行期间传统离散日志难以追踪故障，对这些数据进行分析过程中，一般期望通过可视化的图表来展示详尽的数据和解释，以提高故障追踪效率。通过合理利用时间序列数据库高效且灵活索引，利用其较好的查询展现能力，并按照需求延伸数据表的结构，以时序型数据库与分布式通信系统核心网结合进行深入设计为例，分析和解决了大型系统软件中服务监控系统的需求难题。

关键词：时间序列；数据库；服务监控；InfluxDB；通信系统

中图分类号：TP311文献标志码：A文章编号：1008-1739（2021）06-60-4

0引言

在大型系统软件设计中服务监控系统有海量数据的快速写入和读取需求，要能够适应多个完全不同的项目同时对面向研发与运维的监控的需求，且可以不需修改業务无关部分的代码，也不需修改数据库的结构。经调研，时间序列数据库可以建立高效且灵活的索引，实现更好的查询能力，并且可以随时延伸数据表的结构，适合使用“按列存储”以时间为主要线索的非关系数据库来管理。其中比较知名的时序数据库InfluxDB是由InfluxData使用GO语言开发，经过不断改进现已在开源时序数据库中排名第一[1-2]，应用较为广泛，着力于高性能查询与存储时序型数据，被广泛应用于存储系统的监控数据、IoT行业的实时数据等场景。

1时间序列数据库

在众多的NoSQL数据库存储模型中，时间序列数据库通过使用特殊的存储方式，使得时序数据可以高效存储和快速查询，是管理海量只读数据的一项重要技术。InfluxDB是当今最流行的时序数据库之一，采用了特殊数据存储方式，有较高的以时间作为主要线索的非结构化数据的处理能力。与传统关系数据库相比，时序数据库的特点主要表现为以下几个方面：

①数据模型：同样支持数据库、数据表和记录的3级存储结构，但同一个表中的不同记录可异构，甚至索引也可异构。很多应用都会从这种非结构化数据模型中获益，这些数据库也非常适合于创建原型或是快速融入应用开发，因为这种灵活性使得新特性的开发变得非常容易。开发者希望使用非常灵活的数据库，能够轻松容纳新的数据列，而不用去重构数据表的结构。

②查询效率：使用面向列的存储，同一列的数据毗邻能够实现数据的高效插入与追加、多重索引，能够实现数据高效的多条件查询，查询性能不因条件的增多而显著下降。

③功能专一：现有产品所提供的功能都围绕核心功能与优化性能，因而大多数NoSQL数据库都不支持视图、事务、存储过程与触发器。InfluxDB主要针对时间作为主要查询线索优化，并且多个列作为条件查询时性能优异。

④容灾：自身大量使用内存做索引的缓存，提供离线备份功能，方便备份与恢复，也节约空间，提供集群部署能力。

⑤元数据：使用多个相对独立的列保存，每一列都可以有独立的索引。在查询时不用连续出现，支持同时对多个索引列的查询，支持丰富的筛选关键词。

⑥执行代码：InfluxDB使用编译的本地机器代码，性能有保证。单机部署即可实现很高的检索性能，若选择集群部署更能够提供业界较为领先的能算比，节约运维成本。

2服务监控节点数据分析

对于需要大量采集数据的服务监控系统来说，时间序列数据库还有一些特性，是关系数据库无法简单实现的。这些特性中，最重要的就是无结构（Schema Less）。无结构无需提前创建表，数据表中的列是随着数据的插入和删除而发生变化的，即表的结构会自动去适应新插入数据。这一点在大量有关联的异构数据的收集方面有着先天的优势，对于服务监控的开发来说，项目初期开发人员并不知道采集的数据都要哪些列、哪些类型的数据，数据表的格式是随着项目的进行而不断丰富的。图1是通信系统核心网服务监控系统的追踪前端界面，可以看到追踪的过程中，为了便于分析需要展示一些异构的数据。

服务监控系统要能够适应多个完全不同的项目对于面向研发与运维的监控需求，而不用修改业务无关部分的代码，也不用修改数据库的结构。只要增加业务有关的数据解析组件、在前端增加过滤规则就能够迅速适应新项目。只有无结构的存储才能满足这样的需求，这是大数据与数据挖掘优先选用非关系数据库管理的一个主要原因。

3分布式通信系统核心网服务监控系统设计

3.1系统需求分析

在众多大型系统软件中，例如分布式通信系统核心网架构都需要众多的异步工作的节点参与提供服务，各节点要生成大量在空间上离散的、时间上又是相关的数据，如状态变化、数据变化及调用流程日志等运行信息，传统离散日志难以追踪故障。这就需要预先研发专门的可用于监控软件系统的框架来支持研发与后续运维，这一服务监控系统要满足下面的需求[4]，包括：

①增加透明度：对于分布式通信系统来说，各节点运行状态、节点间消息、网元对数据库的查询、终端的请求响应等信息都需要采集，这就会产生大量异构却又相关的数据，而这些数据都需要纳入监控的采集范围。

②定位关键点：分析监控记录是非常痛苦的，系统每小时可能会产生大量监控日志，发生事件的时候不能寄希望依靠人眼查看数据就能迅速找出问题原因，需要高效率的检索来保证维护人员能够快速定位问题。

③自动化：数千项的数据不可能每一项都靠人工去看，必须要跟自动报警相关联，需要后台有算法不断自动检索。发现数值异常时，可以通过短信、邮件还有系统本身来发出报警信息。报告产生可以无人值守，还可以作为持续集成和持续测试快速判定结果的依据。

④可视化：通过信息采集与分析，记录关键行为的详细信息，形成便于观察的数据表，生成可视化的图表，让人直观上就能迅速判定系统是否有异常。

⑤支持研发过程中把监控嵌入基础框架：用于在调试、测试与运维阶段探测软件内部运行情况的技术集合。服务于研发与优化的过程，减少人为因素造成缺陷的可能性。一般来说项目进行编码时，并不是每个编码人员都会意识到需要在关键的地方嵌入一个监控点，所以要在基础框架本身的关键点预埋监控“探针”。

⑥异地分析：数据采集与分析存储分离，只需要在目标上采集原始数据，支持通过传输到异地再进行解析、储存与分析。

3.2服务监控系统技术栈设计

分布式通信系统核心网的服务监控系统中，相关的技术栈设计以微服务架构监控系统中的技术栈为基础，做出适应性的改进，以减少对网元的改动。

采集：探针负责采集原始数据，将原始数据通过一次内存拷贝转交给传输代理，即完成自身任务；传输：透过传输代理，使用可靠传输协议来传输，当数据到达服务监控系统中，再转交给负责数据解析的解析服务，运行期间保证传输质量，断线时还要能够使用文件做缓存，传输和缓存与业务无关，与被探测对象无耦合；解析：使用动态加载的插件解析数据，根据不同项目的需要动态组合出不同的数据解析进程，支持负载均衡，插件负责将解析出的记录插入数据对应的数据表；存储：使用时间序列数据库保存采集到的大量异构信息，提供高效且灵活的查询能力。

另外还应使用关系数据库保存重要的或者检索条件局限于索引字段的信息，分析手动或自动的分析采集到的监控信息。其中手工分析需要为研发运维人员提供丰富的信息，例如：状态数据、网元日志、注册上下文、呼叫上下文、信令消息、系统资源占用、数据库操作、代码覆盖统计及性能统计等。

图2是InfluxDB在分布式通信系统核心网的服务监控系统中所处的位置。

3.3服务监控系统效果分析

以分布式通信系统的呼叫为例，分析不仅仅要有呼叫的简单信息还要有可以支持研发人员观察的详尽细节，通过可视化的图表、详尽的数据和解释，从而提高故障追踪的效率[5]。图3和图4是一个实际的呼叫分析过程。

如圖3所示，分析呼叫对于研发与运维人员来说，只要简单的查询即可开始分析，分析过程可以是直观的、图形化的，分析之前无需再花费很多时间去过滤日志和抓包，通过时序数据库的检索能力即可迅速找到所有的相关数据，快速呈现。这样的分析过程改变了原本需要多个工具参与的、多个步骤相互分离的、依赖研发运维人员经验的分析过程。把分析过程统一到了同一个分析系统之中，直观且高效率，降低了对人员的熟练程度要求。

通过与InfluxDB的结合，本服务监控系统提供了一种高效检索支持，研发与运维人员在面对数十亿条的服务监控数据时，就能够通过运用面向列存储的数据库减少IO总量，减少负载，提高检索效率，大大节约了调试时间。再利用InfluxDB提供的“类SQL”语法查询能力，让统计分析变得非常简单，结合前端页面设计，能够迅速实现统计分析的功能。图5是一个简单的拓扑统计页面演示，有多个统计信息，得到结果所用的时间少于1 s。

4结束语

面向研发的监控是软硬件研发过程质量控制的关键一环，能够提供对数据的丰富分析与追踪能力。核心思想是通过提高关键事件的溯源效率，来为系统开发过程提供高效“脚手架”，使得研发、测试、运维人员均能从中获益。当前5G系统核心网的架构发展出了更多层次，划分出了更多微服务[6]，可以容纳更多的节点分担负载，由于不同节点间完全的异步工作，并通过异步的消息传递来通信，对故障定位提出更高的要求，传统日志框架难于驾驭，对面向研发与运维的“服务监控系统”提出更高的要求。

智能化就是未来，服务监控系统除了提供面向编码、测试人员的功能外，还要能够提供自动化的数据分析算法。这样才能够让系统自动寻找故障来源，自动化生成客观报告，甚至根据预先制定的策略，自动调节自身运行状态，实现智能化运维。

参考文献

[1]徐化岩，初彦龙.基于InfluxDB的工业时序数据库引擎设计[J].计算机应用与软件，2019，36（9）：33-36.

[2]柴亚刚.基于时序数据库的分布式网络波动监控系统[J].中国传媒科技，2018（3）：36-37.

[3]程天天.基于Redis的时间序列数据库的研究与实现[D].成都：电子科技大学，2020.

[4]吕毅.服务监控方法及系统：北京，CN103209100A[P].2013.

[5]刘金.大规模集群状态时序数据采集、存储与分析[D].北京：北京邮电大学，2018.

[6]许碧洲，路遥，孙道禹.5G核心网的组网架构和演进发展[J].电子技术与软件工程，2018（20）：12.