Gitlab error tracking

Documentation for GitLab Community Edition, GitLab Enterprise Edition, Omnibus GitLab, and GitLab Runner.
  • How error tracking works
  • Sentry error tracking

    • Deploying Sentry
    • Enabling Sentry
    • Enabling GitLab issues links
    • Enable GitLab Runner
  • Error Tracking List
  • Error Details
  • Taking Action on errors

    • Ignoring errors
    • Resolving errors
  • Integrated error tracking

    • Project settings

      • How to enable
      • Managing DSN
      • Limitations

Error Tracking allows developers to discover and view errors generated by their application. Because error information is surfaced where the code is being developed, efficiency and awareness are increased.

How error tracking works

For error tracking to work, you need two pieces:

  • Your application with Sentry SDK: when the error happens, Sentry SDK captures information
    about it and sends it over the network to the backend. The backend stores information about all
    errors.

  • Error tracking backend: the backend can be either GitLab itself or Sentry. When it’s GitLab,
    we name it integrated error tracking because you don’t need to set up a separate backend. It’s
    already part of the product.

    • To use the GitLab backend, see integrated error tracking.
    • To use Sentry as the backend, see Sentry error tracking.

    No matter what backend you choose, the error tracking UI
    is the same.

Sentry error tracking

Sentry is an open source error tracking system. GitLab allows administrators to connect Sentry to GitLab, to allow users to view a list of Sentry errors in GitLab.

Deploying Sentry

You can sign up to the cloud hosted Sentry or deploy your own on-premise instance.

Enabling Sentry

GitLab provides an easy way to connect Sentry to your project. You need at
least Maintainer permissions to enable the Sentry integration.

  1. Sign up to Sentry.io or deploy your own Sentry instance.
  2. Create a new Sentry project. For each GitLab project that you want to integrate, we recommend that you create a new Sentry project.
  3. Find or generate a Sentry auth token.
    For the SaaS version of Sentry, you can find or generate the auth token at https://sentry.io/api/.
    Make sure to give the token at least the following scopes: project:read, event:read, and
    event:write (for resolving events).
  4. In GitLab, enable error tracking:
    1. On the top bar, select Main menu > Projects and find your project.
    2. On the left sidebar, select Monitor > Error Tracking.
    3. Select Enable error tracking.
  5. In GitLab, ensure error tracking is active.
    1. On the left sidebar, select Settings > Monitor.
    2. Expand Error Tracking.
    3. Ensure the Active checkbox is selected.
  6. In the Sentry API URL box, enter your Sentry hostname. For example, enter https://sentry.example.com. For the SaaS version of Sentry, the hostname is https://sentry.io.
  7. In the Auth Token box, enter the token you previously generated.
  8. To test the connection to Sentry and populate the Project dropdown list, select Connect.
  9. From the Project list, choose a Sentry project to link to your GitLab project.
  10. Select Save changes.

You can now visit Monitor > Error Tracking in your project’s sidebar to view a list of Sentry errors.

Enabling GitLab issues links

You may also want to enable Sentry’s GitLab integration by following the steps in the Sentry documentation

Enable GitLab Runner

To configure GitLab Runner with Sentry, you must add the value for sentry_dsn to your GitLab
Runner’s config.toml configuration file, as referenced in GitLab Runner Advanced Configuration.
While setting up Sentry, select Go if you’re asked for the project type.

If you see the following error in your GitLab Runner logs, then you should specify the deprecated
DSN in Sentry.io > Project Settings > Client Keys (DSN) > Show deprecated DSN.

ERROR: Sentry failure builds=0 error=raven: dsn missing private key

Error Tracking List

Users with at least Reporter permissions
can find the Error Tracking list at Monitor > Error Tracking in your project’s sidebar.
Here, you can filter errors by title or by status (one of Ignored , Resolved, or Unresolved) and sort in descending order by Frequency, First Seen, or Last Seen. By default, the error list is ordered by Last Seen and filtered to Unresolved errors.

Error Tracking list

Error Details

From error list, users can navigate to the error details page by selecting the title of any error.

This page has:

  • A link to the Sentry issue.
  • A link to the GitLab commit if the Sentry release ID/version on the Sentry Issue’s first release matches a commit SHA in your GitLab hosted project.
  • Other details about the issue, including a full stack trace.
  • In GitLab 12.7 and newer, language and urgency are displayed.

By default, a Create issue button is displayed:

Error Details without Issue Link

If you create a GitLab issue from the error, the Create issue button changes to a View issue
button and a link to the GitLab issue displays within the error detail section.

Taking Action on errors

You can take action on Sentry Errors from within the GitLab UI. Marking errors ignored or resolved require at least Developer role.

Ignoring errors

From within the Error Details page you can ignore a Sentry error by selecting the Ignore button near the top of the page.

Ignoring an error prevents it from appearing in the Error Tracking List, and silences notifications that were set up within Sentry.

Resolving errors

From within the Error Details page you can resolve a Sentry error by
selecting the Resolve button near the top of the page.

Marking an error as resolved indicates that the error has stopped firing events. If a GitLab issue is linked to the error, then the issue closes.

If another event occurs, the error reverts to unresolved.

Integrated error tracking

Version history

  • Introduced in GitLab 14.4.
  • Disabled in GitLab 14.9 with a flag named integrated_error_tracking. Disabled by default.
  • Enabled on GitLab.com in GitLab 15.6.

