成本优化是指可以减少不必要的费用以及提高运营效率的方法。 通过了解不同的配置选项和减少数据收集量的可能设置，可以显著降低 Azure Monitor 的成本。 使用本文之前，应会看到 Azure Monitor 成本和使用情况，以了解 Azure Monitor 费用的不同方式以及如何查看每月帐单。
本文介绍 Azure Monitor 作为 Azure Well-Architected 框架的一部分的成本优化。 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 活动警报、服务运行状况警报和资源运行状况警报是免费的。 如果想要监控的内容可以通过这些警报类型实现，请使用它们。 |
| 使用日志搜索警报时，请尽量降低日志搜索警报频率。 | 配置日志搜索警报时，请记住，规则评估越频繁，成本就越高。 相应地配置规则。 |
| 使用指标警报时，请尽量减少要监视的资源数。 | 某些资源类型支持指标警报规则，这些规则可以监视同一类型的多个资源。 对于这些资源类型，请记住，如果规则监视许多资源，则成本可能会变得较高。 若要降低成本，可以降低指标警报规则的范围。 您还可以使用日志搜索警报规则来监视大量资源，这种方法成本较低。 |
虚拟机
设计清单
*8 从 Log Analytics 代理迁移到 Azure Monitor 代理，以便进行精细的数据筛选。
- 从代理中过滤掉不需要的数据。
- 确定是否要使用 VM 见解以及要收集的数据。
- 降低性能计数器的轮询频率。
- 确保 VM 不会发送重复数据。
- 使用 Log Analytics 工作区见解分析可计费成本，并确定节省成本的机会。
- 将 SCOM 环境迁移到 Azure Monitor SCOM 托管实例。
配置建议
| 建议 | DESCRIPTION |
|---|---|
| 从 Log Analytics 代理迁移到 Azure Monitor 代理，以实现精细的数据筛选。 | 如果仍具有具有 Log Analytics 代理的 VM，请 将其迁移到 Azure Monitor 代理 ，以便可以利用更好的数据筛选，并使用不同的 VM 集使用唯一配置。 Log Analytics 代理的数据收集配置是在工作区上完成的，因此所有代理会收到相同的配置。 可以调整 Azure Monitor 代理使用的数据收集规则，以满足不同虚拟机集的特定监视要求。 Azure Monitor 代理还允许使用 转换 来筛选正在收集的数据。 |
| 从代理中过滤掉不需要的数据。 | 通过筛选不会用于警报或分析的数据，降低数据引入成本。 请参阅 使用 Azure Monitor 监视虚拟机：收集数据 以了解不同监控场景的数据收集指导，以及 控制成本 的具体指导来通过筛选数据降低成本。 |
| 通过 VM 洞察确定要收集的数据。 | 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 托管服务来收集指标。
- 配置代理收集以修改容器见解中的数据收集。
- 通过 Container Insights 修改指标数据收集设置。
- 如果不在 Azure 门户中使用容器洞察功能，请禁用容器洞察功能的指标数据收集。
- 如果不定期查询容器日志表或将其用于警报，请将其配置为基本日志。
- 限制收集不需要的资源日志。
- 对 AKS 资源日志使用特定于资源的日志记录，并将表配置为基本日志。
- 使用 OpenCost 收集有关 Kubernetes 成本的详细信息。
配置建议
| 建议 | 益处 |
|---|---|
| 启用适用于 Prometheus 的 Azure Monitor 托管服务来收集指标。 请确保不要同时将 Prometheus 指标发送到 Log Analytics 工作区。 | 可以通过启用托管 Prometheus 来使用适用于 Prometheus 的 Azure Monitor 托管服务从群集中抓取 Prometheus 指标。 请注意，可以将容器见解配置为 在 Log Analytics 工作区中收集 Prometheus 指标，但不建议这么做，因为这与托管 Prometheus 中的数据重复，并会导致额外费用。 有关详细信息，请参阅托管 Prometheus 定价。 |
| 配置代理以修改容器见解中的数据收集。 | 分析 Container Insights（容器见解）收集的数据，如 “优化容器见解监控成本” 中所述，并调整配置，以停止收集不需要的数据。 |
| 通过 Container Insights 修改指标数据收集设置。 | 有关如何修改指标数据收集频率以及容器见解所收集命名空间的详细信息，请参阅 启用成本优化设置。 |
| 如果不在 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 中看到意外费用或高成本，本指南将有所帮助。 它涵盖了常见的原因，例如高遥测量、数据引入峰值和配置错误的采样。 如果您正在解决与成本峰值、遥测数据量、采样失效、数据上限、数据摄取量高或意外计费相关的问题，这将特别有用。 要开始使用，请参阅排查 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 的客户应 调整日志级别和范围 ，以优化日志量和成本。 |
后续步骤
- 详细了解如何开始使用 Azure Monitor。