This article explains how to use the XOps Stories Workbench and story drill-down page to analyze XOps stories for anomalous behavior detected by the Experience Monitoring Anomaly engine.
For more about using the Stories Workbench, see Reviewing Detection & Response XOps Stories in the Stories Workbench.
Cato's XOps service detects anomalous activities based on Experience Monitoring, which may indicate an issue with an application or network performance to an application. The Anomaly engine monitors and analyzes the network traffic of each site and each application for an initial period of 14 days to establish a baseline for each new application based on the TTFB (Time to First Byte).
After that period, the engine runs once a day on the data from the previous day and sees if there was a significant deviation from the baseline. In the event that an anomaly occurred, a story is generated.
Note
Note: If several deviations occur on the same day, only one story is generated for all of them.
Even after the baseline is established, it is a dynamic measurement that is updated with each day’s data. Meaning, the initial baseline is established after the first 14 days, but continues to evolve with the data from each new day.
When the anomaly engine generates a story, you can review it in the Stories Workbench and drill down for further analysis of the story data.
These are the indications of anomalous behavior detected by the Experience Monitoring Anomaly engine to generate stories:
| Indication | Description |
|---|---|
| Application Response Time Anomaly in Site | Detects anomalies in the Time to First Byte (TTFB) metric for an application at a specific site. |
| Potential Application Outage Due to Widespread HTTP Errors | Detects anomalies in the ratio of HTTP failures to successes for specific applications in traffic across the Cato global backbone. |
You can click on an Experience Anomaly story in the Stories Workbench to drill down and investigate the details on a different page. This page contains additional information to help you start your investigation of the incident.
Click an Experience Anomaly story in the Stories Workbench page to show the details for the UEBA story.
These are the widgets for an Experience Anomaly story:
| Name | Description |
|---|---|
| Story summary |
At the top of the page, the story summary shows basic information about the story, including:
|
| Story timeline | Under the story summary, the timeline shows changes in the story status |
| Details |
Basic details about the story, including:
|
| Experience Anomaly | Visual representation of the application experience the day of the story |
| Entities | The entities where the story occurred. These could be users, sites, data stores, applications, etc. |
| Time to First Byte | Graph showing the duration between the HTTP request and the receipt of the first byte over time |
| Incident Timeline |
A list of the detected events for issues and resolutions in the story.
|
| Playbook Workflow | A step-by-step troubleshooting guide tailored to the specific issue detected in the story. This helps you quickly identify root causes and resolve the problem using clear, actionable plays. Includes links to relevant documentation. |
Once you have the basic information of the anomaly, including the site on which it occurred, the application and time, you can use the Experience Monitoring widgets to further investigate the story.
For example, you can filter by application and, using the Application Performance tab, view more information about possible issues that occurred at the time of the anomaly. In addition, you can use the Tunnel tab to see if there was a problem with the tunnel, or maybe in the Hosts tab you can see that there was a sudden spike in the number of users who were accessing the application, which might have caused the experience to degrade.
0 comments
Please sign in to leave a comment.