Integrated error tracking is a lightweight alternative to Sentry backend.
You still use Sentry SDK with your application. But you don’t need to deploy Sentry
or set up for cloud-hosted Sentry. Instead, you use GitLab as a backend for it.

Sentry backend automatically assigns a Data Source Name (DSN) for every project you create.
GitLab does the same. You should be able to find a DSN for your project in the GitLab error tracking
settings. By using a GitLab-provided DSN, your application connects to GitLab to report an error.
Those errors are stored in the GitLab database and rendered by the GitLab UI, in the same way as
Sentry integration.

In GitLab 15.6 and later, the integrated error tracking
uses a new backend based on the ClickHouse database that enables better scalability.
Integrated error tracking remains limited in comparison to the Sentry backend, as only a small subset of the
Sentry API is implemented.

Changing the GitLab error UI to use the GitLab Observability UI is tracked in epic 19.

Project settings

You can find the feature configuration at Settings > Monitor > Error Tracking.

How to enable

  1. Select GitLab as the error tracking backend for your project:

    Error Tracking Settings

  2. Select Save changes. After page reload you should see a text field with the DSN string. Copy it.

    Error Tracking Settings DSN

  3. Take the DSN from the previous step and configure your Sentry SDK with it. Errors are now
    reported to the GitLab collector and are visible in the GitLab UI.

Managing DSN

When you enable the feature you receive a DSN. It includes a hash used for authentication. This hash
is a client key. GitLab uses client keys to authenticate error tracking requests from your
application to the GitLab backend.

In some situations, you may want to create a new client key and remove an existing one.
You can do so by managing client keys with the error tracking API.

Limitations

The Integrated Error Tracking feature was built and tested with Sentry SDK for Ruby on Rails.
Support for other languages and frameworks is not guaranteed. For up-to-date information, see the
compatibility issue.

stage group info

Monitor

Observability

To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments

Error Tracking (FREE)

Deprecated in GitLab 15.9.

WARNING:
This feature is in its end-of-life process. It is deprecated
for use in GitLab 15.9, and is planned for removal in GitLab 16.0. We are replacing this feature with functionality in the GitLab Observability UI. Please also reference our direction for Observability and data visualization.

Error Tracking allows developers to discover and view errors generated by their application. Because error information is surfaced where the code is being developed, efficiency and awareness are increased.

How error tracking works

For error tracking to work, you need two pieces:

  • Your application with Sentry SDK: when the error happens, Sentry SDK captures information
    about it and sends it over the network to the backend. The backend stores information about all
    errors.

  • Error tracking backend: the backend can be either GitLab itself or Sentry. When it’s GitLab,
    we name it integrated error tracking because you don’t need to set up a separate backend. It’s
    already part of the product.

    • To use the GitLab backend, see integrated error tracking.
    • To use Sentry as the backend, see Sentry error tracking.

    No matter what backend you choose, the error tracking UI
    is the same.

Sentry error tracking

Sentry is an open source error tracking system. GitLab allows administrators to connect Sentry to GitLab, to allow users to view a list of Sentry errors in GitLab.

Deploying Sentry

You can sign up to the cloud hosted Sentry or deploy your own on-premise instance.

Enabling Sentry

GitLab provides an easy way to connect Sentry to your project. You need at
least Maintainer permissions to enable the Sentry integration.

  1. Sign up to Sentry.io or deploy your own Sentry instance.
  2. Create a new Sentry project. For each GitLab project that you want to integrate, we recommend that you create a new Sentry project.
  3. Find or generate a Sentry auth token.
    For the SaaS version of Sentry, you can find or generate the auth token at https://sentry.io/api/.
    Make sure to give the token at least the following scopes: project:read, event:read, and
    event:write (for resolving events).
  4. In GitLab, enable error tracking:
    1. On the top bar, select Main menu > Projects and find your project.
    2. On the left sidebar, select Monitor > Error Tracking.
    3. Select Enable error tracking.
  5. In GitLab, ensure error tracking is active.
    1. On the left sidebar, select Settings > Monitor.
    2. Expand Error Tracking.
    3. Ensure the Active checkbox is selected.
  6. In the Sentry API URL box, enter your Sentry hostname. For example, enter https://sentry.example.com. For the SaaS version of Sentry, the hostname is https://sentry.io.
  7. In the Auth Token box, enter the token you previously generated.
  8. To test the connection to Sentry and populate the Project dropdown list, select Connect.
  9. From the Project list, choose a Sentry project to link to your GitLab project.
  10. Select Save changes.

You can now visit Monitor > Error Tracking in your project’s sidebar to view a list of Sentry errors.

Enabling GitLab issues links

You may also want to enable Sentry’s GitLab integration by following the steps in the Sentry documentation

Enable GitLab Runner

To configure GitLab Runner with Sentry, you must add the value for sentry_dsn to your GitLab
Runner’s config.toml configuration file, as referenced in GitLab Runner Advanced Configuration.
While setting up Sentry, select Go if you’re asked for the project type.

If you see the following error in your GitLab Runner logs, then you should specify the deprecated
DSN in Sentry.io > Project Settings > Client Keys (DSN) > Show deprecated DSN.

ERROR: Sentry failure builds=0 error=raven: dsn missing private key

Error Tracking List

