在此阶段，你将设计可观测性和监视策略，以确保卓越运营和主动问题解决。
Azure Databricks提供内置的可观测性功能，用于监视平台操作、工作负荷性能、数据质量和模型服务。 设计可观测性策略，以平衡运营见解与监视成本和复杂性。
设计作业和管道监视策略
监视作业和管道执行，以确保数据管道成功运行并快速识别故障。 根据工作负荷关键性、SLA 和操作要求设计监视策略。
作业监视模式
- 实时警报：配置电子邮件通知或 Webhooks，以应对关键作业失败。
- 趋势分析：使用“工作流和管道监视”页跟踪作业运行历史记录并识别模式。
- 异常情况检测：设置 SQL 警报以监视作业持续时间异常或重复失败。
- SLA 监视：为关键作业定义 SLA，并在作业超出预期运行时时发出警报。
- 依赖项跟踪：监视影响下游工作负荷的作业依赖项和上游故障。
管道监视注意事项
- Lakeflow Spark 声明性管道可观测性：监视管道运行状态、数据质量预期和世系。
- 增量处理：跟踪检查点信息和增量处理指标。
- 数据新鲜度：监视管道延迟并确保数据到达 SLA 窗口。
- 错误处理：设计失败记录的重试策略和死信队列。
作业监视的最佳做法
- 为关键作业失败配置电子邮件通知或 Webhook。
- 使用系统表 （
system.workflow.job_runs，system.workflow.task_runs） 监视作业。 - 设置 SQL 警报以监视作业持续时间异常或重复失败。
- 根据业务需求为关键作业定义 SLA。
- 为常见故障方案实现 Runbook 自动化。
- 定期查看作业性能趋势并优化运行缓慢的作业。
有关详细的作业监控配置，请参阅 Lakeflow 作业的监控与可观测性。
有关 Lakeflow Spark 声明性管道可观测性，请参阅 “监视管道”。
设计 Spark 性能监视策略
监视 Spark 作业性能，以确定瓶颈，例如倾斜、溢出、长时间运行的任务以及内存或 I/O 问题。 根据计算类型和性能要求设计 Spark 监视方法。
无服务器化和 SQL 仓库的查询概要
对于无服务器计算和 SQL 仓库，请使用查询配置文件分析和优化查询性能。 查询剖面提供详细的执行计划、阶段级指标和优化建议。
查询配置功能
- 使用阶段级指标可视化查询执行计划。
- 确定成本高昂的操作（例如排序、联接、聚合）。
- 分析数据倾斜和分区不平衡。
- 查看查询优化器中的优化建议。
- 比较不同运行中的查询性能。
查询概况的最佳做法
- 识别慢查询的查询剖析，以识别优化机会。
- 专注于执行时间较高或数据偏斜的阶段。
- 实现建议的优化，例如分区修剪和广播联接。
- 优化后监视查询性能，以衡量改进情况。
适用于经典计算的 Spark UI
对于经典计算群集，请使用 Spark UI 确定性能瓶颈和资源约束。 Spark UI 提供有关执行程序、阶段、任务和存储的详细指标。
Spark UI 功能
- 监视阶段执行时间和任务分布。
- 通过分析任务工期差异来识别数据倾斜。
- 跟踪内存使用情况和溢出指标。
- 查看执行程序指标（例如 CPU、内存、磁盘 I/O）。
- 分析随机读取/写入模式。
Spark UI 的最佳做法
- 启用群集日志传送到云存储以实现长期日志保留。
- 监视群集指标（例如 CPU、内存、磁盘 I/O），以确定资源约束。
- 查看 Spark 事件日志，排查作业缓慢问题并优化配置。
- 专注于具有高乱序或数据溢出的阶段，以减少内存压力。
- 优化分区大小以减少任务倾斜。
有关查询配置文件文档，请参阅 查询配置文件。
有关 Spark UI 故障排除指南，请参阅 Apache Spark 概述。
设计模型监控策略
监视已部署的 ML 模型以跟踪性能、运行状况和请求指标。 根据模型关键性、SLA 要求和合规性需求设计模型监视策略。
模型服务可观测性功能
- 终结点运行状况：监视终结点可用性和运行状况。
- 调用指标：跟踪请求计数、延迟和吞吐量。
- 推理表：记录预测和分析模型行为随时间推移。
- 模型版本跟踪：监视模型版本使用情况和部署历史记录。
- 错误监视：跟踪错误率和故障模式。
模型监视模式
- 实时警报：为异常设置警报，例如高延迟或错误率。
- SLA 监视：为生产模型定义延迟和可用性 SLA 标准。
- 推理分析：使用推理表分析预测分布并检测偏移。
- A/B 测试：监视模型版本的性能以验证改进。
- 回滚过程：根据性能阈值定义自动回滚触发器。
模型监视的最佳做法
- 监视终结点运行状况和调用指标，以确定性能问题。
- 跟踪延迟和请求吞吐量，以确保 SLA 符合性。
- 使用推理表记录预测和分析模型行为。
- 为异常设置警报，例如高延迟或错误率。
- 监视模型版本使用情况以跟踪部署和回滚。
- 记录模型性能基线和可接受的阈值。
设计第三方监视集成策略
将Azure Databricks与外部监视解决方案集成，以便在整个基础结构中集中观察。 根据现有的监视工具、操作要求和团队专业知识设计集成策略。
第三方集成模式
- 中心化监视：将Azure Databricks指标和日志转发到集中式监视平台。
- Multi-cloud 可观测性：使用与云无关的工具跨多个云监视Azure Databricks。
- 自定义仪表板：构建结合Azure Databricks和外部系统指标的统一仪表板。
- 警报集成：通过现有的事件管理系统路由 Azure Databricks 警报。
- 合规性报告：聚合符合性和审核要求的日志。
集成选项
- Datadog：使用 Datadog 集成监视群集指标、作业运行和应用程序日志。
- Prometheus：将群集指标导出到 Prometheus，以便进行时序监视和警报。
- Azure Monitor：将日志转发到Microsoft Azure Databricks部署的Azure Log Analytics。
- Microsoft Sentinel：将审核日志与 Microsoft Sentinel 集成，以便进行安全监视。
第三方集成的最佳做法
- 使用标准集成（例如 Datadog、Prometheus），如果有可用。
- 将日志转发到集中式日志记录平台，以便长期保留。
- 将Azure Databricks指标与基础结构指标相关联，以便进行根本原因分析。
- 跨Azure Databricks和外部系统实现一致的标记。
- 定期测试警报路由和升级过程。
可观测性建议
推荐
- 为所有元存储启用系统表以捕获全面的使用情况数据。
- 基于系统表创建仪表板，以便进行成本、性能和安全监视。
- 使用严重故障警报配置作业和管道监视。
- 启用 Spark 监控（查询分析、Spark UI）以便进行性能故障排除。
- 为关键生产表（黄金层）创建 Lakehouse 监控系统。
- 监视模型服务终端，以监控延迟、错误率和吞吐量。
- 与第三方监视解决方案集成，实现集中可观测性。
- 为关键工作负荷定义 SLA 和警报阈值。
- 编写常见操作场景的Runbook。
根据要求进行评估
- 权衡监视粒度与运营开销和成本之间的关系。
- 仅当需要集中监视时，才考虑第三方集成。
- 根据 SLA 要求评估实时警报功能与批处理监视。
- 考虑大型表的数据质量监视成本（例如存储、计算）。
- 通过从保守的阈值开始和随着时间的推移优化来测试警报疲劳。
阶段 9 结果
完成阶段 9 后，应具备：
- 为作业和管道监视配置了针对严重故障的警报。
- 设计了 Spark 性能监视方案（Spark UI, 查询概况）。
- 专为 ML 终结点设计的模型监视策略。
- 定义的第三方监视集成方法（如果适用）。
- 为关键工作负荷所记录的 SLA 和警报阈值。
- 为常见监视场景创建的运行手册。
下一阶段： 阶段 10：设计高可用性和灾难恢复
实施指南：要获取关于实施您的可观测性策略的分步指南，请参阅 Lakeflow 作业的监控与可观测性。