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日
    浏览(40)
  • 夜莺(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日
    浏览(42)
  • 监控场景及开源监控方案选型

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

    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日
    浏览(41)
  • 开源数据资产(元数据)管理平台选型对比

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

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

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

    2023年04月10日
    浏览(35)
  • 12款开源数据资产(元数据)管理平台选型分析(三)

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

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

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

    2024年02月11日
    浏览(35)
  • 低代码(七)低代码平台后端技术选型2.0

    JWT 登录token Json web token (JWT), 是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准((RFC 7519).该token被设计为紧凑且安全的,特别适用于分布式站点的单点登录(SSO)场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息,以便于从资

    2024年02月09日
    浏览(53)

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

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

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

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

二维码1

领取红包

二维码2

领红包