海量监控数据处理之道（一）：APM指标计算优化

作者：熊彪，腾讯云监控高级工程师

前言

腾讯云应用性能观测（APM）是一款应用性能管理产品，基于实时的多语言应用探针全量采集技术，为用户提供分布式应用性能分析和故障自检能力。本文主要讲述了 APM 链路指标计算场景下，性能优化提升若干方案。通过上述方案，将 APM 指标计算的整体性能提升了 2-3 倍效果。

什么是 APM 指标计算?

应用性能观测（APM）上报的原始数据是一个一个的链路 Span，要计算服务的错误率、平均响应时间、Apdex 等指标，需要将原始链路 Span 转换为相关的指标数据，再通过 Flink 流计算按一分钟窗口聚合出相关指标具体值。上述的过程称作 APM 指标计算。

名词解释：

自研高性能指标计算中台 —— Barad

应用性能监控 —— APM

腾讯云 Flink 计算资源-1核 CPU —— 1CU

海量数据上报面临的挑战

APM 现阶段随着业务接入的增长，上报流量也在不停的创造新的流量洪峰，某个地域最新的峰值流量已达到了数亿/分钟。跟随着上报调用链路数据的增长，指标计算消耗 Flink 资源也在不停的飙升。在不考虑成本情况下， Flink 作业资源若是能够支持不停的横向扩展，事情也有回转的余地，但让人沮丧的是当 Flink 作业的资源达到某 CU 值 的时候，就达到了瓶颈点——导致作业的稳定性会变得极差。那么我们该如何去解决指标计算 Flink 所面临的性能压力的挑战? 并提升系统整体的稳定性？

我们该如何去解决指标计算 Flink 所面临的性能压力的挑战? 并提升系统整体的稳定性？接下来，我们将一一剖析问题的根因。

提升稳定性:拆分作业

1. 为什么扩容了还是高负载?

指标计算的 Flink 作业已经在 Barad 基础指标计算业务运行的很平稳，相同的程序迁移到 APM 指标计算为什么就变得这么不稳定，且资源已经扩容了，为什么 CPU 负载还这么高? 先让我们来看一下 Flink 失败日志信息，截图如下所示: