你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure Monitor 中的成本优化
成本优化是指可以减少不必要的费用以及提高运营效率的方法。 通过了解不同的配置选项和减少数据收集量的可能设置，可以显著降低 Azure Monitor 的成本。 使用本文之前，应先查看 Azure Monitor 成本和使用情况，了解 Azure Monitor 的不同计费方式以及如何查看每月帐单。
本文介绍 Azure Monitor 的成本优化，它涵盖在 Azure 良好架构的框架中。 Azure 架构良好的框架是一组指导原则，可用于提高工作负荷的质量。 该框架包含卓越体系结构的五大要素：
- 可靠性
- 安全性
- 成本优化
- 卓越运营
- 性能效率
Azure Monitor 日志
设计清单
- 确定是否在同一 Log Analytics 工作区中合并操作数据和安全数据。
- 为每个 Log Analytics 工作区通常收集的数据量配置定价层。
- 配置数据保留和存档。
- 将用于调试、故障排除和审核的表配置为基本日志。
- 限制从工作区的数据源收集数据。
- 定期分析所收集的数据，以确定趋势和异常。
- 当数据收集量很高时创建警报。
- 考虑使用每日上限作为预防措施，以确保你不超过特定预算。
- 为适用于 Log Analytics 工作区的 Azure 顾问成本建议设置警报。
配置建议
| 建议 | 好处 |
|---|---|
| 确定是否在同一 Log Analytics 工作区中合并操作数据和安全数据。 | 由于在启用 Sentinel 的情况下，Log Analytics 工作区中的所有数据将按 Microsoft Sentinel 定价计费，因此组合这些数据可能会影响成本。 请参阅设计 Log Analytics 工作区策略，详细了解如何针对环境做出此决策，使之与其他支柱中的准则保持平衡。 |
| 为每个 Log Analytics 工作区通常收集的数据量配置定价层。 | 默认情况下，Log Analytics 工作区将使用即用即付定价，没有最少数据量。 如果收集的数据足够多，则可以使用承诺层级来显著降低成本，借此可以承诺每天收集的最小数据量，以获得更低的费率。 如果跨单个区域中的工作区收集了足够多的数据，则可以将它们链接到专用群集，并使用群集定价来合并所收集的数据量。 请参阅 Azure Monitor 日志成本计算和选项，了解有关承诺层的详细信息以及确定最适合你的使用级别的指导。 请参阅使用情况和预估成本，查看使用情况在不同定价层的预估成本。 |
| 配置交互式和长期数据保留。 | 在 Log Analytics 工作区中保留数据超过 31 天的默认期限将收取费用（如果在工作区上启用了 Sentinel，则期限为 90 天；对于 Application Insights 数据，也为 90 天）。 请考虑使数据随时可用于日志查询的特定要求。 你可以通过配置长期保留来显著降低成本，它允许将数据保留长达 12 年，并且仍可偶尔访问这些数据，方法是使用搜索作业或将一组数据还原到工作区。 |
| 将用于调试、故障排除和审核的表配置为基本日志。 | Log Analytics 工作区中配置为基本日志的表具有较低的引入成本，因此功能有限且会产生日志查询费用。 但如果不经常查询这些表并且不将它们用于警报，则此查询成本可能会被减少的引入成本所抵消。 |
| 限制从工作区的数据源收集数据。 | Azure Monitor 的主要成本因素是你在 Log Analytics 工作区中收集的数据量，因此应确保收集的数据不超过评估服务和应用程序的运行状况和性能所需的数据。 请参阅设计 Log Analytics 工作区体系结构，详细了解如何针对你的环境做出此决策，使其与其他支柱中的条件进行平衡。 权衡：可能需要在成本和监视要求之间做出权衡。 例如，使用高采样率也许能够更快地检测出性能问题，但若想节省成本，则需要使用较低的采样率。 大多数环境都有多个数据源，它们的数据收集类型各不相同，因此对于每个数据源，需要在特定要求与成本目标之间实现平衡。 有关为不同数据源配置数据收集的建议，请参阅 Azure Monitor 中的成本优化。 |
| 定期分析所收集的数据，以确定趋势和异常。 | 使用 Log Analytics 工作区见解定期查看工作区中收集的数据量。 除了帮助你了解不同源收集的数据量外，它还将识别数据收集中可能导致成本过高的异常和上升趋势。 使用分析 Log Analytics 工作区中的使用情况中的方法进一步分析数据收集，以确定是否可以进行其他配置来进一步降低使用量。 添加一组新的数据源（例如一组新的虚拟机或加入新服务）时，这一点尤其重要。 |
| 当数据收集量很高时创建警报。 | 为了避免出现意外账单，应让系统在遇到过度使用时主动通知你。 通知使你可以在计费期结束之前解决任何潜在的异常情况。 |
| 考虑使用每日上限作为预防措施，以确保你不超过特定预算。 | 达到配置的限制后，每日上限会在一天的剩余时间内禁用 Log Analytics 工作区中的数据收集。 不应将此方法用于降低成本，如何时使用每日上限中所述。 如果设置了每日上限，则除了在达到上限时创建警报外，还请确保创建一个警报规则，以便在达到某个百分比（例如 90%）时发出通知。 这让你有机会在上限关闭数据收集之前调查并解决数据增加的原因。 |
| 为适用于 Log Analytics 工作区的 Azure 顾问成本建议设置警报。 | 当有机会优化成本时，适用于 Log Analytics 工作区的 Azure 顾问建议会主动发出警报。 为以下成本建议创建 Azure 顾问警报：
|
Azure 资源
设计清单
- 仅从 Azure 资源收集关键资源日志数据。
配置建议
| 建议 | 好处 |
|---|---|
| 仅从 Azure 资源收集关键资源日志数据。 | 创建诊断设置以将 Azure 资源的资源日志发送到 Log Analytics 数据库时，请仅指定所需的类别。 由于诊断设置不允许对资源日志进行精细筛选，可以使用工作区转换来筛选使用受支持的表的资源的不需要的数据。 有关如何配置诊断设置和使用转换筛选其数据的详细信息，请参阅 Azure Monitor 中的诊断设置。 |
警报
设计清单
- 活动日志警报、服务运行状况警报和资源运行状况警报是免费的。
- 使用日志搜索警报时，请尽量降低日志搜索警报频率。
- 使用指标警报时，请尽量减少要监视的资源数。
配置建议
| 建议 | 好处 |
|---|---|
| 请记住，活动日志警报、服务运行状况警报和资源运行状况警报是免费的。 | Azure Monitor 活动日志警报、服务运行状况警报和资源运行状况警报是免费的。 如果想要监控的内容可以通过这些警报类型实现，请使用它们。 |
| 使用日志搜索警报时，请尽量降低日志搜索警报频率。 | 配置日志搜索警报时，请记住，规则评估越频繁，成本就越高。 相应地配置规则。 |
| 使用指标警报时，请尽量减少要监视的资源数。 | 某些资源类型支持指标警报规则，这些规则可以监视同一类型的多个资源。 对于这些资源类型，请记住，如果规则监视许多资源，则成本可能会变得较高。 若要降低成本，可以缩小指标警报规则的范围，也可以使用日志搜索警报规则，这样可以降低监视大量资源的成本。 |
虚拟机
设计清单
- 从 Log Analytics 代理迁移到 Azure Monitor 代理，以实现精细的数据筛选。
- 筛选代理中不需要的数据。
- 确定是否要使用 VM 见解以及要收集的数据。
- 降低性能计数器的轮询频率。
- 确保 VM 不会发送重复数据。
- 使用 Log Analytics 工作区见解分析可计费成本，并确定节省成本的机会。
- 将 SCOM 环境迁移到 Azure Monitor SCOM 托管实例。
配置建议
| 建议 | 说明 |
|---|---|
| 从 Log Analytics 代理迁移到 Azure Monitor 代理，以实现精细的数据筛选。 | 如果仍拥有具有 Log Analytics 代理的虚拟机，请将它们迁移到 Azure Monitor 代理，以便可以利用更好的数据筛选，并对不同的虚拟机集使用唯一配置。 Log Analytics 代理的数据收集配置是在工作区上完成的，因此所有代理会收到相同的配置。 可以调整 Azure Monitor 代理使用的数据收集规则，以满足不同虚拟机集的特定监视要求。 Azure Monitor 代理还允许使用转换来筛选收集的数据。 |
| 筛选代理中不需要的数据。 | 通过筛选不会用于警报或分析的数据，降低数据引入成本。 请参阅使用 Azure Monitor 监视虚拟机：收集数据以获得对不同监视案例收集数据的指导，以及控制成本以获得有关筛选数据以降低成本的具体指导。 |
| 确定要使用 VM 见解收集的数据。 | VM 见解是很好的功能，可以快速开始监视虚拟机，并提供强大的功能，如映射和性能趋势视图。 如果不使用映射功能或它收集的数据，则应在 VM 见解配置中禁用进程和依赖项数据的收集，以节省数据引入成本。 |
| 降低性能计数器的轮询频率。 | 如果使用数据收集规则将性能数据发送到 Log Analytics 工作区，则可以降低其轮询频率以减少收集的数据量。 |
| 确保 VM 不会发送重复数据。 | 如果具有多宿主代理或创建了类似的数据收集规则，请确保向每个工作区发送唯一的数据。 有关分析收集的数据以确保没有收集重复数据的指导，请参阅分析 Log Analytics 工作区中的使用情况。 如果要在代理之间迁移，请在迁移到 Azure Monitor 代理之前继续使用 Log Analytics 代理，而不是同时使用这两种代理，除非可以确保每个代理都收集唯一的数据。 |
| 使用 Log Analytics 工作区见解分析可计费成本，并确定节省成本的机会。 | Log Analytics 工作区见解可显示在每个表中以及从每个 VM 收集的可计费数据。 使用此信息来识别排名靠前的计算机和表，因为它们是通过筛选数据来降低成本的最佳机会。 使用此见解并记录在 Log Analytics 工作区中分析使用情况中的查询，以进一步分析配置更改的影响。 |
| 将 SCOM 环境迁移到 Azure Monitor SCOM 托管实例。 | 将现有 SCOM 环境迁移到 Azure Monitor SCOM 托管实例，以支持 Azure Monitor 无法替换的任何管理包。 SCOM 托管实例无需维护本地管理服务器和数据库服务器，从而降低了维护 SCOM 基础架构的总体成本。 |
容器
设计清单
- 通过适用于 Prometheus 的 Azure Monitor 托管服务启用指标收集。
- 配置代理收集以修改容器见解中的数据收集。
- 使用容器见解修改指标数据的收集设置。
- 如果不在 Azure 门户中使用容器见解体验，请禁用指标数据的容器见解收集。
- 如果不定期查询容器日志表或将其用于警报，请将其配置为基本日志。
- 限制收集不需要的资源日志。
- 对 AKS 资源日志使用特定于资源的日志记录，并将表配置为基本日志。
- 使用 OpenCost 收集有关 Kubernetes 成本的详细信息。
配置建议
| 建议 | 好处 |
|---|---|
| 通过适用于 Prometheus 的 Azure Monitor 托管服务启用指标收集。 请确保不要同时将 Prometheus 指标发送到 Log Analytics 工作区。 | 可以通过启用托管 Prometheus，使用适用于 Prometheus 的 Azure Monitor 托管服务从群集中抓取 Prometheus 指标。 请注意，可以将容器见解配置为在 Log Analytics 工作区中收集 Prometheus 指标，但不建议这样做，因为这对于托管 Prometheus 中的数据来说是多余的，并且会导致额外的成本。 有关详细信息，请参阅托管 Prometheus 定价。 |
| 配置代理以修改容器见解中的数据收集。 | 按照优化容器见解的监视成本所述，分析容器见解收集的数据，并调整配置以停止收集不需要的数据。 |
| 使用容器见解修改指标数据的收集设置。 | 有关修改容器见解收集指标数据的频率和命名空间的详细信息，请参阅启用成本优化设置。 |
| 如果不在 Azure 门户中使用容器见解体验，请禁用指标数据的容器见解收集。 | 容器见解收集许多与 托管 Prometheus 相同的指标值。 可以通过将容器见解配置为仅收集日志和事件来禁用这些指标的收集，如在容器见解中启用成本优化设置中所述。 此配置在 Azure 门户中禁用容器见解体验，但你可以使用 Grafana 将 Prometheus 指标可视化，并使用 Log Analytics 分析容器见解收集的日志数据。 |
| 如果不定期查询容器日志表或将其用于警报，请将其配置为基本日志。 | 按照优化容器见解的监视成本所述，将容器见解架构转换为 ContainerLogV2，它与基本日志兼容，并且可以显著节省成本。 |
| 限制收集不需要的资源日志。 | AKS 控制平面日志实现为 Azure Monitor 中的资源日志。 创建诊断设置，以便将此数据发送到 Log Analytics 工作区。 有关应收集的类别的建议，请参阅 收集 AKS 群集的控制平面日志。 |
| 对 AKS 资源日志使用特定于资源的日志记录，并将表配置为基本日志。 | AKS 对资源日志支持 Azure 诊断模式或特定于资源的模式。 指定资源日志以启用为基本日志配置表的选项，该选项可减少仅偶尔查询且不用于警报的日志的引入费用。 |
| 使用 OpenCost 收集有关 Kubernetes 成本的详细信息。 | OpenCost 是一个开源、供应商无关的 CNCF 沙盒项目，用于了解 Kubernetes 成本并为 AKS 成本可见性提供支持。 除了特定于客户的 Azure 定价外，它还将详细的成本数据导出到 Azure 存储，帮助群集管理员分析和分类成本。 |
Application Insights
设计清单
- 更改为基于工作区的 Application Insights。
- 使用采样优化收集的数据量。
- 限制 Ajax 调用数。
- 禁用不需要的模块。
- 预先聚合任何 TrackMetric 调用中的指标。
- 尽可能限制自定义指标的使用。
- 确保使用更新的软件开发工具包 (SDK)。
- 使用日志级别来限制不需要的主机跟踪和常规跟踪日志记录。
配置建议
| 建议 | 好处 |
|---|---|
| 更改为基于工作区的 Application Insights。 | 确保 Application Insights 资源基于工作区。 基于工作区的 Application Insights 资源可以应用新的成本节省工具，例如基本日志、承诺层级、按数据类型的保留，以及长期保留。 |
| 使用采样优化收集的数据量。 | 采样是可用来优化 Application Insights 收集的数据量的主要工具。 使用采样来减少从应用程序发送的遥测数据量，同时最大程度减少指标的失真。 |
| 限制 Ajax 调用数。 | 限制每个页面视图中可报告的 Ajax 调用数或禁用 Ajax 报告。 如果禁用 Ajax 调用，则还会禁用 JavaScript 关联。 |
| 禁用不需要的模块。 | 编辑 ApplicationInsights.config 关闭不需要的集合模块。 例如，用户可能认为不再需要性能计数器或依赖项数据。 |
| 预先聚合任何 TrackMetric 调用中的指标。 | 如果将 TrackMetric 调用置于应用程序中，则可通过使用重载降低流量，这种重载接受对一批度量值的平均偏差和标准偏差的计算结果。 或者，可以使用预聚合包。 |
| 限制自定义指标的使用。 | Application Insights 的启用自定义指标维度警报选项会增加成本。 使用此选项可能导致创建更多预聚合指标。 |
| 确保使用更新的软件开发工具包 (SDK)。 | 早期版本的 ASP.NET Core SDK 和 Worker Service SDK 默认收集大量计数器，这些计数器将作为自定义指标收集。 请使用更高版本来指定所需的计数器。 |
| 限制不需要的跟踪日志记录。 | Application Insights 有几种可能的日志源。 日志级别可用于优化和减少跟踪日志遥测。 日志记录也可以应用于主机。 例如，使用 Azure Kubernetes 服务 (AKS) 的客户应调整控制平面和数据平面日志。 同样，使用 Azure Functions 的客户应调整日志级别和范围，以优化日志量和成本。 |