ATOM allows setting thresholds for all the relevant KPIs for your multi-vendor network. This could be based on the SNMP data or streaming telemetry data that ATOM can collect. Alerts are generated once the thresholds are breached.

ATOM supports alert filters. The filter can be based on severity, alert type, location, or resource pool or a combination of one or more of them. The filters can also be saved and pinned to the alert dashboard.

Get one single view of the most important charts, alerts based on location/severity/alert type etc in a single alert dashboard. Drill down to the detailed alerts for detailed understanding of the alerts.

ATOM supports alert history and prevents deduplication of alerts. This prevents sudden deluge of similar alerts. There are configurable parameters in ATOM that controls the alert triggers of similar type.

ATOM allows setting actions to the alert definitions. Actions could be one of slack notification, email notification or workflow. Based on the action set, when the alert gets triggered, ATOM’s workflow gets executed to raise an incident ticket on ServiceNow.

ATOM helps in troubleshooting network issues. ATOM’s diagnosis/troubleshooting workflows allows automated collection of information and auto-ticketing with this collected information to aid NetOps in remediating the issue.

Alerts raised due to % of interface utilization or interface drops can trigger ATOM’s workflow that will raise a ServiceNow ticket, and upon approval perform a remediation action. If the severity changes, ATOM can update the ticker on ServiceNow.

Alerts raised due to BGP neighbor flaps/down trigger ATOM’s workflow that will raise a ServiceNow ticket, and upon approval perform a remediation action such as shutting down the neighbor.

Alert criteria can be set in ATOM to trigger an alert upon  % of BGP prefix count changes over a period of time. Multiple levels of severity can be defined within ATOM’s alerting framework. Once alert gets generated, the same will be notified.

Alert criteria can be set in ATOM to track IPSLA violations. Any threshold variation in RTT and Jitter can be notified or remediation actions can be taken.

Using ATOM,any interface down, can be verified against an existing LAG interface and additional member interfaces in the LAG can be identified and its operational status and bandwidth degradation can be notified.

Any device health parameter such as CPU, memory, temperature or disk utilization variation can be alerted and notified at different levels of severity and ServiceNow ticket can be updated accordingly.

Use ATOM’s capabilities to correlate an alert with information from an external database or its own service models. ATOM updates the alert with insightful information about the customers that are affected by a BGP neighbor flap or a down interface. ATOM supports several such use cases.

Unable to correlate a down interface with a service such as L2/L3VPN? Use ATOM’s capabilities around alerting and event enrichment that can identify the affected service due to an alert involving interface down. ATOM updates the alert with the service name and customer name to ease NetOps troubleshooting.

ATOM supports measurement of TCAM resource utilization. Any variation will be notified 

ATOM supports detection of state changes. The state change could be of an interface or even an active-standby scenario such as an HSRP. Based on the breach of threshold that could be number of state changes, ATOM can trigger a notification or a ServiceNow ticket.