一、为什么要关注日志管理？
在云原生的世界里，服务跑在容器里，节点可能随时自动扩缩，一个微服务出问题，原因可能藏在好几个不同的组件里。如果没有一套统一的日志系统，排查问题就像大海捞针。Azure 的云原生日志体系能帮你把所有日志收拢到一块，然后用类似 SQL 的查询语言（Kusto Query Language，简称 KQL）快速定位问题，还能设置自动告警。我见过不少团队，前期图省事只靠 kubectl logs，结果线上故障时手忙脚乱。今天咱们就用最生活化的方式，从零开始走一遍 Azure 日志管理的实践。
二、Azure 云原生日志体系概览
Azure 的核心日志服务叫 Azure Monitor，它下面又分好几个组件：
- Log Analytics 工作区：存放日志数据的地方，相当于一个巨大的数据库。
- Application Insights：专门用来监控应用性能，比如请求耗时、异常堆栈。
- Container Insights：针对 AKS（Azure Kubernetes Service）容器环境的监控。
它们背后都使用同一种查询语言：KQL。你只需要把日志灌进工作区，剩下就是写查询语句。需要注意的是，日志数据是按量收费的，所以不是所有日志都值得保留很久，后面咱们会说到注意事项。
三、实战：把 AKS 容器日志收集到 Log Analytics
咱们用一个最典型的场景：一个跑在 AKS 上的 ASP.NET Core 应用，把输出日志送到 Azure 的日志工作区。
3.1 准备工作
首先你得有一个 Azure 订阅，并且已经部署了一个 AKS 集群。如果没有，可以先在 Azure 门户上创建一个免费的集群（资源组和命名随意）。然后你需要安装 Azure CLI，并登录：
# 登录 Azure
az login
# 设置当前订阅（替换成你的订阅ID）
az account set --subscription "你的订阅ID"
# 获取 AKS 集群凭据，之后才能用 kubectl 操作
az aks get-credentials --resource-group 我的资源组 --name 我的AKS集群
3.2 为 AKS 启用 Container Insights
Azure 有个现成的解决方案叫 Container Insights，它会自动在集群里安装一个 DaemonSet 收集容器日志和指标。用下面的命令一键开启：
# 开启 Container Insights，这会创建一个默认的 Log Analytics 工作区
az aks enable-addons --addons monitoring --resource-group 我的资源组 --name 我的AKS集群
命令执行完后，Azure 会自动创建一个 Log Analytics 工作区（名字类似 DefaultWorkspace-xxx）。你可以用下面的命令查看工作区 ID：
# 列出工作区
az monitor log-analytics workspace list --resource-group 我的资源组 --query "[].{name:name, id:customerId}" -o table
3.3 部署一个会写日志的示例应用
为了演示效果，咱们手动部署一个简单的 dotnet 容器，它会不断往标准输出写日志：
# 创建一个命名空间（可选）
kubectl create namespace demo-logs
# 创建一个部署，使用官方 dotnet 镜像，并让它每隔5秒输出一行日志
kubectl run dotnet-logger --image=mcr.microsoft.com/dotnet/samples:aspnetapp --namespace=demo-logs --port=80 -- /bin/bash -c "while true; do echo 'App is running at '$(date); sleep 5; done"
等 Pod 运行起来后，你可以用 kubectl logs 查看原始日志，但这不是咱们的目的。关键是让这些日志自动进入 Log Analytics。由于 Container Insights 默认会收集 stdout/stderr，所以这些日志已经自动被你收集了。你可以稍后在日志工作区里查询。
3.4 验证日志是否已流入
等待几分钟，让日志数据被传输，然后查询工作区：
# 使用 az monitor log-analytics query 执行一条简单的 KQL 查询
az monitor log-analytics query --workspace "你的工作区名称" --query "ContainerLog | where TimeGenerated > ago(10m) | project TimeGenerated, LogEntry | limit 10" --output table
如果能看到表格输出，说明日志已经进来了。
四、实战：用 KQL 查询日志定位问题
KQL 有点像 SQL，但语法更清新。咱们结合刚刚收集到的 ContainerLog 表，做一些常见的查询。
4.1 查看最近一小时的错误日志
// 查询 ContainerLog 表中最近一小时的所有 Error 或 Exception 级别的日志
ContainerLog
| where TimeGenerated > ago(1h) // 只取最近一小时的数据
| where LogEntry has_any ("error", "exception") // 不区分大小写
| project TimeGenerated, Computer, ContainerName, LogEntry // 只展示需要的字段
| order by TimeGenerated desc
| take 50
把这段 KQL 复制到 Azure 门户的 Log Analytics 查询编辑器里，或者直接用 CLI 也能执行。注意：KQL 是 Azure 的原生查询语言，不是任何编程语言，所以咱们的技术栈就是 KQL + CLI 组合。
4.2 统计每个容器产生的日志量
如果你想看哪个容器是“话痨”，可以这样查：
ContainerLog
| where TimeGenerated > ago(1d)
| summarize LogCount = count() by ContainerName
| order by LogCount desc
4.3 关联 Pod 日志和 Kubernetes 事件
有时候 Pod 重启了，日志里看不出原因，这时候可以看看 Kubernetes 事件表：
// 先找最近有重启的 Pod
let restartedPods = KubePodInventory
| where TimeGenerated > ago(1h)
| where PodRestartCount > 0
| distinct PodName;
// 再查这些 Pod 的日志
ContainerLog
| where TimeGenerated > ago(1h)
| where ContainerName in (restartedPods)
| project TimeGenerated, LogEntry
| take 100
这里我们用了一个 let 定义临时表，再把结果合并。这种写法在排查多组件问题时很好用。
五、实战：设置告警，让系统替你盯
光有查询还不够，线上环境不可能有人一直盯着控制台。可以基于 KQL 查询结果创建告警。比如当某个容器的错误日志在5分钟内出现超过10次，就发邮件给团队。
5.1 通过 Azure CLI 创建日志搜索告警
先确定你的工作区资源 ID：
# 获取工作区资源 ID
WORKSPACE_ID=$(az monitor log-analytics workspace show --resource-group 我的资源组 --name 你的工作区名称 --query id -o tsv)
然后用下面的命令创建一个基于查询的告警规则（这里简化了，实际需要先创建 Action Group，但为了演示，我们直接发到你的邮箱）：
# 创建一个简单的日志告警规则
az monitor scheduled-query create \
--resource-group 我的资源组 \
--name "错误日志过多告警" \
--scopes $WORKSPACE_ID \
--condition "count > 10" \
--evaluation-frequency 5m \
--query "ContainerLog | where TimeGenerated > ago(5m) | where LogEntry has_any ('error','exception')" \
--action-groups "/subscriptions/.../resourceGroups/.../providers/microsoft.insights/actionGroups/我的邮件组" \
--description "当5分钟内错误日志超过10条时触发"
注意：--action-groups 需要提前创建好一个 Action Group（在 Azure 门户 -> Monitor -> Alerts -> Action Groups），把邮箱加进去。
六、应用场景与优缺点
应用场景
- 微服务故障排查：当用户反馈某个功能异常，先用 KQL 查那个服务的容器日志，再关联上游服务的日志，快速定位。
- 性能监控：利用 Application Insights 自动收集请求响应时间，配合自定义日志，分析慢查询。
- 安全审计：把审计日志（如登录失败、权限变更）集中到 Log Analytics，设置异常行为告警。
优缺点
优点：
- 全托管，无需自建 Elasticsearch 集群，运维成本低。
- 与 Azure 其他服务（AKS、App Service、Functions）原生集成，配置简单。
- KQL 查询效率高，支持各种关联、聚合和可视化（如时间线图）。
缺点：
- 日志量大了费用不低，需要合理控制数据保留期和筛选入库。
- 查询速度受限于工作区的分区策略，如果数据量极大，可能需要开启列式存储（付费）。
- 对于非 Azure 环境（如本地 IDC 或其他云）的日志接入，需要额外配置代理。
注意事项
- 成本控制：别把调试日志全写上去。可以在应用里区分日志级别，只把警告及以上级别发送到 stdout，然后通过 Container Insights 的配置过滤掉 Info 级日志。或者设置 Log Analytics 工作区的数据保留期为7天，归档到存储账号。
- 权限管理：不要把日志工作区的读者权限开放给所有人，敏感信息（如数据库密码）会出现在日志里，建议开启日志脱敏。
- 查询性能：KQL 的
where条件尽量使用索引列（如TimeGenerated、_ResourceId），避免全表扫描。如果查询总是超时，考虑增大时间范围或对表进行分区。
七、文章总结
在 Azure 云原生环境下，日志管理不再是麻烦事。Container Insights 一键接入，KQL 让查询变得灵活高效，结合告警机制可以实现自动化运维。关键在于从一开始就设计好日志策略：哪些日志必须保留、保留多久、如何分词。不要等到出问题再去翻日志。另外，别忘了定期检查日志费用，避免月底收到意外账单。希望今天的实践能帮你少走弯路，让你的 Azure 应用跑得稳稳当当。
Comments