应用监控的选型思考

简介: 最近由于项目的缘故,经常会和同学们聊到一个话题,那就是企业如何在应用性能管理(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订阅方式,并结合应用实时监控服务提供的自定义集成能力,使得您能够以简便的配置方式实现上述多渠道同步通知的功能。
相关文章
|
缓存 NoSQL Redis
Redis高并发场景下秒杀超卖解决
Redis高并发场景下秒杀超卖解决
894 0
|
3月前
|
存储 SQL 人工智能
数据语义层 vs 宽表模式:哪种架构更适合 AI 时代的数据分析?
用户零等待指标交付,逻辑变更分钟级生效,无需 ETL;100%一致口径,所有人与 AI 通过同一语义层访问数据;无缝对接 AI,语义层为 AI 提供标准化查询 API。
|
18天前
|
SQL 人工智能 BI
AI + Data中的 Semantic View:从语义层到 AI 可用的“业务语言”
本文面向数据平台/数仓/湖仓架构师等角色,深入解析AI时代数据平台的刚需——Semantic View(语义视图)。它并非普通SQL视图,而是将业务指标、维度、关系、口径规则等结构化沉淀为可治理、可复用、AI-ready的平台级资产,统一BI、Notebook与Agent的数据“真相接口”,解决多工具口径不一、LLM幻觉、治理难落地等核心痛点。(239字)
270 0
|
数据采集 人工智能 算法
头一回见!提升10倍效率,阿里给业务校验平台插上了AI的翅膀
实时业务校验平台作为阿里集团老牌的业务审计系统,覆盖了集团绝大部分的业务对账场景,在线上问题及时发现以及减少集团资损上发挥着巨大作用,保障了各个系统的业务稳定性。本文主要介绍实时业务校验平台(以下简称BCP: Business Check Platform)在智能化方面的创新和实践。
17856 101
安装并使用labelImg标注数据集,yolo,VOC格式
安装并使用labelImg标注数据集,yolo,VOC格式
981 0
|
测试技术 监控 弹性计算
阿里巴巴在应用性能测试场景设计和实现上的实践
提升性能前,先测试摸个底,找到性能瓶颈。 测试前,先设计好应用性能的测试场景,并实现它。 本文是《Performance Test Together》(简称PTT)系列专题分享的第5期,该专题将从性能压测的设计、实现、执行、监控、问题定位和分析、应用场景等多个纬度对性能压测的全过程进行拆解,以帮助大家构建完整的性能压测的理论体系,并提供有例可依的实战。
9747 99
|
Dubbo Java 应用服务中间件
微服务技术栈选型,看了这个别的可以不用看了
本文由PPmoney架构师敖小剑分享:微服务的核心技术,目前可选的开源微服务框架,以及为微服务提供支撑的基础设施。
18269 136
|
Windows
FL Studio21中文版本下载及切换中文语言教程
1、FL Studio 20.8版本开始才支持简体中文,早于20.8的版本没有官方中文版。 2、中文版建议使用Win10系统电脑,win7系统上目前可能会出现乱码。 FL Studio 20.8版本安装后默认还是英文,需要我们手动切换一下软件语言:
994 0
|
算法
闲鱼技术2022年度白皮书-服务端主题-互动抽奖背后的随机性与算法实现(下)
闲鱼技术2022年度白皮书-服务端主题-互动抽奖背后的随机性与算法实现
844 0
|
人工智能 大数据 数据库
【直播回顾&资料下载】2017阿里巴巴双11技术十二讲,历数双11精彩技术干货
2017阿里巴巴双11技术十二讲,在线技术峰会演讲内容整理及回顾。
27505 0