应用监控的选型思考

简介: 最近由于项目的缘故,经常会和同学们聊到一个话题,那就是企业如何在应用性能管理(Application Performance Monitoring, 简称APM) 领域的开源和商业化产品中选择合适自己的产品,下面就以该领域为例和大家做一个分享。

阿里云应用实时监控和诊断工具 ARMS,点击这里

最近由于项目的缘故,经常会和同学们聊到一个话题,那就是企业如何在应用性能管理(Application Performance Monitoring, 简称APM) 领域的开源和商业化产品中选择合适自己的产品,下面就以该领域为例和大家做一个分享。

先说结论:没有统一答案,企业用户应当从自身需求,技术掌握深度,建设成本这三个方面来衡量。

企业性质和最终方案

技术掌握程度

自身需求

建设成本

世界500强的IT部门, 最终选择商业产品,部署方式为专用云 已经被各大APM厂商进行过POC,接口人对APM领域有一定理解;已经在内部进行过多轮DevOps概念推广和相关环境建设。 1.配合压测调优性能;2.能快速推广和应用到全集团;3.集团大屏幕输出;4.日常运维中的问题报警,排查,诊断。 1.产品费用+咨询费用;2.每年的产品升级和维护费用;3.2名甲方接口人员;4.内部机器成本。最大并发监控规模:万台。平均每台活跃实例/年监控成本在4000元左右。
数千人的中型互联网公司,最终选择基于 pinpoint 自建 负责人为多年从事APM领域的资深专家,并有从原来APM厂商转来的Pinpoint Commiter,正在进行DevOps建设。 日常运维中的问题报警,排查,诊断为主。 1.4名开发人员至少一年的开发维护时间。2.2名运维人员的日常维护和推广。3.内部机器成本。最大并发监控规模:千台。平均每台活跃实例/年监控成本在2000元左右。
数十人的创业团队,最终选择公有云商业产品 对APM领域,仅仅是听过几场meet up,以业务开发为重心。 日常运维中的问题报警,排查,诊断为主。 公有云产品费用,根据业务量,灵活扩缩容。最大并发监控规模:数十台。平均每台活跃实例/年监控成本在1000元左右。

产品完成度&使用场景

上面是三个不同企业规模中APM使用的一个大致情况以及他们的选型和成本情况。当把需求落到具体使用场景上时,商业化产品和开源产品在完成度上,其实也有很多区别:

使用场景

商业化产品-以阿里云ARMS为例

开源产品--以Pinpoint和Skywalking为例

报警和报表:作为日常运维工具,报警功能必不可少。在日常巡检中,需要把关键信息放在一个页面中形成报表,并且对报表定时进行推送。 支持丰富维度的数据报警设置,以及丰富的推送渠道,包括钉钉,短信,邮件等。支持用户自定义设置各种业务报表。 支持简单的报警功能,大部分情况下需要用户额外进行开发和集成。
用户反馈问题跟踪:能根据某一个业务关键ID 查询出对应的分布式调用链路和相关的log。 支持全系排查和100%链路采集。 不支持。
代码瓶颈诊断:发现问题以后,需要快速定位到代码性能瓶颈。 无需额外的埋点,自动适配大部分主流框架,支持自定义埋点。单线程快照技术,能监控到没有埋点的业务代码的运行情况。 无需额外埋点,支持自定义埋点。
稳定性&可拓展性。 经过多年那双十一挑战,产品性能稳定。SaaS产品动态扩缩绒,无需用户关心。 开源项目未经过大规模生产环境检验,需要用户自己进行稳定性的测试,以及根据数据量进行扩缩容量。
使用咨询。 5*8阿里云专家咨询服务:可针对性输出阿里云多年性能调优经验和使用场景,帮助用户快速落地APM产品。 Github issue为主无商业化公司支持,出现问题大部分自己解决。
定制化能力。 支持通过API定制自己的展示页面。 开源产品,可以进行任意改动。

成本计算参考

以阿里云 ARMS 为例,假设监控50个实例,估算下成本:

  • 机器成本:至少7台机器 (3台存储,2台应用,2台Console)+数据库,成本一个月四千以上;用ARMS,费用小于4000左右,成本略低于自建,几乎持平。
  • 运维人力成本:ARMS无需担心扩扩容,用多少付多少,ARMS无需运维工程师,节省人力开支。用以上开源软件至少需要一个专业的运维工程师,中位数工资,约10000左右。
  • 额外开发人力成本:ARMS作为商业产品,每月发布一个新的版本,不断迭代,而且功能丰富。使用开源产品需要自己开发报警和相关运维功能,至少需要2个专业的开发工程师,中位数工资,约40000左右。

总结

在当今互联网云时代,企业在选择建设自己监控系统的时候,一定要结合自身情况进行产品和架构选型,具体建议如下:

