Managed vs Self-Hosted Collectors for GIS Telemetry

Every spatial platform eventually decides whether to run its own telemetry collectors or send everything to a managed provider. The general arguments are well worn — operational burden against control, predictable cost against elastic capacity — and they miss what actually decides the question for geospatial workloads: spatial telemetry has unusual cardinality pressure, unusual burst behaviour, and unusual sensitivity about the data it carries, since a span attribute containing a bounding box is location data about something real. This guide compares the two models against those specific pressures and gives the decision criteria that hold up for GIS. It belongs to choosing spatial observability tooling under spatial incident response and tooling.

Where each model places the processing that spatial telemetry needs most Two pipelines are drawn. In the self-hosted model, spatial workers send to a local collector that performs attribute redaction, grid quantisation, complexity-aware sampling and cardinality capping before anything leaves the network, then forwards a reduced stream to storage. In the managed model, workers send to a vendor agent that forwards raw telemetry to the provider, where sampling and processing happen after ingestion and after billing. A note marks the point in each pipeline where cost is determined and the point where raw coordinates leave the network. The question is where reduction happens, not who runs the servers self-hosted spatial workers local collector redact · quantise · sample · cap cardinality storage cost fixed here nothing raw leaves the network managed spatial workers vendor agent forwards raw provider · ingest, then process sampling and shaping happen after billing cost fixed here raw coordinates crossed the boundary A managed provider that supports edge processing collapses this difference; one that does not, does not.

The three pressures that actually decide it

Cardinality. Spatial telemetry attracts high-cardinality labels — layer, region, grid cell, source, zoom — and the natural instinct of every engineer instrumenting a spatial pipeline is to add one more dimension. Managed pricing is usually a function of series count, so cardinality is a direct cost, and a single well-intentioned label can multiply the bill. Self-hosted shifts that cost to storage and query performance, where it is still real but degrades gradually rather than arriving as an invoice. Neither model removes the need for the discipline described in bounding spatial metric tag cardinality — but managed makes indiscipline expensive faster.

Burst behaviour. Spatial pipelines are bursty in a way request-serving systems are not: a nightly bulk load produces an hour of telemetry volume many times the daily baseline. Managed services absorb that elastically, which is a genuine advantage. Self-hosted collectors must be sized for the peak or configured to shed, which is the budgeting exercise in budgeting collector CPU for vector telemetry.

Data sensitivity. This is the pressure unique to geospatial work and the one most often overlooked. A span attribute carrying a bounding box, a geohash, or a vehicle’s position is location data about a real asset or person. Depending on jurisdiction and contract, sending it to a third-party provider may be a data-transfer decision requiring the same review as sending the underlying dataset. Redacting or quantising it before it leaves the network is straightforward in a self-hosted collector and depends entirely on the provider’s edge-processing capabilities in a managed one.

Dimension Self-hosted Managed
Cardinality cost Storage and query time; degrades gradually Direct billing; arrives as an invoice
Burst absorption Must size for peak or shed Elastic, a real advantage
Coordinate redaction Trivial, before egress Depends on edge processing support
Operational burden Real and continuing Largely removed
Query capability Whatever you build Usually much better
Retention control Complete Tiered, often costly at long tails
Failure independence Fails with your platform Independent; observes your outage

That last row is worth weighing carefully. A self-hosted collector on the same infrastructure as the pipeline is unavailable during exactly the infrastructure incidents you most need visibility into. Managed telemetry keeps working when your platform does not, and for a small team that single property frequently outweighs everything else.

The hybrid that most spatial platforms end up with

The models are not exclusive, and the arrangement that fits geospatial workloads is a local collector performing reduction, forwarding to a managed backend for storage and query. It puts each pressure where it is best handled: redaction and cardinality capping happen before egress, burst absorption and query capability come from the provider, and the operational burden is limited to a stateless collector rather than a storage cluster.

# Local collector: reduce, redact and cap before anything leaves the network.
processors:
  # 1. Redaction — raw coordinates never cross the boundary.
  attributes/redact:
    actions:
      - key: gis.geometry.wkt
        action: delete
      - key: gis.bbox
        action: delete
      # Keep a coarse, non-identifying locator instead of the precise one.
      - key: gis.grid_cell
        action: upsert
        from_attribute: gis.grid_cell_coarse

  # 2. Cardinality cap — an unbounded label is a bill, not a signal.
  transform/cap:
    metric_statements:
      - context: datapoint
        statements:
          - delete_key(attributes, "gis.feature_id")
          - delete_key(attributes, "gis.geohash")

  # 3. Complexity-aware sampling, as the scoping rules require.
  probabilistic_sampler:
    sampling_percentage: 10

exporters:
  otlphttp/managed:
    endpoint: https://ingest.example-provider.net
    headers: { authorization: "${env:TELEMETRY_TOKEN}" }
    sending_queue: { enabled: true, queue_size: 2000 }