Users with at least Reporter permissions
can find the Error Tracking list at Monitor > Error Tracking in your project’s sidebar.
Here, you can filter errors by title or by status (one of Ignored , Resolved, or Unresolved) and sort in descending order by Frequency, First Seen, or Last Seen. By default, the error list is ordered by Last Seen and filtered to Unresolved errors.

Error Tracking list

Error Details

From error list, users can navigate to the error details page by selecting the title of any error.

This page has:

  • A link to the Sentry issue.
  • A link to the GitLab commit if the Sentry release ID/version on the Sentry Issue’s first release matches a commit SHA in your GitLab hosted project.
  • Other details about the issue, including a full stack trace.
  • In GitLab 12.7 and newer, language and urgency are displayed.

By default, a Create issue button is displayed:

Error Details without Issue Link

If you create a GitLab issue from the error, the Create issue button changes to a View issue
button and a link to the GitLab issue displays within the error detail section.

Taking Action on errors

You can take action on Sentry Errors from within the GitLab UI. Marking errors ignored or resolved require at least Developer role.

Ignoring errors

Introduced in GitLab 12.7.

From within the Error Details page you can ignore a Sentry error by selecting the Ignore button near the top of the page.

Ignoring an error prevents it from appearing in the Error Tracking List, and silences notifications that were set up within Sentry.

Resolving errors

Introduced in GitLab 12.7.

From within the Error Details page you can resolve a Sentry error by
selecting the Resolve button near the top of the page.

Marking an error as resolved indicates that the error has stopped firing events. If a GitLab issue is linked to the error, then the issue closes.

If another event occurs, the error reverts to unresolved.

Integrated error tracking (FREE SAAS)

  • Introduced in GitLab 14.4.
  • Disabled in GitLab 14.9 with a flag named integrated_error_tracking. Disabled by default.
  • Enabled on GitLab.com in GitLab 15.6.

NOTE:
Available only on GitLab.com. This feature is currently in Open Beta.

Integrated error tracking is a lightweight alternative to Sentry backend.
You still use Sentry SDK with your application. But you don’t need to deploy Sentry
or set up for cloud-hosted Sentry. Instead, you use GitLab as a backend for it.

Sentry backend automatically assigns a Data Source Name (DSN) for every project you create.
GitLab does the same. You should be able to find a DSN for your project in the GitLab error tracking
settings. By using a GitLab-provided DSN, your application connects to GitLab to report an error.
Those errors are stored in the GitLab database and rendered by the GitLab UI, in the same way as
Sentry integration.

In GitLab 15.6 and later, the integrated error tracking
uses a new backend based on the ClickHouse database that enables better scalability.
Integrated error tracking remains limited in comparison to the Sentry backend, as only a small subset of the
Sentry API is implemented.

Changing the GitLab error UI to use the GitLab Observability UI is tracked in epic 19.

Project settings

You can find the feature configuration at Settings > Monitor > Error Tracking.

How to enable

  1. Select GitLab as the error tracking backend for your project:

    Error Tracking Settings

  2. Select Save changes. After page reload you should see a text field with the DSN string. Copy it.

    Error Tracking Settings DSN

  3. Take the DSN from the previous step and configure your Sentry SDK with it. Errors are now
    reported to the GitLab collector and are visible in the GitLab UI.

Managing DSN

When you enable the feature you receive a DSN. It includes a hash used for authentication. This hash
is a client key. GitLab uses client keys to authenticate error tracking requests from your
application to the GitLab backend.

In some situations, you may want to create a new client key and remove an existing one.
You can do so by managing client keys with the error tracking API.

Limitations

The Integrated Error Tracking feature was built and tested with Sentry SDK for Ruby on Rails.
Support for other languages and frameworks is not guaranteed. For up-to-date information, see the
compatibility issue.

Error Tracking allows developers to easily discover and view the errors that their application may be generating. By surfacing error information where the code is being developed, efficiency and awareness can be increased.

How error tracking works

For error tracking to work, you need two pieces:

  • Your application with Sentry SDK: when the error happens, Sentry SDK captures information
    about it and sends it over the network to the backend. The backend stores information about all
    errors.

  • Error tracking backend: the backend can be either GitLab itself or Sentry. When it’s GitLab,
    we name it integrated error tracking because you don’t need to set up a separate backend. It’s
    already part of the product.

    • To use the GitLab backend, see integrated error tracking.
    • To use Sentry as the backend, see Sentry error tracking.

    No matter what backend you choose, the error tracking UI
    is the same.

Sentry error tracking

Sentry is an open source error tracking system. GitLab allows administrators to connect Sentry to GitLab, to allow users to view a list of Sentry errors in GitLab.

Deploying Sentry

You can sign up to the cloud hosted Sentry, deploy your own on-premise instance, or use GitLab to install Sentry to a Kubernetes cluster.

Enabling Sentry

