如何在Prometheus中监控Cadence运行中的工作流数量

内置指标情况确认 #

你没有遗漏配置，Cadence官方的cadence_history、cadence_worker、cadence_frontend服务默认确实不提供直接统计当前运行中工作流存量的内置指标。你排查到的activity_end_to_end_latency、workflow_success、workflow_terminate、workflow_failed都属于事件触发的增量类、终态类指标，仅能覆盖已结束工作流的统计维度，无法直接计算实时运行的工作流存量。

现有方案的优化方式 #

1. 自定义Gauge埋点方案的缺陷修复 #

你之前写的自定义埋点逻辑之所以统计不准，是因为只覆盖了正常完成、活动执行报错的退出路径，没有覆盖手动终止、超时、取消等异常退出场景。直接用Cadence SDK原生提供的workflow.Defer注册回调即可解决这个问题：该方法注册的逻辑会在工作流退出的所有路径强制执行，不存在漏执行的问题。修正后的示例代码如下：

func MyWorkflow(ctx workflow.Context) error {
    // 工作流启动时计数+1，可按需添加domain、workflowType等标签
    runningWorkflowGauge.WithTags(map[string]string{
        "workflow_type": "MyWorkflow",
        "domain": "default",
    }).Inc()

    // 注册退出回调，无论何种原因退出工作流都会执行减量
    workflow.Defer(ctx, func() {
        runningWorkflowGauge.WithTags(map[string]string{
            "workflow_type": "MyWorkflow",
            "domain": "default",
        }).Dec()
    })

    if err := workflow.ExecuteActivity(ctx, someActivity).Get(ctx, nil); err != nil {
        return err
    }

    // 其余业务逻辑
    return nil
}

如果不想在每个工作流里重复写这段逻辑，可以封装成Cadence的工作流拦截器全局生效，完全不侵入业务代码，也不会出现漏埋的情况。这个方案几乎没有额外性能开销，计数精度最高，是生产环境的首选实现方式。

2. ListOpenWorkflow接口采集方案的优化 #

官方提示该接口压力大，是针对高频、全量拉取的场景。如果你的场景不需要秒级精度的监控，可以把采集间隔拉长到5~10分钟，同时查询时按domain、工作流类型拆分分片请求，避免单次拉取全量数据，对持久层的压力会降到可接受范围，适合没有权限修改工作流代码场景下的粗粒度统计。

其他可行方案 #

• 从持久化层直接采集指标：Cadence的运行中工作流会存在持久化库的executions表中，open状态的工作流对应CloseStatus字段为空的记录，可以直接由数据库侧导出符合条件的表行数指标，完全不占用Cadence服务的API资源，性能开销最低，统计时注意排除软删除的记录即可，有数据库运维权限的团队用这个方案实现成本极低。
• 基于Advanced Visibility采集：如果你的Cadence集群开启了基于Elasticsearch的Advanced Visibility能力，可以直接对ES索引发起count请求，统计CloseTime为0的文档数量作为运行中工作流数。ES的聚合查询性能远高于直接扫描数据库的ListOpenWorkflow接口，10~30秒一次的采集频率不会对集群造成明显压力，还支持按domain、工作流类型等多维度灵活聚合，已经开了高级可见性的集群可以直接用，不需要额外改造。

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