The question comes up in almost every first conversation, and it’s usually loaded before anyone even asks it. One person has heard that commercial APM tools are overpriced vendor lock-in. Another has heard that open source is a hobbyist’s basement that nobody ends up running. Both are partly right, and both are asking the wrong question. Whether you run an observability stack yourself or buy it doesn’t hinge on ideology, but on four sober criteria.
The starting point: two camps asking the same question the wrong way
We’ve seen both worlds from the inside. For years as a subcontractor for a large APM vendor, across EMEA, in production and carrying the on-call phone, and during the same period with the LGTM stack, which for us grew from a side project into a fixture. By that we mean Loki for logs, Grafana for the interface, Tempo for traces and Mimir for metrics. Our customers ranged from a mid-sized company with a platform team of three to a corporate group with dozens of development teams and its own regulator breathing down its neck.
Out of this dual role, one observation stays constant: "open source versus commercial" isn’t the axis the decision actually turns on. The real axis runs elsewhere — between building and operating a stack yourself on one side, and conveniently buying it from a vendor on the other. That’s a different thing, and it can be decided with four criteria instead of articles of faith.
What a self-operated observability stack really costs
A commercial tool takes operational work off your plate; an open-source stack gives you control. That’s the actual trade, not "free software good, expensive software bad." A self-operated Grafana stack isn’t a cost-saving model, it’s a commitment. What you pay for isn’t the license, it’s the people who keep the stack running, upgrade it, scale it and debug it at three in the morning when the ingestion pipeline fills up.
Conversely, nobody buys their way out of responsibility with a commercial APM. They buy their way out of part of the operations, not out of the question of where their data sits and who can access it. And "operations" is no abstraction with the LGTM stack: it means upgrading four components on a cadence set by the vendor, retention and compaction in object storage, capacity planning for ingesters and queriers, and monitoring for the monitoring itself — because a stack that fails silently is worse than none at all.
OpenTelemetry has undercut the old camp logic anyway. Once your applications are instrumented with OpenTelemetry, the question of the backend becomes secondary: the same traces go into a commercial tool today and into Tempo tomorrow, without touching the code. OpenTelemetry is the bridge, not a camp, and that takes much of the drama out of the fundamental decision.
Four criteria the decision actually hinges on
Compliance. In regulated environments such as the financial sector, healthcare or the public sector, the discussion is often over before it gets technical. If the regulator requires that certain data never leaves your own data center, a pure SaaS offering is out — no matter how good it is. That’s why the concrete requirements belong on the table early, not the feature lists.
Data sovereignty. Logs and traces often contain more than those responsible realize: request payloads, user IDs, and in the worst case personal data that nobody meant to store there. If that data ends up in a cloud outside the EU, the question of third-party access is no longer theoretical. Anyone who has to protect European data builds it into the architecture, not on top afterwards as a policy. That can mean a backend in your own data center, a vendor with guaranteed EU operation, or filtering the data before it leaves the building.
In-house expertise. The most honest question in the whole process is whether the team has the people to run the stack today, not whether it could train them. We’ve seen enough projects where an ambitious open-source stack was set up and then orphaned because the two people who understood it left the team. A self-operated stack without lasting internal expertise is a risk, not an asset.
Team structure. If there’s a platform team that can and wants to run observability as a product, self-operation often makes sense. If it’s development teams that are supposed to deliver features and drag monitoring along on the side, you’re better off buying and sparing the team the secondary battlefront. Price is deliberately not on this list: it comes last, and it rarely looks the way it does on the first invoice.
Data sovereignty can be enforced in the pipeline, not in the policy
Of the four criteria, data sovereignty is the only one you can secure technically — and independently of whether you end up building or buying. The OpenTelemetry Collector sits between the applications and any backend. There you can delete or hash attributes before a single span leaves the building. This configuration applies to the OpenTelemetry Collector Contrib 0.128 with Grafana Tempo 2.8 as the backend:
receivers:
otlp:
protocols:
grpc:
endpoint: ${env:MY_POD_IP}:4317
processors:
attributes/datenhoheit:
actions:
- key: http.request.header.authorization
action: delete
- key: user.email
action: delete
- key: enduser.id
action: hash
batch: {}
exporters:
otlp/tempo:
endpoint: tempo-distributor.observability:4317
tls:
insecure: true
service:
pipelines:
traces:
receivers: [otlp]
processors: [attributes/datenhoheit, batch]
exporters: [otlp/tempo]The attributes processor knows the actions insert, update, upsert, delete, hash, extract and convert. In the example, the Authorization header is deleted, the email address is removed, and the user ID is hashed with SHA-1, so that a user remains correlatable across multiple traces without being identifiable. The receiver binds to the pod IP from the environment variable MY_POD_IP, as the collector’s official Helm chart prescribes. If you later swap the exporter for a SaaS vendor, you keep this filter, because it sits before the export.
This turns data sovereignty into a design decision in the collector rather than an assurance in the contract. The contract is still needed, but it’s no longer the only safeguard. And the configuration is auditable: anyone who wants to know what leaves the building reads the list of actions, not the appendix to the data processing agreement.
The order in which we prepare the decision
First the hard limits: compliance and data sovereignty are exclusion criteria, not preferences. What isn’t allowed here isn’t allowed, no matter how attractive the rest would be. Clarifying this usually takes one conversation with data protection and one with the compliance function, and it often cuts the list of options in half.
Then the honest capacity question of who will still be running the stack in two years. If there’s no convincing answer to that, there’s a strong case for bought-in operations, regardless of whether the backend ends up being commercial or open source.
And in every case, instrumentation with OpenTelemetry wherever possible. That decouples the applications from the backend and keeps the door open, so the backend decision is made out of freedom of choice and not out of lock-in. Build or buy is also not a one-time yes-no question: the decision can be made per data class — critical data in your own stack, non-critical telemetry in SaaS.
What changes when the four questions come before the product name
We’ve often been called into projects as firefighters when they were already off the rails, and across industries a pattern repeats: a tool had been chosen before the four questions were clarified. An anonymized example: a team had chosen to build it themselves, for good reasons, because data sovereignty was non-negotiable. Only nobody had thought about team structure. The stack ran, but retention was never configured cleanly, storage costs ran away, and alerting was a patchwork because operations had no permanent owner.
The reverse case is just as common: a commercial APM bought because it promises quick results, and then barely used for months because nobody had set up the instrumentation cleanly and the data sovereignty question only came up after the purchase. We deliberately don’t cite figures on the follow-on costs, because they can’t be compared across projects. Qualitatively the difference is clear: where the four questions are settled before the product name, the decision is made in days and holds for years.
Where these criteria reach their limits
The four criteria provide a direction, not a formula. They can contradict each other: data sovereignty argues for self-operation, the lack of expertise against it, and then someone has to decide which risk the company would rather carry. A hybrid setup — critical data in your own stack, non-critical telemetry in SaaS — often resolves the contradiction, but doubles the operational complexity.
Filtering in the collector only protects what arrives as an attribute. Personal data buried as free text in span names or log lines isn’t caught by the attributes processor; for that you need discipline in instrumentation or a processor with regular expressions, which in turn costs compute time. And a hash is not anonymization in the legal sense if the mapping remains reconstructable elsewhere.
Finally, the self-assessment of expertise often walks out the door with the people. The team that can scale a Loki cluster today may be a different team in two years, and today’s decision then stands on sand.
The bottom line: operations and data sovereignty decide, not the logo
Whether an observability stack is run in-house or bought can’t be answered in the abstract, and least of all along the old front line between open source and commercial. It’s decided by compliance, data sovereignty, in-house expertise and team structure, and these four questions belong at the beginning, not the end. Anyone who answers them honestly almost automatically arrives at the right stack.
We ask these four questions in every first conversation, before a product name is mentioned. Anyone who skips them eventually ends up with someone like us, putting out the fire.