Azure Stream Analytics不定期停止问题排查求助

嘿，我来帮你一步步排查这个Azure Stream Analytics（ASA）不定期静默停止的问题——这种无明显报错的故障确实挠头，咱们从作业状态、输入格式、上下游环节逐个拆解：

首先别只看表面的“停止”状态，得抠细节：

• 打开ASA作业的概述面板，查看「状态历史」：确认停止时的状态是“已停止”还是“失败”？有些时候看似停止，其实是触发了“暂停”，状态历史里会记录触发原因（比如资源不足、输入断开）。
• 务必检查诊断日志：如果还没开，赶紧去「监视」>「诊断设置」里开启，把日志发到Log Analytics。哪怕主界面没报错，日志里大概率藏着线索——比如输入数据源断开、输出写入超时、消息解析失败这类低级别告警，都是静默停止的常见诱因。
• 盯紧ASA的核心度量指标：
  • 「输入事件数」：停止前有没有突然暴跌？如果API发消息的环节断了，ASA长期无输入，会不会触发了「自动停止」（去「配置」>「自动停止」里看看有没有开这个功能）？
  • 「延迟」：有没有持续的高延迟？消息积压过多时，ASA可能触发内部保护机制停摆。
  • 「输出成功率」：如果Table Storage写入失败（比如权限过期、容量满了），有时候不会直接报错，但会导致作业卡住，最终静默停止。

既然你怀疑格式问题，咱们精准验证：

• 抓原始消息：用az eventhubs event read命令（或者开启Event Hub的「捕获」功能把消息存到Blob），拿到API发送的原始消息。然后对比ASA输入配置里的事件序列化格式（JSON/CSV/AVRO）是否完全匹配——比如ASA设的是JSON，但API发的是未转义引号的非标准JSON，就会导致解析失败。
• 检查错误处理策略：去「输入」>对应Event Hub输入>「错误处理」里看，是不是设成了「停止作业」？如果是，哪怕一条格式错误的消息，都会直接停掉作业，这种情况日志里会有明确记录。
• 用测试查询验证：把抓到的原始消息放到ASA的测试查询功能里跑一遍，看有没有隐性的解析错误——比如ASA期望是数字字段，但消息里传的是字符串，这种类型不匹配的问题不会立刻报错，但会让作业运行异常，时间久了可能停摆。

ASA的输入依赖EH，环节出问题也会连累作业：

• 看Event Hub的度量指标：有没有「分区不平衡」？比如API只往一个分区发消息，导致该分区消息积压，ASA读不过来，引发内部错误。另外，有没有「消息保留期过期」？如果ASA长时间没消费，消息过期后也可能导致输入断连。
• 检查API的发送逻辑：有没有批量发送时混入空消息、格式不一致的消息？另外，API有没有处理EH的限流？如果EH返回限流错误，API没做重试，导致消息断发，ASA长期无输入也可能触发停止。

输出端的问题也会导致作业静默停止：

• 检查Table Storage的度量指标：有没有「服务器超时」「写入失败」？比如吞吐量不够、SAS token过期、Managed Identity权限被撤销，都会导致ASA无法写入，进而卡住停摆。
• 核对输出配置：有没有把批处理大小设得过大？批处理太大容易触发Table Storage的写入超时，重试多次后作业可能停止。另外，Table Storage的分区键/行键有没有为空的情况？这会直接导致写入失败，引发作业异常。

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