OpenTelemetry Integration
Problem to solve
At the moment an arsenal of tools is needed to collect metrics, error logs(issues) and analytics for them to be linked to and imported into GitLab. OpenTelemetry is the merger of OpenCensus and OpenTracing, as well as a CNCF Sandbox member that would allow the developer's code to collect all the needed metrics developers, need to find out where problems are arising in libraries that are much smaller and less resource-intensive than Prometheus and Sentry setups.
This system has active marketing with the cloud-native circles and would be perfect as multi-cloud users.
Instead of configuring a Prometheus setup on each datacenter/cluster a CI/CD variable could easily be set to configure OpenTelemetry to send it's information directly to GitLab instead of StackDriver, Sentry, DataDog etc.
Would be better for GitLab Enterprise Sales aswell.
Intended users
Developers would benefit the most as they would no longer need to leave GitLab at all unless they use an external program for development.
Customer Service Teams would benefit as they would be able to link the issues in the service desk to ensure the end-user customer support and developers are all as informed as possible.
Further details
This would be a good step towards GitLabs claims of simplifying the toolchain.
Scenario: Acme International LLC has Kubernetes Clusters running their microservices dotted around the world with Google Cloud, AWS, Alibaba, Azure, Digital Ocean and On-Prem. (Would love their Budget). Now GCP and AWS can both use stack driver natively the others can't (that I know of). The company is an avid GitLab fan who loves having the one platform to manage everything. Something goes wrong they can send a signal out to Sentry to be copied and pasted as a GitLab issue for community users or imported for premium users.
That is all well and good but then they have to look through the deployment logs and try to pair Prometheus events to the same issue which is wasted time. Not to mention big companies love to be as in control of their data as possible so naturally, they have their own enterprise deployment of GitLab and their own deployments of Prometheus on every cluster and copies of Sentry server aswell. Ultimately leading to significant resource requirements (GitLab is a little bit of a resource hog on its own) without adding Prometheus (plus its datastore) and Sentry with its Postgres database and Redis setups which GitLab already use. All these different moving parts would require a member of staff to maintain that as well as the GitLab Cluster.
Scenario 2: (My Company) The People Range offers Business and Data Aggregation Services, It's systems are built on top of GKE Clusters but vendor lock-in is an issue. Especially seen as GCP has an SMTP restriction. Their platform is many microservices deployed using GitLab Runners to Istio enabled clusters. Istio's metrics and logging engine Mixer has a plugin for OpenCensus (part of OpenTelemetry) which would allow GitLab to have insights into the security and networking of programs held on GitLab as well as the actual application logs, traces and analytics which allows GitLab to help the DevOps team make a much more informed decision company-wide instead of just per project. Allowing the company to optimise its infrastructure as well as its applications all from a CI/CD Pipeline without ever leaving or copying and pasting from one platform to another.