As a new user to Unomaly, important concepts to understand are: events, situations, and knowns. This guide focuses on these concepts to help you get started using Unomaly.
Event scoring and anomaly detection
During the training process, Unomaly analyzes the structures of each incoming event to learn the normal behavior of the system. Unomaly does not need pre-defined templates to understand the log formats or structures. Instead, Unomaly builds a database of the structures based on the incoming events it analyzes. The database is referred to as the learnings.
Unomaly breaks down the structure of an event into
objects separated by spaces and other delimiters.
After analyzing the structure of new events and comparing it to the learnings database, Unomaly assigns the event a score that describes how anomalous the event is. If the event is anomalous, Unomaly adds it to a situation (which you will read more about later).
Unomaly further classifies the normal, non-anomalous, events by how regularly they occur on the system: every second, every minute, hourly, daily, monthly, or rarely. These events summarize the system’s baseline behavior, which is how the system behaves under normal conditions. Unomaly saves this summary for each system as the system profile.
See “How Unomaly detects anomalies” to learn more about how Unomaly learns incoming events and detects anomalies.
Working with Situations and anomalies
While the system profile summarizes the normal behavior of your systems, the Situations page focuses on the opposite: all the events in your systems that Unomaly automatically detected as anomalies or recognized as user-defined knowns. Each situation is a collection of anomalous events during a related time period for a single system.
The Situations page consists of a graph of the total volume of events and the anomalous events over the selected time range, filtering options to define the type of situations you want to see, and the list of resulting situations. You can expand each situation to see the individual anomalous events that make up the situation.
The Situations page is the core Unomaly workflow, where you can review,
investigate, and troubleshoot the anomalies that Unomaly detected.
→ Filter Situations for your systems. You can filter situations to only show the anomalies for a selected system or group of systems. This step becomes easier if you have already organized your systems into the groups you need. For example, if you are troubleshooting anomalies on your Production systems, you should already have a group created for those systems. When you select the group, the page updates automatically. See “Create groups of systems”.
→ Saved filtered situations as views. The filtering options help you to build the view that will show you the most relevant situations for you depending on what you want to do. For example, you can select filters and conditions to help you troubleshoot an incident, perform a log review, or verify recent changes and updates to your systems. Afterwards, you can save your custom filters and conditions as a View. This means that selecting the view, applies the filtering options to the selected systems, allowing you to easily troubleshoot incidents, regularly perform log reviews, and quickly verify changes. See “Create views to monitor anomalies”.
→ Star interesting situations to review later. If you find situations that you need to investigate, you can “Star” the situation. This makes it easy to find the situation again, when you have time to review or consult with your colleagues about it. Read more about how to comment and share discoveries while Investing situations and Investigating anomalies.
Monitoring situations and knowns
In general, Unomaly does not differentiate between good and bad events. Unomaly recognizes repeating events as part of the normal behavior and different events as anomalies. You can influence how Unomaly detects and scores events in your systems by converting important events to knowns, that is: explaining what the event means and when it happens, describing how to resolve the event, and specifying how you want Unomaly to score the event. Over time, you can build a useful Knowledgebase of important or critical events, with user-defined context to classify them as good or bad.
→ Convert findings into knowns. When you find an event that is important enough to track, click the [+] next to the event and fill in the information to add it as a known. You can filter situations based on knowns and add notification actions that trigger when Unomaly detects a known. See “Add knowns to track recurring anomalies”.
Unomaly evaluates situations against a ruleset that determines whether to execute an action for the event. When one of your systems goes offline, when a specific critical known is detected, or when the production environment produces significant anomalies, you want Unomaly to take action. This action can be to send an email to a specific user, to post to a team chat room, or to flag the event for later review. See “Configure actions and notifications”.
→ Add a notification action for a classified known. This examples demonstrates how to define an email action for critical or warning situations in the Production systems group.
Send email for critical situations in Production
→ Email notification for failed admin log in attempts This example demonstrates how to trigger an action after an event is seen a certain number of times. For example, you want to be notified if an administrator attempts to log in and fails more than 5 times, because it can be a sign of unathorized access.
Trigger action after 5 admin login attempts
To post or notify to a team chat room, or other external solution, you need to add a custom action to post to that chat service. Unomaly provides integrations to common solutions (such as Slack, HipChat, and Microsoft Teams) which you can install and configure to use with actions. See Unomaly Plugins and Integrations.
Did this article help you?
Thank you for the feedback!