GitLab provides an easy way to connect Sentry to your project. You need at
least Maintainer permissions to enable the Sentry integration.

  1. Sign up to Sentry.io or deploy your own Sentry instance.
  2. Create a new Sentry project. For each GitLab project that you want to integrate, we recommend that you create a new Sentry project.
  3. Find or generate a Sentry auth token.
    For the SaaS version of Sentry, you can find or generate the auth token at https://sentry.io/api/.
    Make sure to give the token at least the following scopes: project:read, event:read, and
    event:write (for resolving events).
  4. In GitLab, enable error tracking:
    1. On the top bar, select Menu > Projects and find your project.
    2. On the left sidebar, select Monitor > Error Tracking.
    3. Select Enable error tracking.
  5. In GitLab, ensure error tracking is active.
    1. On the left sidebar, select Settings > Monitor.
    2. Expand Error Tracking.
    3. Ensure the Active checkbox is selected.
  6. In the Sentry API URL box, enter your Sentry hostname. For example, enter https://sentry.example.com. For the SaaS version of Sentry, the hostname is https://sentry.io.
  7. In the Auth Token box, enter the token you previously generated.
  8. To test the connection to Sentry and populate the Project dropdown, select Connect.
  9. From the Project list, choose a Sentry project to link to your GitLab project.
  10. Select Save changes.

You can now visit Monitor > Error Tracking in your project’s sidebar to view a list of Sentry errors.

Enabling GitLab issues links

You may also want to enable Sentry’s GitLab integration by following the steps in the Sentry documentation

Enable GitLab Runner

To configure GitLab Runner with Sentry, you must add the value for sentry_dsn to your GitLab
Runner’s config.toml configuration file, as referenced in GitLab Runner Advanced Configuration.
While setting up Sentry, select Go if you’re asked for the project type.

If you see the following error in your GitLab Runner logs, then you should specify the deprecated
DSN in Sentry.io > Project Settings > Client Keys (DSN) > Show deprecated DSN.

ERROR: Sentry failure builds=0 error=raven: dsn missing private key

Error Tracking List

Users with at least Reporter permissions
can find the Error Tracking list at Monitor > Error Tracking in your project’s sidebar.
Here, you can filter errors by title or by status (one of Ignored , Resolved, or Unresolved) and sort in descending order by Frequency, First Seen, or Last Seen. By default, the error list is ordered by Last Seen and filtered to Unresolved errors.

Error Tracking list

Error Details

From error list, users can navigate to the error details page by clicking the title of any error.

This page has:

  • A link to the Sentry issue.
  • A link to the GitLab commit if the Sentry release ID/version on the Sentry Issue’s first release matches a commit SHA in your GitLab hosted project.
  • Other details about the issue, including a full stack trace.
  • In GitLab 12.7 and newer, language and urgency are displayed.

By default, a Create issue button is displayed:

Error Details without Issue Link

If you create a GitLab issue from the error, the Create issue button changes to a View issue
button and a link to the GitLab issue displays within the error detail section.

Taking Action on errors

You can take action on Sentry Errors from within the GitLab UI. Marking errors ignored or resolved require at least Developer role.

Ignoring errors

Introduced in GitLab 12.7.

From within the Error Details page you can ignore a Sentry error by clicking the Ignore button near the top of the page.

Ignoring an error prevents it from appearing in the Error Tracking List, and silences notifications that were set up within Sentry.

Resolving errors

Introduced in GitLab 12.7.

From within the Error Details page you can resolve a Sentry error by
clicking the Resolve button near the top of the page.

Marking an error as resolved indicates that the error has stopped firing events. If a GitLab issue is linked to the error, then the issue closes.

If another event occurs, the error reverts to unresolved.

Integrated error tracking

  • Introduced in GitLab 14.4.
  • Disabled in GitLab 14.9 with a flag named integrated_error_tracking. Disabled by default.

FLAG:
By default this feature is not available. To make it available on self-managed GitLab, ask an
administrator to enable the feature flag
named integrated_error_tracking. The feature is not ready for production use.
On GitLab.com, this feature is not available.

WARNING:
Turning on integrated error tracking may impact performance, depending on your error rates.

Integrated error tracking is a lightweight alternative to Sentry backend.
You still use Sentry SDK with your application. But you don’t need to deploy Sentry
or set up for cloud-hosted Sentry. Instead, you use GitLab as a backend for it.

Sentry backend automatically assigns a Data Source Name (DSN) for every project you create.
GitLab does the same. You should be able to find a DSN for your project in the GitLab error tracking
settings. By using a GitLab-provided DSN, your application connects to GitLab to report an error.
Those errors are stored in the GitLab database and rendered by the GitLab UI, in the same way as
Sentry integration.

Project settings

You can find the feature configuration at Settings > Monitor > Error Tracking.

How to enable

  1. Select GitLab as the error tracking backend for your project:

    Error Tracking Settings

  2. Select Save changes. After page reload you should see a text field with the DSN string. Copy it.

    Error Tracking Settings DSN

  3. Take the DSN from the previous step and configure your Sentry SDK with it. Errors are now
    reported to the GitLab collector and are visible in the GitLab UI.

Managing DSN

When you enable the feature you receive a DSN. It includes a hash used for authentication. This hash
is a client key. GitLab uses client keys to authenticate error tracking requests from your
application to the GitLab backend.

In some situations, you may want to create a new client key and remove an existing one.
You can do so by managing client keys with the error tracking API.

Limitations

The Integrated Error Tracking feature was built and tested with Sentry SDK for Ruby on Rails.
Support for other languages and frameworks is not guaranteed. For up-to-date information, see the
compatibility issue.

Introduced in GitLab 11.8.

Error Tracking allows developers to easily discover and view the errors that their application may be generating. By surfacing error information where the code is being developed, efficiency and awareness can be increased.

