能否依赖Log Analytics日志追踪Azure函数链请求以满足审计需求？

用Log Analytics做审计追踪可行吗？ #

完全可以，但核心是要做好全链路关联和日志采集配置：

• 给每个入站请求生成唯一的CorrelationId，从第一个函数开始，把这个ID带到Service Bus消息的自定义属性里，后续每个函数处理消息时都读取这个ID，在关键节点（请求进入、处理完成、消息发往下一队列）都写入带ID的日志到Log Analytics。这样就能通过这个ID一键串联整个请求的完整链路，精准追踪位置。
• 别吝啬日志，把每个函数的日志级别设为Information，覆盖所有审计需要的关键动作——别只打错误日志，正常流程的节点日志才是审计的核心。

没触发应用异常会丢日志吗？ #

会，而且这种“静默丢失”更难排查，常见场景有这几种：

• 实例回收导致日志未投递：Azure Functions是无服务器架构，实例可能在处理完请求后快速销毁，如果日志还在异步投递到Log Analytics的路上，就会直接丢失。
• 采集配置疏漏：比如某个函数的日志类别没加到Log Analytics的采集规则里，或者工作区设置了数据筛选规则，把审计日志误过滤掉了。
• 底层崩溃未捕获：比如函数进程突然崩溃、内存溢出，这种情况没抛出应用级异常，但代码还没来得及写日志就挂了，自然不会生成日志。

Log Analytics和Azure Tables怎么选？ #

• 选Log Analytics：如果追求快速落地、查询便捷，它自带的Kusto查询能快速聚合链路日志，不用额外写存储逻辑，适合大多数审计场景。
• 选Azure Tables：如果对审计数据的完整性要求到了“零容忍”级别，它的写入可靠性更高——只要你代码里写了写入Table的逻辑且执行成功，数据基本不会丢，但代价是要自己开发存储逻辑，还要处理重试、幂等这些细节，比较繁琐。

怎么提升Log Analytics的可靠性？ #

• 开启持久化日志存储：给函数应用配置本地持久化存储，让日志先写到本地再异步推送到Log Analytics，就算实例回收，本地日志也能后续完成投递。
• 添加日志中转层：用Event Hub当中间件，先把日志发送到Event Hub（它的投递可靠性比直接推Log Analytics高），再从Event Hub转发到Log Analytics，就算函数实例挂了，日志已经在Event Hub里了，不会丢失。
• 做完整性校验：定期用Kusto查询统计每个CorrelationId的日志节点数，和预期的链路节点数对比，发现缺节点就告警，及时排查问题。

内容的提问来源于stack exchange，提问作者axk