Define Knowns to highlight log events
If Unomaly repeatedly sees a log event, the log event will become part of the learned events for a system. This means that the event will no longer be highlighted by Unomaly. But in some cases, the log event is important enough to track and keep highlighting.
For example, the log event may be an error or a sign of a serious issue with the underlying system. This is why Unomaly allows you to define knowns that ensure that log events are highlighed in Unomaly’s user interface for you to see.
Typical reasons for creating a known from a log event are:
- Serious errors that need to be addressed but occur on a semi-regular basis, such as once a month.
- Specific log events that may indicate trouble but can also occur regularly. These knowns can help to track down problems that arise from a combination of events. For example, a queue overload might happen normally, but can be problematic if it is followed by a disk full anomaly. Defining a known for the queue overload log event allows you to track these incidents faster.
- Significant log events such as failed login attempts to a restricted section of your infrastructure or download requests to restricted files. It is important to pick selective knowns and not define a known on generic events such as error or login.
Note: Knowns assigned to events will only match to future occurrences of the log event across all the systems that Unomaly analyzes. This means that as soon as you have created a known, every log event that Unomaly analyzes after you defined the known will be shown. Knowns are not applied retroactively to previously analyzed log events or anomalies.
Creating a known event
Creating a known means that you add contextual information such as descriptions and tags to explain what the event means and how to resolve it. You can also specify how you want Unomaly to treat the event, such as whether or not to add it to a situation and assign it a score. You can filter on knowns and define actions to notify you when Unomaly detects the event.
You can create knowns from the Anomalies page, the Situations page, and from the System Profile.
1.Click “Add known… “ from the event menu located on the right of each event line.
2. In the “New Known” window, select at least one segment, which will be the identifying parts of the log event.
Unomaly uses these identifying parts you selected to compare with incoming log events and treats every log event that matches as an anomaly. It is very important that you create knowns for specific log events and not identify on very common terms, such as the the occurrence of “error”, in a log event. Such a known would result in an overload of anomalies.
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.
3. Fill in the text fields to name the event and (optionally) provide details to explain its meaning, reason, and solution.
These details help you to deal with the known when it occurs. (See “Known Metadata” below.)
4. Classify the severity of the log 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. (See “Known severity” below.)
5. Click Save.
Known metadata
Every known has metadata that you define to help deal with the log event when it occurs.
| Fields | Description |
|---|---|
| Display Name | A short descriptive name that is shown whenever a known occurs. This name is used for filtering knowns in the filter bar. |
| Meaning | (Optional) Describe what the event actually means. For example, it might be a sign of something going wrong in the system. This information helps you share the knowledge with other colleagues who might see the known. |
| Reason | (Optional) If the log event has a particular reason why it is being emitted, describe it here. This reason can help you troubleshoot or anticipate the log event the next time. |
| Solution | (Optional) Explain what to do when this log event happens. If the log event is an error of some kind that needs to be resolved, this field can be used to record the solution (if it is simple) or link to internal documentation describing how to handle the error. |
| Tags | (Optional) Allows you to add one or more tags to the known that you can use as filter in the Situations and Anomalies view and as triggers when defining actions. New tags get created automatically. Separate multiple tags withcommas. |
| Classification | Description |
|---|---|
| Critical | The event will always have a score of 7, which is equivalent to a never seen before anomaly. Creates a new situation or adds events to an open situations. |
| Warning | The event will always have a score of 4, which is equivalent to a population-based anomaly. Creates a new situation or adds events to an open situations. |
| Notice | The event will always have a score of 1, which is equivalent to a parameter-based anomaly. Creates a new situation or adds events to an open situations. |
| Informational | Means that you have explained the event. This classification does not affect the scoring. |
| Ignored | Means that you do not want Unomaly to analyze this event. This event can be dropped early in the pipeline to save on performance. (See “Ignore knowns” below.) |
Ignored knowns
Classifying a known as Ignored is a special use-case and should only be used in very specific circumstances, such as:
- To handle problematic log events such as high velocity or high volume events, which may not provide useful information and can overload Unomaly’s ingestion queue.
- To handle log events that do not tokenize well and may lead to false positive anomalies.
Log events that match Ignored knowns will be dropped from Unomaly after tokenization and will not be analyzed.
Using tags
Tags are useful in the following scenarios:
- Triggering actions and notifications.
- Enable auditing for a subset of your log events
- Provide helpful mnemonics with the knowns
Triggering actions and notifications
You can trigger actions from situations that contain a defined known using its id (display name), classification, and tag. Using tags allows you to trigger an action from multiple knowns that share the same tags.
Enable auditing of security data
Adding informational knowns for security 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.