Azure 日志实战:Azure Monitor、Log Analytics 与 KQL 查询

Azure 日志中文实战:Azure Monitor 日志体系(Activity Log / 资源日志 / 应用日志)、Log Analytics 工作区与 KQL 查询语言、Diagnostic Settings 诊断设置、Application Insights 应用日志、保留与成本治理,以及与观测云联动的落地方案。

最佳实践
Azure 日志实战:Azure Monitor、Log Analytics 与 KQL 查询技术指南封面

Azure 的日志体系以 Azure Monitor 为中枢:平台日志(Activity Log)、资源日志、应用日志可按各自采集路径汇入 Log Analytics 工作区,并非自动全部汇入,用 KQL(Kusto Query Language)统一查询。本文讲清三路日志的区别、KQL 上手、诊断配置与观测云联动方案。

核心要点速览

  • 三路日志先分清:Activity Log(订阅级控制面操作)、资源日志(资源内部运行)、Application Insights(应用代码级)。
  • Log Analytics + KQL 是检索中枢:类 SQL 的管道式查询语言,功能强大。
  • Diagnostic Settings 决定日志流向:Log Analytics / Storage Account / Event Hubs 三选一或组合。
  • VM 应用日志接入:可通过 DataKit 采集主机上的日志文件,先验证字段和时间再扩大采集范围。

1. 三路日志的区别

日志 内容 默认开启
Activity Log 谁在什么时候对订阅里什么资源做了什么操作(控制面) ✅
资源日志 资源内部运行事件(如 Key Vault 的访问记录) ❌ 需 Diagnostic Settings
应用日志 App Service/容器应用的 stdout、异常、请求 需配置

最常见的盲区是资源日志——对使用诊断设置的资源类别,需选择类别与目的地才会收集外送;不能概括全部日志来源。NSG/VNet 流日志走 Network Watcher 独立配置,NSG 流日志已进入退役流程,应按官方指引迁移到 VNet 流日志。

2. Diagnostic Settings:日志的开关与路由

每个资源的"诊断设置"里勾选日志类别,选目的地:

  • Log Analytics 工作区:可查询、可告警(主用);
  • Storage Account:廉价归档(合规留存);
  • Event Hubs:用于流式外送;第三方接收方需要具备相应消费与转换流程。

3. KQL 快速上手

// 最近 1 小时的错误日志
AppTraces
| where TimeGenerated > ago(1h)
| where SeverityLevel >= 3
| project TimeGenerated, Message, Properties
| order by TimeGenerated desc

// 按 5 分钟统计最近 1 小时错误量趋势
AppTraces
| where TimeGenerated > ago(1h)
| where SeverityLevel >= 3
| summarize count() by bin(TimeGenerated, 5m)
| render timechart

KQL 的管道式语法(| 串联操作符)读一次就上手:where 过滤、summarize 聚合、render 出图、join 关联。

4. Application Insights:应用代码级日志

给应用装上 Application Insights SDK(或无侵入代理),请求、依赖、异常与 trace 的自动采集范围取决于运行时和配置;关联还依赖上下文传播。工作区表使用 OperationId,应用查询 schema 使用 operation_Id,不能混用字段名或假定所有日志自动关联。受支持的 App Service 配置还可开启 Web Server 日志(如 Windows/IIS)与应用日志;文件系统、Blob 等目的地的支持范围取决于操作系统和运行时。

5. 保留与成本

Log Analytics 费用与摄入量、表计划、保留和查询等有关;交互保留与长期保留不同,支持范围内总保留可达 12 年,需按表计划核对。控费三招:Diagnostic Settings 只开需要的类别;表级保留期差异化;归档需求可评估 Storage Account,同时计算写入、保留、检索与导出费用,不能保证固定降本倍数。

6. 采集 Azure VM 上的应用日志

需要把 Azure VM 的应用日志汇入观测云时,可按 DataKit 日志采集配置文件路径和读取权限。这条路径采集的是 VM 上实际写出的日志,不是 Log Analytics 工作区中的全部数据。

先写入一条带时间、级别和请求标识的测试日志,确认采集端与查看器均可找到。JSON 日志可按文档配置字段解析;再核对时间格式、级别映射和敏感信息处理。保留请求标识方便检索,但与链路跳转关联还需要匹配的 Trace 数据和字段配置。

常见问题(FAQ)

为什么资源日志默认不收集?

设计取舍:资源日志量巨大且按量计费,全开会带来明显成本——所以 Azure 把开关交给用户。生产环境应按资源类型配置关键日志;支持诊断设置的类别用 Diagnostic Settings,网络流日志按 Network Watcher 流程配置。

KQL 难学吗?

不难。会 SQL 的过滤聚合概念即可上手;KQL 在时间序列与日志场景的表达力(ago()、bin()、render)甚至优于 SQL。先掌握 where/summarize/render 三板斧。

Application Insights 和 Log Analytics 是什么关系?

Application Insights 是应用性能管理(APM)功能,数据存在 Log Analytics 工作区里,用同一套 KQL 查询(AppTraces、AppRequests、AppExceptions 等表)。

多云环境日志统一的最佳路径?

先按日志来源分别确定导出与接收方式,再统一时间、服务名和环境字段。主机文件可走 DataKit 日志采集;云服务平台日志需单独验证导出通道、消费端、重试和权限,不能直接套用主机采集步骤。

系列阅读


获取专属方案

联系我们

加入社区

微信扫码
加入官方交流群

立即体验

在线开通,按量计费,真正的云服务!

立即开始

选择观测云版本

代码托管平台