Deep text inspection

How LogX reads the text of every event: the per-event profile, the semantic content analysis that finds errors without rules, statistical problems, where the results appear and how to tune them.

What you will do: understand what LogX finds in event text without a query, where those findings appear, and how to keep them relevant.

Most monitoring starts from a question a person already knows to ask. LogX starts from the text itself: every event gets a profile, profiles aggregate into behaviour profiles and risk patterns, and the engines report what changed. The same mechanism powers the Analytics console, which scans every log that enters the system for errors, risks, statistical problems and predefined rules, with no configuration.

What the engines find

FindingHow
Auto-detected errorsSemantic Content Analysis: the content of each event against a predefined knowledge base; it finds thousands of errors and fault-related events (failure, error, exception, a refused connection) with no configuration
Predefined problemssaved searches with a severity of Low, Medium or High; see Saved searches and export
Statistical problemsunusual behaviour in the stream: high or low logging activity, an application or server that stops logging, an IP that calls the same URL excessively
Top error trends, new errors, removed errorsthe errors of today against the errors of a normal day — what appeared, what disappeared, what grew
Data stream statistics and anomaliesrate and shape changes per source; see Anomaly detection
Clustersthe clustering insight LogX builds on its data models (LogX App)
Server metrics problemsCPU, memory and disk on the source servers, when Servers Metrics Analysis is activated

Each problem carries a risk from 1 to 10 and a count. Monitors that carry a risk level are picked up by the Analytics and LogX engines automatically.

Where the results appear

  • Analytics tab: the Problems Graph over time, a Problems Summary table per folder, application or server (hierarchic or flat, total or risk view, summary or split), and the ten Most Severe Problems; zoom into any time slot, hover a point for its sources, drill to the events.
  • LogX App (Apps > Marketplace, build 7.8050 and later): dashboards for top error trends, new and removed errors and data-stream anomalies.
  • In a query: * in log.secure | analyticstream | where Analytics Risk > 5 | order by Analytics Risk desc lists the findings for a source with their type (Autodetected or Predefined), risk and count; interval buckets them.
  • In a dashboard: the Analytics widget, and the Augmented Search pane's Analytics Insight on any search.

Steps: first week

  1. Deploy LogX from the Marketplace on a deployment that already collects data.
  2. Leave the engines a few normal days; the analysis is re-run every five minutes.
  3. Open Analytics, choose the application view, and read the Most Severe Problems for a source you know.
  4. For each finding, confirm in Search, then either change its severity, exclude it from future analyses (Most Severe Problems menu), or give the saved search that describes it a severity so it becomes a predefined problem.
  5. Under Analytics > Logs disable analysis for sources that only add noise (debug logs, test systems).
  6. Under Analytics > Administration > Settings set the default view, and under PortX > Settings > General > Advanced the business hours (used mainly by data monitoring).

Reading the findings

Treat a finding as a question: the events behind it are the answer. New errors after a release and removed errors after a fix are the two most useful lists. A problem that is real but expected keeps its place in the history when you lower its severity; excluding it removes it from future analyses only.

What is documented and what is not

The wiki documents the mechanisms above; it does not use the name "Deep Text Inspection", and the percentages quoted for it on xplg.com are pending confirmation from XPLG engineering and are not repeated here. The capabilities page scopes LogX "models and assistants" per edition without defining editions; the commercial model names are on Models and credits.

Next: Anomaly detection

Source: XPLG wiki, pages 1602846618, 1594131648, 1594133717, 1594133728, 1594133726, 1594133720, 1594131652, 1594131707, 1594131752, 1602191858, 1597539432, 1594133393, 1594131316, 1594131703, 1594130611 (https://xpolog.atlassian.net/wiki/spaces/XPOL/pages/1594131648).