Log Pattern-Signature
Log Pattern-Signature explained, usage, and configure.
Log Pattern-Signature Explained
Machine log is known difficult to analyze due to its non-structured or semi-structured nature. The non-conforming format plus its volume growth velocity make it challenging to extract values using conventional means such as search and monitoring. Apica Ascent normalizes all incoming logs into Pattern-Signature (PS). PS grouping or clustering all the ingested logs based on their underlying logging structure, in the structure-data term, Schema.
The current logging method tries to unify the logs into a machine-like format such as homogeneous field assignments or key-value pair JSON format for simplifying the post analytics. The practice, however, limits logging capability which is analogous to limiting all the observability log data to only one schema. Moreover, a homogeneous machine log form is not intuitive and notoriously difficult to interpret. The use of the advanced Pattern-Signature AI/ML method will make it fruitful.
Apica Ascent Pattern-Signature autonomously derives the underlying schema for every log stream, see the example below,
Derived Pattern-Signatures (PS) or log data Schemas are shown below
Symbol * from the PS line is a variable or mutable field that can be extracted for reporting, monitoring, or anomaly tracking. Everything else is a fixed token or constant that gives PS its attribute.
Pattern-Signature (PS) has many use cases.
Log Reduction Based on Pattern Signature (PS)
The logs can be forwarded or dropped based on their structure form or Pattern-Signature Id.
For example, debugging logs are useful for a specifically targeted instance/time. The developers often do not always remove them when done troubleshooting the code. Added logs to the already overloaded log ingestion pipeline. SRE’s/DevOps, on the other hand, are never sure what logs are to be dropped and forwarded for storing and therefore took all in. Apica Ascent PS generation will examine and analyze log pattern signatures holistically and therefore better and more accurately assess the log state for logging efficiency.
To get to the PS listing, one first goes to the log explorer page and set the namespace and application parameters for the log records to display.
Example log display from namespace selection
After that, go to the right side and click on the log summary button (see below) to display the PSes. See the final log PS display below.
Annotation explanations
1)-2) Display PS action will change the tab organization and now there are two levels of tabs
3) 2nd row right-most tab shows the PS in sort count order
4) 1st row right-most tab corresponding to this log query state. Notice that this log query state is called Investigate Group (IG) and the query is fixed at namespace(s), application(s), and time period specification.
5) 2nd row left-most tab shows the queried logs.
6) The main ingesting log window. This is the place one specifies and initiates the log query.
7) One can display all the logs of similar PS via the search icon, see outputs below. Notice that the new specific PS id search tab appears on the top row now.
Log Outlier/Anomaly Isolation
Pattern signature grouping gives the user a way to quickly pick out anonymous logs based on infrequent PS logs. For the example below, one apparent failed SSL log is shown from thousands of 24-hour ingress logs.
Log Trending Analysis
A deterministic quantity of logs signifies the system executes in steady stead. The logging quantity of the frequent identical PS logs is evenly distributed over time. Excessive or decreased logs hint that the logging subject experiences an anomaly.
Click on the search icon to further drill down to one PS type.
Log Comparison Analysis
Apica Ascent provides a robust platform for comparing logs from two different periods or different log partition spaces such as different namespaces or applications. See the figure below where the PS comparison is made for the different time intervals of 12 hours.
Investigation Group #1, IG1. Notice that there are two tab groups; IG#1 and IG#2. The tab group access method is shown below.
Investigation Group #2, IG2.
Configuring Pattern-Signature
Pattern-Signature feature is activated and controlled via the configuration steps below,
1) Go to the menu item “Ingest Configuration” to display the PS configuration fillers.
2) Four rows are used to manage PS features: “PS_Configure”, “PS_STREAM_ENABLE”, “PS_STEAM_MAX_SIZE”, “PS_TOTAL_STREAM_MAX_SIZE”.
PS_STREAM_MAX_SIZE
Maximum number of Pattern-Signatures (PS) that each namespace-application log stream can create. The ingestion turns off the Pattern-Signature engine and assigns default null PS id *6 to that log stream. The default max count is set to 8,000.
PS_TOTAL_STREAM_MAX_SIZE
A maximum number of total Pattern-Signatures (PS) the cluster can create. Once the total maximum count is reached, subsequent log event PS will be set to default PS id *6. The default max count is set to 20,000.
PS_STREAM_ENAB
[ ( <ns> <app>,)*]
<ns> is the namespace string, a valid namespace specifier.
<app> is the application name string, a valid application specifier.
PS_CONFIG
Reserved for internal uise.
PS Id Default Code
*3 : Disable PS generation at the top level.
*4 : PS feature is turned off from log stream configuration or FlashOps level.
*6 : Exceed PS count at either total PS count or per log stream PS count max.
Last updated