anchor.diff:        documentation:
           title: Router Exhausted Connections By Router
           description: |
  -          The lifetime number of requests that have been rejected by the Gorouter VM due to the `Max Connections Per Backend` limit being reached across all tried backends. The limit controls the number of concurrent TCP connections to any particular app instance and is configured within PAS.
  -
  -          **Use**: Indicates that PAS is mitigating risk to other applications by self-protecting the platform against one or more unresponsive applications. Increases in this metric indicate the need to investigate and resolve issues with potentially unresponsive applications. A rapid rate of change upward is concerning and should be assessed further.
  +          The lifetime number of requests that have been rejected by
  +          the Gorouter VM due to the `Max Connections Per Backend`
  +          limit being reached across all tried backends. The limit
  +          controls the number of concurrent TCP connections to any
  +          particular app instance and is configured within PAS.
  +
  +          **Use**: Indicates that PAS is mitigating risk to other
  +            applications by self-protecting the platform against one
  +            or more unresponsive applications. Increases in this
  +            metric indicate the need to investigate and resolve issues
  +            with potentially unresponsive applications. A rapid rate
  +            of change upward is concerning and should be assessed
  +            further.
   
             **Origin**: Firehose
             **Type**: Counter (Integer)
  
positive.code:         description: |
            The number of file descriptors currently used by the Gorouter job.
  
            **Use**: Indicates an impending issue with the Gorouter. Without proper mitigation, it is possible for an unresponsive app to eventually exhaust available Gorouter file descriptors and cause route starvation for other apps running on PAS. Under heavy load, this unmitigated situation can also result in the Gorouter losing its connection to NATS and all routes being pruned.
  
            While a drop in `gorouter.total_routes` or an increase in `gorouter.ms_since_last_registry_update` helps to surface that the issue may already be occurring, alerting on `gorouter.file_descriptors` indicates that such an issue is impending.
  
            The Gorouter limits the number of file descriptors to 100,000 per job. Once the limit is met, the Gorouter is unable to establish any new connections.
  
            To reduce the risk of DDoS attacks, we recommend doing one or both of the following:
  
            * Within PAS, set **Max Connections Per Backend** to define how many requests can be routed to any particular app instance. This prevents a single app from using all Gorouter connections. The value specified should be determined by the operator based on the use cases for that foundation.
            * Add rate limiting at the load balancer level.
  
            **Origin**: Firehose
  
negative.code:       documentation:
          title: Latency by Router
          description: |
            The time in milliseconds that the Gorouter takes to handle
            requests to backend endpoints, which include both
            applications routable platform system APIs like Cloud
            Controller and UAA. This is the average round trip response
            time, which includes router handling.
  
            **Use**: Indicates how Gorouter jobs in PAS are impacting
            overall responsiveness. Latencies above 100 ms can indicate
            problems with the network, misbehaving backends, or the need
            to scale the Gorouter itself due to ongoing traffic
            congestion. An alert value on this metric should be tuned to
            the specifics of the deployment and its underlying network
            considerations; a suggested starting point is 100 ms.
  
            **Origin**: Firehose
            **Type**: Gauge (Float in ms)
  