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

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

运维工作最重要的就是维护系统的稳定性,其中监控是保证系统稳定性很重要的一环。通过监控可以了解系统的运行状态,及时发现问题和系统隐患,有助于一线人员快速解决问题,提高业务系统的可用时长。

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

可观测性在期货行业落地的难点

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

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

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

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

落地实践三阶段

  1. 标准化数据结构
  2. 构建期货场景下的可观测三大支柱
  3. 面向业务场景,打通可观测数据

1. 标准化数据结构

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

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

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

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

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

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

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

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

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

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

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

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

效果与展望

目前面向业务的可观测体系已经在部分业务系统实现了落地,其实具体效果如下:

日志处理

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

灭火图

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

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

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

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

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

总结

通过上述方案落地,整体上实现了从问题发现到下钻追查,直至细节的全部串联,可以明显加速用户问题的发现和处理效率。

我们主要从扩大可观测性监控试点落地的范围、接入更多核心业务系统,引入更加智能化的运维监控手段;从两个方向来着手,具体如下:

  1. 目前看,我们可观测实践的产品形态,满足了试点业务内部研发、运维侧的需求,后面需要在更大范围内进行落地;主要的工作,是在更多业务系统中,完成相关“期货业务”日志插件的适配,完成日志的标准化处理,将更多的数据纳入到可观测体系中来;

  2. 引入智能化的异常检测手段:在我们提取到业务指标后,对业务指标进行观察,发现由于交易所的特性,部分的业务指标是有非常强的规律性的。如下图所示,为某“功能号”的流量请求趋势图,可以看当前时间的流量趋势,和昨天、上周同一时间段的趋势相比,是非常吻合的,指标曲线非常有规律,这时我们就可以使用基于算法的智能检测,对曲线进行智能报警。

热门相关:宝贝迷人,总裁圈住爱   傲娇驾到,总裁别闹   全系灵师:魔帝嗜宠兽神妃   甜妻动人,霸道总裁好情深   试婚100天:夜少,宠上瘾