警报是监视 Azure Kubernetes 服务（AKS）上的工作负荷的关键部分。 高级警报需要在 Log Analytics 工作区中使用 Analytics 层日志，但对于大容量环境或某些类型的日志（例如审核日志）而言，这可能成本高昂。
通过将保存容器日志的表转换为 基本日志 并利用 Log Analytics 平台的其他经济高效策略，可以显著降低数据引入成本。 Azure Monitor 提供针对这些表的事件驱动和基于摘要的警报的选项，使你能够更好地控制成本，而无需牺牲对 AKS 工作负载的运行状况和行为的可见性。
本文介绍使用经济高效的日志配置监视 AKS 工作负荷的多个警报策略。 这些建议有助于平衡成本和性能，同时仍满足运营需求和服务级别目标（SLO）。
下表总结了本文中讨论的策略，包括何时使用它们及其最适用的表：
| 策略 | 何时使用 |
|---|---|
| 托管 Prometheus 警报 | 当指标可用时，尤其是 Pod、节点或容器状态。 在可能的情况下，指标应该是发出警报的首选。 这些警报是实时、可缩放且经济高效的。 仅当指标不可用时，才使用日志警报。 |
| 简单日志搜索警报规则（预览版） | 需要监视那些无法通过指标获取的特定消息或模式时。 这些警报是基于日志的快速警报，其复杂性较低，例如针对未经授权的访问错误或代理错误发出警报。 当日志内容包含明确的失败关键上下文时，它们最有效。 |
| 带有转换功能的分析层 | 当其他方法（如摘要规则）太慢或不够精细时，用于对高值日志数据进行准实时警报。 转换允许在将日志发送到分析层之前筛选和调整日志，同时启用详细的警报和仪表板，从而降低成本。 非常适合及时性至关重要的关键任务见解。 |
托管 Prometheus 警报
尽可能优先考虑针对指标的警报而不是日志，因为这通常更具可扩展性和成本效益，特别是在大型 AKS 环境中。 与日志相比，指标是精简的、专为快速评估而构建的，并且会产生较低的引入、存储和查询成本。
Azure 托管 Prometheus 支持准实时的指标引入和警报，而无需管理自己的 Prometheus 基础结构的开销。 它可以直接与 AKS 集群集成，并支持以 Prometheus 格式抓取 Kubernetes 原生指标。 可以在 Azure 托管 Grafana 中可视化和分析警报规则，或集成到 Azure Monitor 中，以便进行警报路由。
首先启用建议的 警报规则。 这包括平台指标警报，例如当节点的 CPU 超过阈值时触发。 还可以为各种方案启用不同级别的 Prometheus 警报。 除了内置警报规则，还使用 Prometheus 指标创建自己的自定义警报规则。
托管 Prometheus 警报通常用于替换下表中的警报：
简单日志搜索警报规则（预览版）
Azure Monitor 中的简单日志搜索警报旨在提供传统日志搜索警报的更简单、更快的替代方法，并且基本日志表支持这些警报。 与在定义的时间段内聚合行的日志搜索警报不同，简单的日志警报单独评估每一行并允许单条件日志搜索。 它们非常适合用于监视特定错误事件或状态变化等情景。
例如，可以设置一个规则，在每次出现来自基于云的应用程序的特定错误消息时触发，或者可以选择对任何具有错误级别严重性的消息触发。
除了在每次出现消息时触发外，还可以为指定时间窗口内的出现次数设置阈值。 例如，你可能有一条消息指示登录失败，并希望在一分钟内在其应用程序中失败的登录尝试次数超过阈值时发出警报。 标识后，可以使用表本身的日志查询来识别失败的登录尝试
简单的日志搜索警报通常用于以下数据表中发出警报：
具有转换的 Analytics 层
如果需要对容器日志进行近实时警报，摘要规则可能不够响应。 在操作敏感场景中，当需要准实时日志警报时，可使用 转换，将高价值日志（如错误和关键事件）路由到 Analytics Logs 表，同时将其他日志发送到 Basic Logs 或 Auxiliary Logs 表中。 使用此策略，可以在分析层中的表上执行高级警报，同时将其他数据路由到成本较低的层，实现经济高效的存储和偶尔分析。
有关此转换的详细配置，请参阅容器见解中的数据转换。
此策略通常用于从下表发出警报：