Sentry error tracking

Sentry is an open source error tracking system. GitLab allows administrators to connect Sentry to GitLab, to allow users to view a list of Sentry errors in GitLab.

Deploying Sentry

You can sign up to the cloud hosted Sentry, deploy your own on-premise instance, or use GitLab to install Sentry to a Kubernetes cluster. To make this easier, we are considering shipping Sentry with GitLab.

Enabling Sentry

GitLab provides an easy way to connect Sentry to your project. You need at
least Maintainer permissions to enable the Sentry integration.

  1. Sign up to Sentry.io or deploy your own Sentry instance.
  2. Create a new Sentry project. For each GitLab project that you want to integrate, we recommend that you create a new Sentry project.
  3. Find or generate a Sentry auth token for your Sentry project.
    Make sure to give the token at least the following scopes: event:read, project:read, and event:write (for resolving events).
  4. In GitLab, enable error tracking:
    1. On the top bar, select Menu > Projects and find your project.
    2. On the left sidebar, select Monitor > Error Tracking.
    3. Select Enable error tracking.
  5. In GitLab, ensure error tracking is active.
    1. On the left sidebar, select Settings > Monitor.
    2. Expand Error Tracking.
    3. Ensure the Active checkbox is selected.
  6. In the Sentry API URL box, enter your Sentry hostname. For example, enter https://sentry.example.com. For the SaaS version of Sentry, the hostname is https://sentry.io.
  7. In the Auth Token box, enter the token you previously generated.
  8. To test the connection to Sentry and populate the Project dropdown, select Connect.
  9. From the Project list, choose a Sentry project to link to your GitLab project.
  10. Select Save changes.

You can now visit Monitor > Error Tracking in your project’s sidebar to view a list of Sentry errors.

Enabling GitLab issues links

You may also want to enable Sentry’s GitLab integration by following the steps in the Sentry documentation

Enable GitLab Runner

To configure GitLab Runner with Sentry, you must add the value for sentry_dsn to your GitLab
Runner’s config.toml configuration file, as referenced in GitLab Runner Advanced Configuraton.
While setting up Sentry, select Go if you’re asked for the project type.

If you see the following error in your GitLab Runner logs, then you should specify the deprecated
DSN in Sentry.io > Project Settings > Client Keys (DSN) > Show deprecated DSN.

ERROR: Sentry failure builds=0 error=raven: dsn missing private key

Error Tracking List

Users with at least Reporter permissions
can find the Error Tracking list at Monitor > Error Tracking in your project’s sidebar.
Here, you can filter errors by title or by status (one of Ignored , Resolved, or Unresolved) and sort in descending order by Frequency, First Seen, or Last Seen. By default, the error list is ordered by Last Seen and filtered to Unresolved errors.

Error Tracking list

Error Details

From error list, users can navigate to the error details page by clicking the title of any error.

This page has:

  • A link to the Sentry issue.
  • A link to the GitLab commit if the Sentry release ID/version on the Sentry Issue’s first release matches a commit SHA in your GitLab hosted project.
  • Other details about the issue, including a full stack trace.
  • In GitLab 12.7 and newer, language and urgency are displayed.

By default, a Create issue button is displayed:

Error Details without Issue Link

If you create a GitLab issue from the error, the Create issue button changes to a View issue
button and a link to the GitLab issue displays within the error detail section.

Taking Action on errors

You can take action on Sentry Errors from within the GitLab UI.

Ignoring errors

Introduced in GitLab 12.7.

From within the Error Details page you can ignore a Sentry error by clicking the Ignore button near the top of the page.

Ignoring an error prevents it from appearing in the Error Tracking List, and silences notifications that were set up within Sentry.

Resolving errors

Introduced in GitLab 12.7.

From within the Error Details page you can resolve a Sentry error by
clicking the Resolve button near the top of the page.

Marking an error as resolved indicates that the error has stopped firing events. If a GitLab issue is linked to the error, then the issue closes.

If another event occurs, the error reverts to unresolved.

Introduced in GitLab 11.8.

Error Tracking allows developers to easily discover and view the errors that their application may be generating. By surfacing error information where the code is being developed, efficiency and awareness can be increased.

Sentry error tracking

Sentry is an open source error tracking system. GitLab allows administrators to connect Sentry to GitLab, to allow users to view a list of Sentry errors in GitLab.

Deploying Sentry

You can sign up to the cloud hosted Sentry, deploy your own on-premise instance, or use GitLab to install Sentry to a Kubernetes cluster. To make this easier, we are considering shipping Sentry with GitLab.

Enabling Sentry

GitLab provides an easy way to connect Sentry to your project. You need at
least Maintainer permissions to enable the Sentry integration.

  1. Sign up to Sentry.io or deploy your own Sentry instance.
  2. Create a new Sentry project. For each GitLab project that you want to integrate, we recommend that you create a new Sentry project.
  3. Find or generate a Sentry auth token for your Sentry project.
    Make sure to give the token at least the following scopes: event:read and project:read.
  4. In GitLab, navigate to your project’s Monitor > Error Tracking page, and
    click Enable Error Tracking.
  5. Navigate to your project’s Settings > Monitor. In the Error Tracking section,
    ensure the Active checkbox is set.
  6. In the Sentry API URL field, enter your Sentry hostname. For example, enter https://sentry.example.com if this is the address at which your Sentry instance is available. For the SaaS version of Sentry, the hostname is https://sentry.io.
  7. In the Auth Token field, enter the token you previously generated.
  8. Click the Connect button to test the connection to Sentry and populate the Project dropdown.
  9. From the Project dropdown, choose a Sentry project to link to your GitLab project.
  10. Click Save changes for the changes to take effect.
  11. You can now visit Monitor > Error Tracking in your project’s sidebar to view a list of Sentry errors.

