无需App Insights，如何监控Azure函数应用的触发与代码卡顿情况？

• 本地/持久化日志输出
  直接在函数代码里给关键节点加日志，比如作业触发前、启动时、核心步骤完成时，把日志写到Azure Blob存储或者文件存储里，避开App Insights的实时上报。比如用Console.WriteLine或者自己写个简单的日志类，把作业ID、触发时间、当前状态、耗时这些信息存起来，之后批量分析日志就能定位哪些作业没真的启动，或者卡在了哪个环节。

• 轻量级自定义指标追踪
  不用App Insights的全量监控，自己搞个简单的指标收集逻辑。比如用Azure表存储来存每个作业的生命周期数据：作业ID、触发时间、预期启动时间、实际启动时间、结束时间、状态。在函数触发入口、业务逻辑开始、结束这几个节点把数据写进去，之后查一下表存储就能对比UI显示和实际状态的差异，也能统计出哪个环节耗时最长。

• 函数内部埋点计时
  在代码的关键代码块前后记个时间戳，比如：

  var startTime = DateTime.UtcNow;
  // 要监控的代码逻辑
  var elapsed = DateTime.UtcNow - startTime;
  // 把耗时和代码块标识写入日志或存储
  

  这样能精准定位到函数内部哪段代码卡顿，比如是队列处理慢，还是业务逻辑里的某个API调用超时了。

• 用Azure Functions内置日志系统
  开启函数应用的文件系统日志（默认一般是开着的，也能在配置里调日志级别），直接从Kudu控制台看日志文件，或者通过Azure门户的“日志流”实时查看（注意别长时间开，避免影响性能）。这些日志会记录函数的触发事件、执行状态，能快速确认作业是不是真的被触发了，以及执行过程中有没有报错。

• 排查资源瓶颈
  作业没启动或超时大概率和资源不够有关，直接看函数应用的应用服务计划指标：CPU使用率、内存占用、队列长度（如果是队列触发的话）。比如队列堆得老高，说明函数实例处理不过来，导致作业延迟启动；CPU或内存一直满负载，可能是代码里有内存泄漏或者低效逻辑，得优化。

• 验证触发机制
  如果是定时触发或事件触发的作业，直接检查触发源状态：比如定时触发的CRON表达式对不对，事件源（比如Blob、Event Hub）有没有产生事件但没被函数拾取。可以在触发入口加个日志，确认触发请求到底有没有传到函数里。

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