概述
本文内容适合关注性能监控领域、使用过 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:错误链路强制采用。更详细配置:
https://skywalking.apache.org/docs/main/latest/en/setup/backend/trace-sampling/
亮点:单独做了 Slow SQL sampling 数据库慢查询的采样配置。
https://skywalking.apache.org/docs/main/v8.5.0/en/setup/backend/slow-db-statement/
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 做了一些重要更新:(https://github.com/DataDog/dd-trace-java/releases)
亮点
开源的 skywalking、商业的 Datadog 在主流的组件监控支持上下了功夫,而且对云原生上 Kubernetes 容器和 Istio 也成熟运用到生产环境,这是大部分其他 APM 产品没有做到的。
推荐
从这些方面看,如果你的业务系统不是主流的 APM 监控对象,比如采用.Net 语言开发,或者用到了 SAP 公司的 IT 系统,那么你考虑的最重要优先级是哪些 APM 能真正支持。
另一方面,如果你的业务系统用到了最新的一些组件版本或者语言框架,比如 Java 用了最新版本,那很多开源 APM 是没有去迭代更新的。
总结
毕竟商业端的 APM 有更多技术储备,和专注能力去兼容更多的组件。当然在生产环境,一些公司用了开源,借助本身技术能力,采用自研方式,做了一些个性化监控的技术方案。到底是开源还是商业,根本上看性价比的。如果你确实自研不了,开源也不能支持公司某些核心组件,那考虑商业 APM 产品是一种选择。
五、告警管理能力
告警管理提供了可靠的告警收敛、通知,帮助业务系统快速检测和修复业务告警。告警管理从功能维度上,包含基本功能:添加监控事件、配置告警、告警推送。
在实际生产环境中,一方面业务系统往往十分复杂,服务众多,简单的一个个添加监控事件,会导致运维工作量骤增;另一方面,业务告警不光要及时推送,也需要提供足够丰富的报警数据和友好可视化的展示,让 IT 人员能够快速定位问题和修复故障。
从这些维度来看,很多 APM 提供了告警高级功能:告警模板,配置告警自动化,更友好的告警界面。下面我们看看主流 APM 具体对告警支持:
Skywalking:告警通过脚本配置:
https://github.com/apache/skywalking/blob/master/docs/en/setup/backend/backend-alarm.md
Skywalking 的报警界面不太友好,查看报警和添加报警事件比较麻烦。不过 Skywalking 告警消息推送源比较丰富,比如飞书、钉钉、Slack ,还开放告警 hook,这样开发者基于自定义更多告警推动源。
Pinpoint:基本告警模板库、做了告警消息简单分组,但是不开放自定义告警源,有简单模板。
比起开源 APM,商业化 APM 告警高级功能算是比较强了。
我们看看 Datadog、阿里云 ARMS 的高级功能:
告警模板库:丰富的告警模板,不用自己手动创建。
监控配置更加自动化:比如下面对 Mysql 告警,通过灵活的监控阀值和指标配置,可以很快速和实用做到监控。这个比起纯脚本方式,极大节约了系统运维的工作量。当然,要提供这样的高级功能,对 APM 产品开发投入也是很大的。
友好的告警大屏:覆盖整个 IT 系统的告警状况,通过钻取查看具体某项服务。
相比于商业的 APM 才能具备高级功能,开源产品限于资源有限,很难把告警能够做到如此。目前,从开源上能够把告警做得这样接近的,可以看看国内的专门做监控报警的夜莺团队,开源监控产品 Nightingale,原来 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 则完全不支持:
https://github.com/pinpoint-apm/pinpoint-kubernetes/issues
Skywalking: 在 Kubernetes、Istio 方面可观测的支持非常成熟。
这是 Skywalking 的一大亮点,而且 Skywalking 已经支持了一段时间,趟过很多坑。
比如之前在生产环境,对于 Istio 本身的性能缺陷,Skywalking 做了很多优化;再比如说 Skywalking 从 Istio 性能很差的 Mixer 方案逐渐迁移到 Envoy 的 Access Log Service,解决了服务网格观察的性能瓶颈。更多内容请参考这篇干货:
https://www.tetrate.io/blog/observe-service-mesh-with-skywalking-and-envoy-access-log-service/
Datadog:对 Kubernetes、Istio 的支持可以说是很强悍了。
比如支持灵活的日志过滤管理,可以优化 Kubernetes 下日志的采集策略
https://docs.datadoghq.com/agent/logs/advanced_log_collection/?tab=kubernetes#filter-logs
Datadog 基于 Pod 去管理容器节点的链路追踪,可以支持 name, image, or kube_namespace 这些粒度管理,可谓相当通用。
Datadog 对 Istio 也有丰富的支持,暴露了很多 Envoy 监控指标:
https://docs.datadoghq.com/integrations/envoy/?tab=host#log-collection
八、社区和文档支持
技术文档
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 中国社区发起人,https://github.com/open-telemetry/docs-cn 核心维护者
欢迎大家关注“OpenTelemetry”公众号,这是中国区唯一官方技术公众号。
评论 2 条评论