Distinguish a new pipeline sender from a gateway port expansion

Source facts

In Microsoft’s Traefik example, another client using an existing receiver connects to the same gateway address and port without a gateway or pipeline-group change. Adding a receiver on a new port instead requires exposing that port. The documented Helm upgrade restarts the gateway pod and briefly interrupts existing client connections, including traffic on previously configured ports. Microsoft calls for a maintenance window. Microsoft Learn.

Applicability

This distinction applies to the documented gateway arrangement, which assumes Kubernetes LoadBalancer support. Confirm the implementation, pipeline group, receiver protocol, port, and current routes before borrowing its procedure. Other gateway products require their own change-impact review.

DSE recommendation

Classify the request as another sender on an existing receiver or a new receiver port before choosing a gateway change. For a new port, identify owners of existing connections and agree on an interruption window, not just an onboarding time for the new client. Preserve current port definitions and inspect the proposed route alongside the gateway’s exposed ports.

Verification

For an added client, verify its traffic reaches the intended existing receiver without changing gateway configuration unnecessarily. For an approved port expansion, compare the service and routing configuration afterward, then check both the new flow and representative old connections. Record restoration of existing ingestion separately from successful onboarding. A working new receiver should not close an unexplained gap on the old one.

Official references

Microsoft Learn: Configure a Kubernetes gateway for Azure Monitor pipeline. Source reviewed September 9, 2026.