已解决：最近你的 Azure 账单中，最出乎意料的昂贵项目是什么？
Source: Dev.to
请提供需要翻译的正文内容，我将按照要求进行简体中文翻译并保留原有的格式。
Executive Summary
TL;DR: Azure Log Analytics 可能因默认诊断设置摄取过多数据而意外成为一笔巨大的云费用。本文提供了三种策略——通过设置每日上限等快速修复、使用细粒度诊断设置和数据收集规则（DCR）进行永久性修复，以及通过将数据分为冷热路径的“核弹”架构拆分——帮助您有效管理并降低摄取成本。
Source: …
问题
Azure 服务的默认诊断日志往往会因发送非关键数据而导致 Log Analytics 吞吐量意外升高，进而产生高额的摄取费用。
- 快速修复 – 使用 KQL 查询识别噪声数据类型，并在 Log Analytics 工作区设置中临时设定每日摄取上限。
- 永久修复 – 对 Diagnostic Settings 进行细粒度控制，只选择有价值的日志类别，并利用 DCR（数据收集规则）在摄取前进行转换和过滤。
- 根本方案 – 通过拆分数据流进行重新架构：
- Hot Path – 为实时需求保留精简的 Log Analytics。
- Cold Path – 将长期保存的成本效益数据放入 Azure Storage Account。
如果管理不当，Azure 的 Log Analytics 可能悄然成为您最大的云费用。本指南提供三种实用策略，从快速修复到永久性架构改进，帮助您控制失控的数据摄取成本，让账单回归正轨。
真实案例
我记得就像昨天发生的一样。我们刚刚推出了一个流畅的新微服务，auth-svc-prod。我们的一位锐意进取的初级工程师——我们叫他 Ben——按照教材的步骤完成了监控设置：App Insights、每个相关资源的诊断设置，都指向同一个中心 Log Analytics 工作区。
一个月后，财务部门在 Slack 上给我发来一张 Azure 账单的截图，并只问了一个问题：
“什么是 ‘Log Ingestion’，为什么它的费用比我们整个生产环境的虚拟机还要高？”
Ben 并没有做错任何事；他完全按照文档操作。正是这点，正是陷阱所在。
默认诊断日志 是 Azure 预算的隐形杀手。当你部署新环境时，往往会冲动地点击 “发送到 Log Analytics” 并启用 所有 类别。Azure 让这一步变得很容易，但许多服务默认情况下非常“唠叨”：
| 服务 | 嘈杂的类别 |
|---|---|
| App Service | 每一次成功的健康探针 ping |
| Azure Firewall | 每一个被允许的数据包 |
| Storage Account | 每一次成功的读取操作 |
单独来看这些都是极小的数据量，但若每小时有数百万次事务，它们就会变成直接冲向你的 Log Analytics 工作区的消防水管——而且你要为每一个 GB 付费。
根本原因不是 bug，而是优先级的不匹配。默认设置是为最大可见性而优化的，而不是为成本考虑。我们这些身处第一线的工程师，需要把这股“消防水管”调节成可管理且有价值的数据流。
三个层级的响应
1️⃣ 快速修复 – 使用止血带
目标： 立即限制费用，让你有喘息空间。
步骤 1 – 找出最嘈杂的表
在工作区运行此 KQL 查询，以查看哪些数据类型成本最高：
// Find the biggest data hogs (last 30 days)
Usage
| where TimeGenerated > ago(30d)
| where IsBillable == true
| summarize BillableDataGB = sum(Quantity) / 1000 by DataType
| sort by BillableDataGB desc步骤 2 – 设置每日摄入上限
- 打开 Log Analytics Workspace → Usage and estimated costs。
- 设置 每日摄入上限。
警告： 上限非常粗糙——一旦达到，Azure 将在当天剩余时间停止摄入 所有 数据。关键的安全或错误日志可能会丢失。仅在临时安全阀的情况下使用此方法。
2️⃣ 永久修复 – 有意的数据收集
现在立即的“出血”已止住，是时候进行正式手术：有意识地选择收集的内容。
优化诊断设置
- 不要 勾选 “AllMetrics” 和 “AllLogs”。
- 请 仅选择能提供真实业务或运营价值的类别。
示例对比
| 资源 | “AllLogs”（昂贵） | 过滤后（智能） |
|---|---|---|
| Azure 防火墙 | 所有日志 → 大量数据 | 仅 AzureFirewallApplicationRule 与 AzureFirewallDnsProxy 日志 |
| Key Vault | 所有指标 → 不必要 | 仅 AuditEvent 日志（安全/合规） |
专业提示 – 使用数据收集规则 (DCR)
DCR 允许你在数据摄入并计费之前应用 KQL 转换。你可以：
- 删除噪声列。
- 过滤掉整个日志条目（例如，200 OK 健康检查）。
这是你成本优化武器库中最强大的工具。
3️⃣ 核心选项 – 热/冷架构
当即使是过滤后的数据对 “热” Log Analytics 工作区来说仍然过于庞大时，需要重新思考架构。
拆分数据流
| 路径 | 目的 | 存储 | 保留期限 |
|---|---|---|---|
| 热 | 实时警报与交互式仪表盘（错误、安全警报、关键绩效指标） | Log Analytics（精简） | 30‑90 天 |
| 冷 | 长期合规与取证分析（原始日志） | Azure Storage（Blob/ADLS） | 1 年以上（更便宜） |
实施示意
flowchart LR
subgraph HotPath[Hot Path (Log Analytics)]
A[High‑priority logs] --> LA[Log Analytics Workspace]
end
subgraph ColdPath[Cold Path (Storage)]
B[All other logs] --> SA[Azure Storage Account]
end
A -->|DCR filtering| B- 仅将高价值数据摄入热工作区。
- 将其余数据归档到 Azure Storage，在需要时仍可通过 Azure Synapse、Azure Data Explorer 或 Log Analytics “Data Export” 进行查询。
回顾
| 等级 | 操作 | 何时使用 |
|---|---|---|
| 快速修复 | 每日摄入上限 + 识别噪声表 | 出现即时成本泄漏，需要快速临时解决方案 |
| 永久修复 | 细粒度诊断设置 + DCR（数据收集规则） | 持续运营，想要可持续的成本控制 |
| 核选项 | 冷/热分离架构 | 长期合规数据量过大，仅热工作区无法承载 |
冷路径（低成本）
对于其他所有数据——详细的应用日志、网络流日志、合规数据——如果需要保留但很少查询，请直接将数据发送到 Azure Storage Account 而不是 Log Analytics。此方式 成本低几个数量级。
当需要分析这些数据时，你可以：
- 使用 Azure Data Explorer 在原位查询，或
- 按需重新加载（Re‑hydrate）。
这需要稍多的设置，但对于大规模环境来说，这是在不牺牲合规性或可视性的前提下，控制日志成本的唯一可持续方案。
那张意外的账单对我们的团队是一次痛苦却有价值的教训。它迫使我们不再把日志视为事后考虑，而是把它当作应用架构的关键组成部分。不要等财务团队敲门。主动检查你的 Usage 表吧；你可能会对结果感到惊讶。
👉 在 TechResolve.blog 阅读原文
☕ 支持我的工作
如果本文对你有帮助，你可以请我喝杯咖啡：