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

这篇具有很好参考价值的文章主要介绍了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. 引入智能化的异常检测手段:在我们提取到业务指标后,对业务指标进行观察,发现由于交易所的特性,部分的业务指标是有非常强的规律性的。如下图所示,为某“功能号”的流量请求趋势图,可以看当前时间的流量趋势,和昨天、上周同一时间段的趋势相比,是非常吻合的,指标曲线非常有规律,这时我们就可以使用基于算法的智能检测,对曲线进行智能报警。文章来源地址https://www.toymoban.com/news/detail-749185.html

到了这里,关于20 套监控平台统一成 1 套 Flashcat,国泰君安监控选型提效之路的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 夜莺(Flashcat)V6监控(二):夜莺页面全网最详细功能介绍及案列

    目录 (一):如何把数据转发给多个时序库 (二):监控仪表盘的配置 (三):告警的配置管理            (1):告警规则 ①: 基础配置 ②:规则配置:分为Metric和Host机器类型的告警 ③: 生成配置 ④:通知配置   (2): 内置规则   (3) 屏蔽规则   (4) 订阅规则   (5) 活跃告警

    2024年02月06日
    浏览(43)
  • 夜莺(Flashcat)V6监控(五):夜莺监控k8s组件(下)---使用kube-state-metrics监控K8s对象

    目录 (一)前言 (二)categraf作为Daemonset的方式去运行监控k8s组件  (1)1.24版本以下的k8s集群部署方法: ①创建autu.yaml绑定权限 ②Daemonset部署categraf采集监控kubelet,kube-proxy ③测试数据是否采集成功  (2)1.24版本以上的k8s集群部署方法: ①创建secret token 绑定sa账号 ③测试认证 ④Daemo

    2024年02月09日
    浏览(45)
  • 监控场景及开源监控方案选型

    先看监控的需求来源,即监控系统可做什么 再跳出监控,从可观测性,看监控与日志、链路间的关系及它们各自的作用 最后介绍开源社区几个有代表性的方案以及它们各自的优缺点,便于你之后做技术选型。 系统出问题我们能及时感知。随时代发展,对监控系统提出更多诉

    2024年01月22日
    浏览(38)
  • 对于监控选型的一些思考

    监控的选型: 1.首先是拉模式(例如prometheus)和推模式: 拉可以随意控制拉取频率和指标,可大可小,推的话收集者可以下发改变推频率的指令,实现比较麻烦;拉失败快速知道客户端节点agent监控异常,推的话只能看哪个节点没上报比较麻烦; 拉模式下客户端agent只需要读

    2024年02月11日
    浏览(38)
  • 开源大数据管理平台选型

    随着CDH和HDP的闭源,还有国内信创需求,经过前期调研和后期实践,目前主要有两个产品满足要求:apache bigtop 和 DataSophon 符合要求。因为这两个产品都是完全开源的,自助可控。 项目地址:https://bigtop.apache.org Apache Bigtop 是一个开源项目,旨在提供一套完整的开源软件栈,用

    2024年02月21日
    浏览(43)
  • 开源数据资产(元数据)管理平台选型对比

    尽管数据行业的新词热度,由大数据平台-数据治理-数据中台-数字化转型(现代数据技术栈)转换,做为这些新词的基础组成部分,数据资产管理平台/元数据管理平台/数据目录管理平台等技术方案,依旧处于Gartner曲线的爬升恢复期,相关平台百花齐放,一统江湖的开源平台

    2024年01月24日
    浏览(47)
  • 12款开源数据资产(元数据)管理平台选型分析(三)

    如上,是ChatGPT的百度指数和微信指数,继2022年12月上旬技术圈火热之后,因为微软、谷歌等巨头的推广加持,ChatGPT成为全球大众热源的话题。各大媒体都在消费这波舆论红利,打开微信公众号,劈天盖地各种姿势的ChatGPT推文。关于ChatGPT是否会替代人类的文章,在各个领域和

    2023年04月22日
    浏览(65)
  • 聊一聊微前端框架的选型和实现 | 业务平台

    一、项目背景 目前,我们开发维护的项目主要有 6 个,但是分别对应 PC 和 H5 两个端: 如上图所示,我们 6个项目最开始是一个一个进行开发维护的,但是到后期,这几个项目之间有的部分会有业务逻辑不同,UI 基本相似的情况出现。而这几个项目前端维护人员较少, 这个时

    2024年02月11日
    浏览(36)
  • 低代码(四)低代码平台前端技术组件选型2.0

    上节已经介绍了前端的部分组件技术选型,本节继续。 AntV 数据可视化组件 AntV 是一个数据可视化项目,也是一个团队,蚂蚁金服数据可视化团队,一群有爱有梦的人,怀揣「让人们在数据世界里获得视觉化思考能力」的梦想前行, 希望成就智能时代全球领先的数据可视化解

    2023年04月10日
    浏览(37)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包