作者|涯海
审核 & 校对：白玙
编辑 & 排版：雯燕

在陪伴泛滥企业独特经验业务上云与云上原生之后，咱们能够看到每个企业的运维监控体系搭建过程都非常艰苦。这是因为企业业务倒退迅速，对 IT 的要求也愈发严苛且简单。这不仅仅体现在运维团队架构与工作流程上，也体现在工具选型与平台搭建上。只管不同阶段不同规模的企业须要面对各种各样事实问题，但依然有些最佳实际有迹可循，明天咱们好好聊一下工具选型与平台搭建思路与实际关键点。

工具选型与平台搭建必然趋势

要特地阐明的是，监控平台不是轻易下载一个开源监控工具就能够，它须要依据监控的业务特点进行整合与二次开发，以达到与理论业务状况相吻合。通过大量实际后，咱们发现企业普遍存在的监控体系需要与倒退方向：

• 自动识别与采集

云原生带来了跨技术栈与高动静的技术架构。因而面向复杂多变的被监控环境，采集器尽可能做到对环境的自动识别，对指标的自主采集成为所有的开始。数据都无奈采集，如何监控？

• 数据管理能力一直强化

云、容器和微服务的呈现使被监控的对象数量减少了几个数量级。当业务飞速发展，面对几亿甚至十亿级别时序数据，咱们该如何治理？

• 数据看板体系成为刚需

随着数据量爆发式增长，传统的线图、直方图、散点图等数据展现办法很难让运维人员找到数据背地的异样或暗藏瓶颈。如何针对不同业务或者不同监控对象，找到更适合的数据看板以及展示模式，成为了每个运维人员的必修课。

• 中台枢纽作用

随着技术飞速发展，监控零碎在整体运维零碎的中台枢纽作用越来越显著，运维监控从传统的流程驱动转变为数据驱动。如何更便捷的与其它泛滥运维子系统对接整合，也是运维团队在监控体系搭建之初须要思考的问题。

企业监控体系演进历程

联合上述特点，咱们讲企业监控体系的演进历程演绎为以下阶段。

推广期：服务器数量 50～100 台之间

这个阶段因为服务器数量较少、业务规模较小，因而，运维团队对监控的需要也绝对简略。可能实现根本的告诉问题、疾速定位与解决问题即可。此时的平台搭建次要是让研发、运维等同学可能逐步相熟产品应用，并通过体验和反馈，确认是否满足企业 IT 运维以及业务特色需要，这其中几个要害特点包含：

（1）部署简略，有成熟的文档与服务体系，上手易用；

（2）稳固运行，SLA 保障；

（3）告警体系的告诉模式不必太丰盛，但确保绝对及时、可用；

（4）低成本费用或收费。

基于以上需要，很多初创企业可能会抉择 Nagios，Cacti，Zabbix，Ganglia 等开源工具。热门的开源监控产品文档绝对残缺，可疾速上手且有大量企业实际可供参考。但这里存在问题就在于开源产品的性能、应用场景无奈满足随着业务场景的倒退以及业务量增长，进而呈现各种各样的问题。与此同时，高可用成为致命问题，毕竟开源社区不会时刻有志愿者帮咱们排查故障。

暴发期：服务器数量 200～1000 台之间

这个阶段因为服务器数量变多、技术架构产生了变动、组件越发丰盛，监控需要也开始变得复杂。但面对泛滥服务模块或运维零碎，咱们须要分批次有序接入，在保障稳定性的前提下，疾速上量、对立技术栈。监控零碎次要用于告警告诉，发现问题并防止同样问题再次发生。这其中具备几个要害特点：

（1）监控内容汇总与分类

因为监控对象以及信息随着技术架构与业务规模扩充而增多，须要针对软硬件、业务等不同维度的数据实现全笼罩式监控。并针对不同监控用处，须要对监控进行分类汇总，比方零碎根底监控数据、网络监控数据和业务监控数据。尽可能多的监控笼罩，尽快发现重要问题，确保业务稳固运行。

（2）多种告警形式，及时无漏报

依据监控对象的重要水平、紧急水平进行分类，并通过邮件、微信、短信、电话等不同级别不同形式进行告警告诉，每个监控对应到不同责任人，确保每个告警都有人及时跟进解决。

（3）告警策略优化与信息收敛

因为须要监控的服务越来越多，告警信息数量激增，每天都可能收到上千封报警邮件。过多的告警信息就失去了精准告知的意义。如何对告警策略进行配置和优化，尽量减少不必要的告警邮件，成为策略设置的外围。

成熟期：服务器数量 1000 台以上

因为业务持续增长，对服务器的需要越来越大，当服务器超过 1000 台当前，意味着外围零碎须要全副接入，并构建新的稳定性保障体系，包含监控大盘、告警告诉、应急值班等。能力确保整个业务与技术大盘的稳固。这其中，须要关注：

（1）监控延时与告警滞后

