应用监控的选型思考

简介: 最近由于项目的缘故,经常会和同学们聊到一个话题,那就是企业如何在应用性能管理(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定制监控大盘。
大型上市公司 有自建机房,业务求稳,而且在国内外有较强监管和合规需求。 考虑采用专有云和混合云的商业化服务为主,可以配合厂商尝试开源产品,部分科技型公司可选型开源产品。
相关实践学习
通过轻量消息队列(原MNS)主题HTTP订阅+ARMS实现自定义数据多渠道告警
本场景将自定义告警信息同时分发至多个通知渠道的需求,例如短信、电子邮件及钉钉群组等。通过采用轻量消息队列(原 MNS)的主题模型的HTTP订阅方式,并结合应用实时监控服务提供的自定义集成能力,使得您能够以简便的配置方式实现上述多渠道同步通知的功能。
相关文章
|
存储 Prometheus Kubernetes
OpenTelemetry 简析
OpenTelemetry 是 CNCF 的一个可观测性项目,旨在提供可观测性领域的标准化方案,解决观测数据的数据模型、采集、处理、导出等的标准化问题,提供与三方 vendor 无关的服务。 2021.02.10,OpenTelemetry 的 tracing spec 达到 1.0 版本 (link),基于这个里程碑,笔者对 OpenTelemetry 进行了探索,判断在可观测性领域带来的价值和发展前景。 下面给出笔者对 OpenTelemetry 的理解,抛砖引玉。由于笔者能力有限,理解不当的地方请大家指正。
OpenTelemetry 简析
|
安全 Windows
Windows提权/杀软进程在线对比
Windows提权/杀软进程在线对比
617 0
Windows提权/杀软进程在线对比
|
机器学习/深度学习 并行计算 调度
构建高效GPU算力平台:挑战、策略与未来展望
【8月更文第5天】随着深度学习、高性能计算和大数据分析等领域的快速发展,GPU(图形处理器)因其强大的并行计算能力和浮点运算速度而成为首选的计算平台。然而,随着模型规模的增长和技术的进步,构建高效稳定的GPU算力平台面临着新的挑战。本文旨在探讨这些挑战、应对策略以及对未来发展的展望。
811 1
|
运维 监控 Devops
基础设施即代码(IaC):自动化运维的新纪元
【6月更文挑战第21天】基础设施即代码(IaC)是将基础设施配置转为代码,实现自动化和标准化运维的实践。它通过文本文件描述基础设施,保证重复性、一致性和自动化部署。IaC提升效率,降低成本,加速产品上市,增强安全性和可移植性,在配置管理、环境管理、CI/CD及监控告警中发挥关键作用,推动DevOps和云时代的创新。
|
负载均衡 算法 应用服务中间件
Nginx的Fair算法:配置与原理
Nginx的Fair算法:配置与原理
312 0
|
消息中间件 Oracle 关系型数据库
Flink CDC (Change Data Capture)
Flink CDC (Change Data Capture) 是一种基于 Flink 的流式数据处理技术,用于捕获数据源的变化,并将变化发送到下游系统。Flink CDC 可以将数据源的变化转换为流式数据,并实时地将数据流发送到下游系统,以便下游系统及时处理这些变化。
828 1
|
负载均衡 应用服务中间件 nginx
nginx这种负载均衡模式,你用过吗
nginx这种负载均衡模式,你用过吗
216 0
|
存储 安全 Unix
Restic文件备份工具
Restic文件备份工具
1477 0
|
监控 Java 双11
重试利器之Guava Retrying
重试利器之Guava Retrying
710 0
重试利器之Guava Retrying
|
前端开发 Java 关系型数据库
Spring Boot开发的导师管理系统,可做毕设,增加项目经验
Spring Boot开发的导师管理系统,可做毕设,增加项目经验
485 0
Spring Boot开发的导师管理系统,可做毕设,增加项目经验