Docs » Integrations Guide » Use the Smart Agent » Monitors » gitlab-runner

gitlab-runner 🔗

Monitor Type: gitlab-runner (Source)

Accepts Endpoints: Yes

Multiple Instances Allowed: Yes

Overview 🔗

Monitor for the Gitlab runner service. This usually runs on port 9252, so to monitor an instance on the same host as the agent, you can do:

- type: gitlab-runner
  host: localhost
  port: 9252

For more information on configuring monitoring within Gitlab runner itself, see

See the Gitlab monitor for more information.

Configuration 🔗

To activate this monitor in the Smart Agent, add the following to your agent config:

monitors:  # All monitor config goes under this key
 - type: gitlab-runner
   ...  # Additional config

For a list of monitor options that are common to all monitors, see Common Configuration.

Config option Required Type Description
httpTimeout no int64 HTTP timeout duration for both read and writes. This should be a duration string that is accepted by (default: 10s)
username no string Basic Auth username to use on each request, if any.
password no string Basic Auth password to use on each request, if any.
useHTTPS no bool If true, the agent will connect to the server using HTTPS instead of plain HTTP. (default: false)
httpHeaders no map of strings A map of HTTP header names to values. Comma separated multiple values for the same message-header is supported.
skipVerify no bool If useHTTPS is true and this option is also true, the exporter's TLS cert will not be verified. (default: false)
caCertPath no string Path to the CA cert that has signed the TLS cert, unnecessary if skipVerify is set to false.
clientCertPath no string Path to the client TLS cert to use for TLS required connections
clientKeyPath no string Path to the client TLS key to use for TLS required connections
host yes string Host of the exporter
port yes integer Port of the exporter
useServiceAccount no bool Use pod service account to authenticate. (default: false)
metricPath no string Path to the metrics endpoint on the exporter server, usually /metrics (the default). (default: /metrics)
sendAllMetrics no bool Send all the metrics that come out of the Prometheus exporter without any filtering. This option has no effect when using the prometheus exporter monitor directly since there is no built-in filtering, only when embedding it in other monitors. (default: false)

Metrics 🔗

These are the metrics available for this monitor. Metrics that are categorized as container/host (default) are in bold and italics in the list below.

  • gitlab_runner_api_request_statuses_total (cumulative)
    The total number of API requests, partitioned by runner, endpoint and status
  • gitlab_runner_autoscaling_machine_creation_duration_seconds (cumulative)
    Histogram of machine creation time
  • gitlab_runner_autoscaling_machine_creation_duration_seconds_bucket (cumulative)
    Histogram of machine creation time
  • gitlab_runner_autoscaling_machine_creation_duration_seconds_count (cumulative)
    Histogram of machine creation time
  • gitlab_runner_autoscaling_machine_states (gauge)
    The current number of machines per state in this provider
  • gitlab_runner_concurrent (gauge)
    The current value of concurrent setting
  • gitlab_runner_errors_total (cumulative)
    The number of catched errors
  • gitlab_runner_limit (gauge)
    The current value of concurrent setting
  • gitlab_runner_request_concurrency (gauge)
    The current number of concurrent requests for a new job
  • gitlab_runner_request_concurrency_exceeded_total (cumulative)
    Counter tracking exceeding of request concurrency
  • gitlab_runner_version_info (gauge)
    A metric with a constant ‘1’ value labeled by different build stats fields

Non-default metrics (version 4.7.0+) 🔗

To emit metrics that are not default, you can add those metrics in the generic monitor-level extraMetrics config option. Metrics that are derived from specific configuration options that do not appear in the above list of metrics do not need to be added to extraMetrics.

To see a list of metrics that will be emitted you can run agent-status monitors after configuring this monitor in a running agent instance.