请描述在使用 Azkaban 调度工作流时，如何借助日志来定位和分析任务执行过程中的性能瓶颈？可以结合日志的获取方式、关键指标以及分析方法来说明。
考察说明
考察候选人是否理解 Azkaban 任务日志的构成，以及能否从日志中识别性能问题的常见思路。
回答思路
- 【回答框架 1】Azkaban 任务日志主要包含两层：调度器日志和具体 job 的执行日志。调度器日志记录任务提交、排队、开始、结束等生命周期事件，jobb 日志则包含实际运行输出。分析性能问题时，应首先从 Web UI 或 API 获取工作流执行的 job 列表和对应日志。
- 【回答框架 2】关键指标通常在日志中体现为时间戳，如任务提交时间、启动时间、结束时间，以及失败重试信息。通过比较不同 job 的 startTime 和 endTime，可以算出执行时长，识别耗时较长的 job。同时注意日志中的警告，如资源不足、内存溢出等提示。
- 【回答框架 3】分析时可采用漏斗思路：先看工作流整体执行时间，再定位到具体 job，区分是调度延迟（如排队等待）还是执行本身慢。若日志显示 job 在某个时间点提交后长时间未启动，可能是资源限制或并发分数不足；若 job 启动后运行时间长，则重点看 job 内部的日志输出，例如 hive 任务的执行计划或者 SQL 中耗时步骤。
- 【回答框架 4】若日志中存在大量重试记录，需检查失败原因，区分是瞬时错误还是持续性能问题。还可结合 Azkaban 的监控指标（如 CPU、内存）来辅助，但日志仍是定位到具体代码逻辑的主要手段。
- 【回答框架 5】常见工具方法包括：使用日志级别调整获得更详细输出，对日志进行关键字搜索（如 ERROR、WARN），以及利用 Azkaban 提供的 executor 日志和 flow 执行历史来对比不同批次的表现。
- 【关键点 1】Azkaban 日志分为调度器日志和 job 执行日志，分析时需区分。
- 【关键点 2】通过 job 的 startTime 和 endTime 计算执行时长，定位耗时节点。
- 【关键点 3】关注日志中的警告和重试记录，排查资源不足或异常错误。
- 【关键点 4】结合调度延迟和执行延迟进行分层，区分是排队还是运行慢。
- 【关键点 5】利用日志关键字搜索和对比多次执行历史，发现性能波动。
- 【易错点 1】不要只关注 job 的执行日志，忽略调度器日志，否则可能遗漏排队等待问题。
- 【易错点 2】注意不同 job 类型日志格式不同，避免直接统一解析。
- 【易错点 3】性能问题可能源于外部系统，日志中未直接体现，需结合其他监控数据综合判断。