Enabling GitLab issues links

You may also want to enable Sentry’s GitLab integration by following the steps in the Sentry documentation

Error Tracking List

Users with at least Reporter permissions
can find the Error Tracking list at Monitor > Error Tracking in your project’s sidebar.
Here, you can filter errors by title or by status (one of Ignored , Resolved, or Unresolved) and sort in descending order by Frequency, First Seen, or Last Seen. By default, the error list is ordered by Last Seen and filtered to Unresolved errors.

Error Tracking list

Error Details

From error list, users can navigate to the error details page by clicking the title of any error.

This page has:

  • A link to the Sentry issue.
  • A link to the GitLab commit if the Sentry release ID/version on the Sentry Issue’s first release matches a commit SHA in your GitLab hosted project.
  • Other details about the issue, including a full stack trace.
  • In GitLab 12.7 and newer, language and urgency are displayed.

By default, a Create issue button is displayed:

Error Details without Issue Link

If you create a GitLab issue from the error, the Create issue button changes to a View issue
button and a link to the GitLab issue displays within the error detail section.

Taking Action on errors

You can take action on Sentry Errors from within the GitLab UI.

Ignoring errors

Introduced in GitLab 12.7.

From within the Error Details page you can ignore a Sentry error by clicking the Ignore button near the top of the page.

Ignoring an error prevents it from appearing in the Error Tracking List, and silences notifications that were set up within Sentry.

Resolving errors

Introduced in GitLab 12.7.

From within the Error Details page you can resolve a Sentry error by
clicking the Resolve button near the top of the page.

Marking an error as resolved indicates that the error has stopped firing events. If a GitLab issue is linked to the error, then the issue closes.

If another event occurs, the error reverts to unresolved.

Graphic showing the GitLab and Sentry logos

Sentry is an error-tracking platform that lets you monitor issues in your production deployments. It supports most popular programming languages and frameworks.

GitLab is a Git-based DevOps platform to manage the entire software development lifecycle. GitLab can integrate with Sentry to display captured errors. In this article, we’ll use the two services to stay ahead of issues in a React application.

Getting Set up

GitLab and Sentry both have self-hosted and SaaS options. The steps in this guide apply to both variants. We’ll assume that you’ve already got a React project ready to use in your GitLab instance.

Log in to Sentry and click the “Create Project” button in the top-right corner. Click “React” under the “Choose a platform” heading. This lets Sentry tailor example code snippets to your project.

image of adding a new React project in Sentry

Choose when to receive alerts using the options beneath “Set your default alert settings.” Select “Alert me on every new issue” to get an email each time an error is logged. The “When there are more than” option filters out noise created by duplicate events in a given time window.

Give your project a name in the “Project name” field. Click “Create Project” to finish your setup.

Adding Sentry to Your Codebase

Now, you need to integrate Sentry with your React code. Add the Sentry library to your project’s dependencies using npm:

npm install @sentry/react

You’ll need to initialize Sentry as soon as possible in your app’s JavaScript. This gives Sentry visibility into errors that occur early in the React lifecycle. Add Sentry’s bootstrap script before your first ReactDOM.render() call. This is typically in index.js:

import App from "./App.js";
import React from "react";
import ReactDOM from "react-dom";
import * as Sentry from "@sentry/react";
 
Sentry.init({
    dsn: "my-dsn"
});
 
ReactDOM.render(<App />, document.getElementById("react"));

Replace my-dsn with the DSN that Sentry displays on your project creation screen. The DSN uniquely identifies your project so that the service can attribute events correctly.

Capturing Errors

Sentry will automatically capture and report unhandled JavaScript errors. Although it can’t prevent the crash, it lets you know that something’s gone wrong before the user report arrives.

Here’s an example App.js:

import React from "react";
 
export default () => {
    const data = null;
    return data.map((val, key) => {
        <h1 key={key}>{val}</h1>;
    });
};

This code is broken—data is set to null, so the map property will be undefined. We try to call data.map() regardless so that the app will crash. You should see an issue show up in Sentry.

Sentry issues include as much data about the error as possible. You can see the page URL as well as information about the user’s device. Sentry will automatically combine duplicate issues together. This helps you see whether an event was a one-off or a regular occurrence that’s impacting multiple users.

image of a Sentry error

Sentry automatically fetches JavaScript source maps when they’re available. If you’re using create-react-app, source maps are automatically generated by npm run build. Make sure that you copy them to your web server so that Sentry can find them. You’ll see pretty stack traces from the original source code instead of the obfuscated stack produced by the minified build output.

image of Sentry showing a stack trace from a source map

You can mark Sentry errors as Resolved or Ignored once they’ve been dealt with. You’ll find these buttons below the issue’s title and on the Issues overview page. Use Resolved once you’re confident that an issue has been fixed. Ignored is for cases where you don’t intend to address the root cause. In React sites, this might be the case for errors caused by old browser versions.

