概述
本文内容适合关注性能监控领域、使用过 apm，或对性能问题也有一定了解的朋友
apm：application performance monitor，即应用性能监控。主要是为了对企业核心业务系统进行性能上的故障定位和处理，帮助优化性能，提高业务系统的可靠性，优化用户体验。
我们用一张图描述下 apm 在系统稳定性保障的位置：
目前 apm 开源、商业化产品比较成熟，大部分公司生产环境都部署了 apm 系统。本文将从主流 apm 产品介绍出发，透过生产环境中关注的几个重要维度，给到大家一些适合自身公司场景的 apm 选型方案建议。
一、主流竞品概述
先带大家大致回顾下目前国内、外都有哪些比较有口碑和市场占有率的 apm 监控产品：
除上面提及产品 ，市面上还有譬如：开源 zipkin、dynatrace、国内的 oneapm，博睿等。限于篇幅和个人了解程度，本文不做对比。我主要收录的判定维度：
产品体验：侧重生产环境的 apm 功能上易用性、实用性，个人喜好程度；
数据采样：很多 apm 在生产环境中收集链路数据过多，会遇到很多性能问题。特别大型分布式系统中，apm 采样能力、存储能力决定 apm 的靠谱程度；
agent 观察：从 agent 的技术生态、支持组件、开发语言能力。可能很多公司生产系统在这个维度就已经做了 apm 的选型了。比如你是.net 业务系统，上面提到一大半压根不支持；
报警 db 支持：预警、告警的能力、对调用链路中最典型数据库的支持能力；
对云原生的支持能力：在 kubernetes 和 istio 生产环境的成熟度，这个门槛也排除了很多 apm , 特别是一些开源产品，在这方面普遍做得不理想；
数据大屏：题外话，数据大屏，是公司希望在监控系统中，更多地展示业务监控的产品诉求体现；
社区和文档支持：产品对应的技术社区成熟度和产品文档的质量；
其它：日志、数据大屏，自检，存储能力。限于优先级和本文篇幅，以后可以做更多相关分享，在此不多做介绍；
接下来从这几个方面一一深度分析。
二、产品体验
核心功能：业务链路图、链路追踪分析
亮点：pinpoint 的 监控链路视图在实际使用中用的比较顺手。
推荐理由：业务链路图更直观、链路追踪分析更懂业务
业务链路拓扑图
pinpoint 链路分析指标丰富、从拓扑图钻取详细链路体验更高效。
详细链路 trace
备注：一般成熟的 apm，考虑到数据库核心场景，在调用链中，一般支持 sql 传参完整显示。
三、数据采样
调用链数据总体体量与业务体量正相关，全量采集调用链数据将会给公司系统整体带来两方面压力：
因数据上报造成的每个业务服务的网络 i/o 压力
因数据采集、分析造成的调用链追踪服务的计算和存储压力
为了降低这两方面压力，采样是大多数调用链追踪系统的必备模块。实践中常用的采用策略可以分为三类：
头部连贯采样：head-based coherent sampling
尾部连贯采样：tail-based coherent sampling
单元采样：unitary sampling
目前应用最广泛的采样策略主要是尾部采样，下面是它们基本原理图：
skywalking：采样机制成熟，做在 server-side，能够支持简单的采样百分比 sample rate 配置，允许 forcesampleerrorsegment：错误链路强制采用。更详细配置：
亮点：单独做了 slow sql sampling 数据库慢查询的采样配置。
pinpoint：基本采样，支持百分比采样 percent 和 简单的总数采样 counting。
jaeger：依赖于 opentelemetry 底层实现，支持尾部采样，异常采样，过滤规则采样等。
datadog 、腾讯云、阿里 arms：apm 都有基本采样，采样支持策略也非常丰富。
亮点：还进一步支持丰富的 db、rum(前端采样)，如下方图片所示，可以简单看一个腾讯云下面 apm 采样配置。
四、agent 能力
考虑我们业务系统在不同语言开发、不同操作环境下运行。而且，随着云原生和微服务的发展，现在业务系统也逐步部署在容器和服务网格中。这增加了 apm 产品的技术难度，实际情况：很多 apm 都支持不了所有场景，只能 case by case 考量。
因为 apm 普遍通过 agent 方式采集链路数据。如果要看 apm 产品是否支持你的业务系统，最直接方式看 agent 端实现能力了。
agent 开发生态现状
开源产品
pinpoint：虽然国内 java 系统有一定使用量。但是 pinpoint 探针升级慢，最近快半年没有升级。最新 java 主流中间件很多不支持，对于 kubernetes、istio 还支持不了。
skywalking：平均两个月一个周期。主要支持 java 主流中间件版本升级、它对 kubenetes、istio 成熟的支持，迭代兼容不同最新版本。python，go 也开始做了支持。
商业产品
阿里云，腾讯云 apm，美国 datadog ：每周更新。为什么更新如此频繁？它们依托技术团队，去覆盖更多的组件、开发语言的系统。当然，这也是技术平台公司的定位。
我总结的最近一个月，datadog agent 做了一些重要更新：（）
亮点
开源的 skywalking、商业的 datadog 在主流的组件监控支持上下了功夫，而且对云原生上 kubernetes 容器和 istio 也成熟运用到生产环境，这是大部分其他 apm 产品没有做到的。
推荐
从这些方面看，如果你的业务系统不是主流的 apm 监控对象，比如采用.net 语言开发，或者用到了 sap 公司的 it 系统，那么你考虑的最重要优先级是哪些 apm 能真正支持。
另一方面，如果你的业务系统用到了最新的一些组件版本或者语言框架，比如 java 用了最新版本，那很多开源 apm 是没有去迭代更新的。
总结
毕竟商业端的 apm 有更多技术储备，和专注能力去兼容更多的组件。当然在生产环境，一些公司用了开源，借助本身技术能力，采用自研方式，做了一些个性化监控的技术方案。到底是开源还是商业，根本上看性价比的。如果你确实自研不了，开源也不能支持公司某些核心组件，那考虑商业 apm 产品是一种选择。
五、告警管理能力
告警管理提供了可靠的告警收敛、通知，帮助业务系统快速检测和修复业务告警。告警管理从功能维度上，包含基本功能：添加监控事件、配置告警、告警推送。
在实际生产环境中，一方面业务系统往往十分复杂，服务众多，简单的一个个添加监控事件，会导致运维工作量骤增；另一方面，业务告警不光要及时推送，也需要提供足够丰富的报警数据和友好可视化的展示，让 it 人员能够快速定位问题和修复故障。
从这些维度来看，很多 apm 提供了告警高级功能：告警模板，配置告警自动化，更友好的告警界面。下面我们看看主流 apm 具体对告警支持：
skywalking：告警通过脚本配置：
skywalking 的报警界面不太友好，查看报警和添加报警事件比较麻烦。不过 skywalking 告警消息推送源比较丰富，比如飞书、钉钉、slack ，还开放告警 hook，这样开发者基于自定义更多告警推动源。
pinpoint：基本告警模板库、做了告警消息简单分组，但是不开放自定义告警源，有简单模板。
比起开源 apm，商业化 apm 告警高级功能算是比较强了。
我们看看 datadog、阿里云 arms 的高级功能：
告警模板库：丰富的告警模板，不用自己手动创建。
监控配置更加自动化：比如下面对 mysql 告警，通过灵活的监控阀值和指标配置，可以很快速和实用做到监控。这个比起纯脚本方式，极大节约了系统运维的工作量。当然，要提供这样的高级功能，对 apm 产品开发投入也是很大的。
友好的告警大屏：覆盖整个 it 系统的告警状况，通过钻取查看具体某项服务。
相比于商业的 apm 才能具备高级功能，开源产品限于资源有限，很难把告警能够做到如此。目前，从开源上能够把告警做得这样接近的，可以看看国内的专门做监控报警的夜莺团队，开源监控产品 ，原来 open-falcon 的前身。在国内也是有众多的拥护者。
总结
告警管理对于 apm 来说，是一个相对重要的功能，尽管商业 apm 远好于开源产品，但毕竟需要付费。所以大家在实际项目中做选型，要看看公司业务系统对这些高级功能的迫切性和投入价值。当然，也确实有一些公司在开源的基础上，自研了这些高级功能。
六、对 db 的支持
数据库是业务系统里面非常核心组件，生产环境常常可能因为数据库的承载能力不足，而出现性能问题，最常见的例子就是慢查询。
通过 apm 可以看到完整慢查询 sql 语句和耗时，也可以做慢查询和其他数据库异常指标告警，快速定位数据库性能故障。数据库支持实用度体现在两个方面：
sql 调用链传参完整显示，比如 skywalking，通过配置，看到的 完整 sql：
推荐
刚才提到的两个核心维度，有的 apm 会有不支持的情况：各种数据库比较多，要看具体说明。
整体来说，db 监控友好性还是体现在细节方面，比如有些 apm 提供图形化界面，动态配置慢查询和报警，的确大大便利了运维人员的使用。
所以，在生产环境下，使用 apm 对 db 进行监控，更多考虑的是效率问题。而在一般场景，pinpoint、skywalking 足够用了。
七、对 kubernetes 和 istio 的支持
对于 kubernetes、istio 的价值，本文中不再赘述，在实际生产环境中，能真正支持好 kubernetes、istio 的 apm 确实不多，很多过去主流的 apm 都不支持，甚至包括一些商业的 apm 产品。
pinpoint: 目前最新开始支持 kubernetes，不过到不了生产环境。istio 则完全不支持：
skywalking: 在 kubernetes、istio 方面可观测的支持非常成熟。
这是 skywalking 的一大亮点，而且 skywalking 已经支持了一段时间，趟过很多坑。
比如之前在生产环境，对于 istio 本身的性能缺陷，skywalking 做了很多优化；再比如说 skywalking 从 istio 性能很差的 mixer 方案逐渐迁移到 envoy 的 access log service，解决了服务网格观察的性能瓶颈。更多内容请参考这篇干货：
datadog：对 kubernetes、istio 的支持可以说是很强悍了。
比如支持灵活的日志过滤管理，可以优化 kubernetes 下日志的采集策略
datadog 基于 pod 去管理容器节点的链路追踪，可以支持 name, image, or kube_namespace 这些粒度管理，可谓相当通用。
datadog 对 istio 也有丰富的支持，暴露了很多 envoy 监控指标：
八、社区和文档支持
技术文档
skywalking、datadog、arms 文档非常完整丰富，同时在网上搜索一些问题，都能找到合适的金马国际的解决方案，这对于维护者来说是非常有价值的。好的产品文档，也有助于我们了解产品的内部运行原理。
不过 arms 文档显得比较凌乱，毕竟它是很多团队，不同子系统集成而来，略微臃肿。像 skywalking 这样的开源产品做了一些 apm 技术布道，关于链路追踪技术，网上的很多文章都来自于他们，这是开源社区的一些贡献。
推荐总结：要上生产环境，我们往往希望系统是可控的，完善、成熟的技术文档对于选型来说，是一个很基本的要求。开源还有一个额外的好处，就是代码的开放性，不用担心黑盒的情况存在。如果团队技术能力足够强，也能自己 fix 问题。
社区生态
开源产品一大优势在于开放性，主要体现社区和金马国际的技术支持上。 比如 skywalking、opentelemetry、pinpoint 国内都有活跃的社群：
skywalking 技术社群
大家在社群上寻求帮助和交流产品问题，而且社群上都有核心的开源负责人答疑解惑，这本身也是一种强大的金马国际的技术支持。而且，社群中包含了很多生产环境的碎片化的实践内容，如果遇到相似的难题和坑，也可以寻求到答案。
在这个维度上，商业化产品就显得比较闭塞了。
金马国际的技术支持
开源产品，本身自带社区属性，遇到技术问题寻求支持时，整体流程会更高效，但是解决问题速度和反馈因不同团队的精力而异。目前在主流 apm 社区中， skywalking 、pinpoint 国内比较活跃， 在国外 opentelemetry 显得更活跃。
在商业 apm 里，datadog 借助 slack 方式金马国际的技术支持做得特别好：既有技术内容沉淀，对使用者更友好。
datadog 技术社区
总结
我从几个重要维度对比了主流的 apm 产品，也提到一些实际场景下的选型建议。
在过去的生产环境下，我曾参与过 apm 产品自研，也曾把开源、商业 apm 部署在业务系统。其实，刨根究底，关于 apm 产品如何选型的问题，其核心就是追逐性价比：每个公司 it 系统既有通用性，也有其自身业务特性。而且，系统有大有小，团队对 apm 技术把控能力也不尽相同。采用哪一种 apm 方案要考虑是否是当前最合理的方案，而不是最完美的方案。也许，很多复杂的功能并非你想要的。
希望我的分享能帮助你，也欢迎大家留言提问。
作者介绍
蒋志伟，爱好技术的架构师，先后就职于阿里、qunar、美团，前 pmcaff.com cto，目前 opentelemetry 中国社区发起人， 核心维护者
欢迎大家关注“opentelemetry”公众号，这是中国区唯一官方技术公众号。
评论 2 条评论