当业务规模越老越大，因为组件或服务的耦合关系，很可能因为部分的细小故障导致整个业务零碎的瘫痪。因而，及时发现问题成为了所有的大前提。但如果还在抉择时开源产品，这时可能就有不小的麻烦。以 Zabbix 举例，当规模达到一定量后，有时候会呈现监控数据不能及时显示，告警延时等问题。咱们的确能够通过各种优化形式进行调整。但业务呈现问题而造成的损失并不能挽回。

（2）监控零碎本身的 SLA

当收集运维数据飞速增长，监控零碎本身的高可用也成为了重要关注点。毕竟，失去了监控零碎意味着对整个技术与业务的运行状态失去了管制。

更具性价比的解决方案：利用实时监控服务 ARMS

面对上述不同阶段的痛点，ARMS 成为了最佳的解决方案。与此同时，阿里云推出 ARMS 3.0 普惠打算旨在通过更灵便的计费计划，帮忙不同类型的用户在不同应用阶段，以更正当的老本获取更高性价比的可观测体验。在 2021 年 10 月行将推出的利用监控根底版（按量计费）模式反对 0 元用：指标收费存储 3 天，调用链根底采样收费存储 1 天，性能与原有根底版保持一致，可按量付费缩短存储周期或进步链路采样。详情可参考利用监控根底版性能列表或产品计费阐明。

根据上述阶段的用户诉求，ARMS 3.0 利用监控推出了配套的灵便计费策略：

（1）试用期：ARMS 提供新用户 15 天收费应用，全面评估 ARMS 产品与业务符合水平。

（2）推广期：ARMS 提供根底版收费额度，利用监控指标收费存储 3 天，调用链根底采样收费存储 1 天。零门槛无限期应用，不必放心推广期间的费用问题。

（3）暴发期：ARMS 根底版反对按流量计费，能够按需调整指定利用的调用链采样率，或缩短存储周期。

（4）成熟期：依据业务流量类型自由选择按流量计费或按节点计费。

按流量计费，用多少算多少

随着微服务和 Kubernetes 的遍及，微服务拆分越来越细，单个 Pod 流量越来越小。按节点计费模式就显得不够灵便，在业务流量不变的状况下，老本随节点规模快速增长显然不够正当。

为了解决小流量和弹性流量用户的可观测老本问题，ARMS 3.0 推出了利用监控根底版（按量计费）模式：调用链根底采样收费存储 1 天，付费采样链路依照 0.2 元 /(百万条 Trace* 天) 进行计费，单条 Trace 最多可蕴含 10 条 Span 调用，超出局部按比例折算。指标数据 3 天内收费，可按需付费缩短存储周期，如下表所示。

以 ARMS 某根底版用户为例，该用户创立了约 300 个 Pod，原始调用总量约为 54 亿次 / 天，调用链采样率为 10%，理论存储量约 5400 万 Trace/ 天。依照原根底版链路存储 1 天，指标存储 3 天计算，降级为按流量计费后费用可节俭 90% 以上。

超大流量，按节点计费更划算

一些 ToC 类型的业务流量十分大，并且对问题可追溯的时间跨度要求高，须要长周期存储。此时，能够抉择 ARMS 专家版按节点计费模式，链路存储 30 天，指标存储 90 天，一价全包，费用封顶，更适宜大流量外围利用接入。专家版还可享受 容器服务 ACK 或 EDAS 用户半价优惠，购买预付费流量包最低可至 1.308 元 /(探针 * 天)，详见 ARMS 产品价格阐明。

常见问题

Q：新老用户如何降级至利用监控新根底版（按量计费）模式？
A：2021 年 10 月当前，新用户试用期完结后，抉择开明根底版，默认进入按量计费模式；存量根底版用户能够在利用监控 -> 利用列表页面上方点击降级至新计费模式。新根底版链路收费采样依赖 Agent 降级至 2.7.1.3 版本，能够在利用监控 -> Agent 列表 -> java 版本阐明页面抉择对应区域进行下载，https://arms.console.aliyun.c…。

Q：新根底版（按量计费）默认是收费的吗？收费多久？
A：开明新根底版（按量计费）后，默认是完全免费的，如果不调整存储周期或调用链采样率能够无限期收费应用，非常适合小流量或测试利用接入。

Q：根底版蕴含哪些性能？与开源和专家版有什么区别？
A：根底版反对调用链、服务监控、JVM/ 主机监控、告警等根底 APM 性能，与开源能力根本持平。专家版在内存 / 线程 / 异样等诊断方面会有大幅加强，按节点计费，调用链存储 30 天，指标存储 90 天，更适宜大流量或外围生产利用。

Q：除利用监控外，ARMS 前端监控、云拨测和 Prometheus 监控是否反对按量计费？
A：ARMS 前端监控、云拨测和 Prometheus 监控均反对按量计费，并且能够通过预付费取得优惠折扣，详情请参考 ARMS 产品价格阐明。

相干链接：

1）利用监控根底版性能列表：
https://help.aliyun.com/docum…

2）产品计费阐明：
https://www.aliyun.com/ntms/p…

3）ARMS 产品价格阐明：
https://www.aliyun.com/ntms/p…

点击下方链接，理解更多双十一优惠！
https://www.aliyun.com/activi…