Let us learn about certain use cases of the incident policy framework.
A few of the use cases of the incident policy framework are discussed. Read
on to understand each use case for your business requirement.
- Business intent defined incident priority
The default priority of system
generated incidents can be changed by you to priority levels defined by your
business requirements.
For example, using an incident policy rule, you
can change the severity of the BGP peer down critical incident
for Branch sites to be a P1 instead of the default P2.
- Escalate priority of standing incidents
When certain incidents are left
standing for a long time, you can specify an escalation policy rule to increase
the priority of the incident.
For example, if the Device
Disconnected from controller incident is standing for more than 24
hours there should be an escalation rule in place to alert you and to ensure
that you fix this condition.
- Suppress incidents during a maintenance window
When you bring down a site
during a scheduled maintenance window, all incidents generated during this
period can be suppressed using a policy rule.
Example, when a Data Center
site goes down for scheduled maintenance, it will cause a series of incidents to
be generated like Secure Fabric Down, BGP peer
down, Interface down, etc. You can easily
configure an incident policy to suppress all alerts and incidents originating at
this Data Center site during the time period when the maintenance window is
scheduled.
- System rules to suppress incidents during internet outage at a site
When
there is an Internet outage, a series of incidents may be generated because of
VPNs going down. Since this is an expected issue, you can choose to suppress
incidents until the Service Provider fixes the outage situation.
- Escalate Priority when Core BGP peer flaps at Data Center site
There are
some scenarios where the incidents raised and cleared are in quick succession
multiple times within a short time period. However, since the condition is
cleared you are blind to such an incident in your network. You can now be
aware of such flaps happening in the network, by creating a flap rule and a new
Flap rate exceeded incident will also be generated to alert
you.
For example, if the standard VPN to Prisma Access flapped 3 times in
1 hour, you can be alerted for all such incidents across all Branch sites so
that they can investigate if there is an underlying provider issue or if there
is something else contributing to the flapping and take corrective action before
becoming a reported problem.
- Suppress incidents during staging
An incident policy rule can be used to
suppresses particular incident codes that you may not be interested in being
alerted about.
For example, you may not care to see the Site
Circuit Missing incident across all sites, or may want to suppress
BGP down incidents for particular branch sites, since the devices are still
being staged.
- Suppress incidents on unstable LTE circuit
If you are aware of an unstable
LTE circuit at a branch site, you can choose to suppress all incidents arising
at the site or reduce the priority of these incidents. This allows you to only
focus on unexpected issues in the network.
