适配多云环境,货拉拉智能监控平台的设计与实践

如何获得讲师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需要综合考虑数据和感觉两个方面。通过合理的成本投入和架构升级，我们可以实现更好的技术规模效应和用户体验，为公司创造更大的价值。