Support BYO Prometheus instead of GMAv1 Prometheus
Tasks
-
New integration tab allowing users to enable Prometheus integration - [-] Migrate existing prometheus as a new Integration, write docs on what to do, e.g. uninstall, upgrade, etc => #327655 (closed)
- We can use the
version
, andstate
field. If state isexternally_installed
, we should set a differentversion
- There's about 14K records on production
-
Update the empty state text in the Health tab and prompt users to manually install Prometheus and enable the integration from the Integrations tab. -
[-] Information banner (with dismiss button) on the top of the integrations tab to inform the user that the Applications will be deprecated and they will need to enable the integrations for Prometheus and Elastic Stack here. Not doing for now
- Something like “After the release 14.0 the cluster applications integration with GitLab is changing. In order to use Prometheus and Elastic Stack integrations with GitLab enable the integrations below after you have installed the applications in your cluster. Learn more about the cluster integrations.”
-
New model/table clusters_integration_prometheus
Release notes
By integrating your cluster services with GitLab you can benefit from various GitLab features, like Environment boards, Prometheus metrics, application logs. Previously, these integrations required to use the GitLab provided GitLab Managed Apps that did not fit the workflow and requirements of many of our users. With the current release, GitLab allows you to register GitLab supported services with GitLab, and keep their maintenance on your end, following your company processes.
At the same time, we provide extensive documentation and a recommended workflow on how to install these applications if you are just getting started with any of the supported applications. In this release, we are providing support to bring your own Prometheus and have the deep metrics integrations available with a GitLab Managed Prometheus before.
Problem to solve
As a Platform Engineer, I want to register my existing Prometheus/ElasticStack installations with GitLab, so I can use my own settings and configuration and benefit from the GitLab integrations at the same time.
Intended users
User experience goal
Provide an API endpoint and UI for each cluster to to enable:
- Integration with Prometheus installed in the cluster. There seems to be some research related to this in &4045
-
Integration with Nginx Ingress installed in the cluster.See also alternative proposal.
Proposal
Iteration 1
Just provide a simple, checkbox-like experience. The application is assumed to be installed with Helm, in a fixed namespace (gitlab-managed-apps
), and with a specific name.
If the user enables the integration, we mark it as Manually installed
in the appropriate model. Everything else that depends on that model should continue to work as normal.
It can look something like :
Project cluster "cluster name"
Details | Health | Integrations | Advanced Settings
[x] Enable ElasticStack integration.
Enables ElasticStack integration, via Kubernetes API. ElasticStack must be installed in the Kubernetes cluster, a Service resource called
elastic-stack-elasticsearch-master
must exist in thegitlab-managed-apps
namespace so that GitLab may use that Service to make Elasticsearch queries. Learn more[x] Enable Prometheus integration.
Enables Prometheus integration, via Kubernetes API. Prometheus must be installed in the Kubernetes cluster, and a Service resource for Prometheus called
prometheus-prometheus-server
in thegitlab-managed-apps
namespace must exist so that GitLab may use that Service to make PromQL queries. Learn more
Iteration 2
Provide customizations for the application registration, like the namespace, service account how the application can be reached
Out of scope
Integrations with other Kubernetes applications. See #292460 (comment 485949173)
Further details
Permissions and Security
We provide extensive documentation and a recommended workflow on how to install these applications. At minimum, we will provide instructions on how to replicate what GMA v1 currently does.
- required namespace
- required Helm release name
- required Helm values
- required Helm chart versions
- required post-install scripts.
If possible, we will provide examples for easy copy-paste.
Availability & Testing
What does success look like, and how can we measure that?
What is the type of buyer?
Is this a cross-stage feature?
Links / references
Followups
-
- Integration with ElasticStack installed in the cluster. #326560 (closed)
This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.