Supported GitLab versions:
Other supported versions with additional configuration:
datadog_ci_integration feature flag.Configure the integration on a project or group by going to Settings > Integrations > Datadog for each project or group you want to instrument.
Configure the integration on a project or group by going to Settings > Integrations > Datadog for each project or group you want to instrument.
You can also activate the integration at the GitLab instance level, by going to Admin > Settings > Integrations > Datadog.
Enable the datadog_ci_integration feature flag to activate the integration. Run one of the following commands, which use GitLab’s Rails Runner, depending on your installation type:
Omnibus installations
sudo gitlab-rails runner "Feature.enable(:datadog_ci_integration)"From source installations
sudo -u git -H bundle exec rails runner \
-e production \
"Feature.enable(:datadog_ci_integration)"Kubernetes installations
kubectl exec -it <task-runner-pod-name> -- \
/srv/gitlab/bin/rails runner "Feature.enable(:datadog_ci_integration)"Then, configure the integration on a project by going to Settings > Integrations > Datadog for each project you want to instrument.
Fill in the integration configuration settings:
datadoghq.comgitlab-cienv tag) to attach to each span generated by the integration. Use this to differentiate between groups of GitLab instances (for example: staging or production).nonekey:value.You can test the integration with the Test settings button (only available when configuring the integration on a project). After it’s successful, click Save changes to finish the integration set up.
As an alternative to using the native Datadog integration, you can use webhooks to send pipeline data to Datadog.
Go to Settings > Webhooks in your repository (or GitLab instance settings), and add a new webhook:
https://webhook-intake./api/v2/webhook/?dd-api-key=<API_KEY> where <API_KEY> is your Datadog API key.Job events and Pipeline events.To set custom env or service parameters, add more query parameters in the webhooks URL: &env=<YOUR_ENV>&service=<YOUR_SERVICE_NAME>
To set custom tags to all the pipeline and job spans generated by the integration, add to the URL a URL-encoded query parameter tags, with key:value pairs separated by commas. If a key:value pair contains any commas, surround it with quotes. For example, to add key1:value1,"key2: value with , comma",key3:value3, the following string would need to be appended to the Webhook URL:
?tags=key1%3Avalue1%2C%22key2%3A+value+with+%2C+comma%22%2Ckey3%3Avalue3
After the integration is successfully configured, the Pipelines and Pipeline Executions pages populate with data after the pipelines finish.
Note: The Pipelines page shows data for only the default branch of each repository.
If you are using self-hosted GitLab runners, you can correlate jobs with the infrastructure that is running them.
For this feature to work, the GitLab runner must have a tag of the form host:<hostname>. Tags can be added while
registering a new runner. For existing runners, add tags by updating the runner’s config.toml. Or add tags
through the UI by going to Settings > CI/CD > Runners and editing the appropriate runner.
After these steps, CI Visibility adds the hostname to each job. To see the metrics, click on a job span in the trace view. In the drawer, a new tab named Infrastructure appears which contains the host metrics.
For failed GitLab pipeline executions, each error under the Errors tab within a specific pipeline execution displays a message associated with the error type from GitLab.
See the table below for the message and domain correlated with each error type. Any unlisted error type will lead to the error message of Job failed and error domain of unknown.
| Error Type | Error Message | Error Domain |
|---|---|---|
| unknown_failure | Failed due to unknown reason | unknown |
| config_error | Failed due to error on CI/CD configuration file | user |
| external_validation_failure | Failed due to external pipeline validation | unknown |
| user_not_verified | The pipeline failed due to the user not being verified | user |
| activity_limit_exceeded | The pipeline activity limit was exceeded | provider |
| size_limit_exceeded | The pipeline size limit was exceeded | provider |
| job_activity_limit_exceeded | The pipeline job activity limit was exceeded | provider |
| deployments_limit_exceeded | The pipeline deployments limit was exceeded | provider |
| project_deleted | The project associated with this pipeline was deleted | provider |
| api_failure | API Failure | provider |
| stuck_or_timeout_failure | Pipeline is stuck or timed out | unknown |
| runner_system_failure | Failed due to runner system failure | provider |
| missing_dependency_failure | Failed due to missing dependency | unknown |
| runner_unsupported | Failed due to unsupported runner | provider |
| stale_schedule | Failed due to stale schedule | provider |
| job_execution_timeout | Failed due to job timeout | unknown |
| archived_failure | Archived failure | provider |
| unmet_prerequisites | Failed due to unmet prerequisite | unknown |
| scheduler_failure | Failed due to schedule failure | provider |
| data_integrity_failure | Failed due to data integrity | provider |
| forward_deployment_failure | Deployment failure | unknown |
| user_blocked | Blocked by user | user |
| ci_quota_exceeded | CI quota exceeded | provider |
| pipeline_loop_detected | Pipeline loop detected | user |
| builds_disabled | Build disabled | user |
| deployment_rejected | Deployment rejected | user |
| protected_environment_failure | Environment failure | provider |
| secrets_provider_not_found | Secret provider not found | user |
| reached_max_descendant_pipelines_depth | Reached max descendant pipelines | user |
| ip_restriction_failure | IP restriction failure | provider |
The following GitLab versions support collecting job logs:
To enable collection of job logs:
datadog_integration_logs_collection feature flag in your GitLab self-hosted or GitLab.com account. This reveals the Enable logs collection option in the Datadog integration.Enable logs collection option and save the changes.Job logs are collected in the Logs product and automatically correlated with the GitLab pipeline within CI Visibility.
Additional helpful documentation, links, and articles:
