Defining Knowns enables you to add contextual information explaining and describing events in Unomaly. If a situation contains important events, convert the events into known events.
After Unomaly learns an event, the event will not be highlighted if it is seen again. If you want Unomaly to track a learned event, convert it into a known. Knowns get tracked automatically once they have been defined. Use knowns to add more contect to relevant events and influence how Unomaly displays and scores the event. You can filter on knowns in the Situations view and define actions to notify you in real time when Unomaly detects the event. Over time, this builds a useful database of critical events, whether the events are good or bad.
What types of events should you convert into a known? In general, events that occur regularly or represent “business as usual” use cases should not be converted into knowns. Knowns should highlight interesting events that you want to know about when they happen, such as certain login attempts or download requests.
Adding a known event
To the convert an event into a known and save it to Knowns:
Hover over the event and click the plus-sign icon.
Select at least one segment in the event.
Unomaly uses these selected anchors to compare and match incoming events with known events in Knowns.Tip: Select as many anchors as possible to define a unique known. This guarantees that the known matches on the specific events and not events that share some anchors.
Fill in the text fields to name the event and (optionally) explain its meaning, reason, and solution.
Fields Description Display Name The name that gets presented in the UI beside the raw event. The anchors you selected will automatically be proposed as the default display name. Editing does not change matching. Meaning (Optional) Describe what the event actually means. For example, you can describe the results of researching the event on Google or a finding the answer from a colleague. Reason (Optional) Describe why this particular event got created. It helps you understand it the next time. Solution (Optional) Explain what to do when this event happens.
Classify the event as Critical, Warning, Notice, Informational, or Ignored.
Classifications determine how Unomaly treats the known event: whether to create a situation, add the event to a situation, and how to score the event depending on the context you add.
The first three classification levels (Critical, Warning, and Notice) create new situations or add events to existing situations. Even if the event is not anomalous, it will be assigned a score.
Classification Description Critical The event will always have a score of 7, which is equivalent to a never seen before anomaly Warning The event will always have a score of 4, which is equivalent to a population-based anomaly. Notice The event will always have a score of 1, which is equivalent to a parameter-based anomaly. Informational Means that you have explained the event. This classification does not affect the scoring. Ignored Means that you do not want to analyze this event. This event can be dropped early in the pipeline to save on performance.
(Optional) Add one or more tags to the known.
Tags are useful for categorizing the knowns, as filters in the Situations view, and as triggers when defining actions.
New tags get created automatically. As you type in the tag, you will see suggested auto-completes if your text matches existing tags. Add multiple tags by comma-separating them.
Tagging known events
When creating knowns, you can also use tags to make it possible to track the known event for different purposes, such as:
- To trigger actions, such as notifications
- Enable auditing for security logs
- Track changes in different environments or based on categories
Fine tune actions for the right people
By adding tags that describe which teams should be looking at the notification for the known event, you also make it possible to fine tune the actions you create based on the known event. For example, tag a known event with “support” so that the Support team can respond to any situations with the known. Or, tag a known with “dev-team-web” for UI related issues that you want the web developers to track.
Track changes or deployments in staging
Creating knowns for changes or deployments in a staging environment for a specific change request allows you to identify already known new data in a production environment. For example, add the tag “CHANGE-BE-520” for a changed related to the back end with ID 520.
Track problems based on category or subsystem
By adding tags such as “storage”, “resource limitation”, “API”, “hardware”, “failed task”, and so on, you can track issues by defined types. You can then use these tags to filter for specific types of issues, allowing you to identify frequent issues with clear solutions. For example, resource limits could mean you need more CPU or memory resources.
Enable auditing of security data
Adding information knowns for security auditing logs and tagging them with “audit” enables you to perform audits of security events. You can also set up an action to forward the audit event to external software, such as an audit report generation software.
Did this article help you?
Thank you for the feedback!