feat(metrics): add pipeline_id and pipeline_name labels to prometheus metrics

[pgaijin66]

Summary

When building Grafana dashboards for Codefresh pipeline metrics, the runner/engine only exports pipeline_id as a hash in metric labels. There's no pipeline_name, so dashboards end up showing opaque IDs instead of human-readable pipeline names.

The workarounds people end up doing are all pretty annoying:

• Installing extra Grafana plugins to join IDs to names via an external API
• Standing up a separate /metrics endpoint that maps IDs to names, then joining in PromQL
• Using log-based transformations in Grafana to correlate IDs from pod labels

All of these add unnecessary dependencies for something that should just be available natively.

Changes

• Add pipeline_id and pipeline_name labels to workflow and agent histogram metrics
• Gated behind METRICS_INCLUDE_PIPELINE_NAME env var (fully opt-in, no change when unset)
• Pipeline names are sanitized to be metric-friendly (lowercase, alphanumeric + underscores)
• Add PipelineId and PipelineName fields to task metadata
• Add unit tests for sanitization and metric observation functions

Usage

Set the env var on the runner deployment to enable pipeline labels:

runner:
  env:
    METRICS_INCLUDE_PIPELINE_NAME: "true"

Expected behavior

Without METRICS_INCLUDE_PIPELINE_NAME (default, no change):

runner_wf_processing_sec_bucket{workflow_type="create", le="1"} 1
runner_agent_processing_sec_bucket{agent_type="proxy", le="1"} 1

With METRICS_INCLUDE_PIPELINE_NAME=true:

runner_wf_processing_sec_bucket{workflow_type="create", pipeline_id="64a1b2c3d4e5f6", pipeline_name="my_deploy_pipeline", le="1"} 1
runner_agent_processing_sec_bucket{agent_type="proxy", pipeline_id="64a1b2c3d4e5f6", pipeline_name="my_deploy_pipeline", le="1"} 1

Affected metrics

• runner_wf_duration_since_creation_sec
• runner_wf_duration_in_runner_sec
• runner_wf_processing_sec
• runner_agent_processing_sec

[pgaijin66]

Hey @zarbis, would appreciate a review on this when you get a chance. Pretty small change that saves operators from building workarounds just to get readable pipeline names in their Grafana dashboards. Thanks!

[masontikhonov]

Hey @pgaijin66, highly appreciate your contribution!
It may take some time for us to get this PR merged though.

I would also greatly appreciate your input on how/when you rely on Runner metrics. This will help us to better understand your use case and align it with our internal vision for these metrics.

---

In the meantime, I would recommend using codefresh.classic.build.info{ cf.classic.build.id, cf.classic.pipeline.id, cf.classic.pipeline.name } metrics emitted by the engine as a filter for other metrics, joining by Build ID/Pipeline ID depending on your needs.

Please find the full list of available metrics, and some Grafana dashboards in the docs: https://codefresh.io/docs/docs/installation/runner/classic-runtime-monitoring/

[masontikhonov]

@pgaijin66 Unfortunately, neither pipelineId nor pipelineName are part of the incoming Task metadata, so this approach will not work.

[masontikhonov]

@pgaijin66 Unfortunately, proposed solution will not work: see #681 (comment). I don't see other straightforward way to enrich Runner's metrics with pipeline_id/pipeline_name, that's why I'm closing this PR for now.

With this said, I am inviting you to continue discussion here: #681 (comment). Please explore mentioned above available metrics of the engine, and share your opinion. Having your use case explained in more details will be helpful as well, as we might be able to suggest some workaround for you, or come up with a better solution.

Looking for your feedback!