Azure Data Factory错误推送Slack：两种方案的效率与成本对比

结论：方案1更优 #

方案1（Log Analytics警报+操作组+Logic App）在资源利用率、成本控制、通知及时性上全面优于方案2。

效率对比 #

• 方案1是事件触发模式：只有当ADF实际出现错误（Log Analytics查询返回结果）时，才会触发警报并调用Logic App发送Slack通知，全程无无效空跑，资源利用率拉满。而且Azure平台的警报调度延迟极低，错误发生后能快速收到通知。另外，警报规则可直接将start、end、status等维度嵌入触发参数，Logic App无需编写复杂的JSON解析逻辑，维护成本更低。
• 方案2是定时轮询模式：无论是否有错误，每5分钟都会执行一次Log Analytics查询和判断逻辑。哪怕全天无错误，也会空跑288次，属于纯粹的资源浪费。且若错误恰好发生在两次轮询间隔内，最多需等待5分钟才能收到通知，及时性明显不足。

成本对比 #

• Log Analytics查询费用：方案1仅在触发警报时执行查询（或按警报评估频率执行，但无结果时不会产生后续动作）；方案2每5分钟必执行一次查询，长期累积下来查询费用会高出不少。
• Logic App运行费用：方案1仅在有错误时启动流程，按实际运行次数计费；方案2每5分钟都会启动一次流程，即便无错误也会消耗触发和查询步骤的费用，日积月累成本差异会很显著。

额外优势 #

• 扩展性：方案1新增ADF实例或错误类型时，仅需调整警报规则的查询语句即可；方案2则需修改Logic App的轮询逻辑，复杂度更高。
• 可靠性：Azure警报服务为平台托管，比手动在Logic App中编写的轮询逻辑更可靠，不会因Logic App自身故障导致错误通知遗漏。

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