嘉宾 | 罗凯 整理 | 李天天
出品 | CSDN云原生
业务中当前有多少个端到端工作流实例，它们的状态是什么？在过去的24小时内，有多少个工作流实例未成功完成？为什么未成功完成？完成工作流程实例或工作流程中的特定步骤平均需要多少时间？
针对以上发问，2022年8月9日，CSDN云原生系列在线峰会第15期“Prometheus峰会”上，中海庭运维开发工程师罗凯从企业业务形态及云原生工作流的使用情况入手，分享了Prometheus监控Argo Workflow云原生工作流的方法。
Argo Workflow监控实例
容器化CI + Argo Workflow实现生产的Devops
在引入K8s前，一般使用传统PC工具对数据入库、任务排产及任务派发进行处理，该过程需要人工处理、手动配置，但存在诸多弊端：
PC算力有限，大数据集情况下，人工处理效率低下；
手动配置易出错，难以及时发现问题。
于是，我们引入了K8s，利用Argo Workflow任务编排调度实现数据的自动化处理。
从传统PC工具转型Web化工具，通过容器沙箱提供生产需要的工具并通过CI/CD集成相应的数据容器组成独立的沙箱工作环境，并在需要与人交互的环节提供Web界面和专用的Web访问地址。
规范化作业信息流、数据流，自动化代替手动环境准备。
操作数据集的提交、流转通过CI/CD自动完成。
Arogo Workflow实现生产数据编译的任务调度
首先根据用户的定制化需求制定编译工具链及相应配置，随后在数据上游进行数据拉取、串联，并进行GRB、EFD处理，最终交付给客户。其中，在EFD处理完成后，NDS的配置会根据EFD的数据结果动态生成，整个工作流程十分复杂，手工处理耗时，容易出错。
使用Argo Workflow进行编排后，数据处理流程会变得清晰。通过CI/CD动态提供相应的编译工具单元形成自动化工具链，取代手工部署配置环节提高编译效率，保证数据质量。
Argo Workflow介绍
什么是Argo Workflow
Argo Workflow是一个开源项目，为Kubernetes提供Container-native工作流程，主要通过Kubernetes CRD实现。它有四大特点：
容器云原生：工作流的每一步都是一个容器，可以通过环境变量注入配置；
建模：将多步骤工作流建模为一系列任务，或者使用有向无环图（DAG）描述任务之间的依赖关系；
易调度：可以在短时间内轻松运行用于机器学习或数据处理的计算密集型作业；
配置简单：在Kubernetes上运行CI/CD Pipeline，无需复杂的软件配置。
云原生工作流种类多样，为什么要选择Argo Workflow呢？
Airflow虽然是老牌任务管理、调度、监控，但存在语言强绑定以及过于依赖Python的缺点。
K8s原生Workflow的使用简单直接，但灵活度过差。
Apache Dolphin Scheduler的界面十分友好，任务定制简单，但API不友好，模板编排不灵活。
Argo Workflow与云原生结合紧密，专注于编排并行任务，容器编排灵活，并且模板编排支持模块化，能够有效提高调度效率。
Argo Workflow简单样例
Argo Workflow简单样例——dag
在编排过程中，首先定义一个echo模板，将模板的输入参数message直接打印到控制台。
其中，dag编排任务过程中最关键的部分是通过dependencies进行依赖。上图中的依赖关系为：B依赖A、C依赖A、D依赖B与C，故任务的执行顺序十分明朗：A先执行，随后B与C同时执行，最后执行D。
Argo Workflow简单样例——Steps
在Step步骤中，可以通过不同的标识来控制串行、并行。
“--”代表和上一步串行 ；
“–”代表和上一步并行。
如上图所示，我们可以看出，hello1与hello2a串行，hello2a与hello2b并行。
我们的Argo Workflow编排样例
在实际过程中，由于业务形态种类多样，因此会有很多并行、串行dag等任务的编排。
其中包含根据上一步运行结果的不同来运行不同的后续步骤的编排，也有根据不同的外部业务调用不同API生成不同的步骤的编排。
监控工作流关心的指标
从监控的角度来看，主要有以下几个指标需要重点关注：
每个工作流的运行耗时；
工作流中失败的步骤
l工作流运行总数；
集群资源以及工作流资源消耗情况等。
Prometheus Vs. Prometheus Operator
在Prometheus中我们需要手动维护配置文件，而在K8s集群中配置文件的维护十分不方便，因此引入Prometheus Operator ，通过K8s原生资源CRD的方式来管理监控。
在集群中，一组需要监控的export(Service)就是一个ServiceMonitor对象，Prometheus Operator会自动监控ServiceMonitor对象的改变而自动生成对应的配置，这样就不需要手动更改Prometheus的配置了。
上图是Prometheus Operator的架构图，其中Operator是最核心的部分，作为一个控制器，它会创建Prometheus、ServiceMonitor、AlertManager以及PrometheusRule 4个CRD资源对象，随后一直监控并维持这4个资源对象的状态。
其中，所创建的Prometheus资源对象作为Prometheus Server存在，而ServiceMonitor就是exporter的各种抽象，exporter用于提供Metrics数据接口。Prometheus正是通过ServiceMonitor提供的Metrics数据接口来Pull数据的。
Service和ServiceMonitor都是K8s的资源，一个 ServiceMonitor可以通过labelSelector的方式去匹配一类Service，Prometheus也可以通过labelSelector去匹配多个ServiceMonitor。
因此，当我们想要在集群中监控数据时，便可以直接操作Kubernetes集群的资源对象，操作更便捷。
Argo Workflow的ServiceMonitor
Argo Workflow作为一个云原生的编排工具，在Prometheus中，只需建立一个类型为ServiceMonitor的资源对象，并将selector指向workflow-controller，就可以实现对指标的自动拉取。
总结
Argo Workflow容器编排灵活并与云原生紧密结合，能够充分利用原生态的工具，大幅提高调度效率。它目前正处于快速迭代中，值得我们共同探索，相信在将来的云原生生态系统中，Argo Workflow会不负期待。
本篇文章整理来自@ 李天天，由CSDN修订完成 。
想要参与到专家技术分享的一手整理过程中并获得相应权益吗？关注【CSDN云原生】公众号并回复关键词“志愿者”了解详情，我们期待你的加入~
