There are a few traffic check_prometheus based alerts that should be migrated to Alertmanager:
monitoring::check_prometheus { "aggregate-ipsec-tunnel-status-${site}":
monitoring::check_prometheus { "varnish_${title}":
monitoring::check_prometheus { "ats_${title}":
monitoring::check_prometheus { $title:
monitoring::check_prometheus { "varnishkafka-${instance}-${cache_segment}-eqiad-kafka_drerr":
monitoring::check_prometheus { "varnishkafka-${instance}-${cache_segment}-codfw-kafka_drerr":
monitoring::check_prometheus { "varnishkafka-${instance}-${cache_segment}-esams-kafka_drerr":
monitoring::check_prometheus { "varnishkafka-${instance}-${cache_segment}-ulsfo-kafka_drerr":
monitoring::check_prometheus { "varnishkafka-${instance}-${cache_segment}-eqsin-kafka_drerr":
monitoring::check_prometheus { 'purged-event-lag':
monitoring::check_prometheus { 'purged-backlog':
monitoring::check_prometheus { 'varnishd-mmap-count':
monitoring::check_prometheus { 'excessive-lvs-rx-traffic':
monitoring::check_prometheus { 'lvs-cpu-saturated':
monitoring::check_prometheus { 'pybal_bgp_sessions':
monitoring::check_prometheus { 'varnish-frontend-check-child-start':Notably the "reduced availability" alerts can suffer from delays or excessive averaging due to their use of the prometheus global instance and icinga evaluation period.