为落实“敏捷、科技、生态”战略转型，推动运维中心四化转型，助力运维智能化，G行智能运维技术团队构建智能运维项目群，涵盖数据采集、数据处理存储、数据计算服务、数据可视化等功能。
本文转自 / 匠心独运维妙维效 作者 / 刘轶勇
引言
今天让我们来一起详细了解一下针对网络流量数据进行采集分析的TCP监控分析系统吧！
G行TCP监控分析系统建设以来，从最早的网络报文数据采集与分析，进一步完成与kafka系统对接，并利用大数据平台的算力实现特定场景的监控分析，实现底层数据使用专业平台底层算法计算与统计数据使用大数据平台算法计算的双路并行模式。目前已实现绝大部分网络交换机的数据采集与向kafka进行数据输出，每秒钟数据采集量为4100万pps，向kafka数据输出每分钟200万条，为各种日常运维场景及实时监控提供基础数据。
平台建设背景
网络流量数据是除应用和主机日志、主机和网络设备性能数据等之外的重要数据资产，相对于传统网管采集数据具备更细颗粒度及更小时间精度的特点，在应用场景上涵盖应用、系统、网络领域，具备深度数据挖掘意义，对网络流量数据的应用可对运维故障排查定位及日常运维能提供有效补充，且在很多场景能发挥独立价值。
目前业界对网络流量数据的应用主要通过专有设备，数据环境封闭，难以与其它系统进行数据交互，数据应用场景依赖采集平台自身的功能设计，对于复杂与快速多变运维需求尤其是需利用多种数据计算的场景实现起来比较困难，同时也受限于原厂商的开发进度。为打破这种桎梏，G行协同原厂商经过近一年多努力，实现采集系统的全量数据吐出，为基于网络流量数据的大数据应用场景输出奠定数据基础，在我行多运维数据融合计算方面弥补网络流量领域空白。
关键技术设计
在系统建设过程中，有一些比较关键的技术点，这里跟大家分享一下。
3.1 网络报文数据的分类采集
传统数据采集通常使用一份整量流量即可（由分流系统汇总与过滤后的流量），随着运维需求的进一步精细化，在特定场景下使用整量流量无法满足需求，例如当判定应用报文丢失在哪台交换机时，就需要各台交换机镜像流量，因此G行设计与实现分布式流量采集（采集单台交换机）与整量流量采集两种模式架构，实现整量采集能力1700万pps，分布式采集能力2400万pps，同时实现单台采集设备采集30台交换机流量的容量突破，节省大量资源投入，满足不同场景下对数据采集模式的需求，支撑各种场景下的智能运算。
3.2 各类报文信息的输出
传统采集系统针对网络报文进行统计分类，这些统计信息以往只局限在设备自身使用，G行协同原厂对设备里15大类（ip会话、tcp会话等）的统计信息进行分类输出，涵盖几百种统计指标，输出频率可以按照秒级、分钟级、小时级及自定义。同时，为满足原始报文头或内容分析，我们设计实现元数据推送模式，可实时推送每个报文里面每个协议字段内容，为特定场景实现提供数据可能，例如ip地址冲突检测等。报文信息输出方式实现可汇总(统计信息)可明细(元数据)的模式，丰富数据使用场景。
3.3 精准时间戳的实现
传统报文采集系统使用NTP服务器进行时间同步，我们知道NTP的时间误差是毫秒级，这对于一般应用场景是足够的，但对于一些特定场景，毫秒级的误差导致无法分析判定，例如局域网里面，交换机之间的转发时延通常是20微秒左右，如果要分析应用报文在网络中的传递路径，毫米级的时间戳将无法使用。为此，我们协同采集、分流设备厂商，实现纳秒级的精度，大幅缩小误差，为对时间精度有严格要求的分析场景奠定基础
部分场景落地
基于以上关键技术的使用及场景定制，G行实现几个典型场景的应用，下面就几个典型场景分别做介绍。
4.1 某传统柜面业务连接监控-基于采集系统实现
某传统柜面业务连接监控主要是针对该系统的应用服务器对外服务端口的服务状态进行实时监控，可直观地观察到当前与历史时间内，业务客户端连接数量的情况，为管理员日常运维及变更后了解系统运行状态提供协助。
图1 服务端口连接数监控
4.2 某支付业务相关节点响应时间监控-基于采集系统实现
某支付相关业务节点时间响应监控将交易从专线、防火墙、F5、SSL设备、关联系统之间的拓扑进行呈现，并将各节点关键性的流量、响应时间等指标在同一个界面展示，为重保及日常运维提供局部应用系统的全局性视角。
图2 某支付业务拓扑及指标监控
4.3 互联网流量监控-基于采集系统实现
互联网流量监控实现各个互联网出口专线流量使用情况的秒级监控视图，通过带宽使用率、pps、会话数、SYN/ACK数等指标，可实时监测互联网专线健康程度与及时发现互联网攻击。
图3 互联网出口流量监控
4. 4 全行骨干网监控-基于采集系统实现
全行骨干网监控将百余条总分行间业务及办公传输专线进行集中监控，可实时了解各线路带宽使用率、丢包与重传率、占用带宽系统ip排名等，有效减轻常规运维工作量。
图4 骨干网专线监控
4. 5 服务器存活流量查询-基于大数据实现
常规采集系统自身的数据存储通常在几小时至几天，通过kafka接口进行数据输出在大数据平台存储后，可实现按月或按年存储，为网内任意服务器及关联方的通讯记录长时间查询提供保障，可实现数据存储周期内服务流量的历史及实时查询，了解服务器的通讯及各种流量性能类指标情况，为服务器下线、变更、访问关系查询等场景下提供判定依据。
图5 服务器存活流量监控
4. 6 三层环路与二层环路监控-基于大数据实现
网络二层环路及三层环路会造成网络中断造成严重业务影响，通过常规手段且不易监控，我们通过实时采集各网络交换机的报文转发数量、ARP包数量、广播包数据，当出现二层环路时，将实时通报异常交换机，为管理员定位提供协助；对于三层环路，我们通过监测报文段中的TTL数值，可实时发现三层环路的通讯对，为快速定位及恢复提供协助。
4.7 应用系统网络访问关系拓扑呈现
传统应用运维中一般使用手工方式记录与维护应用系统的访问关系，访问关系的准确性基本依赖于管理员的细心及认真程度。因网络流量数据已大数据化，已具备利用大数据平台的算力来实现系统内部及系统之间的访问关系计算后呈现访问拓扑，同时实时展示系统内部与关联方的各类性能指标，为管理员日常运维提供协助。
总结与展望
网络流量数据是数据资产中重要不可分割的一部分，G行利用现在的运维数据，已实现较重要的新型场景监控，并已初步发挥了作用。但未来会有更多场景需要新的场景和技术发挥作用。因此，如何充分挖掘该部分数据资产价值，服务于我们运维科技，将是后续较长一段时间内运维技术中网络流量领域智能化、自动化方面努力的方向。同时，随着技术的发展，银行业中应用系统的云化，也对网络流量数据的采集与使用提出新的课题与挑战，后续我们将不断跟进与研究相应技术的改进。