Alerting
Questions about alerting and problem detection in Dynatrace.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Best practice for monitoring network switch interfaces without generating noise from unused ports

Gewo
Visitor

Hi everyone,

I’m working on a use case where a customer wants to monitor network switch/router interfaces and generate Problems only when critical ports go down.

We are using the Dynatrace network device extension metric com.dynatrace.extension.network_device.if.status.

The initial idea was to alert when an interface is admin up but oper down or lowerLayerDown.

This technically works, but it creates too much noise because many ports are admin up and oper down simply because nothing is connected to them. They match the condition, but they are not real incidents.

So the actual requirement is:

admin up + oper down + expected-up interface = alert

The customer also wants to classify interfaces as P1, P2 or P3. Only P1 interfaces should automatically open tickets in Halo ITSM through Problem Notifications / Alerting Profiles.

I’m considering these options:

  1. Maintain an allowlist of expected-up interfaces and alert only on those.
  2. Tag interfaces with expected_up:true and priority:P1/P2/P3.
  3. Create separate DQL alerts for P1/P2/P3 and route only P1 Problems to Halo.
  4. Use lookup data or an external source instead of hardcoding all interfaces in the DQL query.

What would be the recommended Dynatrace approach for this use case?

Is tagging network interface entities reliable for this, or would you recommend handling the classification directly in DQL with an allowlist/lookup?

Has anyone implemented a scalable way to avoid alerting on unused admin up / oper down switch ports?

Thanks!

0 REPLIES 0

Featured Posts