Task	监控	性能	优先级	完成度
系统负载能力	✅		high
压力测试		✅	middle
任务积压	✅		middle	doing
仪表盘分析	✅		middle
组建优化		✅	middle
业务细粒度监控	✅		middle	todo

目前的风险点及后续规划思考

1. 目前没有一个地方能直观看到 Temporal Server 到底能扛多大业务量（属黑盒）
2. 实时的积压情况，什么时候该扩容，什么时候该调整
3. 业务接入后无法及时判定是否正常（客诉、报警）
4. 无细粒度的监控（请求率、错误率、延迟）

延迟优化

1、系统负载能力（吞吐量）：每秒完成的工作流数量=> 状态转换操作（持久化写入）

2、请求时间性能调优

• History
  • 分片锁的延迟：Temporal 使用分片在历史 Pod 间划分命名空间工作流历史的责任，每个 Pod 管理一组分片。每个工作流历史记录属于单个分片。在创建或更新工作流历史记录之前，必须获取片锁。分片数量越大，锁争用越少
  • 解法：调整 Shards 数
• Matching
  • 计划延迟：请求任务的时间和处理任务的时间之间将会存在延迟
    • 同步匹配：从其内存中向其传递任务。如果内存中某个任务的时间过长，则该任务将刷新到持久性数据库
    • 异步匹配：持久性数据库的任务需稍后再次加载以交给轮询器
  • 解法：调整内存和 Pods 数

监控报警

1、任务积压

• taskQueue 级别的监控（metrix 指标）

2、压力测试

• 一般数据库为瓶颈
• 关注指标：schedule_to_start_latency

仪表盘统计分析

• 服务指标
  • 对服务使用情况的基本可见性，允许查看跨服务、名称空间甚至操作的请求率：service_requests, service_errors和service_latency
    • 包含字段：类型、操作和名称空间
• 持久性指标
  • 每个操作的请求率、错误率或延迟：persistence_requests, persistence_errors和persistence_latency
• 工作流执行统计
  • 工作流执行完成的总体统计：workflow_success, workflow_failed, workflow_timeout, workflow_terminate, workflow_cancel      

业务监控

• 改写 Worker.Option 代码，配置默认采集项
• 封装 SDK 统一接入