20 套监控平台统一成 1 套 Flashcat，国泰君安监控选型提效之路 ...

author:宋庆羽-国泰君安期货

运维工作最重要的就是维护系统的稳定性，其中监控是保证系统稳定性很重要的一环。通过监控可以了解系统的运行状态，及时发现问题和系统隐患，有助于一线人员快速解决问题，提高业务系统的可用时长。
作为国内头部期货公司，随着行业的发展，国泰君安期货的业务不断增长，近年来各开发厂商对新技术的引用，其运维工作面临着系统种类多、主机数量多、技术栈多、机房多（跨地域）的难题，而原有监控A无法满足现有的监控需求，我们期望找到一个既能统一管理多平台、扩展性较好、满足现有场景且包含主流的技术，又能支持异地纳管统一上报的更高效的运维监控平台。经历了3个多月的产品调研、PoC测试选型、系统/主机收集和机器资源申请，最终选择了 Flashcat，Flashcat 顺利帮助我们完成了监控平台的统一、管理统一、配置统一，提升了系统的可观测性和运维效率。同时，结合Flashcat的最佳实践，也推动了监控系统往可观测性平台的演进和转变。
可观测性在期货行业落地的难点

目前在期货行业，可观测性已经开始逐步推广起来，但是推广的业务目前还仅限于移动端等新业务，或者是内部的周边业务，最核心的交易系统，目前还没有真正落地，现在所谓的可观测性，仍然在使用比较传统的监控技术，造成这个问题的原因主要包括以下几个方面：

• 非标准化的数据：国内期货行业的核心交易系统，有其行业特色的数据形态，从可观测性角度来讲，数据非常的不规范，特征不明显，不利于统一纳入分析；
  
• 缺乏面向行业的通用方案：目前国内主流的监控工具、主流的产品形态偏向于通用的解决方案，不是非常适合于期货行业，虽然有部分产品宣称有期货行业案例，但是仔细看来，结合的还比较表面，与行业的核心业务差距还比较远；
  

在核心业务落地可观测的实践

针对上述难点，结合自身实际情况，针对可观测性的深水区，开始落地自身的可观测性实践——“面向业务的可观测体系”，目的是在深层次的系统中，落地可观测最佳实践，提升核心系统稳定性。
落地实践三阶段：

• 标准化数据结构
  
• 构建期货场景下的可观测三大支柱
  
• 面向业务场景，打通可观测数据
  

1. 标准化数据结构

如下图所示，是我司期货某业务系统日志的一个示例，从监控角度来讲，对于一般服务程序，我们最关注的核心数据包括请求API、错误状态、耗时等信息；但是从上述日志截图来看，期货行业的日志存在很强的特殊性：

想要将这类数据从半结构化数据转变为结构化数据，还是具有很强挑战性且有长远意义的：

• 首先我们邀请Flashcat产品技术团队与我司业务运维团队进行深入沟通，了解数据含义，确认该系统定位是核心应用系统，对提升系统稳定性具有重大意义，且具有通用性，故双方对该系统的日志结构进行了深入的解剖分析；
  
• 其次，需要Flashcat产品技术团队，实现相应的日志插件，可以根据预定义的规则，将半结构化的日志数据，转换为结构化的日志数据，纳入到可观测体系中；
  

Flashcat平台本身有强大的日志处理能力，同时架构也比较灵活，可以将我司需要的日志处理能力作为“日志插件”集成进来。日志的处理流程概括起来如下图所示：

通过以上处理后，交易系统日志数据由半结构化数据，转变为结构化数据，样例如下：

2. 完善期货场景下的可观测要素

在经典的可观测理论中，可观测数据包括指标、日志、Trace，在期货行业中，其实也需要对应的可观测要素，只是在期货核心业务中，由于期货行业的特点，略有差异：

