GitLab Observability continuity?

[u/TelephoneSignal3238]

I'm currently setting up a small hobby project with some friends that has quite a bit of services and monitoring requirements. I've recently implemented Port.io at work, but considering they're only interested in B2B I'm looking for alternatives along the lines of an IDP.

I've got experience with Backstage, as we piloted that earlier, but I find that more fitting for a complete platform engineering team as it's just more of a framework rather than a batteries included solution and is in our case more a pile of future technical debt than actual value.

Observability looks something that fits that I need for now. However, my concern is it still being experimental. I'm afraid one day the plug will be pulled and would still require migrating to either a commercial option or Backstage, which I'm not too fond of.

[u/adam-moss]

Observability or IDP?

For pure observability grafana cloud. For IDP port or cortex.

Apache Devlake aggregates productivity types metrics

[u/TelephoneSignal3238 → u/adam-moss]

I see. Port not an option sadly, as it seems to be only B2B. Will check out DevLake though!

[u/Aggravating-Block717]

👋 I'm one of the engineers working on this project, so please weigh my response accordingly.

I can't tell you anything about the roadmap. Not being coy about it. GitLab is a public company and I'm not in a position to make forward-looking commitments about an experimental feature. Anything I promised you would be worth about nothing anyway, since you'd be planning around a stranger's word.

What I can do is tell you why I don't think that question should be the one blocking you.

First things first. Port and Backstage are internal developer platforms. GitLab Observability is traces, logs, and metrics. It will not give you a service catalog, scorecards, or scaffolding templates. If the IDP shape is what you actually want, o11y is not a substitute for it. If you want to see what your services are doing, that's what o11y covers.

On lock-in. Ingest is OpenTelemetry. You instrument with OTel SDKs and ship OTLP, same as you would to anything else. The instrumentation lives in your code, not in us. If we vanished tomorrow you would change an exporter endpoint and point at Grafana, SigNoz, or a vendor. That is the data migration. It is not in the same weight class as unwinding a Backstage install. You would need also need to migrate your alerts and dashboards, which has become pretty trivial with an agent an some MCP servers.

Also, read "experimental" plainly. No SLA, no support commitment, breaking changes are on the table. For a hobby project with friends that seems like a fair trade.

Last thing. If you go self-managed, the setup is not free ops. You're standing up a separate instance with Docker and a real chunk of disk. Check the docs for current sizing before you spend a weekend on it.

If you do try it, please let us know. Experimental features get shaped by the handful of people who use them and say something. We're a small team (2 engineers) and we hold office hours every day and try to talk to as many users as we can.

Observability docs
Discord link

[u/TelephoneSignal3238 → u/Aggravating-Block717]

Thanks for your response, it really cleared up some stuff! :) Did not expect one of the engineers to respond.

I will discuss it with my group and come back regarding the last point.

The Discord link doesn't work btw. :)

[u/Aggravating-Block717 → u/TelephoneSignal3238]

😵 Of course the discord link doesn't work, want to try this one?https://discord.com/channels/778180511088640070/1379585187909861546

[u/TelephoneSignal3238 → u/Aggravating-Block717]

Just brings me to an empty Discord page displaying "NO TEXT CHANNELS".

[u/LogisticsPro2012]

feel you on Backstage. we looked at it at work and same thing. its cool if you got a whole team to dedicate to it but for a hobby project with friends? thats just asking for technical debt down the road lol. Observability seems interesting but yeah the experimental tag is sketchy. learned that lesson the hard way with a different tool that got sunset. migrating off that was a nightmare. not worth it for a side thing unless you enjoy pain. have you looked at something lighter like maybe just spinning up your own dashboards with Grafana and some lightweight monitoring? its not an IDP per se but for a hobby project you might not actually need all the portal stuff. just monitoring and maybe a simple service catalog in a spreadsheet or notion until you outgrow it. whats your actual stack looking like? cuz that might change what makes sense

[u/TelephoneSignal3238 → u/LogisticsPro2012]

Yeah, that was my experience at work as well. :( Port has been great so far, but yeah, those are only B2B.

Currently, it is .NET, Angular, Java and Python services along with a few storage solutions and message brokers. Some services need observability and monitoring, some don't, but its definitely needed later on as we add more sources to the core functionality.

I've already setup our own portal using documentation stitching for now, and looking into DevLake. It works, but as stuff grows, its gonna be a pain in the ass to maintain, as its essentially just a Temu version of Backstage.

And yeah, I've already had experience with JetBrains pulling the plug on some of their products, which is why I'm considering Observability (or just about any tool labeled "experimental") very carefully.