SaaS, Self-Managed and Dedicated Troubleshooting tables
Troubleshooting tips for various problems on each GitLab platform type
Overview
The purpose of this page is to provide a single reference point that Support Engineers can use when they need troubleshooting tips for various problems on any GitLab platform. The goal is to make it easier for each Support Engineer to resolve support tickets regardless of the GitLab platform involved.
How to use this page
Find the topic of interest to you, and follow the instructions there in the table row that matches the appropriate GitLab platform: Self Managed, SaaS, or Dedicated.
Logs and Performance
| Self-managed | GitlabSOS is a great way to gather all logs from a customer instance in order to investigate further on potential issues. Similar to GitlabSOS, use KubeSOS if your customer uses Kubernetes instead of source or omnibus installations. Fast-stats is a great way to compare performance analytics from and between GitLab Logs. Green-hat is an experimental SOS and log parser. |
| DotCom | Kibana provides visualization capabilities on top of the content indexed on an Elasticsearch cluster to find Web based queries. Check the tips and tricks to understand what kind of information you can pull using this tool. Sentry helps investigate errors across different applications or environments, for example Ruby code related errors. Search on Sentry usually is done using a Correlation ID. Grafana is used for infrastructure metrics collection for GitLab.com |
| Dedicated | The GitLab Dedicated Logs workflow has information about using Opensearch to view logs. The Observability and Monitoring workflow has information about using Grafana to diagnose performance problems. |
Configuration
| Self-managed | Customers manage the configuration for their self-managed instances. Depending on the deployment method, the configuration will be in /etc/gitlab/gitlab.rb, docker-compose.yml, values.yaml or similar. |
| DotCom | The GitLab.com configurations is managed by the infrastructure team and cannot be modified to meet individual customer’s needs. |
| Dedicated | GitLab Dedicated customers can configure their tenants via Switchboard and via the Admin Area. GitLab Support team members can get access Switchboard through Okta by following these steps. Some configuration changes must be done via a Request for Help issue. |
Architecture
| Self-managed | Check out the reference architectures we recommend to our customers and their different variations |
| DotCom | The GitLab.com architecture is managed by the infrastructure team and cannot be modified to meet individual customer’s needs. |
| Dedicated | GitLab Dedicated is a fully isolated, single-tenant, SaaS service managed through AWS by the GitLab Dedicated Group. GitLab Dedicated tenants use the GitLab Cloud Native Hybrid reference architectures with high availability enabled. See the list of changes from the reference architectures. |
Auth
| Self-managed | Self Managed Administrators will need to configure the desired auth provider directly in their gitlab.rb. Any configuration change on this file will require that you run gitlab-ctl reconfigure to successfully apply changes. |
| DotCom | Customers will Configure SAML SSO for Groups directly, by going to Group > Settings > SAML SSO. |
| Dedicated | Start the investigation by searching the logs. To escalate, raise an issue with the GitLab Dedicated team. |
Geo
| Self-managed | Geo is configured in the gitlab.rb file. It requires a premium or higher subscription. The steps must be followed in the order in which they appear. |
| DotCom | Geo is a Self-Managed feature only. |
| Dedicated | Raise issue with Dedicated team |
Admin Area
| Self-managed | Administrators of self-managed systems will have access to their instance admin. |
| DotCom | Only GitLab Team Members can make use of administrative tasks on GitLab.com, therefore access is not granted to customers. |
| Dedicated | Customers have instance admins that can access the Admin Area. There is no GitLab Rails console access for customers. |
Use the Admin Area docs for reference.
Gitaly
| Self-managed | Gitaly configuration is managed through the gitlab.rb file. A customer can configure stand-alone Gitaly or leverage Gitaly Cluster to fulfill its git requirements. Be sure you know which of these types of Gitaly configuration a self-managed customer is using before you begin troubleshooting. |
| DotCom | Gitaly is managed by the infrastructure team of GitLab, so customers do not have access to it. |
| Dedicated | Raise issue with Dedicated team |
Runners
| Self-managed | Self-managed runners are deployed to customer-owned infrastructure and registered to the self-managed GitLab instance. |
| DotCom | GitLab-hosted runners are available to all projects stored on GitLab.com. Self-managed runners can also be registered to GitLab.com. |
| Dedicated | GitLab-hosted runners (beta) can be provisioned for Dedicated customers. Self-managed runners can also be registered to Dedicated environments. |
Last modified April 9, 2024: Add runners section to Support Team troubleshooting doc (
c5a5f31a)
