Tekton 组件的指标采集
目录
概览前提条件Tekton PipelinesPipelineRun 指标running_pipelineruns 标签级别状态标签值TaskRun 指标config-observability 配置Histogram Buckets推荐的生产环境配置Tekton TriggersController 指标(端口 9000)EventListener Sink 指标Tekton ResultsWatcher 指标删除指标共享指标Watcher config-observabilityAPI Server 指标Tekton ChainsChains 指标Controller Framework 指标设置 ServiceMonitorPipeline ServiceMonitorTriggers ServiceMonitorEventListener Sink ServiceMonitorResults ServiceMonitorChains ServiceMonitor验证直接检查指标 endpoint检查 Prometheus 目标PromQL 示例查询MonitorDashboard 示例Tekton Pipeline DashboardTekton Pipeline Dashboard 解读(常见问题)Tekton Triggers DashboardTekton Triggers Dashboard 解读(常见问题)Tekton Results DashboardTekton Results Dashboard 解读(常见问题)Tekton Chains DashboardTekton Chains Dashboard 解读(常见问题)概览
Tekton 组件通过 HTTP endpoint 暴露与 Prometheus 兼容的指标。通过部署 ServiceMonitor 资源,Prometheus(或 VictoriaMetrics)可以自动发现并抓取这些指标。
命名空间说明:本文档使用
tekton-pipelines作为控制平面组件(Pipelines、Triggers、Results、Chains)的默认命名空间。 主要例外是 EventListener Services,它们运行在创建 EventListener 的应用命名空间中。如果你的部署使用不同的命名空间,请同时更新下面命令中的命名空间,以及
ServiceMonitor资源中的namespaceSelector字段。
本文档涵盖以下 Tekton 组件的指标:
- Tekton Pipelines - PipelineRun / TaskRun 执行指标
- Tekton Triggers - EventListener、TriggerBinding 及相关资源指标
- Tekton Results - Run 删除和存储指标
- Tekton Chains - 签名和 provenance 指标
- Controller Framework - 所有 controller 共享的基础设施指标
还涵盖以下内容:
- 如何通过
config-observability配置指标行为 - 如何部署用于抓取的
ServiceMonitor资源 - 如何验证指标采集是否生效
前提条件
- Tekton 控制平面组件已安装并运行(至少包括你计划抓取的组件:Pipelines、Triggers、Results 和/或 Chains)。
kubectl已配置为连接目标集群,且你的账户可以在监控命名空间中创建ServiceMonitor资源。- 已部署监控栈(Prometheus 或兼容的 VictoriaMetrics),并且可以发现/抓取
ServiceMonitor资源(或平台使用的等价抓取发现对象)。 - 你的 Prometheus/VictoriaMetrics 实例已配置为发现你创建的
ServiceMonitor对象(命名空间和 label selector 必须匹配)。 - 网络策略和防火墙允许抓取端 Pod 访问 Tekton 指标端口(大多数控制平面 Service 使用
9090,Triggers controller 和 EventListener sink 使用9000)。 - 如果你需要 EventListener sink 指标,EventListener 必须存在于其目标命名空间中,并暴露
http-metrics端口。
Tekton Pipelines
Tekton Pipelines 组件包含多个暴露 9090 端口指标的子服务:
Pipeline controller 指标使用前缀 tekton_pipelines_controller_。
PipelineRun 指标
* 标有 * 的标签为可选项,取决于
config-observability配置。
running_pipelineruns 标签级别
running_pipelineruns 指标的标签由 metrics.running-pipelinerun.level 控制:
状态标签值
对于 PipelineRun 指标:
success- PipelineRun 成功完成failed- PipelineRun 失败cancelled- PipelineRun 被取消
对于 TaskRun 指标:
success- TaskRun 成功完成failed- TaskRun 失败
TaskRun 指标
config-observability 配置
tekton-pipelines 命名空间中的 config-observability ConfigMap 控制 Pipeline controller 的指标行为。该 ConfigMap 由 Tekton Operator 管理,应通过 TektonConfig 资源的 spec.pipeline.options.configMaps 字段进行配置。详见 调整子组件的可选配置项。
热加载行为:
config-observability会在运行时被监听。大多数 key 的变更(例如metrics.*)无需重启 Pod 即可生效。请等待一到两个抓取周期,让 dashboard/query 的变化显示出来。只有当 Pod spec 设置发生变化时才需要重启(例如在 Deployment 中修改CONFIG_OBSERVABILITY_NAME)。
通过 TektonConfig 的示例配置:
Histogram Buckets
当 duration 类型为 histogram 时,将使用以下 bucket 边界(单位:秒):
对应于:10s、30s、1m、5m、15m、30m、1h、1.5h、3h、6h、12h、24h。
推荐的生产环境配置
在生产环境中,建议使用聚合级别来控制 label 基数:
如果你需要按单次运行的粒度进行排查,可以临时切换为:
请注意,这会显著增加时间序列数量。
Tekton Triggers
Tekton Triggers 组件通过不同进程暴露两类指标。
Controller 指标(端口 9000)
Triggers controller 每 60 秒报告一次资源数量指标。
Triggers controller 指标使用前缀 controller_。
EventListener Sink 指标
每个 EventListener Pod 都会暴露额外的 HTTP 和事件处理指标。这些指标来自 EventListener sink 进程(不是 controller)。Prometheus 指标前缀为 eventlistener_。
eventlistener_http_duration_seconds的 histogram buckets:0.001, 0.01, 0.1, 1, 10(秒)eventlistener_event_received_count的 status 值:succeeded、failedeventlistener_triggered_resources的 kind 值:所创建对象的 Kubernetes 资源 Kind(例如PipelineRun、TaskRun)
这些 sink 指标是按每个 EventListener Pod 暴露的,而不是由中心 controller 暴露。如果 EventListener Pod 暴露了指标端口,你可能需要单独的
ServiceMonitor或PodMonitor来抓取它们。
Tekton Results
Tekton Results 有两个暴露指标的子服务。
Watcher 指标
Watcher 指标使用前缀 watcher_。
删除指标
* 可选标签取决于 Results Watcher 的
config-observability设置。
注意:只有当 Watcher 实际执行删除时,才会记录
pipelinerun_delete_count、pipelinerun_delete_duration_seconds、taskrun_delete_count和taskrun_delete_duration_seconds。除非在tekton-results-watcherDeployment 上将--completed_run_grace_period标志设置为非零值,否则这些指标会一直为空(没有数据点)。默认情况下该标志为0,会禁用自动删除。将其设置为正持续时间(例如10m)可在宽限期后启用删除,或者设置为负值以在归档后立即删除。
Results Watcher 的状态标签值:
success- Run 成功完成failed- Run 失败cancelled- Run 被取消
共享指标
这些指标由 Watcher 中的 PipelineRun 和 TaskRun reconciler 共同注册,用于跟踪与存储相关的事件。
kind 标签用于标识 run 类型(某些 metric series 中为 PipelineRun / TaskRun,另一些中为 pipelinerun / taskrun)。
注意:只有在 Watcher 持有 finalizer 用于协调归档时,run 被外部删除(例如通过
kubectl delete)才会记录runs_not_stored_count。除非同时满足以下所有条件,否则该指标会一直为空:
--logs_api标志为false(禁用 log 存储)——如果启用了 logs,Watcher 会完全跳过基于 finalizer 的协调。--disable_crd_update标志为false(启用 annotation 更新)。--store_deadline标志设置为非零持续时间——这是 Watcher 等待归档完成后放弃并允许删除前的最长等待时间。- Run 在成功归档之前被外部删除(没有
results.tekton.dev/stored=trueannotation),且store_deadline已经过期。在正常运行中(run 在删除前已归档,或由 Watcher 通过
--completed_run_grace_period自身触发删除),该 counter 会保持为 0。非零值表示可能存在数据丢失:run 在其状态保存到 Results API 之前就被删除了。
快速复现(测试环境): 如果你看不到这个指标,通常说明触发条件未满足,而不是指标缺失。
- 通过
TektonConfig配置 Results Watcher,使logs_api=false、disable_crd_update=false,并且store_deadline非零(例如30s)。- 通过
TektonConfig临时将 Results API 副本数设为0(spec.result.options.deployments.tekton-results-api.spec.replicas: 0),使 run 无法被归档。- 创建一个 TaskRun 或 PipelineRun,并等待其完成。
- 等待
store_deadline经过后,再外部删除该 run(kubectl delete ...)。- 检查 Watcher 的
/metrics或 Prometheus 中的watcher_runs_not_stored_count(在 exposition 格式中为带组件前缀的名称);它应该会增加。- 恢复原始
TektonConfig(重新启用 Results API 副本和正常的logs_api设置)。
run_storage_latency_seconds histogram 使用以下 bucket 边界(单位:秒):
Watcher config-observability
Results Watcher 有自己的 config-observability ConfigMap(通过 CONFIG_OBSERVABILITY_NAME 环境变量命名,通常为 tekton-results-config-observability)。该 ConfigMap 由 Tekton Operator 管理,应通过 TektonConfig 资源的 spec.result.options.configMaps 字段进行配置。详见 调整子组件的可选配置项。
热加载行为:Results Watcher 同样会监听这个 ConfigMap,并在不重启 Pod 的情况下应用大多数 key 的变更。只有在 Deployment 级别设置(例如 env var/args)发生变化时才需要重启。
它支持以下 key:
注意:不同于 Tekton Pipelines,Results Watcher 不支持
pipelinerun/taskrun的单次运行粒度级别。它也没有metrics.count.enable-reason、metrics.running-pipelinerun.level或metrics.taskrun.throttle.enable-namespace这些 key。上游已知问题:
taskrun_delete_duration_seconds使用的是metrics.pipelinerun.duration-type(而不是metrics.taskrun.duration-type)来确定聚合类型。这看起来是 Results 源码中的一个复制粘贴 bug。
API Server 指标
API server 通过 go-grpc-prometheus 库在 9090 端口暴露标准的 gRPC Prometheus 指标。这些指标包括:
grpc_server_handled_total- server 上已完成的 RPC 总数grpc_server_started_total- server 上已启动的 RPC 总数grpc_server_msg_received_total/grpc_server_msg_sent_total- 消息计数grpc_server_handling_seconds(如果启用了PROMETHEUS_HISTOGRAM)- RPC 处理耗时
Tekton Chains
Tekton Chains 是一个安全组件,用于为通过 Tekton Pipelines 构建的 artifact 生成、签名并存储 provenance。它会观察已完成的 TaskRun 和 PipelineRun,然后创建 attestations 和签名。
Chains controller 指标使用前缀 watcher_(与 Results Watcher 相同,但自定义指标名称不同,因此不会冲突)。
Chains 指标
所有 Chains 指标都是不带标签的 Counters。
注意:官方 Tekton Chains 文档还提到了 TaskRun 和 PipelineRun 的
*_signing_failures_totalcounter,但当前上游源码中并不存在这些指标。请以你部署的版本为准进行验证。
Controller Framework 指标
所有 Tekton controller 都会自动暴露以下基础设施指标。这些指标使用与组件自定义指标相同的前缀(例如 tekton_pipelines_controller_、controller_、watcher_)。
设置 ServiceMonitor
要为 Tekton 组件启用 Prometheus 抓取,需要部署 ServiceMonitor 资源。
前提条件见 前提条件。
请根据你的监控栈采用以下指导:
- 如果你使用 Prometheus(Prometheus Operator),如
metadata.labels.prometheus: kube-prometheus之类的 label 必须与 Prometheus CR 的spec.serviceMonitorSelector匹配;否则该ServiceMonitor不会被抓取。 - 如果你使用 VictoriaMetrics,通常不需要类似
prometheus: kube-prometheus的 label;请根据你的监控配置创建ServiceMonitor/VMServiceScrape。
使用 Prometheus 时,可通过以下命令查找并验证 selector:
如果集群中不存在 Prometheus CR,监控通常由平台托管(例如 VictoriaMetrics)或以不同方式实现。在这种情况下,通常不需要 prometheus: kube-prometheus 之类的 label;请遵循你的平台抓取规则。
更多信息请参阅 集成外部指标。
Pipeline ServiceMonitor
Pipeline ServiceMonitor YAML
这个 ServiceMonitor 会匹配带有 app.kubernetes.io/part-of: tekton-pipelines label 的 Pipeline services(包括 remote-resolvers),并在 tekton-pipelines 命名空间中对它们进行抓取。
Triggers ServiceMonitor
Triggers ServiceMonitor YAML
这个 ServiceMonitor 只收集 Triggers controller 指标(controller_*)。它不包含 EventListener sink 指标。
EventListener Sink ServiceMonitor
EventListener Sink ServiceMonitor YAML
EventListener Services 通常运行在应用命名空间中,因此此示例使用
namespaceSelector.any: true来实现跨命名空间抓取。如果你需要更严格的范围,可以切换为matchNames并显式列出允许的命名空间。
Results ServiceMonitor
Results services 同时带有 app.kubernetes.io/part-of: tekton-results 和 app.kubernetes.io/name 标签。为了精确定位 API + Watcher(并排除 Postgres),此示例按 app.kubernetes.io/name 进行匹配:
Results ServiceMonitor YAML
Results API server 使用端口名
prometheus(9090),Watcher 使用端口名metrics(9090)。每个 service 只会暴露其中一个端口名,因此只有匹配的 endpoint 会被抓取。
Chains ServiceMonitor
Chains ServiceMonitor YAML
验证
部署 ServiceMonitor 资源后,请验证 Prometheus 是否正在抓取这些目标。
直接检查指标 endpoint
eventlistener_event_received_count和eventlistener_http_duration_seconds这类 EventListener sink 指标是由请求驱动的。请在验证这些指标之前,至少向 EventListener 发送一次请求。
检查 Prometheus 目标
PromQL 示例查询
MonitorDashboard 示例
以下 MonitorDashboard 资源提供了可直接使用的 Tekton 组件监控 dashboard。请将它们部署到 cpaas-system 命名空间下的 tekton 目录中。
重要:每个 panel 都必须包含
id(唯一整数)、datasource: prometheus和transformations: []。每个 target 都必须包含datasource: prometheus和refId。本文档中的 Duration P50/P95 panel 使用*_bucket查询,并要求metrics.*.duration-type=histogram;如果你使用lastvalue,请将这些查询替换为类似avg_over_time(...)的 LastValue 风格表达式。
Tekton Pipeline Dashboard
Tekton Pipeline Dashboard YAML
Tekton Pipeline Dashboard 解读(常见问题)
PipelineRun Total (by status)是 controller 记录的完成事件 counter,不是 PipelineRun 对象总数。在当前实现中,用户触发的取消(spec.status=Cancelled)可能不会进入这个统计路径,因此cancelled序列可能不会出现。要验证取消数量,请检查 PipelineRun 对象和事件。Running PipelineRuns是实时快照(当前正在运行的数量)。它可以独立于PipelineRun Total变化。Completed PipelineRuns (last 5m)表示吞吐量(最近 5 分钟内新完成的 run 数)。在低流量或空闲时段看到0是正常的。PipelineRun Success Rate (cumulative)是从 controller 启动以来的累积值,而不是 5 分钟窗口成功率。短期失败不会立即导致大幅变化。Reconcile Count (by success)统计的是 controller 的 reconcile 循环,而不是 PipelineRun 数量。- 状态序列只会为所选时间范围内实际存在样本的标签值显示。如果某个状态在窗口内没有样本,其曲线/legend 不会出现。
TaskRun Duration P50 / P95 (Standalone)和TaskRun Duration P50 / P95 (In-Pipeline)被拆分以避免混合查询不稳定。在只暴露一种 histogram family 的环境中,另一张图表为空是正常现象。
Tekton Triggers Dashboard
Tekton Triggers Dashboard YAML
Tekton Triggers Dashboard 解读(常见问题)
EventListener Count、TriggerTemplate Count、TriggerBinding Count、ClusterTriggerBinding和ClusterInterceptor是对象数量快照,不是请求量或事件处理吞吐量。All Trigger Resource Counts (trend)展示的是相同资源计数的组合趋势。在一个抓取周期内,与单资源趋势图之间出现短暂偏差是正常的。- 当不存在 Triggers 资源时显示
0是正常现象,并不表示抓取失败。
Tekton Results Dashboard
Tekton Results Dashboard YAML
Tekton Results Dashboard 解读(常见问题)
- 此 dashboard 版本基于 Results Watcher 的
reconcile/workqueue指标以及 Results API 的 gRPC 指标,因此在常见部署方式下(logs_api=true、禁用自动删除)仍会持续显示数据。 PipelineRun Reconcile Count (last 5m)和TaskRun Reconcile Count (last 5m)分别显示success=true和success=false在最近 5 分钟内的增量。PipelineRun Reconcile Latency P95和TaskRun Reconcile Latency P95由 watcher reconcile latency histogram 计算得出。在低流量情况下,该曲线可能较稀疏。Workqueue Depth显示当前队列深度,Workqueue Adds (last 5m)显示最近 5 分钟的入队量。gRPC Error Percentage (Results API, excl. NotFound/Canceled)是异常错误占总请求量的百分比,排除了常见业务返回码(NotFound、Canceled)。
Tekton Chains Dashboard
Tekton Chains Dashboard YAML
Tekton Chains Dashboard 解读(常见问题)
TaskRun Signatures Created (last 5m)、PipelineRun Signatures Created (last 5m)、Payloads Stored (last 5m)和Marked Signed (last 5m)都使用了increase(...[5m]),表示最近 5 分钟内的增量。- 当没有新的签名或存储活动时,这些曲线会降为
0;这并不意味着组件异常。 Payloads Stored和Marked Signed表示不同的处理阶段,因此它们的数值不一定始终一致。