如何获得讲师PPT:
扫码关注公众号,后台回复「1221」即可获得讲师PPT哟~
还能一键订阅后续精彩活动内容~
Q&A环节答疑:
1、老师好,请问一下,一站式监控平台,不同技术栈和团队之间的协同工作你们是怎么做的?
货拉拉已经走过十年的发展历程,技术发展历经多个阶段,从PHP到Java和Go等。公司有强大的核心基础设施部,其中包含处理不同技术的中间件团队。这些中间件在应用注册、服务发现、指标上报等方面发挥了关键作用,使业务集成更为顺畅。监控系统的协同工作也依赖于这些中间件,它们确保了系统的稳定运行。虽然我今天主要讨论的是一站式监控平台,但其背后的成功离不开各个中间件团队,特别是兄弟团队的辛勤付出和努力。这些团队的支持和协作,为监控平台的稳定运行提供了坚实的保障。
2、(货拉拉)监控团队多大?aiops那里看到了neo4j,具体是怎么用的?
我们团队大约有十个人,成员涵盖了前端、后端和全栈开发。大家具备多种技能,能够处理各种技术问题。在之前,我们考虑将应用的拓扑集成到我们的mod中,这个功能被命名为“业务大图”。通过拖拽的方式,你可以画出业务的链路,例如从下单、接单、拉货到履约的流程。这个业务大图的亮点在于,你可以将指标曲线与业务节点结合起来,从而全面了解业务的流程和关系。这对于一些场景,如异常检测、问题定位等非常有帮助。例如,当业务链条很长时,你可以快速定位哪个数据掉了,并确定问题出在哪个业务节点上。此外,HTTP或SOA调用可以自动生成应用的依赖关系,这些依赖信息也被存储起来供其他项目使用,例如架构梳理、上下游依赖治理等。这些功能也都集成在我们的一站式监控平台中,今天很遗憾没有展示这个图。
3、老师好,团队多少人?这个平台人效比咋样?
关于这个问题,我认为我们货拉拉追求的是最大化产出,希望每位团队成员都能发挥自己的最大聪明才智和努力,为用户创造更多价值。当然,我们也有一些具体的降本增效目标,例如提高研发效率、减少定位时间、降低报警比例等,这些目标是我们产品团队的重要KPI。但是,我们并不以人效作为度量标准,因为我们认为每个团队成员都非常重要,他们的努力和贡献是无法用简单的数字来衡量的。
4、(公有云上)如果出现故障,应急流程是怎样的,都有哪些团队主导或者联动了?
我们部门有一个专门的稳定性团队,这个团队主要负责日常的稳定性规章流程的治理和推广,以及7×24小时的值班。当故障发生时,监控报警系统会覆盖并触发报警,专门的团队成员会实时处理这些报警。如果确认是极为高危的事故,如业务中断或下单下跌等严重问题,他们会立即启动故障处理流程。这个流程会自动拉起一个快速响应群,包括稳定性团队成员和其他核心业务相关的负责人。然后开始执行应急分析,自动查看每个核心应用ID的报警和最近30分钟的变更事件,并将这些信息以卡片的形式推送出来。同时,还会拉起在线会议,由稳定性团队成员主导分析,进行故障定位和后续应急流程的决策。整个过程大多数都是自动化的、流程化的、体系化的。
5、metrics是如何跟trace和log进行关联的 ?
以异常曲线为例,如果观察到异常曲线上升,可以通过点击曲线上的点来查询对应的trace记录。因为trace记录中包含了关键的key和tag,例如exception或HTTP标签,可以用来查找对应时间段的采样数据。这样,用户只需点击异常曲线,就可以查看对应的链路数据。
此外,日志与异常曲线关联是因为我们在Java中间件中实现了自动日志输出带ID的功能。因此,当用户查询某个trace记录时,只需点击搜索按钮并输入ID,就可以查询到对应的日志信息。
总的来说,通过这种方式,我们可以将异常曲线与日志信息进行关联,方便用户快速定位和解决问题。
6、需要用到哪些组件?用到了哪些开源软件吗?
我们技术架构中的关键组件,如普罗米修斯和Victoria Matrix,都是基于开源的。在指标管理方面,我们基于SkyWalking的SDK进行了深度定制,对字节码注入、上报、采集和存储等环节进行了优化。为了提升性能和成本效益,我们将存储从ES+Base升级到了ES+Cos,这大大提高了数据查询的效率和响应速度。
在日志处理方面,我们简化了原有的处理流程,通过自主研发的日志组件进行数据采集,并存储到EES等系统中。虽然我们使用了许多开源的存储组件,但在增强功能、API查询以及报警机制等关键实践上,我们都是自主开发和定制的。这些定制化的解决方案使得我们的系统更加高效、灵活和稳定,能够更好地满足业务需求。
7、请问不同的云服务之间,你们数据一致性是怎么实现的?
我们目前尚未实现跨云多活或类似的架构,但未来可能会考虑。当前,我们的数据库和ES都部署在同一个云中,但我们在2022年实现了跨高可用区的部署,以确保在某个可用区出现问题时,另一个可用区仍能继续提供服务。为了解决数据一致性问题,我们可以利用阿里云的DTS或腾讯云类似的产品来实现数据同步。
8、日志告警量很大,针对日志告警是如何进行过滤、分组、降噪的?
关于日志告警量大的问题,确实是一个常见问题。我建议进一步细化报警规则或增强报警条件,以减少无效报警。为了实现这一目标,我们可以提供强大的报警规则配置功能,并引入一些升级策略。例如,除了提供阈值外,还可以提供动态基线和动态同环比等功能,以便根据业务数据配置更可靠的规则。此外,我们提供了一个重放功能,允许用户在配置报警规则后回放过去的数据,以检查是否触发了过多的报警。如果发现有过多报警,用户可以调整规则,如调整阈值或增加更多限制条件,以使规则更加灵敏。通过这些方式,可以有效减少无效报警量。
9、老师好,你们监控重点关注的性能指标有哪些?
在监控领域,我们关注的技术指标主要包括数据的吞吐量、成本以及数据的延迟等。这些技术指标直接关系到系统的性能和效率。除此之外,我们还需要关注产品层面的指标,如UV、PV以及前端页面加载时间等。这些指标能够反映用户对产品的接受度和满意度。
对于一个监控平台来说,真正的成功不仅仅是技术上的实现,更重要的是产品的易用性和用户喜爱度。以呼拉拉为例,我们的研发团队规模较大,峰值UV能达到300到400人,大约是五分之一或四分之一的研发同事在使用我们的监控平台。这说明我们的产品不仅技术上可靠,而且用户体验良好,得到了团队的认可。
因此,除了技术指标外,我们建议在产品体验和功能上提出更高的要求,以满足用户的需求和期望。只有综合考虑技术实现和用户体验,才能打造出真正成功的产品。
10、为什么没有用到OpenTelemetry呢?后续有计划么?还是感觉用不上
我非常关注相关的组件,并且赞同其中的理念。但是,当我来到货拉拉这边时,整个普罗米修斯的生态已经铺开,因此没有强制进行技术转型。我们会持续关注普罗米修斯等组件的进展,如果有明显的替换可能性或者兼容的必要性,我们会考虑将其作为一个新的数据源或采集方式兼容进来。目前,我们不仅支持普罗米修斯,未来还会支持MySQL等其他数据源。
11、你们的java中间件埋点主要埋哪些信息?
还是比较多的。大家可以回看monitor的整体架构图 。监控的中间件种类繁多,像是主流的中间件,包括Easy Open、Spring、Spring Boot等,以及底层的一些组件,例如Kafka等,我们都已经支持。这些支持都得益于SkyWalking提供的强大插件机制,让我们能够站在巨人的肩膀上,实现对这些主流中间件的自动采集。
12、做监控平台如何衡量ROI,更好的去立项?
关于度量ROI,我认为可以从两个方面来看。首先是数据层面,有很多度量的角度,例如成本。在呼拉拉,我们非常关注成本,尤其是业务增长时,技术成本的增加量应该尽量小,增加的比例要小于业务增长的比例。这是为了体现技术的规模效应。
以我们最近做的存储架构选型为例,我们的目标是尽量在成本不增加的情况下,提升存储时间和相关性能指标。比如,我们将存储方案从每月8万的ES成本降低到了每月2万,同时提供了更多的功能,如研发人员可以配置报警和看板等。这是成本方面的一个显著提升。
另一个角度是感觉层面。有时候,为了提升用户体验或稳定性,可能需要投入一些额外的成本。这时,我们需要坚定方向,并争取得到老板的支持,进行架构升级和改造。面对直接的或强制的ROI压力,我们可以动之以情,晓之以理,告诉他们不要只看短期的ROI,而要看到更长远的目标。
总的来说,度量ROI需要综合考虑数据和感觉两个方面。通过合理的成本投入和架构升级,我们可以实现更好的技术规模效应和用户体验,为公司创造更大的价值。
本文来自投稿,不代表TakinTalks稳定性技术交流平台立场,如若转载,请联系原作者。