Error Boundaries

React error boundaries let you render a fallback UI when an error is thrown within a component. Sentry provides its own error boundary wrapper. This renders a fallback UI and logs the caught error to Sentry.

import * as Sentry from "sentry";
 
export default () => {
    const data = null;
    return (
        <Sentry.ErrorBoundary fallback={<h1>Something went wrong.</h1>}>
            {
                data.map((val, key) => {
                    <h1 key={key}>{val}</h1>;
                });
            }
        </Sentry.ErrorBoundary>
    );
};

Now, you can display a warning to users when an error occurs. You’ll still receive the error report in your Sentry project.

Adding GitLab Integration

There are two sides to integrating GitLab and Sentry. First, GitLab projects have an “Error Tracking” feature that displays your Sentry error list. You can mark errors as Resolved or Ignored from within GitLab. The second part involves connecting Sentry to GitLab. This lets Sentry automatically create GitLab issues when a new error is logged.

image of creating an API key in Sentry

Let’s look at GitLab’s Error Tracking screen first. You’ll need to create a Sentry API key. Click your username in the top left of your Sentry UI, and then the API Keys in the menu. Click “Create New Token” in the top-right corner.

Add the following token scopes:

  • alerts:read
  • alerts:write
  • event:admin
  • event:read
  • event:write
  • project:read

This allows GitLab to read and update your Sentry errors.

image of Sentry API token scopes

Next, head to your GitLab project. Click Settings in the side menu, and then Operations. Expand the “Error tracking” section. Paste your Sentry authentication token into the “Auth Token” field and press “Connect.” If you’re using a self-hosted Sentry instance, you’ll also need to adjust the “Sentry API URI” field to match your server’s URI.

image of GitLab's error tracking settings

The “Project” dropdown will populate with a list of your Sentry projects. Select the correct project and press “Save changes.” You’re now ready to use Error Tracking in GitLab.

Click Operations > Error Tracking in the left sidebar. You’ll see your Sentry error list. It’s filtered to Unresolved issues by default. This can be changed using the dropdowns in the top-right corner. Click an error to see its detailed stack trace without leaving GitLab. There are buttons to ignore, resolve, and convert to a GitLab issue. Once you’ve opened a GitLab issue, you can assign that item to a team member so that the bug gets resolved.

image of GitLab's Error Tracking screen

Now, you can add the second integration component—a link from Sentry back to GitLab. Click Settings in your Sentry sidebar, and then Integrations. Find GitLab in the list and click the purple “Add Installation” button in the top-right corner. Click “Next” to see the setup information.

image of adding the GitLab Sentry integration

Back on GitLab, click your user icon in the top-right corner, followed by “Preferences.” Click “Applications” in the left side menu and add a new application. Use the details shown by Sentry in the installation setup pop-up.

image of creating a new GitLab application integration

GitLab will display an Application ID and Secret Key. Return to the Sentry pop-up and enter these values. Add your GitLab server URL (gitlab.com for GitLab SaaS) and enter the relative URL path to your GitLab group (e.g. my-group). The integration doesn’t work with personal projects.

image of adding the GitLab Sentry integration

Click the purple Submit button to create the integration. Sentry will now be able to display GitLab information next to your errors. This includes the commit that introduced the error, and stack traces that link back to GitLab files. Sentry users on paid plans can associate GitLab and Sentry issues with each other.

Disabling Sentry in Development

You won’t necessarily want to use Sentry when running your app locally in development. Don’t call Sentry.init() if you want to run with Sentry disabled. You can check for the presence of a local environment variable and disable Sentry if it’s set.

if (process.env.NODE_ENV === "production") {
    Sentry.init({
        dsn: "my-dsn"
    });
}

NODE_ENV is set automatically by create-react-app. Production builds hardcode the variable to production. You can use this to selectively enable Sentry.

Enabling Performance Profiling

Sentry can also profile your app’s browser performance. Although this isn’t the main focus of this article, you can set up tracing with a few extra lines in your Sentry library initialization:

npm install @sentry/tracing
import {Integrations} from "@sentry/tracing";
 
Sentry.init({
    dsn: "my-dsn",
    integrations: [new Integrations.BrowserTracing()],
    tracesSampleRate: 1.0
});

Now, you’ll be able to see performance data in your Sentry project. This can help you identify slow-running code in production.

Conclusion

Sentry lets you find and fix errors before users report them. You can get real-time alerts as problems arise in production. Stack traces and browser data are displayed inline in each issue, giving you an immediate starting point for resolution.

Combining Sentry with GitLab provides even tighter integration with the software development process. If you’re already using GitLab for project management, adding the Sentry integration lets you manage alerts within GitLab and create GitLab issues for new Sentry errors.

READ NEXT

  • › 5 AI Technologies Hackers Can Use in Terrible New Ways
  • › Amplify the Crunch of Helmets With $50 off a Sonos Soundbar
  • › Mozilla Is Rebuilding Thunderbird “From the Ground Up”
  • › No, Incognito Mode Won’t Protect You When Torrenting
  • › How to Reset or Change Your Steam Password
  • › How Do You Unfollow Someone on TikTok?

Graphic showing the GitLab and Sentry logos

