github_exporter
github_exporter copied to clipboard
Custom workflow labels
Hi there, is there any way to add custom labels to workflow metrics?
I was using this (https://promhippie.github.io/github_exporter/#getting-started) reference doc to set the exporter, and it mentioned the following ENV variable:
GITHUB_EXPORTER_WORKFLOWS_LABELS
List of labels used for workflows, comma-separated list, defaults to owner, repo, workflow, event, name, status, branch, number, run
Is it possible to enrich the default set of labels, or is this ENV variable there to reduce cardinality?
I would like to tie the runner_name from the webhook payload to the workflow metrics to gain insight into our self-hosted runner's usage.
Generally this variable exist to reduce cardinality, but it could also get extended.
This list of available labels is defined at https://github.com/promhippie/github_exporter/blob/master/pkg/config/config.go#L93 while the mapping is handled by https://github.com/promhippie/github_exporter/blob/master/pkg/store/types.go#L27.
If the webhook parses more flags and stores it within the database this could be extended to get mapped.
If this doesn't answer your question feel free to reopen this issue, otherwise I gonna close this issue for now.
@tboerger I have the exact same use-case as described by @al-vovk.
We are trying to identify which runners are running which workflows.
Having the runner_name label added to the workflows would enable this.
In the case of the runner_name, this is available in the WorkflowJobEvent. From what I can see, the code currently only supports the WorkflowRunEvent.
I propose, handling the WorkflowJobEvent webhook and emitting metrics e.g. github_workflow_job_*
We can then join the workflow run to the job to get details about the runner (using prometheus query, not in this code base).
Hey @tboerger Would you be open to a contribution on this? Essentially supporting the WorkflowJobEvent and emitting metrics.
I would be open to contributons, absolutely! If this is increasing the load or the count of labels we should just add flags to enable/disable the metrics and disable it by default :)
Hi @apj0nes did you ever start looking at handling workflow_run webhook events and emitting github_workflow_job_* type metrics? I'm interested in the same use case and I'm just about to start working on a similar approach
This should be resolved with the release of v4.0.0, if something is missing or not working please raise an issue. The release should pop up in a few minutes.