[Feature] Add pipeline variables to metrics

[misaon]

Firstly, I would like to express my thanks for the excellent work on this exporter.
I would send PR but I have no experience with GO.

Idea:
Add variable information to metrics. See the pipelines API documentation (https://docs.gitlab.com/ee/api/pipelines.html#get-variables-of-a-pipeline).

Why?
Now, for example, in Grafana we are limited to working only with information "repository name" and "ref". I think it's a good idea to be able to add a column in Graphana to display your own information using variables from pipelines.

My scope:
I solve this problem because in my company we would like to use monitoring of export orders from our e-shops using Gitlab pipelines (via scheduler). Now we have a problem, because we have one ".gitlab-ci.yml" file, inside are defined "deploy" and "export of orders" stages. The "export of orders" stage is only started when I create a pipeline with the appropriate rules and the "deploy" starts when the merge request is created.
However, both "deploy" and "export orders" go to the metrics. It is mixed together and it is not possible to filter records.

Can you think of a solution to this problem?
Thanks a lot 👍

[mvisonneau]

👋 hey @misaon, thanks for the kind feedback! 🙇

I started to put some thoughts into it. It should be doable indeed. I believe this requires quite some work though as we would need to have dynamically generated labels which implies some refactoring of the existing codebase in order to work flawlessly!

I am not planning to look into this right now but MRs are welcome! :)

[inge4pres]

Hi @mvisonneau did you have already some work done on this? I can pick it up

[mvisonneau]

I have not, feel free to pick it up! :) thanks!

[inge4pres]

Hey there @misaon what would be the desired metric layout for you to address this? Would you like a label for every variable? Or a single label with variables encoded in some format? The first implementation could blow up metrics a bit, depending on the number of variables.
Both implementations would be gated by a config flag

[inge4pres]

I just noticed that the variables are only populated when running a pipeline manually or a schedule with variables set. @misaon can this still be useful?

[inge4pres]

@mvisonneau do you think the variables can fit into a set of labels for the already existing metric gitlab_ci_pipeline_job_run_count or would you prefer a dedicated metric for them?

[inge4pres]

after digging into it for a while, I found that we could either:

• use a NewConstMetrics with labels set as variable names (no values! as they could be sensitive data)
• curry the job_run_count metric with more labels with some sort of encoding

I'll try and write tests for both see what the implementation could be and then we can discuss

[nfm]

Hiya 👋 I've just started experimenting with gitlab-ci-pipelines-exporter and I'm also finding it really useful. Thanks @mvisonneau! ❤️

I think I have a similar use-case to @misaon and thought it might be helpful to share on this issue.

I'd like to instrument how long our main build/test/deploy pipeline takes on the master branch so we can optimize those durations. However, we have a couple of additional scheduled pipelines that also target the master branch (for example, scheduled nightly renovate jobs). These do something totally different to our build/test/deploy pipeline. Currently it's not possible to omit these from the gitlab_ci_pipeline_last_run_duration_seconds{ref="master"} metric.

GitLab does provide a CI_PIPELINE_SOURCE variable that can be used to identify whether the pipeline was triggered from a schedule. If we could add this variable as a label to the metric, we could filter out scheduled master pipeline durations, and focus on what we need to measure.

There are a lot of pipeline variables though, so I think it would make sense to whitelist which ones are sent as labels. Alternatively if a general purpose solution is hard to architect, maybe we could enumerate some common use-cases for this and just support those.

[inge4pres]

Hi @nfm this is another feature compared to the one discussed in this issue that, yet relevant to this, can be developed on its own once this issue is completed and some refactoring is done on the current implementattion.
@mvisonneau I am about to send a PR with a pretty big change that could allow us to create new metrics on the fly every time we scan he projects list; I will definitely need your review on this because of my limited experience with the prometheus package.

[mvisonneau]

thanks for the kind feedback @nfm 🙇 !

Indeed I reckon that this could be very useful. We need to figure out a pragmatic approach in order to let people choose which variables they would like to get.

[mvisonneau]

This feature is now part of 0.3.0

I reckon this does not cover @nfm use case though as the API only returns the user defined variables though. I'll have referenced it in another issue (#96)