# Distinguish a new pipeline sender from a gateway port expansion

> Will onboarding a telemetry source require restarting the existing Traefik gateway?

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-274-distinguish-a-new-pipeline-sender-from-a-gateway-port-expansion/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:27:22+00:00
- Modified: 2026-09-10T01:23:48+00:00
- Last reviewed by DSE: 2026-09-09
- Resource type: Guide
- DSE priority: Information
- Topics: Business Continuity, IT, Networks & Infrastructure
- Reading time: 2 minutes

## What you need to know

Will onboarding a telemetry source require restarting the existing Traefik gateway?

## Potentially affected

Azure Monitor pipeline deployments using the documented Traefik gateway on clusters supporting LoadBalancer services.

## DSE recommendation

Classify the request as another sender on an existing receiver or a new receiver port before choosing a gateway change.

## Article

## 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](https://learn.microsoft.com/en-us/azure/azure-monitor/data-collection/pipeline-kubernetes-gateway).

## 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](https://learn.microsoft.com/en-us/azure/azure-monitor/data-collection/pipeline-kubernetes-gateway). Source reviewed September 9, 2026.

## Primary reference

- Name: Configure a Kubernetes gateway for Azure Monitor pipeline - Azure Monitor | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/azure-monitor/data-collection/pipeline-kubernetes-gateway
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Distinguish a new pipeline sender from a gateway port expansion,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-274-distinguish-a-new-pipeline-sender-from-a-gateway-port-expansion/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.