作者｜涯海
审核&校对：白玙
编辑&排版：雯燕
在陪伴众多企业共同经历业务上云与云上原生之后，我们可以看到每个企业的运维监控体系搭建过程都十分艰辛。这是由于企业业务发展迅速，对 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.com/#/tracing/agentList/cn-hangzhou 。
Q：新基础版（按量计费）默认是免费的吗？免费多久？
A：开通新基础版（按量计费）后，默认是完全免费的，如果不调整存储周期或调用链采样率可以无限期免费使用，非常适合小流量或测试应用接入。
Q：基础版包含哪些功能？与开源和专家版有什么区别？
A：基础版支持调用链、服务监控、JVM/主机监控、告警等基础 APM 功能，与开源能力基本持平。专家版在内存/线程/异常等诊断方面会有大幅增强，按节点计费，调用链存储 30 天，指标存储 90 天，更适合大流量或核心生产应用。
Q：除应用监控外，ARMS 前端监控、云拨测和 Prometheus 监控是否支持按量计费？
A：ARMS 前端监控、云拨测和 Prometheus 监控均支持按量计费，并且可以通过预付费获得优惠折扣，详情请参考 ARMS 产品价格说明。
相关链接：
1）应用监控基础版功能列表：
https://help.aliyun.com/document_detail/65682.html
2）产品计费说明：
https://www.aliyun.com/ntms/price/detail/arms_detail
3） ARMS 产品价格说明：
https://www.aliyun.com/ntms/price/detail/arms_detail
点击下方链接，了解更多双十一优惠！
https://www.aliyun.com/activity/1111/cloudnative?spm=5176.20960838.0.0.7603305eAKBvI9