GitLab

·

Collect GitLab operation data and report it to Guance in the form of metrics.

Configuration¶

Collector Configuration¶

First, you need to open the data collection function of GitLab service and set the white list. See the following sections for specific operations.

After the GitLab setup is complete, configure the DataKit. Note that the data collected may vary depending on the GitLab version and configuration.

[[inputs.gitlab]]
    ## set true if you need to collect metric from url below
    enable_collect = true

    ## param type: string - default: http://127.0.0.1:80/-/metrics
    prometheus_url = "http://127.0.0.1:80/-/metrics"

    ## param type: string - optional: time units are "ms", "s", "m", "h" - default: 10s
    interval = "10s"

    ## datakit can listen to gitlab ci data at /v1/gitlab when enabled
    enable_ci_visibility = true

    ## Set true to enable election
    election = true

    ## extra tags for gitlab-ci data.
    ## these tags will not overwrite existing tags.
    [inputs.gitlab.ci_extra_tags]
    # some_tag = "some_value"
    # more_tag = "some_other_value"

    ## extra tags for gitlab metrics
    [inputs.gitlab.tags]
    # some_tag = "some_value"
    # more_tag = "some_other_value"

GitLab Turns on Data Collection¶

GitLab needs to turn on the Prometheus data collection function as follows (taking English page as an example):

• Log in to your GitLab page as an administrator account
• Go to Admin Area > Settings > Metrics and profiling
• Select Metrics - Prometheus, click Enable Prometheus Metrics and save change
• Restart the GitLab service

See official configuration doc.

Configure Data Access Whitelist¶

It is not enough to turn on the data collection function. GitLab is very strict with data management, so it is necessary to configure the white list on the access side. The opening mode is as follows:

• Modify the GitLab configuration file /etc/gitlab/gitlab.rb, find gitlab_rails['monitoring_whitelist'] = ['::1/128'] and add the access IP of the DataKit to the array (typically the IP of the host where the DataKit resides, if the GitLab is running in a container, depending on the actual situation)
• Restart the GitLab service

See official configuration doc.

Turn on GitLab CI Visualization¶

Ensure that the DataFlux Func platform is available.

By configuring GitLab Webhook, GitLab CI visualization can be achieved. Data reporting needs to be done through DataFlux Func, and the steps to enable it are as follows:

1. Install the GitLab CI integration (script ID: guance_gitlab_ci) on DataFlux Func. Follow the installation process as referenced in GitLab CI Integration Configuration;
2. In GitLab go to Settings > Webhooks, configure the URL to the API address obtained from step one. Trigger configure Job events and Pipeline events, and click Add webhook to confirm the addition;

Triggering the GitLab CI process will allow you to log in to Guance to view the execution status of CI after completion.

Metric¶

For all of the following data collections, the global election tags will added automatically, we can add extra tags in [inputs.gitlab.tags] if needed:

 [inputs.gitlab.tags]
  # some_tag = "some_value"
  # more_tag = "some_other_value"
  # ...

We can specify additional tags for Gitlab CI data in the configuration by [inputs.gitlab.ci_extra_tags]:

 [inputs.gitlab.ci_extra_tags]
  # some_tag = "some_value"
  # more_tag = "some_other_value"
  # ...

Note: To ensure that GitLab CI functions properly, the extra tags specified for GitLab CI data do not overwrite tags already in its data (see below for a list of GitLab CI tags).

gitlab¶

GitLab runtime metrics

• Tags

• Metrics

gitlab_base¶

GitLab programming language level metrics

• Tags

NA

• Metrics

gitlab_http¶

GitLab HTTP metrics

• Tags

• Metrics

gitlab_pipeline¶

GitLab Pipeline event metrics

• Tags

• Metrics

gitlab_job¶

GitLab Job Event metrics

• Tags

• Metrics