Sentry is a popular error-tracking platform that gives you real-time visibility into issues in your production environments. GitLab’s Error Reporting feature lets you bring Sentry reports into your source control platform, offering a centralized view that unifies Sentry errors and GitLab issues.

The feature originally relied on an integration with an existing Sentry service, either the official Sentry.io or your own self-hosted server. This changed with GitLab 14.4 which added a lightweight Sentry-compatible backend to GitLab itself. You no longer need an actual Sentry installation to get error reports into GitLab.

Here’s how to get started with the integrated Sentry backend. Before we proceed, it’s worth mentioning that this capability might not be right for you if you’re already acquainted with the Sentry dashboard. GitLab’s backend is a barebones solution which surfaces errors as a simple list. It’s best for smaller applications where you don’t want the overhead of managing a separate Sentry project.

Getting Started

Create a new project on GitLab.com or your own GitLab server. Navigate to Settings > Monitor in your project’s sidebar and then expand the “Error tracking” section. Enable the checkbox under “Enable error tracking”. Make sure the “Error tracking backend” radio button is set to “GitLab”. Press the blue “Save changes” button to continue.

image of setting up GitLab error tracking with integrated Sentry backend

The page will reload. Now you can expand the “Error tracking” section again to reveal your DSN string. This URL is used to configure your Sentry client library to send events to the GitLab server.

image of setting up GitLab error tracking with integrated Sentry backend

Configuring the Client

Now you can add Sentry to your code. Here’s a basic example using the official Sentry client library for Node.js. You can install the package by running npm install @sentry/node. Documentation on all the available clients is available from Sentry.

const sentry = require("@sentry/node");
 
sentry.init({
    dsn: "https://glet_abc123@gitlab.example.com/api/v4/error_tracking/collector/1"
});

Replace the DSN value with the string you copied from the GitLab UI. The part before the @ is a special authentication token that permits access to the GitLab server. The remainder consists of the unique error tracking ingest API endpoint for your project.

Testing Your Integration

Official Sentry client libraries start capturing unhandled errors as soon as they’re configured with a DSN. If any following code throws an error that you don’t catch, the event will be reported to your GitLab server.

You can test the integration by manually capturing events. Here’s an example that creates and reports an Errorinstance:

Sentry.captureException(new Error("Sentry test"));

Use your project’s sidebar in the GitLab web UI to navigate to the Monitor > Error Tracking page. The error you captured should show up in the list. Click its entry to view the full report and stack trace.

image of error reports screen in GitLab

GitLab issues can be created from reports using the blue “Create issue” button in the top-right. This lets you assign remediation work to team members and start a discussion on the problem. The issue will retain a link to the error report and the stack trace will show inline below the issue’s description.

image of an error report in GitLab

Once you’re done patching an issue, use the Error Tracking page to mark it as resolved. Issues can also be ignored if you don’t intend to remedy them, perhaps because they were transient or logged by an outdated client.

Limitations

GitLab’s integrated Sentry backend is currently intended for small-scale situations where deploying Sentry is seen as too complex or unnecessary. The full Sentry platform is a broad system that can take time to configure and maintain. GitLab’s integration is a single checkbox in your project’s settings but this simplicity comes at a cost.

The Error Tracking list is your only view into reports. You can’t currently graph them, view changes in report volumes over time, or filter by individual users or clients. Detailed information shown by the Sentry UI, such as browser and server data, isn’t currently supported or surfaced anywhere in GitLab.

You should also be aware that GitLab can’t yet send emails for new error reports. You must manually monitor the Error Tracking page to stay ahead of the events being generated by your deployments.

As GitLab implements the core features of the Sentry API, it’s compatible with most major SDKs and client libraries. As of GitLab 14.5, it’s confirmed to work with Ruby, JavaScript, Java, and Python; other languages either have partial support or will be added in future GitLab releases.

Summary

GitLab’s Sentry backend provides a simple way to capture error reports from your application and store them alongside your code. Although its current limitations render it unsuitable for all but the simplest of use cases, it’s still a compelling option for smaller sites and personal projects that don’t need the complexity of a full Sentry service.

The integrated backend could also be useful when testing Sentry integration with your code. If you’re setting up a new client, or modifying settings of an existing one, you could use your GitLab server as a temporary backend so you don’t pollute your primary Sentry deployment.

GitLab’s Error Tracking component remains in development and is due to be expanded over subsequent milestones. This should see it evolve into a more fully fledged option that can replace standalone Sentry in a broader set of environments.

READ NEXT

  • › How to Reset or Change Your Steam Password
  • › How Do You Unfollow Someone on TikTok?
  • › Mozilla Is Rebuilding Thunderbird “From the Ground Up”
  • › 5 AI Technologies Hackers Can Use in Terrible New Ways
  • › Amplify the Crunch of Helmets With $50 off a Sonos Soundbar
  • › No, Incognito Mode Won’t Protect You When Torrenting

Понравилась статья? Поделить с друзьями:

Читайте также:

  • Get adcomputer сервер вернул следующую ошибку недопустимый контекст перечисления
  • Get 500 ошибка
  • Get 500 internal server error ajax
  • Get 404 ошибка
  • Get 304 error

  • 0 0 голоса
    Рейтинг статьи
    Подписаться
    Уведомить о
    guest

    0 комментариев
    Старые
    Новые Популярные
    Межтекстовые Отзывы
    Посмотреть все комментарии