问题描述
在 Azure Container Apps 中，需要将容器应用产生的日志集中发送到 Log Analytics Workspace，以便后续进行日志查询、监控和故障排查。
Azure Container Apps 主要提供 Console Logs、System Logs，以及通过 Diagnostic Settings 启用的 HTTP Logs。Console Logs 来自容器的 stdout/stderr，System Logs 由 Azure Container Apps 平台产生。
Azure Container Apps 环境支持不同的日志目标。其中选择 Azure Monitor 后，日志不是简单地直接写入 Log Analytics Workspace，而是需要通过 Diagnostic Settings 配置路由，可以发送到 Log Analytics Workspace、Storage Account、Event Hub 等目标。
实际使用过程中，一个常见问题是：
为什么 Container App 已经产生了日志，但 Log Analytics 中需要等待几分钟才能查询到？这个 latency 是否可以消除或调整？
问题解答
1. Azure Container Apps 的 Azure Monitor 日志链路
选择 Azure Monitor 作为 Azure Container Apps 的 Logs Destination 后，可以通过 Diagnostic Settings 将日志发送至 Log Analytics Workspace。Microsoft 文档明确指出 Azure Monitor 可以将 Container Apps 日志路由至 Log Analytics Workspace、Azure Storage、Event Hub 或支持的合作伙伴监控方案。
当环境的 Logs Destination 选择 Azure Monitor 时，日志链路可以用下面的逻辑图说明：
图示说明：
| 环节 | 作用 |
|---|---|
| Container App | 应用将 Console Logs 输出到 stdout/stderr。System Logs 则由 Container Apps 平台产生，并非应用输出。 |
| Azure Container Apps Logging | 表示 Container Apps 的日志采集能力，是逻辑环节，不是需要单独创建的 Azure 资源。 |
| Azure Monitor / Resource Logs | 表示通过 Azure Monitor 资源日志机制提供日志数据。 |
| Diagnostic Settings | 配置需要收集的日志类别与发送目标；它是路由配置，并不是独立的日志存储服务。 |
| Log Analytics Workspace | 摄取并存储日志，供后续查询和分析。 |
| KQL 查询 | 查询已完成摄取、可以检索的日志，不是直接读取容器的实时输出。 |
这种架构的优势是可以利用 Azure Monitor 的标准 Diagnostic Settings 机制，将不同类别的日志灵活路由到不同目标，而并非只能存储在单一 Log Analytics Workspace 中。图中的 Log Stream 则是用于实时查看容器输出的另一种方式，不需要等待日志在 Workspace 中变为可查询。
2. Log Analytics 中可以看到什么日志
Azure Container Apps 提供不同类型的日志用于监控和排障，包括：
- Console Logs：应用程序产生的日志，也就是容器的 stdout/stderr。
- System Logs：Azure Container Apps 平台产生的日志，例如 Revision provisioning、Dapr、Volume Mount、Domain Binding 等相关平台事件。
- HTTP Logs：Ingress 层产生的 HTTP 请求日志，需要通过环境级别的 Diagnostic Settings 启用。
Microsoft 文档同时明确指出，Log Analytics 中可以使用对应日志表查询这些数据，例如 Console Logs 和 System Logs。
3. 为什么 Azure Monitor 模式会存在 Latency
Microsoft Learn 明确说明：
发送到 Log Analytics Workspace 或 Azure Monitor destination 的 Container Apps 日志不会立即可用。新的 Console Logs 和 System Logs 记录通常需要等待数分钟后才能在目标中查询。
因此：
Container App 已经输出日志 ≠ Log Analytics 立即能够查询到该日志。
Azure Monitor 对 latency 的定义，是从数据在被监控系统中产生，到最终能够在 Azure Monitor 中进行分析之间的时间。
特别需要区分的是，Microsoft Learn 中提到普通 Azure Monitor 日志摄取的平均延迟小于 10 秒，但这是 Azure Monitor ingestion 本身的指标，并不能直接理解为所有 Azure Resource Logs 从源服务产生到 Log Analytics 可查询只需要 10 秒。对于 Azure Metrics、Resource Logs 和 Activity Logs，文档单独给出了更大的 latency 范围。
4. Resource Logs 的典型延迟范围
对于 Azure Metrics、Resource Logs 和 Activity Logs，Microsoft 给出的整体范围是：
30 秒到 20 分钟。
其中最新 Microsoft Learn 文档进一步说明，Resource Logs 通常需要约 3--10 分钟才能变为可用，实际时间取决于具体 Azure Service 以及处理复杂度。
需要注意，以上是 Azure Monitor 对多种 Azure 数据类型的说明，不是 Container Apps 专属的延迟 SLA，也不是每条日志的固定等待时间或最大延迟保证。
Container Apps 使用 Azure Monitor 作为日志目标时，通过 Azure Monitor Resource Logs / Diagnostic Settings 路径进行日志处理，因此观察到分钟级延迟并不意味着 Container App 没有产生日志，也不能仅凭这个现象判断 Log Analytics 出现异常。
5. 能不能调整这个延迟？
在这条托管日志链路中，没有可供用户直接设置端到端延迟的配置项。不能通过 Diagnostic Settings 指定"立即入库"或将可查询延迟调整为某个固定值。
如果应用要求的是集中存储、KQL 分析、日志关联、历史查询或基于日志的数据分析，那么 Azure Monitor + Diagnostic Settings + Log Analytics Workspace 是合适的方案。
但如果实际需求是：
"Container 刚输出一条日志，我希望立即看到。"
那么不应该把 Log Analytics 当作严格意义上的实时日志流。
Microsoft 的 Container Apps 文档建议，如果需要实时查看 Container 输出，使用 Log Stream 功能。
因此可以简单总结为：
| 使用场景 | 推荐方式 |
|---|---|
| 日志分析、集中存储、历史查询 | Log Analytics |
| 实时查看容器输出、现场排障 | Log Stream |
两者解决的是不同场景，并不冲突。
参考资料
- Azure Container Apps 日志存储和监视选项：介绍日志目标、Diagnostic Settings，以及日志可查询前的分钟级延迟。
- 使用 Log Analytics 监视 Azure Container Apps 日志：介绍 Console Logs、System Logs、HTTP Logs 及其查询方式。
- Azure Monitor Diagnostic Settings：介绍资源日志类别及 Log Analytics Workspace、Storage Account、Event Hub 等目标的配置。
- Azure Monitor 日志数据摄取时间：解释端到端延迟、Azure 数据可用时间与 Azure Monitor 处理时间的区别。
- Azure Monitor Resource Logs：介绍资源日志及其收集机制。
- Azure Container Apps 实时日志流：介绍如何实时查看系统日志和容器控制台输出。
当在复杂的环境中面临问题，格物之道需：浊而静之徐清，安以动之徐生。 云中，恰是如此!