Treat observability integrations as operational dependencies

A support date can become an upgrade deadline

An observability integration is part of the platform’s operational dependency graph, not just a way to collect telemetry. It has versions, compatibility limits, an owner, and a support window. I would track those alongside Kubernetes versions and application instrumentation, because an integration’s support policy can turn into a constraint on when a cluster must change.

New Relic’s Kubernetes supported-version notice says that, effective October 19, 2026, its Kubernetes integration will support only the three most recent Kubernetes minor versions. The notice says the integration may continue to work on older versions, but New Relic cannot guarantee its quality there and will not accept support requests for versions that have reached end of life. That is a useful distinction: software continuing to run is not the same as having a supported operational path.

The cutoff does not automatically mean every cluster should be upgraded immediately. It does mean the platform team needs to know which clusters depend on that integration, which Kubernetes versions they run, and what happens if their upgrade schedule does not line up with the integration’s support window. If that information is missing, a vendor policy can quietly become an emergency change request.

I would put the integration on the same dependency register as the cluster version and the instrumentation libraries. The register should make it easy to answer practical questions: Which clusters use this integration? Who owns it? Which versions are supported today? When does that support change? What is the tested alternative if the cluster cannot move in time? Those answers are more useful than a general statement that “monitoring is installed.”

Separate the telemetry contract from the vendor integration

A direct vendor integration often makes sense. It may provide a supported installation path, cluster-specific data, and a straightforward route into the platform the team already uses. The cost is coupling: the integration’s compatibility schedule becomes one more schedule that can affect cluster operations.

I would look for a boundary between collecting and exporting telemetry, and the vendor-specific behavior around it. For example, an OpenTelemetry Collector can receive telemetry through a pipeline and export it to a destination; the Collector configuration documentation describes the receiver, processor, exporter, and pipeline model. A simplified configuration could look like this:

receivers:
  otlp:
    protocols:
      grpc:

exporters:
  otlp:
    endpoint: telemetry-gateway.internal:4317
    tls:
      insecure: false

service:
  pipelines:
    metrics:
      receivers: [otlp]
      processors: []
      exporters: [otlp]

This is an illustrative configuration, not a drop-in production recipe. It shows the boundary I mean: instrumentation sends telemetry to a collector, and the collector exports it onward. A team could then assess whether to change the export destination without rewriting every application’s instrumentation. The actual path still needs authentication, certificates, resource attributes, batching, failure handling, and tests suited to the environment.

That boundary is not free. The collector becomes another component to deploy, upgrade, monitor, and troubleshoot. The team must test not only whether telemetry arrives, but whether the data remains useful: names and attributes have to make sense, dashboards and alerts need to keep working, and failures in the export path must be visible. A layer that preserves theoretical choice but nobody tests is not a useful option; it is an additional failure mode.

So I would not insert a collector just to claim vendor independence. I would use one when the option value is worth its operational cost: for example, when the organization needs a stable telemetry interface across multiple destinations or wants to decouple application instrumentation from a vendor-specific agent. If the direct integration is easy to test, supported for the cluster lifecycle, and acceptable to the team, the simpler path may be the better architecture.

Make the support window part of upgrade planning

For every integration, I would record its supported platform range and the date or condition that changes that range. Then I would compare those facts with the cluster team’s own upgrade plan. The point is not to force every team onto a single calendar. It is to identify mismatches early enough to choose between upgrading, changing the integration, or accepting a defined support gap.

That choice should have an owner. If the cluster team owns Kubernetes upgrades and a different team owns observability, neither team should discover during an incident that the other assumed it was handling compatibility. I would make the dependency visible in the change review: which cluster versions are in scope, which integration version has been tested, what telemetry is expected, and what rollback or fallback path exists.

The same review should cover application instrumentation. A cluster integration and an application library may have different support windows and different failure consequences. One may affect infrastructure signals while the other affects traces or application metrics. Treating them as one undifferentiated “monitoring version” hides the dependencies that matter. I would list them separately, then test the complete signal path that operators rely on.

For a support change approaching, I would ask the owners to produce a small, explicit plan: identify affected clusters, check their upgrade constraints, validate the next integration version against a representative environment, and decide what to do where those dates do not align. If a telemetry gateway is part of the design, test its export path and its behavior when the destination is unavailable. The plan should state what signals become unavailable or unsupported under each choice, rather than treating continued operation as proof of support.

Keep options real, not theoretical

Loose coupling is valuable only when the alternative path has been exercised. A second exporter that has never been deployed, a collector configuration no one owns, or dashboards built around vendor-specific attributes can leave a team just as locked in as a direct integration. I would preserve options selectively and pay for them with tests, ownership, and documentation.

My default is to treat each cluster integration as an operational dependency with a support window, then decide whether a telemetry boundary is worth maintaining. That reframes the question from “Can we collect the data?” to “Can we keep collecting the signals we depend on, within a support window our platform team can accept?”