2. Azure数据平台架构概览

Azure数据平台不是单一产品，而是一组职责不同、边界清晰的服务组合。Synapse Analytics负责计算与查询，Data Factory负责数据集成与调度，Databricks负责Spark计算与工程化作业，Data Lake Storage负责持久化存储，Event Hubs负责流式接入。可观测性工程的第一步，不是立刻打开某个监控面板，而是先建立一张“服务—信号—切入点”的对应关系图：每个服务天然产生哪些信号，这些信号从哪里采集，采集后能回答什么问题。

理解这张图的关键在于区分三类信号。第一类是控制面信号，描述资源是否创建、配置是否变更、扩缩容是否发生，例如Synapse工作区或Databricks集群的创建、更新、删除事件，它们通常来自Azure Activity Log。第二类是数据面信号，描述作业与查询实际执行情况，例如Data Factory管道运行、Synapse SQL请求、Databricks作业运行、Event Hubs消息吞吐，它们来自各服务的诊断日志与指标。第三类是依赖面信号，描述服务所依赖的存储、网络、身份是否正常，例如ADLS Gen2的延迟与错误、Key Vault访问、私有终结点连接状态。可观测性切入点，就是为每类信号找到正确的采集通道。

把这张图落到具体服务上，切入点各有侧重。Synapse Analytics的可观测性核心是“工作区诊断设置”。在Synapse工作区中启用诊断设置后，可以把SQL池的请求、等待、连接、失败，以及Spark池的应用、作业、执行器日志发送到Log Analytics。对于专用SQL池，最值得先看的不是CPU，而是等待类型与查询执行时间分布：如果大量时间消耗在RESOURCE_SEMAPHORE或IO_COMPLETION，说明瓶颈在内存授予或存储IO，而不是计算本身。Synapse Studio的Monitor Hub提供管道运行、SQL请求、Spark作业的图形化视图，适合快速定位失败活动，但跨服务关联仍需依赖Log Analytics中的KQL查询。

Data Factory的切入点分为两层。第一层是管道运行监控：在ADF Studio的Monitor中可以看到每次管道运行的触发时间、持续时间、活动状态与错误信息，失败活动会给出错误码和错误消息。第二层是诊断日志：将ADF诊断设置发送到Log Analytics后，可以查询ADFPipelineRun、ADFActivityRun、ADFTriggerRun等表，从而回答“过去24小时哪些管道失败率最高”“哪个活动平均耗时最长”“自承载集成运行时是否成为瓶颈”。一个常见的可观测性切入点是给关键管道配置失败告警，并在告警中携带管道名、运行ID和失败活动名，而不是只发一条“管道失败”的泛化通知。

Databricks的可观测性需要区分作业层与集群层。作业层关注运行状态、持续时间、重试次数、失败原因，可以通过作业运行API、作业UI或诊断日志获取；集群层关注CPU、内存、磁盘、Spark任务与阶段，通常通过Spark UI、Ganglia指标或集群日志观察。对于Delta Lake表，还应关注_delta_log中的事务提交、文件数量、小文件问题以及OPTIMIZE、VACUUM的执行效果。一个实用的切入点是：把Databricks作业运行日志与ADLS Gen2的存储指标放在同一时间轴上对比，判断作业变慢是计算侧还是存储侧引起。

ADLS Gen2是数据平台的持久化底座，它的可观测性切入点主要是存储指标与诊断日志。关键指标包括事务数量、入口/出口流量、端到端延迟、服务器延迟、成功E2E延迟以及各类错误（如AuthorizationFailure、ServerBusy、ThrottlingError）。当上游作业出现间歇性失败时，先看ADLS的延迟与错误指标，往往能快速区分是应用逻辑问题还是存储限流。Event Hubs的切入点则是命名空间与分区级指标：传入/传出消息数、吞吐量、消费者延迟、服务器错误、用户错误、节流错误。对于流式管道，消费者延迟是最能反映“消费是否跟得上”的信号，应优先纳入告警。