• 指标：在指标监控方面，采用categraf进行指标采集。同时，随着国内“信创”合规的要求，现在在逐步扩大国产设备及软件的使用，这里和Flashcat团队进行密切的配合，完成了国产化设备的监控需求，同时也丰富了Flashcat的指标采集能力；
  
• 日志：通过上述提到的日志插件，我们可以将日志标准化处理后，纳入到可观测体系中；
  
• Trace：Trace 可以用于分析上下文调用，在单个异常问题排查中，是非常有效的工具，但是在期货行业中，由于核心系统大部分是第三方软件，并没有提供Trace相关的能力，在这里，我们使用“用户ID”的维度，来替代Trace ID， 通过“用户ID”来分析用户在一段时间内的操作上下文。
  

如下图所示，通过“用户ID”，将用户操作按照时间维度串联起来， 可以回溯用户操作，并可以查看到其状态、延时以及请求详情：

3. 场景化能力——面向业务的监控

有几类可观测数据后，我们期望能将几类数据串联起来，这里我们采用了Flashcat的稳定性最佳实践，如下图所示：

• 首先通过灭火图，来实时反映各个功能的健康度状态（通过异常码、耗时，来判断功能是否正常）；
  
• 发现异常时，可以在灭火图点击异常点，立即定位到异常日志；
  
• 在异常日志里面，发现“用户ID”等信息，定位到用户请求的详情，查找根因；
  

效果与展望

目前面向业务的可观测体系已经在部分业务系统实现了落地，其实具体效果如下：
日志处理

• 我们根据处理后的结构化日志数据，生成日志报表，可以实时查看当前所有“功能号”的功能状态；
  
• 可以从不同的维度查看“功能号”的异常状态，以下图为例，在期货行业中，一笔交易的完成，请求都是在一台机器上完成的，所以我们可以查看特定某台机器，其处理的业务“功能号”状态，来判断是单机异常，还是集群异常；
  

灭火图

1.有了日志数据后，我们获取了各个“功能号”的核心指标（错误码、延迟、流量等等），可以构建业务维度的“健康度”实时看板（灭火图），下图是某业务线的灭火图示例：

• 展开灭火图，可以看到出现问题的异常点，如下图所示，夜间收市后，请求成功率下跌属于正常情况，但是在盘中，可以看到部分“功能号”成功率有异常，可能需要我们来进行排查：
  

• 点击异常点，可以看到异常日志的特征分布（默认展示错误状态码的异常分布），可以让我们快速定位主要问题，如下图所示，在分析的时间段内，异常错误码主要包括三类，-1005、-1003、-1090，并能看到各错误码的错误数分布特征，帮助快速锁定主要问题：
  

• 可以在特征分析里，直接查看到错误日志详情，如下图所示，点击可以看到错误的原因，为“CTP：连续登陆失败次数超限，登录被禁止”：
  

• 如果遇到错误日志，可以根据“用户ID”，直接在日志系统查到关联的用户行为操作利用“用户ID”，查看用户行为的调用关系信息：
  

总结

通过上述方案落地，整体上实现了从问题发现到下钻追查，直至细节的全部串联，可以明显加速用户问题的发现和处理效率。
我们主要从扩大可观测性监控试点落地的范围、接入更多核心业务系统，引入更加智能化的运维监控手段；从两个方向来着手，具体如下：

• 目前看，我们可观测实践的产品形态，满足了试点业务内部研发、运维侧的需求，后面需要在更大范围内进行落地；主要的工作，是在更多业务系统中，完成相关“期货业务”日志插件的适配，完成日志的标准化处理，将更多的数据纳入到可观测体系中来；
  
• 引入智能化的异常检测手段：在我们提取到业务指标后，对业务指标进行观察，发现由于交易所的特性，部分的业务指标是有非常强的规律性的。如下图所示，为某“功能号”的流量请求趋势图，可以看当前时间的流量趋势，和昨天、上周同一时间段的趋势相比，是非常吻合的，指标曲线非常有规律，这时我们就可以使用基于算法的智能检测，对曲线进行智能报警。
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！