GitLab promises observability for all, asks for help in return

GitLab promises observability for all, asks for help in return
Gitlab Logo

Following its stewardship mandate, GitLab has announced the moving of “a big portion of our observability features” to the core and therefore making them freely available to its community users.

According to the official blog post, GitLab’s mission is “to provide an end-to-end DevOps solution for developers that is also open source”. However, the company previously kept “essential observability tools in a proprietary codebase”, which isn’t great when you’re working on a personal project and are interested in its performance once it has been deployed.

So in the spirit of open sourcing components individual contributors will care about, GitLab now promised to move some logging, tracing, alerting, and custom metrics features out of the enterprise part of the codebase and into the open core. The migration is planned to be done in early 2020.

Apart from the self-imposed policy, the step is also motivated by the company’s interest in additional observability input. In fact, the company has a whole list of things it wants help with. For one, GitLab is looking for feedback on its logging capabilities, especially in relation to Kubernetes clusters. At the moment, devs can essentially see “a live stream of their logs”. GitLab’s director of product, Ops products, Kenny Johnston, isn’t sure this is sufficient and would appreciate comments on the issue. 

Even more work needs to be put into GitLab’s tracing capabilities, which are still rudimentary at best, with it boiling down to an embedded UI of CNCF tracing project Jaeger. Johnston would therefore “love to see contribution from members of the Jaeger community for more deep integration into GitLab. Maybe developers and operators who use GitLab would like to see more of the Jaeger UI experience directly in GitLab.” Once that is provided for, alerting could be improved as well.

Prometheus integration meanwhile seems pretty solid, but since everything can be improved, merge requests for metric improvements are also on the company’s wishlist. Or as Johnston puts it “If you don’t like the way that your alerting is set up, or you don’t like the way that your log system is aggregated we’d love your contributions. If you don’t like how metric charts, logs or traces are displayed in fire-fighting issues we’d love your contributions.”

Active community participation might also be needed at this point, since attempts to collect more user data and giving it to third party services to learn about user habits, did lead to some backlash earlier this year. As a consequence, the company pulled its telemetry plans and apologised for “not living up to our own core value of collaboration”.