公司形态 用户画像 建议选型
小型初创公司 以公司生存,业务发展为主,需要快速见效并且性价比高的产品。 以公有云Saas为主,不建议投入过多精力在监控领域的开源自建,而需要专注于核心业务发展。
中型成长企业 有较稳健业务收入和增长,希望对于技术有所发展和挑战。 商业产品+开源产品,可以通过商业产品快速学习某一领域知识,再结合自身情况通过开源产品定制部分监控,如采用grafana定制监控大盘。
大型上市公司 有自建机房,业务求稳,而且在国内外有较强监管和合规需求。 考虑采用专有云和混合云的商业化服务为主,可以配合厂商尝试开源产品,部分科技型公司可选型开源产品。
相关文章
|
6月前
|
存储 监控 Cloud Native
阿里性能监控引擎建设之路
阿里巴巴智能引擎事业部自研的 Khronos 系统是阿里内部接入规模最大的性能数据存储引擎。Khronos 支持动态生命周期的存储计算分离架构,采用 schemaless 的 data model 设计,在万亿数据规模下为业务提供易用、高效、经济的服务,团队近期的优化工作也被国际学术会议CIKM2023收录。本⽂总结了Khronos 在性能监控领域遇到的技术挑战,以及在这个场景下的一些价值判断。
|
存储 数据采集 Prometheus
监控系统选型,一篇全搞定!
监控系统选型,一篇全搞定!
|
Prometheus 运维 监控
无监控,不运维!深入浅出介绍ChengYing监控设计和使用
监控系统俗称「第三只眼」,几乎是我们每天都会打交道的系统,它也一直是IT系统中的核心组成部分,负责问题的发现以及辅助性的定位。 ChengYing作为一站式全自动化全生命周期大数据平台运维管家,自然也提供大数据产品的监控服务。这篇文章,将为大家系统性地介绍ChengYing监控的设计和使用,带大家进一步了解ChengYing。
258 0
无监控,不运维!深入浅出介绍ChengYing监控设计和使用
|
监控 NoSQL 数据库
企业级解决方案-性能指标监控|学习笔记
快速学习企业级解决方案-性能指标监控
149 0
企业级解决方案-性能指标监控|学习笔记
|
存储 缓存 Prometheus
企业级解决方案-性能指标监控命令|学习笔记
快速学习企业级解决方案-性能指标监控命令
58 0
企业级解决方案-性能指标监控命令|学习笔记
|
消息中间件 运维 Kubernetes
Sentry(v20.12.1) K8S云原生架构探索,玩转前/后端监控与事件日志大数据分析,高性能高可用+可扩展可伸缩集群部署
Sentry(v20.12.1) K8S云原生架构探索,玩转前/后端监控与事件日志大数据分析,高性能高可用+可扩展可伸缩集群部署
874 0
Sentry(v20.12.1) K8S云原生架构探索,玩转前/后端监控与事件日志大数据分析,高性能高可用+可扩展可伸缩集群部署
|
存储 监控 前端开发
APM 组件选型
常用监控手段: 按监控层次分:业务监控、应用监控和基础监控等; 按监控日志来源分:基于日志文件监控、基于数据库监控和基于网络监控等; 按监控领域分:前端监控、后端监控、全链路监控、业务间监控等; 按监控目标分:系统故障监控、业务指标监控、应用性能监控、用户行为监控、安全合规监控等。
APM 组件选型
|
监控 BI
从0到1,搭建数据监控体系
大家好,我是爱学习的小熊妹。 上周五,阳光很好,微风很好,无惊无险又到六点,小xiong熊妹美美地在座位上补了个妆,拿起小包包,正打算去撸麻辣火锅的时候,听到了最怕听到的话—— 小熊妹,麻烦给个数,领导马上就要看…… 我整个人顿时就不好了!我的火锅,我的小伙伴,我的奶茶,我的电影!
348 0
从0到1,搭建数据监控体系
|
存储 Prometheus 监控
在微服务架构下基于 Prometheus 构建一体化监控平台的最佳实践
个人认为将来可观测性一定是标准化且由开源驱动的。现在整个软件架构体系变得越来越复杂,我们要监控的对象越来越多,场景也越来越广。封闭的单一厂商很难面面俱到的去实现全局可观测能力,需要社区生态共同参与,用开放、标准的方法来构建云原生可观测性。
584 0
在微服务架构下基于 Prometheus 构建一体化监控平台的最佳实践
|
弹性计算 监控 数据可视化
构建完整的性能压测体系及工具选型
本文作者: 殷成涛(花名:风起),阿里云PTS开发工程师,专注于性能压测与高可用架构领域 本文致力于给出性能压测的概念与背景介绍,同时针对市场上的一些性能压测工具,给出相应的对比,从而帮助大家更好地针对自身需求实现性能压测。
230 0
构建完整的性能压测体系及工具选型