The decisive question when evaluating a managed provider is therefore not its query language or its dashboards but whether it supports this shape: can you run reduction at your own edge, and does the provider’s pricing reward you for doing so. A provider that only accepts raw telemetry through its own agent forces the cost and the data-transfer decision back to the point where you have least control.

Decision path for choosing a collection model on a spatial platform A three-question decision path. The first asks whether coordinate-bearing attributes may leave the network; if not, edge reduction is mandatory and only a hybrid or self-hosted model qualifies. The second asks whether the team can carry storage operations; if not, managed storage behind a local collector is indicated. The third asks whether telemetry must survive a platform-wide outage; if yes, the backend must be independent of the platform's own infrastructure. The endpoint of all three paths for most teams is the hybrid arrangement. Three questions, and most teams land in the same place may coordinates leave? if no → edge reduction is mandatory can the team run storage? if no → managed backend must it survive an outage? if yes → independent backend hybrid local collector reduces, redacts and caps managed backend stores and queries each pressure handled where it is cheapest Telemetry volume reduction achieved at each edge-processing stage Raw telemetry volume from a bulk load enters at the left. Redaction of coordinate attributes removes a modest share. Cardinality capping removes a larger share by dropping unbounded labels. Complexity-aware sampling removes the largest share. The residual leaving the network is a small fraction of the raw volume. A note states that this residual is what a managed provider bills for, which is why the reduction has to happen before egress rather than after ingestion. Reduce before egress; a provider bills what arrives, not what you keep raw telemetry from one bulk load after coordinate redaction after cardinality capping after complexity-aware sampling this is what leaves the network A provider that only accepts raw telemetry through its own agent removes every stage above.

Verification: test the model before committing

Run a representative load through a candidate arrangement and measure four things: the series count actually produced, the cost that implies at the provider’s pricing, whether coordinate attributes survive to the backend, and whether telemetry continues flowing when a pipeline node fails.

The third of those is the one worth being rigorous about. Query the backend directly for any attribute matching a coordinate pattern — a well-known-text fragment, a bounding-box tuple, a geohash of more than a few characters. Finding one means the redaction is incomplete, and discovering that in a trial is enormously cheaper than discovering it in a review.

Gotchas

Evaluating on query features alone. Managed backends generally win on query experience, which makes it easy to skip the cardinality and egress questions until the first invoice.

Assuming the vendor agent can redact. Some agents forward whatever the SDK emits. If redaction has to happen at the SDK, it is scattered across every service instead of centralised in one collector configuration.

Self-hosting the backend as well as the collector. Running a metrics store is a substantial ongoing commitment, and it is the part that fails during the incidents you need it for. Collector self-hosting and backend self-hosting are separate decisions.

Ignoring retention economics. Correctness signals need long retention for post-incident review; high-volume serving metrics do not. A provider whose retention is uniform charges you extended-retention rates for everything.

Forgetting the collector is a dependency. A self-hosted collector that blocks when its exporter fails becomes back-pressure on the pipeline, which is why bounded queues matter regardless of model.

FAQ

Does the choice affect alert routing?

Only in where the rules evaluate. The severity model, grouping and inhibition described in alert routing and on-call design for spatial pipelines are model-independent, and keeping rule definitions in version control rather than in a provider’s console is what preserves the ability to change models later.

Is the hybrid model more work than self-hosting everything?

Less, usually. The collector is stateless and small; the storage layer is where the operational weight lives. Running the first and buying the second is the arrangement with the lowest total burden for most teams.

What about air-gapped or sovereign deployments?

Then the question is settled: everything is self-hosted, and the design effort goes into retention tiering and query performance instead. Worth planning the reduction pipeline the same way regardless, since it keeps the option open.

How reversible is the decision?

More reversible than it feels, provided two things are true from the start. Instrument through a vendor-neutral SDK rather than a provider’s proprietary client, so the emitting code does not encode the choice; and keep alert rules, dashboards and recording rules in version control in a portable form rather than authored in a console. With both in place, changing backend is a collector configuration change and a dashboard migration — a week of work rather than a re-instrumentation project. Without them, the choice hardens into every service in the platform within a couple of quarters, which is the real reason teams stay on a backend they have outgrown.

Does the model affect what you can measure about spatial data specifically?

It can, through retention and cardinality limits rather than through capability. The signals that make spatial pipelines observable — per-layer freshness, per-region coverage, per-zoom completeness — are all dimensional, and a provider with an aggressive series cap forces you to drop exactly the dimension that localises a fault. Test a candidate backend against your real label set, not a sample one, before assuming the dimensions you rely on will survive.

How do I compare cost honestly?

Compare against the reduced series count you would actually send, not the raw one, and include the engineering time to operate a store. Comparing raw managed cost against self-hosted infrastructure cost flatters self-hosting by omitting the labour and flatters nothing else.