Welcome to InsightFinder Docs!
Categories
Log Project Settings
Project-level configuration, model tuning, anomaly controls, and frequency detection
Configuration Guide and Tuning Reference
| Identity & retention
Project naming, system membership, data/model retention, clustering, and project-wide sensitivity. |
Model & processing
Model span, tokenization, batch sizing, processing mode, throughput controls, and pattern limits. |
| Anomaly families
Global anomaly switches plus rare, whitelist, new-pattern, critical-event, and priority controls. |
Frequency detection
Hot/cold event detection, independent sampling interval, scoring, thresholds, limits, and scope. |
| Source scope Based on the provided “Log Project Settings Reference” within the Log Analysis Workflow document. The source identifies a 3-step wizard (Basic settings → Core functions → Advanced), but does not enumerate Core functions settings in this reference; this guide therefore documents the settings that are actually described in the source. |
01 / PROJECT SETTINGS
How project settings are organized
The source organizes Log project configuration across Basic settings and multiple Advanced sections. Use this page as the map for the detailed reference that follows.
| Basic settings
Identity, system membership, retention, clustering similarity, global sensitivity, feature outliers, zones, and project-level behaviors. |
Advanced — General
Model validity, sampling interval, training history, processing mode, JSON/multiline preprocessing, and holiday windows. |
| Sensitivity — Log Processing
Training-model construction and detection-pipeline throughput, batching, tokenization, pattern limits, and processing enablement. |
Sensitivity — Anomaly Detection
Master anomaly switches and controls for rare, whitelist, new-pattern, critical events, and incident priority. |
| Core functions The provided project-settings section names Core functions as the second step in the wizard but does not provide setting-level descriptions for that page. No Core functions settings are invented in this guide. |
High-impact tuning relationships
| Control | Effect described by source |
| Similarity degree ↑ | Requires log entries to be more alike before grouping; creates more, finer-grained patterns. |
| Sensitivity ↑ | Lowers the practical detection bar and produces more anomaly events. |
| Model matching threshold ↑ | Requires incoming logs to match an existing pattern more closely. |
| Rare cluster size ↑ | Widens the definition of “rare,” increasing candidate rare patterns. |
| Base score ↑ | Raises that anomaly class in severity ranking and downstream threshold behavior. |
| Number limit ↓ | Reduces the maximum volume reported in each detection window. |
02 / PROJECT SETTINGS
Basic settings
General identity, retention, clustering, and detection-sensitivity options for the Log project.
| Setting | Technical behavior / purpose | Source note |
|---|---|---|
| Project display name | Human-friendly name shown in the UI. Changing it does not change the real project name used by APIs and agents. | UI label only |
| Project name (real) | Immutable internal project name used in API calls, data ingestion, and URLs. It cannot be edited after project creation. | Immutable |
| System name | System that contains the project. Systems group multiple projects for system-level anomaly correlation, timelines, and incident prediction. | System membership |
| Data retention (day) | Number of days raw ingested log data is retained before purge. Longer retention increases storage use and extends look-back. | Days |
| Model retention (day) | Number of days trained ML models are retained. Old models past the configured age are cleaned up. | 0 = default policy |
| Similarity degree | Controls how aggressively log entries are clustered into the same pattern. Higher values require closer similarity and create more, finer-grained patterns; lower values create fewer, broader patterns. | Higher = finer patterns |
| Sensitivity | Overall anomaly detection sensitivity. Higher sensitivity flags more events; lower sensitivity reports only stronger deviations. | Higher = more anomalies |
| Feature outlier detection sensitivity | Sensitivity used specifically for feature-level outlier detection on numeric values extracted from log content. | Medium = default balance |
| Absolute outlier threshold | Fixed numeric threshold for feature outlier detection. Suppresses statistically significant but practically small deviations unless the absolute deviation exceeds the threshold. | 0 = disabled filter |
| Zone name key | JSON/log field whose value is used as the instance zone (for example availability zone or data center) for grouping and detection. | Field name |
| Incident resolution setting (Config button) | Opens automatic incident-resolution configuration, including how and when an incident is resolved after the anomaly stops. | Dialog |
| Large project | Read-only indicator that the backend partitions the project workload differently using sharded processing. | Read-only |
| Grouping by instance | Clusters and analyzes log entries per instance instead of across the entire project. Intended for instances with materially different log profiles. | On / Off |
| Component name auto overwrite | Allows incoming data to automatically overwrite component names instead of preserving manually assigned names. | On / Off |
03 / PROJECT SETTINGS
Advanced — General
Project-wide processing parameters that determine model validity, analysis granularity, input preprocessing, and date-specific behavioral context.
| Setting | Technical behavior / purpose | Source note |
|---|---|---|
| Min valid model span (min) | Minimum training-data duration a model must cover before the model is considered valid for detection. Models trained on less data are ignored. | Minutes |
| Sampling interval | Base analysis time bucket used for log frequency counts and anomaly scoring. Configure the granularity appropriate for frequency-based detection. | Value + unit |
| Training model span range | Optional fixed historical start/end date range used for model training instead of a rolling training window. | Optional range |
| Processing mode | Controls how project data is processed. The source identifies Live streaming/cron processing and also references historical, dedicated, and AW modes; dedicated mode immediately triggers the full log analysis when data arrives. | Mode selection |
| Enable JSON preprocess | Parses log entries as structured/pretty JSON before analysis so fields such as instance, timestamp, zone, and feature values can be extracted. | Structured JSON |
| Enable regex multiline | Treats multiple physical lines as one logical event using regex-based boundaries, such as multi-line stack traces. | Multiline events |
| Holidays | Named date ranges where different behavior/traffic is expected so models and detection can account for the change. | Add / Delete |
| Processing mode terminology The source explicitly references Live, historical, dedicated, and AW processing modes, but only describes Live and dedicated behavior. This guide preserves that scope rather than inferring the other modes. |
04 / PROJECT SETTINGS
Advanced — Sensitivity → Log Processing
Controls model training and the log-detection pipeline itself.
Log Training
| Setting | Technical behavior / purpose | Source note |
|---|---|---|
| Model span (days) | Number of days of data covered by one training model. Longer spans smooth day-to-day variation; shorter spans adapt faster. | 0 = default |
| Feature vector length | Maximum number of keyword features extracted per log entry for the clustering feature vector. More features increase detail, model size, and training cost. | Default: 200 |
| Maximum training data sample value per model | Cap on the number of log samples used to train a single model, preventing unbounded training jobs on very large projects. | Default: 10,000 |
| Model keyword setting | Defines how keywords are extracted/tokenized for model training and therefore what counts as a word during clustering. | Tokenization |
| Model Matching Threshold | Similarity threshold for matching incoming log entries to existing model patterns. Higher thresholds require closer matches. | Higher = stricter match |
| Model Keyword Segment K | K value used when segmenting keywords during pattern matching and pattern-granularity tuning. | Default: 3 |
| Enable NLP | Uses NLP-based processing during model training rather than only token-based clustering. | On / Off |
| Disable model keyword stats collection | Stops collection of per-keyword statistics during training to reduce overhead when those statistics are not required. | Performance control |
Log Detection
| Setting | Technical behavior / purpose | Source note |
|---|---|---|
| Maximum log detection threads | Number of parallel threads used for this project’s log detection jobs. Increasing it supports higher volume at the cost of shared worker capacity. | Thread count |
| Minimum log entry value for one analysis batch | Minimum log-entry count required before a batch is analyzed. Smaller batches wait for more data unless the wait-time trigger fires. | Default: 10,000; source notes 1 for small datasets |
| Maximum log entry value in one analysis batch | Maximum logs processed in a single analysis batch; larger sets are split. A separate LOG_DETECTION_BATCH_SIZE memory cap may also limit batch size. | Batch cap |
| Maximum wait time for triggering one analysis batch (min) | Maximum time to wait before running a batch even if the minimum log-entry count has not been reached. | Minutes |
| Keyword setting | Detection-time keyword extraction configuration, analogous to Model keyword setting but applied when data is analyzed. | Detection tokenization |
| Pattern limit size | Maximum number of distinct log patterns the project can hold. The source notes a default of 1,024 and a supported UI setting up to 9,999; changing beyond that would require migration/code changes because incident pattern IDs begin at 10,000. | Default: 1,024 |
| Disable log processing | Turns off clustering and detection for the project. The source notes that data can still be ingested / passed to Log-to-Metric, but is not analyzed or saved as normal processed log data. | Master processing off |
05 / PROJECT SETTINGS
Advanced — Sensitivity → Log Anomaly Detection
Controls which categories of log anomalies are generated and how those anomaly types are scored or constrained.
Global switches
| Setting | Technical behavior / purpose | Source note |
|---|---|---|
| Disable normal log saving | Does not store normal (non-anomalous) log entries after analysis; only anomalies are kept. Saves storage but removes normal-log context from LogCompressedEvent storage. | Storage control |
| Enable anomaly detection | Master switch for log anomaly detection. When disabled, the project does not generate log anomaly events. | Master anomaly switch |
Rare event detection
Detects log entries that fall into rarely seen patterns. Cluster size defines the rarity boundary; base score influences ranking; the number limit caps detection-window volume.
| Setting | Technical behavior / purpose | Source note |
|---|---|---|
| Enable all rare event detection | Collects/reports all rare events instead of only the most significant events. This increases coverage and noise. | On / Off |
| Enable missing data incident escalation | Escalates expected data stopping as an incident, such as an instance going silent. | Incident escalation |
| Rare event cluster size | Pattern-size cutoff for rare behavior. Clusters containing no more than the configured number of entries are considered rare. Increasing it classifies more patterns as rare. | Example in source: 10 |
| Rare event base score | Base anomaly score assigned to a rare event. Higher values move rare events higher in severity ranking and closer to incident/alert thresholds. | Example in source: 75 |
| Rare event number limit | Maximum rare events reported per detection window, acting as a flood-control cap. | Per window |
| Rare anomaly type | Selects the backend rare-event detection algorithm or mode variant. | Mode selector |
06 / PROJECT SETTINGS
Whitelist, new-pattern, critical-event & priority controls
Additional anomaly families and incident-priority guardrails described in the project-level source.
Whitelist event detection
Detects log entries that match user-defined whitelist keywords or patterns that are explicitly selected for alerting.
| Setting | Technical behavior / purpose | Source note |
|---|---|---|
| Enable new pattern only | Reports a whitelist match only when it appears in a new pattern rather than on every occurrence, reducing repeated alerts. | On / Off |
| Base score | Base anomaly score assigned to whitelist-event matches. | Example in source: 1 |
| Number limit | Maximum whitelist events reported per detection window. | Per window |
New pattern detection
Detects when a never-before-seen log pattern appears and keeps it classified as new for the configured detection period.
| Setting | Technical behavior / purpose | Source note |
|---|---|---|
| Base score | Base anomaly score applied to new-pattern events. | Example in source: 40 |
| Number limit | Maximum new-pattern events reported per detection window. | Per window |
| New pattern detection period (days) | Number of days after first appearance that a pattern remains classified as new. | Example in source: 1 day |
Critical event detection
| Setting | Technical behavior / purpose | Source note |
|---|---|---|
| Base score | Base anomaly score for critical events that match configured critical keyword rules such as FATAL/ERROR conditions. | 0 = default scoring |
Incident priority cap
Controls how high computed/suggested incident priority can go and can optionally map anomaly-score ranges to explicit priority bands.
| Setting | Technical behavior / purpose | Source note |
|---|---|---|
| Ticket creation priority cap | Maximum priority allowed when incidents from the project create external tickets. | Priority cap |
| Suggested priority cap | Maximum priority the system is permitted to suggest for project incidents. | Priority cap |
| Enable incident priority threshold | Enables explicit anomaly-score ranges for Planning, Low, Moderate, High, and Critical; incidents are assigned priority based on the range containing their score. | Score-to-priority mapping |
07 / PROJECT SETTINGS
Advanced — Sensitivity → Hot/Cold Event Detection
Controls frequency-anomaly detection: a pattern suddenly occurring much more often (hot) or much less often (cold) than its learned baseline.
| Sensitivity behavior The source states that higher hot/cold sensitivity produces more anomaly detections. Hot/cold detection uses its own sampling interval, independent from the project’s main sampling interval. |
| Setting | Technical behavior / purpose | Source note |
|---|---|---|
| Enable hot event | Master switch for hot-event (frequency surge) detection. The detection sampling interval is editable only when hot-event detection is enabled. | Master switch |
| Hot event detection sampling interval | Time bucket used to count pattern frequency for hot/cold evaluation; independent of the project’s main sampling interval. | Value + unit |
| Hot event unit score | Score added per unit of frequency deviation above baseline. Higher values make surges reach alerting severity more quickly. | Example: 0.1 |
| Cold event unit score | Score applied per unit of deviation below baseline for cold (frequency-drop) events. | Example: 0.075 |
| Hot event number limit | Maximum hot events reported per detection window. | Per window |
| Cold event number limit | Maximum cold events reported per detection window. | Per window |
| Hot event threshold | Minimum frequency deviation above baseline required before a hot event is generated. | Minimum deviation |
| Cold event threshold | Minimum deviation below baseline required before a cold event is generated. | Minimum deviation |
| All patterns / Whitelist patterns only | Scope of hot/cold evaluation: all log patterns or only patterns matching the whitelist. Whitelist-only scope focuses detection on selected patterns. | Scope selector |
How the controls fit together
| Enable | Sample | Measure | Score | Limit |
Enable hot-event detection → choose the hot/cold counting interval → compare pattern frequency against baseline → apply hot/cold unit scores and thresholds → cap reported events with number limits.
08 / PROJECT SETTINGS
Quick tuning reference
A compact view of source-provided defaults, examples, and high-impact values. Example values are not universal defaults unless the source explicitly calls them defaults.
| Setting | Value | Interpretation |
|---|---|---|
| Feature outlier detection sensitivity | Medium | Source calls Medium the default balance between recall and noise. |
| Absolute outlier threshold | 0 | Disables the extra absolute-deviation filter. |
| Feature vector length | 200 | Source states default feature-vector length is 200. |
| Maximum training data sample value per model | 10,000 | Source states default is 10,000 log samples. |
| Model Keyword Segment K | 3 | Source states default K is 3. |
| Minimum log entry value for one analysis batch | 10,000 | Source states default 10,000 and notes 1 for smaller datasets. |
| Pattern limit size | 1,024 | Source states default 1,024; UI can be set up to 9,999 in the described implementation. |
| Rare event cluster size | 10 (example) | Illustrative example in source, not stated as universal default. |
| Rare event base score | 75 (example) | Illustrative example in source. |
| Whitelist base score | 1 (example) | Illustrative example in source. |
| New-pattern base score | 40 (example) | Illustrative example in source. |
| New-pattern detection period | 1 day (example) | Illustrative example in source. |
| Critical-event base score | 0 (example) | Source notes 0 uses default scoring. |
| Hot event unit score | 0.1 (example) | Illustrative example in source. |
| Cold event unit score | 0.075 (example) | Illustrative example in source. |
| Use as a reference, not a blanket recommendation Project behavior depends on data volume, pattern diversity, desired anomaly recall, storage objectives, and the role of each anomaly class. The values above are included only where the provided source names a default or example. |
Source and scope
Source: “Log Analysis Workflow” → “Log Project Settings Reference,” provided by the user. This document intentionally covers only setting behavior described in that source and does not add undocumented Core functions controls or undocumented backend semantics.
From the Blog
Blogs 
See how InsightFinder helps your team deliver reliable services across every layer of the stack
Take InsightFinder AI for a no-obligation test drive. We’ll provide you with a detailed report on your outages to uncover what could have been prevented.
