通过

Azure Monitor 中的成本优化

  • 项目

成本优化是指可以减少不必要的费用以及提高运营效率的方法。 通过了解不同的配置选项和减少数据收集量的可能设置，可以显著降低 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%）时收到通知。 这让你有机会在上限关闭数据收集之前调查并解决数据增加的原因。

Azure 资源

设计清单

  • 仅从 Azure 资源收集关键资源日志数据。

配置建议

建议 好处
仅从 Azure 资源收集关键资源日志数据。 创建诊断设置以将 Azure 资源的资源日志发送到 Log Analytics 数据库时，请仅指定所需的类别。 由于诊断设置不允许对资源日志进行精细筛选，可以使用工作区转换来筛选使用受支持的表的资源的不需要的数据。 有关如何配置诊断设置和使用转换筛选其数据的详细信息，请参阅 Azure Monitor 中的诊断设置。

警报

设计清单

  • 活动日志警报、服务运行状况警报和资源运行状况警报是免费的。
  • 使用日志搜索警报时，请尽量降低日志搜索警报频率。
  • 使用指标警报时，请尽量减少要监视的资源数。

配置建议

建议 好处
请记住，活动日志警报、服务运行状况警报和资源运行状况警报是免费的。 Azure Monitor 活动警报、服务运行状况警报和资源运行状况警报是免费的。 如果想要监控的内容可以通过这些警报类型实现，请使用它们。
使用日志搜索警报时，请尽量降低日志搜索警报频率。 配置日志搜索警报时，请记住，规则评估越频繁，成本就越高。 相应地配置规则。
使用指标警报时，请尽量减少要监视的资源数。 某些资源类型支持指标警报规则，这些规则可以监视同一类型的多个资源。 对于这些资源类型，请记住，如果规则监视许多资源，则成本可能会变得较高。 若要降低成本，可以降低指标警报规则的范围。 您还可以使用日志搜索警报规则来监视大量资源，这种方法成本较低。

虚拟机

设计清单

  • 从 Log Analytics 代理迁移到 Azure Monitor 代理，以实现精细的数据筛选。
  • 从代理中过滤不需要的数据。
  • 确定是否要使用 VM 见解以及要收集的数据。
  • 降低性能计数器的轮询频率。
  • 确保 VM 不会发送重复数据。
  • 使用 Log Analytics 工作区见解分析可计费成本，并确定节省成本的机会。

配置建议

建议 说明
从 Log Analytics 代理迁移到 Azure Monitor 代理，以实现精细的数据筛选。 如果仍拥有具有 Log Analytics 代理的虚拟机，请将它们迁移到 Azure Monitor 代理，以便可以利用更好的数据筛选，并对不同的虚拟机集使用唯一配置。 Log Analytics 代理的数据收集配置是在工作区上完成的，因此所有代理会收到相同的配置。 可以调整 Azure Monitor 代理使用的数据收集规则，以满足不同虚拟机集的特定监视要求。 Azure Monitor 代理还允许使用转换来筛选收集的数据。
从代理获取的数据中筛选出不需要的数据。 通过筛选不会用于警报或分析的数据，降低数据引入成本。
降低性能计数器的轮询频率。 如果使用数据收集规则将性能数据发送到 Log Analytics 工作区，则可以降低其轮询频率以减少收集的数据量。
确保 VM 不会发送重复数据。 如果具有多宿主代理或创建了类似的数据收集规则，请确保向每个工作区发送唯一的数据。 有关分析收集的数据以确保没有收集重复数据的指导，请参阅分析 Log Analytics 工作区中的使用情况。 如果要在代理之间迁移，请在迁移到 Azure Monitor 代理之前继续使用 Log Analytics 代理，而不是同时使用这两种代理，除非可以确保每个代理都收集唯一的数据。
使用 Log Analytics 工作区见解分析可计费成本，并确定节省成本的机会。 Log Analytics 工作区见解显示在每个表和每台 VM 中收集的计费数据。 使用此信息来识别排名靠前的计算机和表，因为它们是通过筛选数据来降低成本的最佳机会。 使用此见解并记录在 Log Analytics 工作区中分析使用情况中的查询，以进一步分析配置更改的影响。

容器

设计清单

  • 启用适用于 Prometheus 的 Azure Monitor 托管服务来收集指标。
  • 配置代理收集以修改容器见解中的数据收集。
  • 修改容器洞察中的指标数据收集设置。
  • 如果不在 Azure 门户中使用容器监控功能，请禁用容器监控的指标数据收集。
  • 如果不定期查询容器日志表或将其用于警报，请将其配置为基本日志。
  • 限制收集不需要的资源日志。
  • 对 AKS 资源日志使用特定于资源的日志记录，并将表配置为基本日志。
  • 使用 OpenCost 收集有关 Kubernetes 成本的详细信息。

配置建议

建议 好处
通过适用于 Prometheus 的 Azure Monitor 托管服务启用指标收集。 请确保不要同时将 Prometheus 指标发送到 Log Analytics 工作区。 可以通过启用托管 Prometheus 来使用适用于 Prometheus 的 Azure Monitor 托管服务从群集中抓取 Prometheus 指标。 请注意，可以将容器见解配置为在 Log Analytics 工作区中收集 Prometheus 指标，但不建议这样做，因为这对于托管 Prometheus 中的数据来说是多余的，并且会导致额外的成本。 有关详细信息，请参阅托管 Prometheus 定价。
配置代理以修改容器见解中的数据收集。 根据优化 Container Insights 的监控成本中的描述，分析 Container Insights 收集的数据，并调整配置以停止收集不必要的数据。
按容器见解修改指标数据的收集设置。 有关修改指标数据的收集频率及由 Container Insights 收集的命名空间的详细信息，请参阅启用成本优化设置。
如果不在 Azure 门户中使用容器见解体验，请禁用容器见解的指标数据收集。 容器见解会收集许多与托管 Prometheus 相同的指标值。 可以通过将容器见解配置为仅收集日志和事件来禁用这些指标的收集，如在容器见解中启用成本优化设置中所述。 此配置在 Azure 门户中禁用容器见解体验，但你可以使用 Grafana 将 Prometheus 指标可视化，并使用 Log Analytics 分析容器见解收集的日志数据。
如果不定期查询容器日志表或将其用于警报，请将其配置为基本日志。 请将您的容器见解架构转换为ContainerLogV2，后者与基本日志兼容，可以显著节省成本，正如< c0 >优化容器见解的监视成本< /c0 >中所述。
限制收集不需要的资源日志。 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 和辅助角色服务 SDK 默认会收集许多计数器，这些计数器是作为自定义指标收集的。 使用更高版本以仅指定所需的计数器。
限制不需要的跟踪日志记录。 Application Insights 有几种可能的日志源。 日志级别可用于优化和减少跟踪日志遥测。 日志记录还可以应用于主机。 例如，使用 Azure Kubernetes 服务 (AKS) 的客户应调整控制平面和数据平面日志。 同样，使用 Azure Functions 的客户应调整日志级别和范围，以优化日志量和成本。

后续步骤