From Alert Floods to Precedence Forests: Zero-Prior-Knowledge Incident Triage with LOGOS

From Alert Floods to Precedence Forests: Zero-Prior-Knowledge Incident Triage with LOGOS Radhika Niranjan Mysore

arXiv:2610.02297v1 [cs.DC] 1 Oct 2026

Abstract

this bounded representation provides a distilled, cross-vendor failure context—replacing unguided log grepping with an empirical baseline upon which enterprise operators, vendor engineers, and future AIOps pipelines can build. Existing log-only diagnostic studies [11,16,17,21,28,30,33, 45,50,51] rely on clean, stationary healthy baselines. However, enterprise infrastructure rarely yields such baselines: healthy telemetry is absent during new deployments and upgrades, and otherwise non-stationary, sparse, or unrecorded during normal operation [19, 21, 25]. Consequently, how far raw text logs alone can bound the enterprise diagnostic search space without healthy execution baselines remains an open question. Our contribution. In this paper, we present LOGOS to answer this question. LOGOS is a log-only analysis system that bounds and orders the diagnostic search space by inferring approximate fault propagation across vendor infrastructure subsystems. For example, when applied to virtual infrastructure logs, LOGOS isolates latent faults like unpersisted configuration changes and infers how they propagate to disrupt virtual network bring-up. The goal of LOGOS is to serve as a fully automated first step before an enterprise administrator begins manual triage. Therefore, LOGOS must trace faults through raw telemetry without relying on external inputs. To bound the search space, LOGOS eliminates background noise by leveraging system and runtime entity identifiers embedded in log text to link related events (events sharing entities) and related entities (entities co-occurring across events). Together, these form a bipartite entity-event graph; computing the transitive closure over this graph isolates related events from unrelated background noise (e.g., as illustrated by config_store in Listing 1). Within this graph, higher-severity events (e.g., [WARN], [ERROR]) denote faults, while participating identifiers represent impacted entities—either originating faults or downstream victims. To order the search space, LOGOS sorts impacted entities in this isolated graph by their earliest faults. However, pure chronological sorting alone does not reveal how faults propagate between entities that do not directly share a log event. To establish fault precedence from log data, LOGOS connects each impacted entity to its nearest earlier co-occurring entity in a parent-child relationship, reconstructing the failure propagation sequence. This log-only reconstruction is challenging for two primary reasons. First, identifying faults in logs is hard. Enterprise logs do not encode the correct severity of events. In virtual infrastructure logs, third-party vendor subsystem events are logged verbatim without assigned severities, because they do

Commercial observability platforms rely on domain artifacts like distributed traces, topology maps, and baseline metrics. However, when troubleshooting proprietary software, enterprise operators are left with only raw, unannotated text logs. We explore the extreme boundary of log-only diagnosis: To what extent can we isolate failure propagation using strictly raw text logs? We present LOGOS, an unsupervised system that exploits entity-event co-occurrence and temporal precedence to collapse millions of raw log lines into a compact precedence forest. Evaluated across 25 production enterprise outages and 12 open-source issues, LOGOS operates with zero prior knowledge—requiring no seed queries, observed symptoms, or pre-defined incident boundaries. In a median wall-time of 4.5 minutes, LOGOS eliminates a median 99.8% of background noise, achieves 0.76 mean recall, and detects failure cascades with a 16-hour median diagnosis-verified lead time—consolidating alert floods 124× to enable 80% enterprise (100% open-source) zero-shot LLM root-cause accuracy.

1

Introduction

Modern observability platforms [9, 12, 39] rely on rich domain artifacts—dependency maps, distributed traces, and execution baselines—that are absent in black-box enterprise deployments. Enterprise IT administrators lack the source code, vendor-specific domain expertise, and incident history required to inspect proprietary vendor binaries, while vendor engineering teams lack visibility into the customer’s private deployment state until an outage surfaces [19, 44, 46]. This creates a double bind: troubleshooting guides and runbooks quickly become stale [14, 19, 37, 40], and emergent cross-vendor failures fall outside any single vendor’s source code or documentation. Consequently, enterprise debugging remains overwhelmingly manual [40]. While recent AIOps pipelines [8, 22, 36, 37, 42, 44, 49] attempt to automate triage, they assume curated playbooks or historical incident archives that enterprise environments do not possess. Because raw text logs remain the only universally accessible artifact spanning all vendor boundaries [19] (§2), this work explores the extreme end of the spectrum: To what extent can we bound the diagnostic search space using strictly raw text logs? By establishing this lower bound—without requiring source code, distributed traces, or healthy execution baselines—log-only analysis empowers enterprise administrators to troubleshoot complex multi-vendor incidents as far as possible on their own. When severe issues exceed inhouse resolution and require escalation to vendor support, 1

not share common logging conventions or error codes, leaving them at risk of being misclassified as benign [INFO] events. While determining exact event severity without domain knowledge is impossible, LOGOS captures these faults by elevating central subsystem logs that wrap such third-party events directly to fault candidates. Additionally, it extracts embedded severity keywords from free-form log text; for instance, the line [t0 - 37m] [INFO] management_node: Ignoring config_parse_exception[1046]: Not a non-singleton object: key alert (Listing 1) is promoted based on its embedded alert keyword—a heuristic we call severity elevation. Second, identifying the boundary of failure propagation, especially its origin, is hard. Entity correlation alone cannot distinguish originating faulty entities from downstream victims. Blindly correlating all impacted entities across an entire multi-day log bundle inflates the search space as victims cooccur with unrelated background events. To isolate the failure origin without domain knowledge, LOGOS partitions the log timeline into uniform windows and flags fault propagation onset at the first window where correlated faults span two or more distinct subsystems—marking the start of a multisubsystem cascade. Starting from this onset window, LOGOS correlates faults across consecutive windows, constructing a bipartite entity-event graph and computing its transitive closure to isolate independent subgraphs. LOGOS tracks the maximal connected component (the primary propagation cascade detected) and expands it until a subsequent window adds no new faults, at which point graph construction terminates. We call this process progressive onset tracking. LOGOS organizes the impacted entities in this primary cascade into parent-child relationships to reconstruct the failure propagation sequence. However, this construction is confounded by entities that occur ubiquitously in logs—such as global session identifiers or cluster-wide task handles used by management subsystems—because they co-occur with nearly all other entities. Lacking domain context, LOGOS would treat these handles as universal parent hubs, causing them to falsely appear as the root of all other faults. To prevent this structural distortion, LOGOS identifies and filters out ubiquitous entities prior to tree construction—a technique we call hub-node pruning. Removing these hub nodes partitions the cascade into a precedence forest of distinct propagation trees suited for direct human triage or AIOps synthesis. To summarize, this work makes three core contributions: System Design. We introduce LOGOS, an unsupervised, domain-agnostic log system that bounds the enterprise diagnostic search space in linear O(M) memory, where M is the number of entity–event incidences (edges of the bipartite graph) in the log bundle, without requiring source code, distributed traces, or execution baselines. Early Detection. Progressive onset tracking isolates developing failures hours before catastrophic outages—achieving a 16-hour median diagnosis-verified lead time—while collaps-

ing raw alerts into precedence forests (124× median reduction). Empirical Validation. Across 25 enterprise outages and 12 open-source incidents, LOGOS achieves 0.76 mean recall and a median 99.8% noise reduction in a median wall-time of 4.5 minutes, outperforming O(M 2 ) graph centrality baselines. Zero-shot LLM (Gemini) evaluation yields 80% enterprise and 100% open-source root-cause accuracy—establishing an empirical log-only lower bound upon which LLM reasoning and AIOps pipelines can build.

2

Background and Motivation

Log analysis is the primary diagnostic method for complex enterprise outages. Across 100 severe virtual infrastructure incidents we studied, spanning distributed enterprise datacenters across compute, storage, networking, and control planes, 56 were root-caused using logs alone, 7 required fine-grained metrics, 7 required memory core dumps, and 8 required source code analysis (primarily locking and resource contention). The remaining 22 were resolved out-of-band via upgrades or reconfigurations—a common outcome for complex enterprise issues [14, 15]. Diagnosing the 56 log-centric issues was an inherently manual and iterative process spanning vendor support and engineering teams, averaging ∼33 days in calendar resolution time. LOGOS directly targets the empirical cost of unguided log search by eliminating a median 99.8% of background noise in a median compute wall-time of 4.5 minutes (§6.3, §6.6)—narrowing, rather than replacing, this 33-day manual investigation. From the 56 log-centric issues, we selected 25 log-diagnosable issues for evaluating LOGOS based on complete log bundle availability and verified ground truth. The 25 issues highlight how faults cross subsystem and vendor boundaries in complex enterprise outages. Table 1 summarizes the symptom and root-cause categories across these incidents, revealing two key characteristics. First, thirdparty vendor issues account for nearly two-thirds of all incidents (16 of 25). This concentration reflects the operational pain point resulting from emergent cross-vendor interactions where administrators lack source code or runbooks. Second, root causes rarely reside in the same subsystem as the observed symptom [35] and are often logged days before the final outage [20]. Consequently, diagnosing these incidents requires analyzing multi-day logs across several decoupled subsystems to trace terminal symptoms back to their originating root cause. While simple frequency and severity ranking heuristics capture root-cause entities in nearly half of these incidents (12 of 25), flat entity lists fail to reconstruct the cross-subsystem failure propagation required for diagnosis, detailed next. Naive Entity-Ranking Heuristics. To evaluate whether naive entity-ranking heuristics can resolve these incidents, we tested simple frequency and severity baselines on candidate faults isolated via severity elevation. While these rankings capture the root-cause entity in nearly half the incidents (12 of 25), a 2

Table 1: Symptom and Root Cause Category breakdown across the 25 enterprise evaluation incidents. Symptom Category

Root Cause Category

Compute

Third-party storage

2

Control plane Control plane Control plane

Compute / Config Network / Config Storage / Config

1 1 1

Management plane Management plane Management plane

Config Memory Third-party management plane

3 2 1

Memory

Third-party config

1

Network Network

Third-party config Memory / Config

1 1

Storage Storage Storage

Third-party storage Third-party management plane Third-party network

9 1 1

Total Incidents

Table 3: Entity Density & Unipartite Projection Density. N: bundles evaluated per platform. Individual log lines average Nline > 1 entities, forming natural bipartite edges; Nco-occur is the mean number of entities each entity co-occurs with in a pattern. Converting these into unipartite entity-entity graphs inflates edge density (ρmax ), causing baseline graph algorithms to suffer Out-of-Memory (OOM) failures.

Count

25

Table 2: Evaluation of naive entity-ranking heuristics across 25 enterprise incidents. Shows the number of incidents where each heuristic successfully surfaced ground-truth root-cause entities within its Top-10 list. Combined, at least one heuristic worked in 12 of 25 incidents (48.0%). Caught

Top entities by raw cross-subsystem fault count Top entities by distinct cross-subsystem fault spread Top entities by cross-subsystem fault severity Top-10 entities per subsystem by fault count Top-10 entities per subsystem by fault severity Low-frequency (≤ 15) application-level entities

7 2 0 12 0 0

Combined Union (Any Heuristic Surfaced Root Cause) Missed (No Heuristic Surfaced Root Cause)

12 13

N

Nline

Nco-occur

ρmax

Virtual Infrastructure OpenStack TrainTicket

25 4 8

4.37 2.61 2.57

5.32 7.58 24.21

68.21% 56.06% 10.85%

and free-form log text. Because native log levels are unreliable [19], LOGOS applies severity elevation. Log fields are parsed using vendor-specific regular expressions, abstracting free-form text into parameterized log templates (or events) following standard log abstraction models [18]. This abstraction condenses millions of repetitive log lines into a compact vocabulary of event patterns—each representing a distinct logging statement in the underlying code—while isolating dynamic parameters (e.g., task handles, disk IDs) to serve as entity “glue” in our bipartite graph. Entity Co-Occurrence. To verify whether log lines naturally link events across subsystems, we analyzed telemetry across three platforms: 25 enterprise virtual infrastructure bundles, 4 OpenStack cloud datasets [53], and 8 TrainTicket microservice benchmarks [52]. Across all three environments, individual log lines contain multiple co-occurring identifiers (Nline > 1, averaging 2.57 to 4.37 IDs per line). This validates our core thesis: dynamic identifiers (e.g., task handles, VM UUIDs, disk IDs) naturally appear together in log text, acting as the “glue” that stitches cross-subsystem failure paths without manual schemas or tracing headers. Crucially, attempting to convert these log lines into standard pairwise entity graphs used by traditional graph-based algorithms [4, 25, 43] creates dense cliques (up to 68.21% overall density; Table 3). In practice, this O(M 2 ) projection bottleneck (where M is the number of entity–event incidences in the bundle) causes standard centrality baselines to run out of memory on 9 of our 25 enterprise incident bundles (36%). LOGOS avoids this quadratic scaling by preserving the native bipartite structure between entities and log events, keeping computation linear (O(M)) and evaluating successfully across all 25 bundles.

flat ranked list fails to reveal how the failure propagated across subsystem boundaries [36, 44]. Consequently, operators are still forced to manually investigate each entity as an isolated starting point, leaving the diagnostic search space unreduced. Table 2 breaks down the number of incidents each heuristic surfaced.

Heuristic Description

Dataset / Stack

Enterprise Telemetry. When enterprise incident tickets are filed, administrators upload diagnostic log bundles spanning retention windows from days to weeks. Bundles encompass telemetry across control, management, and data planes, organized in directories representing clusters, with separate log files for specialized subsystems (e.g., host management daemons, hypervisor kernels, virtual storage drivers). While enterprise bundles contain heterogeneous artifacts such as memory crash dumps and metric time-series, LOGOS operates strictly on raw text logs. Each log line comprises four primary fields: a timestamp, emitting subsystem, native severity level (e.g., INFO, ERROR),

3

Upgrade Incident Case Study

Consider a real enterprise incident where virtual machines (VMs) failed to migrate following a hypervisor upgrade. Despite state-of-the-art observability tooling and tens of gigabytes of telemetry spanning ∼3 years, enterprise administrators could not isolate the cause. The ticket was escalated to vendor support teams and routed to core engineering, where engineers spent over a month debugging and deploying workarounds before tracing the root cause out-of-band to a 3

product defect that prevented host configuration updates from being persisted to disk for two years. In this case study, the product defect itself is not explicitly recorded in the logs, but its downstream impact on the infrastructure is. LOGOS must trace this impact through raw telemetry, isolating fault propagation from background noise without relying on external inputs. Accordingly, it is provided strictly with the raw 20.5 million-line log bundle—requiring no starting query, observed symptom seed, or pre-defined incident boundaries. Incident Timeline. Listing 1 shows an excerpt of the log lines capturing the incident. Two years prior (t0 − 2yr), a maintenance script (backup_cron) marked the host as pending reboot (pending_reboot=1). Expecting an imminent reboot, the configuration store (config_store) silently stopped persisting new changes to disk—a latent product defect. Because the host was never actually rebooted, all subsequent configuration updates over the next two years (including virtual switch and network group renames) existed strictly in volatile RAM. Pre-upgrade log lines at t0 − 116h and t0 − 37m recorded early warnings of this latent state drift. When administrators rebooted the hypervisor following the upgrade at t0 , the host restored the stale twoyear-old disk configuration (t0 + 12m11s to t0 + 12m11.3s). Driven by this stale state, the switch restore daemon (virtual_switch_info) re-applied outdated port bindings, triggering network configuration errors that ultimately caused VM migration failures. Concurrently, host management daemons repeatedly attempted to re-attach the failed switch endpoint (add_virtual_switch_to_host from t0 to t0 + 24m). LOGOS’s Log Representation. LOGOS parses raw logs into events and entities. Severity elevation classifies all events in Listing 1 as faults, even those carrying benign [INFO] tags. Specifically, management_node’s line is elevated because it contains the keyword alert, while boot_init’s lines are elevated because they are logged by a central subsystem that interfaces with unstandardized third-party components. For this incident, progressive onset tracking evaluates 7.9 million log lines across a 7-day window surrounding the upgrade. LOGOS partitions this span into 2-hour tumbling windows to detect fault onset and construct the bipartite entity-event graph. Figure 1 shows an excerpt of the maximal connected subgraph isolated by computing its transitive closure (Section 4). End-to-end, LOGOS processes this bundle—ingestion through precedence-forest construction—in under 48 minutes (Figure 3, labeled upgrade), against the month engineers spent debugging it out-of-band. In Figure 1, extracted high-entropy identifiers form entity nodes (top row), encompassing both runtime entity names (boot_init, config_store) and system entity names (config_store_backup, data_file_store). Because a log line’s entity set defaults to its logging subsystem (Table 4), boot_init is both the logging subsystem of the restoresequence lines and an entity node in the graph. Their as-

Listing 1: Upgrade Incident Log Excerpt (Masked). Chronological snippet from a multi-year log snapshot. Text following % denotes added annotations (event counts and context) rather than literal log output. [~2 y prior ]

[ t0

[ t0

[ t0

[ t0

[ t0 [ t0

[ t0

[ t0

[ t0

[ t0

[ INFO ] backup_cron : Workflow run with pending_reboot =1; Live install status never persisted to config_store % reconstructed from incident report; no raw -log timestamp - 116 h] [ WARN ] host_agent : Skip saving virtual_net_group to : filePath empty % recurs ~every 5 min from here through the reboot - 37 m] [ INFO ] management_node : Ignoring config_parse_exception [1046]: Not a non - singleton object : key alert + 0s .. +24 m] [ ERROR ] host_agent : add_virtual_switch_to_host : object not found / hostcfg disabled % recurs 13x across this window, never resolves + 12 m11s ] [ ERROR ] boot_init : config_store : Failed to connect to database % repeats 4x, 3ms apart + 12 m11 .2 s] [ INFO ] boot_init : config_store : load_store Start . + 12 m11 .2 s] [ INFO ] boot_init : config_store : Restore config_store from config_store_backup + 12 m11 .2 s] [ INFO ] boot_init : config_store : config_store restored successfully from backup + 12 m11 .2 s] [ INFO ] boot_init : config_store : data_file_store backup ( data_file_backup ) is valid + 12 m11 .3 s] [ INFO ] boot_init : config_store : data_file_store restored successfully from backup + 12 m21s ] [ INFO ] boot_init : virtual_switch_info : Prepare to restore : virtsw_local_binding % excerpt only: thousands more real lines/ entities not shown

sociated log statements form event nodes (bottom row), with undirected edges connecting each entity to its co-occurring events. Entities bind related events into connected components; for instance, boot_init co-occurs across more than 570 events in the full graph, of which the figure shows five, spanning from the database connection failure and backuprestore sequence (t0 + 12m11s to t0 + 12m11.3s) to the virtual switch restore attempt (t0 + 12m21s). Linking each entity to its nearest-earlier co-occurring entity while pruning ubiquitous hub nodes transforms this bipartite graph into the precedence forest (Figure 2), partitioning the failure space into three distinct propagation trees. Tree A (Connected Restore Branch) is anchored at boot_init (which links upward to an excluded hardware/BMC ancestor); this branch links the database failure to the backuprestore sequence (load_store, config_store_backup, data_file_store, data_file_backup) and resolves two hops down to the failing switch entity (virtsw_local_binding). Tree B (Isolated Retry-

4

Entity: config_parse_exception

(shared hub entities)

Entity: add_virtual_switch_to_host

management_node

Event (t0−37m) “Ignoring config_parse_ exception[1046]...”

(shared hub entities)

Entity: config_store

Entity: load_store

Entity: config_store_backup

Entity: data_file_store

Event (t0+12m11s) “Failed to connect to database”

Event (t0+12m11.2s) “load_store Start.”

Event (t0+12m11.2s) “Restore config_store from config_store_backup”

Event (t0+12m11.2s) “data_file_store backup (data_file_backup) is valid”

Entity: data_file_backup

Subsystem: boot_init

Entity: virtual_switch_info

Entity: virtsw_local_binding

··· (thousands more entities/events, not shown)

host_agent

Event (t0+0s) “...object not found/ hostcfg disabled”

Event (t0+12m21s) “Prepare to restore: virtsw_local_binding”

Figure 1: Bipartite Entity-Event Subgraph Excerpt. Edges link entity nodes (top) to log event nodes (bottom). config_store connects the database failure to backup-restore events, while boot_init links them to the virtual switch restore attempt. Dashed edges connect events associated with config_parse_exception and add_virtual_switch_to_host to the rest of the full graph via elided hub entities prior to hub-node pruning. Precedence Forest: 3 trees, 10 entities . . . earlier ancestor (hardware/BMC)

add_virtual_switch_to_host [ROOT_CANDIDATE] [DEAD_END] tbeg =t0+0s, tend =t0+24m

boot_init tbeg =t0+12m11s, tend =t0+12m21s

config_store t0+12m11s

virtual_switch_info t0+12m21s

load_store [DEAD_END] t0+12m11.2s

data_file_store t0+12m11.2s

config_store_backup [DEAD_END] t0+12m11.2s data_file_backup [DEAD_END] t0+12m11.2s

virtsw_local_binding [DEAD_END] t0+12m21s config_parse_exception [ROOT_CANDIDATE] [DEAD_END] t0−37m

· · · additional trees

Figure 2: Incident Precedence Forest Excerpt. Directed edges point from child entities to their nearest earlier co-occurring parent entities. Tree A resolves 2 hops from boot_init down to virtsw_local_binding, while Trees B and C form isolated root candidates. ing Root) consists of add_virtual_switch_to_host, an isolated root candidate whose 13 retries share no entity tokens with Tree A, leaving it disconnected. Tree C (Pre-existing Parsing Root) is the separate, isolated root node config_parse_exception (t0 − 37m). Each node in the forest encapsulates an impacted entity along with its associated co-occurring events. While the bipartite graph in Figure 1 captures how entities and events relate structurally, the precedence forest captures the temporal unfolding of failure propagation across impacted entities. Although the root cause of the incident itself lies outside the evaluated 7-day window, the forest establishes that within this window, the configuration parsing exception (config_parse_exception) strictly preceded all other faults in Figure 2. Meanwhile, failed retries by the host management daemon to attach the switch endpoint (add_virtual_switch_to_host) occurred concurrently with boot_init faults. This temporal precedence enables operators to reconstruct the precise sequence of runtime and system entity faults during triage. LLM Reasoning over Topology. Because this experiment strictly withholds event text, the prompt frames the input purely as structure: it explains that the data is a forest of inde-

pendent failure-propagation trees rather than a single chain, that each entity is shown only by its first- and last-occurrence timestamps and its precedence edges to other entities, and that certain entities are tagged as likely entry points (no earlier identified cause within their own tree) or terminal effects (no further downstream effect within their own tree). The model is asked to trace forward from a tagged entry point along these edges and propose a root cause and propagation path using only the graph’s own shape and entity naming—since no log content is available in this ablation, the model cannot verify that its chosen entity’s own line describes an actual fault, a limitation the response below surfaces directly. Constructing the precedence forest reduces the diagnostic search space from 7.9 million lines over the 7-day period to 34,927 nodes, a ∼ 227× reduction. To evaluate whether graph topology alone is sufficient for triage, we serialized a 1,600node excerpt from this forest using only entity names, initial and final fault timestamps (tbeg ,tend ), parent-child edges, and structural annotations ([ROOT_CANDIDATE], [DEAD_END])— strictly omitting all raw log event text—and queried Gemini for interpretation. The prompt yielded the following diagnostic response and self-reported caveats:

5

the diagnostic search space. LOGOS is structured as a twostage pipeline that transforms raw text logs into compact precedence forests. First, the ingestion stage parses raw log lines into entity identifiers and log events, applying severity elevation to isolate fault candidates. Second, the graph construction stage leverages progressive onset tracking and hub-node pruning to transform these fault candidates into compact precedence forests. Table 4 summarizes the formal constructs, notation, and graph operations used across both stages. Log Ingestion. The ingestion stage transforms raw log lines L into a filtered candidate fault set E (L → E). Using regex templates (§2), raw lines sharing the same log pattern are collated (CollateLines(L)) into parameterized events e ∈ E, inheriting the earliest line timestamp t(e) = minℓ∈e t(ℓ) and conS stituent entity sets Entities(e) = ℓ∈e Entities(ℓ). To capture misclassified third-party errors (§1), LOGOS applies severity elevation, promoting lines with embedded severity keywords or originating from central wrapper logs. The resulting elevated event stream E = {e ∈ CollateLines(L) | severity(e) ≥ [WARN]} serves as the primary input for graph construction.

“The config_parse_exception entity appears at t0 − 37m, making it the earliest event in the timeline by a wide margin. This indicates a corrupted or malformed configuration file. This underlying failure likely caused the add_virtual_switch_to_host operation to hang or continuously fail starting at t0 (lasting 24 minutes). The system or service was likely restarted to recover, evidenced by boot_init at t0 + 12m11s. During initialization, the system attempted to load the config and had to fall back to config_store_backup and data_file_backup, semantically corroborating that the primary configuration was broken by the earlier parse exception. [Caveats] Because these entities exist in separate trees without explicit co-occurrence edges, the causal links between the config exception, the hanging virtual switch operation, and the subsequent reboot are inferred solely from chronological sequencing and semantic naming. Furthermore, since boot_init has an excluded hardware/BMC parent in the full graph, it is possible an underlying hardware or storage failure caused both the initial config file corruption (the parse exception) and a later forced hardware reboot, making the hardware fault the true unseen root cause.”

This response illustrates the power of bounding and ordering the log search space before incident triage. The precedence forest helps Gemini arrive at a hypothesis close to the actual cause: a configuration issue, without any domainspecific augmentation, despite the absence of event text. With domain expertise and event text, we expect human operators and downstream AIOps pipelines to improve over this response. This example also highlights two gaps when applying LLM reasoning over the precedence forest. First, Gemini bridges disconnected trees into a single incident trajectory by leveraging temporal sequencing and semantic hints embedded within entity names—overriding the explicit structural boundaries maintained by LOGOS due to a lack of co-occurring entities. Although ground truth from the incident confirms that all three trees indeed stem from the same cause (unpersisted configuration updates), this behavior reveals an LLM tendency to speculate cross-tree causality beyond explicit structural evidence. Second, because the latent root cause, a product defect, was unrecorded in the log bundle, the precedence forest captures only the subsequent failure propagation, which Gemini misattributes to hardware failures and file corruption due to the absence of event text. These gaps help identify the augmentations needed for a downstream AIOps pipeline: (1) prompting must enforce explicit awareness of forest topology boundaries, and (2) event text must be included to eliminate speculative hardware failure and file corruption hypotheses. We use the event text in our subsequent evaluations (§6).

4

4.1

Graph Construction

The graph construction stage transforms the elevated fault set E into compact precedence forests σ (E → F ∗ → σ). Progressive onset tracking (Algorithm 1) partitions E into uniform temporal windows and detects fault propagation onset at the first window where correlated faults span two or more subsystems. From this onset window, it correlates faults across consecutive windows to construct a bipartite entity-event graph, computing its transitive closure to track the maximal connected component F ∗ ⊆ E representing the primary failure propagation cascade (Algorithm 2). When a subsequent window adds no new faults to this component, graph expansion terminates. At both the initial onset and upon termination, LOGOS converts F ∗ into a precedence forest σ via hub-node pruning and temporal edge assignment between impacted entities (Algorithm 3). Progressive Onset Tracking. To detect propagating failures without assuming a known outage timestamp, LOGOS discretizes the timeline into uniform 2-hour windows (W = (w0 , . . . , wN−1 ), Tw = 2h). These windows serve as input to progressive onset tracking (Algorithm 1). Across these windows, LOGOS tracks failure propagation onset, expansion, and termination to output an ordered sequence of precedence forests S = ⟨σ1 , σ2 , . . . ⟩, where each forest σ ∈ S captures an isolated failure propagation cascade. Onset. For every window scanned, progressive onset tracking constructs a bipartite entity-event graph and computes its transitive closure to evaluate candidate failure components (Line 3). An onset is flagged when the subsystem footprint of the maximal connected component F ∗ spans two or more distinct subsystems (|Subsystems(F ∗ )| ≥ Kcomp = 2, Line 3), signaling that correlated faults are propagating across subsys-

Design

In this section, we describe how the key concepts introduced in Section 1—severity elevation, progressive onset tracking, and hub-node pruning—are combined to bound and order

6

Table 4: LOGOS Constructs & Notation. Construct

Formal Definition & Operations

Raw Log Line (ℓ ∈ L)

Log entry containing timestamp t(ℓ), raw text, and logging subsystem Subsystem(ℓ). Entity set Entities(ℓ) is extracted via regular expressions, defaulting to {Subsystem(ℓ)}.

Log Event (e ∈ E)

Template-level aggregation e = CollateLines(L) following severity elevation, with timestamp t(e) = minℓ∈e t(ℓ). Establishes entity correlation (u, v ∈ Entities(e)) and event correlation (Entities(e1 ) ∩ / Entities(e2 ) ̸= 0).

Log Window (wi ⊂ L)

Chronological Tw = 2h slice used during progressive onset tracking across log pool L.

Maximal Failure Subgraph (F ∗ ⊆ E)

Maximal connected component F ∗ = argmaxC∈C | e∈C Entities(e)| selected from connected components C formed via transitive closure over the bipartite entity-event graph within correlation bound |t(e1 ) − t(e2 )| ≤ Tc = 2h. Footprint: Subsystems(F ∗ ) = {Subsystem(e) | e ∈ F ∗ }.

Precedence Forest (σ)

Graph σ = (V, Eπ ) constructed over maximal component F ∗ via hub-node pruning: • Hub-Node Blocklist (G): Ubiquitous hub entity identifiers (e.g., global session identifiers or clusterwide task handles).
S • Impacted Entity Nodes (V ): Entities e∈F ∗ Entities(e) \ G, bound to [tbeg (v),tend (v)]. • Precedence Edges (Eπ ): Directed pairs (u∗ , v) linking entity v to its nearest temporally preceding co-occurring entity u∗ .

S

tem boundaries—i.e., a cascade is forming. Expansion. Upon identifying an onset window wonset , the algorithm initiates an expanding window walk across up to Kwalk = 15 consecutive windows (Lines 7–19). By accumuS lating log lines R = wi , LOGOS continuously recomputes maximal component Fs∗ to capture failure cascades that cross window boundaries. Termination. The expanding walk terminates either by naturally converging—when the failure cascade stops expanding ∗ , Line 13)—or forcibly upon reaching the walk (Fs∗ = Fprev cap Kwalk = 15 without convergence (Line 20). Forest Sequence. At both initial onset (s = 0) and upon con∗ ), the algorithm invokes C ONSTRUCTvergence (Fs∗ = Fprev F OREST to transform the maximal failure subgraph F ∗ into a precedence forest σ (Lines 13–14), enforcing temporal precedence across impacted entities. Capturing forests at both onset and upon convergence preserves both the initial failure cascade right after it impacts multiple subsystems, and the final cascade after convergence (or walk termination). If the walk cap Kwalk is reached without converging, a fallback forest is emitted for the accumulated window slice (Line 21). The search index then advances past the processed cascade (idx ← ilast + 1, Line 23) to resume scanning. Once the primary loop completes, any trailing unexamined windows (last_covered < N − 1) undergo a final fallback scan (Lines 25–28), returning the complete sequence of precedence forests S . Bounded Bipartite Subgraph Detection. D ETECT S UB GRAPHS correlates input faults E within a temporal correlation bound Tc = 2h to construct a bipartite entity-event graph. Within this graph, it isolates failure propagation cascades by computing its transitive closure, returning the maximal failure subgraph F ∗ ⊆ E representing the primary failure cascade (Algorithm 2).

To compute transitive closure across shared entities efficiently, the algorithm initializes a Union-Find structure over E (Line 2), whose amortized near-linear complexity is a classical result [41]. For each unique entity u, LOGOS constructs a chronologically ordered sequence of its associated faults Lu = (e1 , e2 , . . . , em ) (Lines 3–4). To bound search-space growth temporally and avoid correlating faults far apart in time, LOGOS merges adjacent faults ei and ei+1 via union only when their temporal separation falls within the correlation bound t(ei+1 ) − t(ei ) ≤ Tc (Lines 5–8). Finally, the algorithm extracts all connected components C (Line 11) and S selects F ∗ = argmaxC∈C | e∈C Entities(e)| as the maximal connected component spanning the most impacted entities (Line 12), returning F ∗ as the maximal failure subgraph for precedence forest construction (Line 13). Precedence Forest Construction. C ONSTRUCT F OREST accepts the maximal failure subgraph F ∗ and accumulated log lines R, returning a precedence forest σ = (V, Eπ ) that establishes the chronological fault propagation topology across impacted entities (Algorithm 3). To prevent ubiquitous infrastructural handles from acting as false root hubs (hub-node pruning), the algorithm first filters entities in F ∗ against blocklist G to isolate the impacted node set V (Line 2). Next, LOGOS records the first and last appearance of each entity v ∈ V across log lines R as its active temporal boundaries [tbeg (v),tend (v)] (Lines 3–6), defining its active event span for triage (§5). Sorting V in ascending order by earliest appearance—breaking timestamp ties deterministically by entity ID v, i.e., (tbeg (v), v)—establishes a global rank order(v), capturing each entity’s earliest fault since onset (Line 7). Finally, the algorithm constructs parent-child precedence edges Eπ (Line 8). For each entity v ∈ V , LOGOS identifies co-occurring entities in F ∗ (Line 10) and filters for tempo-

7

Algorithm 1 Progressive Onset Tracking Require: Log windows W = (w0 , . . . , wN−1 ), correlation bound Tc , walk cap Kwalk = 15, onset threshold Kcomp = 2 Ensure: Sequence of precedence forests S 1: S ← ⟨⟩, idx ← 0, last_covered ← −1 2: while idx< N do
3: I ← j ∈ [idx, N − 1] Subsystems D ETECT S UBGRAPHS(CollateLines(w j ), Tc ) ≥ Kcomp 4: if I = 0/ then break 5: end if ∗ ← 0, / / 6: onset ← min(I ), R ← 0, Fprev ilast ← onset − 1, terminated ← false 7: for s ← 0 to Kwalk − 1 do 8: if onset + s ≥ N then break 9: end if 10: ilast ← onset + s ▷ Track window index currently processed 11: R ← R ∪ wilast 12: Fs∗ ← D ETECT S UBGRAPHS(CollateLines(R), Tc ) ∗ then 13: if s = 0 ∨ Fs∗ = Fprev ▷ Initial onset or natural convergence 14: S ← S ∥ ⟨C ONSTRUCT F OREST(Fs∗ , R)⟩ 15: if s > 0 then terminated ← true; break 16: end if 17: end if ∗ ← F∗ 18: Fprev s 19: end for 20: if not terminated ∧ s > 1 then ▷ Walk cap reached without natural convergence ∗ , R)⟩ ∗ for last processed window 21: S ← S ∥ ⟨C ONSTRUCT F OREST(Fprev ▷ Emits Fprev 22: end if 23: last_covered ← max(last_covered, ilast ), idx ← ilast + 1 24: end while 25: if last_covered < N − 1 then ▷ Fallback scan for trailing window ∗ ← D ETECT S UBGRAPHS (CollateLines(w 26: Ffinal N−1 ), Tc ) ∗ ,w 27: S ← S ∥ ⟨C ONSTRUCT F OREST(Ffinal N−1 )⟩ 28: end if 29: return S dence edge (u∗ , v) is drawn from the single nearest prior cooccurring entity u∗ = argmaxu∈P(v) order(u) (Lines 12–14). This yields a directed acyclic forest σ = (V, Eπ ) (Line 17), producing a compact, ordered diagnostic artifact suited for direct human triage or downstream AIOps synthesis.

Algorithm 2 Bounded Bipartite Subgraph Detection 1: function D ETECT S UBGRAPHS (E, Tc ) 2: UF ← Initialize UnionFind over log events E S 3: for each entity u ∈ e∈E Entities(e) do 4: Let Lu = (e1 , e2 , . . . , em ) be log events in E con-

taining u, ordered by t(e) for i ← 1 to m − 1 do if t(ei+1 ) − t(ei ) ≤ Tc then UF.union(ei , ei+1 ) end if end for 10: end for 11: C ← ConnectedComponents(UF) S 12: F ∗ ← argmaxC∈C | e∈C Entities(e)| bounded bipartite subgraph 13: return F ∗ 14: end function

5

5: 6: 7: 8: 9:

Implementation

LOGOS is implemented as a CPU-only pipeline in approximately 3,150 lines of Python 3.10+. It leverages Python’s concurrent.futures thread pools and pre-compiled regular expressions for parallel log ingestion, utilizing SQLite (v3.35+) to persist parsed event templates and extracted entities for retrieval by progressive onset tracking. Vendor-Specific Log Parsing. LOGOS employs lightweight, source-specific integration modules for both enterprise environments and open-source benchmarks (OpenStack [53], TrainTicket [52]). Because enterprise log schemas remain stable in production, each log source requires only a onetime integration module with four components: (1) a precompiled regex cascade extracting the primary 4-field tuple

▷ Maximal

rally preceding candidates P(v) where order(u) < order(v) (Line 11). If preceding candidates exist, a directed prece-

8

Algorithm 3 Precedence Forest Construction

Table 5: Top-k (k ∈ {1, 10}) reachability and recall for graph baselines vs. LOGOS on enterprise incidents. Closeness, Betweenness, PPR, and earliest-temporal order are computed on the identical 7-day/Tc = 2h (and optionally hub-node pruned) graph LOGOS uses across N = 16 tractable enterprise bundles. LOGOS is reported for both populations: restricted to N = 16 for a direct baseline comparison, and across the full N = 25 enterprise population.

1: function C ONSTRUCT F OREST(F ∗ , R)

V ← ( e∈F ∗ Entities(e)) \ G ▷ Hub-node pruning 3: for each entity v ∈ V do ▷ Phase 1: Record active temporal boundaries 4: tbeg (v) ← min{t(ℓ) | ℓ ∈ R ∧ v ∈ Entities(ℓ)} 5: tend (v) ← max{t(ℓ) | ℓ ∈ R ∧ v ∈ Entities(ℓ)} 6: end for 7: order(v) ← rank of v when V is sorted ascending by (tbeg (v), v) ▷ Phase 2: Global order 8: Eπ ← 0/ 9: for each entity v ∈ V do ▷ Phase 3: Parent pointer assignment 10: C(v) ← {u ∈ V \ {v} | ∃e ∈ F ∗ s.t. {u, v} ⊆ Entities(e)} ▷ Co-occurring entities 11: P(v) ← {u ∈ C(v) | order(u) < order(v)} ▷ Temporally preceding candidates 12: if P(v) ̸= 0/ then 13: u∗ ← argmaxu∈P(v) order(u) ▷ Nearest-earlier co-occurring parent entity 14: Eπ ← Eπ ∪ {(u∗ , v)} 15: end if 16: end for 17: return σ = (V, Eπ ) ▷ Precedence forest 18: end function 2:

S

Method

Top-10

Recall@All

Recall@1600

Closeness Closeness (pruned) Betweenness Betweenness (pruned) PPR [26, 43] PPR [26, 43] (pruned) Earliest-temporal order Earliest-temporal order (pruned)

0.0% 0.0% 0.0% 6.2% 0.0% 6.2% 0.0% 0.0%

12.5% 12.5% 18.8% 18.8% 31.2% 31.2% 6.2% 12.5%

0.60 0.58 0.60 0.58 0.60 0.58 0.60 0.58

0.33 0.31 0.38 0.36 0.44 0.42 0.41 0.38

LOGOS (N = 16)

31.2%

75.0%

0.72

0.55

LOGOS (N = 25)

20.0%

60.0%

0.76

0.46

Table 6: Top-k (k ∈ {1, 10}) reachability and recall for graph baselines vs. LOGOS on open-source software incidents. Recall@1600 is identical to Recall@All (1.00), hence not shown. Hub-node pruning yields identical performance across all baselines and is omitted for brevity.

(timestamp, subsystem, severity, text); (2) a semantic severity elevation rule set targeting embedded error keywords and central orchestrator subsystems; (3) entity extraction patterns (e.g., config_store UUIDs in virtual infrastructure, TraceIDs/SpanIDs in TrainTicket); and (4) a hub-node blocklist G specifying ubiquitous infrastructure handles. Intermediate Persistence & Storage. Parsed events and entities from log ingestion are streamed into per-subsystem SQLite shards in write-batch flushes of 5,000 items. This sharded write bounds ingestion memory to a flat RSS footprint regardless of raw log scale N. The normalized event templates E with <ENTITY> placeholders are computed per log line and stored in the database. Indexes on severity and timestamps enable fast window queries over faults (N ′ ) during progressive onset tracking, while raw log files remain on disk for lazy parameter resolution. The constructed precedence forests σ—comprising entities, event templates, and precedence edges—are persisted in the database layer for triage.

6

Rank-1

Method

Rank-1

Top-10

Recall@All

Closeness Betweenness PPR [26, 43] Earliest-temporal order

33.3% 33.3% 33.3% 33.3%

33.3% 33.3% 33.3% 91.7%

1.00 1.00 1.00 1.00

LOGOS

83.3%

100.0%

1.00

evaluated using Google’s gemini-3.1-pro-preview model via the Gemini Enterprise API endpoint on Vertex AI (temperature T = 0.1, default decoding parameters). Our evaluation answers five core questions: (1) SearchSpace Bounding: How effectively does LOGOS isolate ground-truth root causes while eliminating background noise (§6.1)? (2) Diagnostic Utility: Can precedence forests enable zero-shot LLM root-cause identification without domain artifacts (§6.2)? (3) Early Detection: Does progressive onset tracking provide actionable lead time and alert reduction (§6.3)? (4) Sensitivity & Ablation: How do LOGOS’s parameter settings and individual design decisions impact recall, compression, and diagnostic accuracy (§6.5)? (5) System Overhead: What compute and memory runtime costs does LOGOS impose (§6.6)?

Evaluation

6.1

Our work aims to address a key pain point of enterprise operators facing black-box outages: the lack of domain artifacts to diagnose incidents. This section evaluates how effectively LOGOS closes this gap by utilizing strictly raw logs across 25 enterprise outages and 12 open-source software incidents. All evaluations are conducted on a VM with 8 vCPUs, 256 GB RAM, running Ubuntu 22.04 LTS. LLM interpretability is

Forest Recall and Accuracy

To explain how a root cause leads to a symptom, the precedence forest must capture not only the cause and terminal symptom, but also intermediate faults—mirroring a support engineer’s diagnostic process. Failing to capture these intermediate faults degrades recall, while placing them in trees ranked late in the forest degrades accuracy by increasing the number of candidate trees an operator must inspect.

9

To evaluate recall and accuracy, we extract all impacted entities documented in vendor incident diagnoses and opensource post-mortems as ground truth (GT). Recall measures the fraction of GT terms (entity values and event metadata) retained in the extracted forest. Severity elevation isolates GT faults in 24 of 25 enterprise incidents, establishing an empirical recall ceiling of 0.96 on enterprise telemetry (versus 1.00 on open-source benchmarks); the one incident without isolated GT faults is a severity-elevation miss (1 of 25), and a further 3 of 25 incidents have zero recall because maximal cascade selection discards their root-cause subgraph (§8), which together with partial retention in the remaining incidents yields the 0.76 mean recall. Notably, all four of these zero-recall enterprise incidents (the severity-elevation miss and the three maximal-cascade-selection cases) stem from third-party components, demonstrating that unannotated third-party log streams present the steepest boundary for logonly correlation. To evaluate accuracy, we order trees in the precedence forest chronologically by their root node’s earliest fault timestamp. We quantify accuracy via Top-k reachability—the fraction of incidents where a GT-matching tree ranks within the first k roots examined. Comparative Baseline Selection. We compare LOGOS against four canonical baselines that operate directly on raw telemetry without requiring pre-existing dependency maps or repeated observations (unlike Sherlock [4]): (1) Closeness Centrality (shortest-path distance sums), (2) Personalized PageRank (random walks with seed teleportation) [26, 43], (3) Betweenness Centrality (shortest-path traversal density), and (4) Earliest-Temporal Order (first-seen timestamp sorting). Proprietary frameworks (e.g., RCACopilot, AIDA) are excluded as they are closed-source. We similarly exclude log-anomaly baselines (DeepLog [11], LogBERT [16], LogAnomaly [33]): they mask entity parameters into wildcards and require healthy baselines this evaluation’s incidents lack (see the LogBERT paragraph below). For strict experimental parity, all graph baselines execute on the exact same candidate graph constructed by LOGOS following severity elevation. Table 5 summarizes performance across enterprise virtual infrastructure incidents. Due to O(M 2 ) memory scaling (§2), graph baselines run out of memory on 9 enterprise incidents, completing on only 16 tractable bundles. Across them, overall baseline recall (Recall@All) is identical across methods within each variant (0.60 raw, 0.58 hub-node pruned) because all four rank the same underlying entity set. This recall remains capped below LOGOS’s (0.72 on N = 16) because the baselines rank entities exclusively, ignoring ground-truth embedded in event pattern text. Baseline Top-10 reachability remains low (≤ 31.2%) because centrality metrics consistently favor high-volume, central subsystems—a topological bias that hub-node pruning only marginally mitigates. Earliesttemporal ordering similarly degrades when root-cause events occur later in the incident window.

By preserving its O(M) bipartite structure, LOGOS evaluates across all N = 25 incidents. Because it ranks precedence trees rather than flat entity lists, any path from an impacted entity back to its root provides a complete fault propagation chain of entities and associated log events. Consequently, LOGOS achieves 60.0% Top-10 reachability and 0.76 overall recall (0.46 prompt-capped at 1,600 nodes) across all 25 incidents—nearly double the accuracy of graph baselines, approaching the 0.96 candidate fault isolation ceiling. On open-source benchmarks (Table 6), centrality baselines exhibit the same topological bias toward high-volume, central subsystems (33.3% Top-10 reachability). In contrast, earliesttemporal ordering reaches 91.7% Top-10 reachability, reflecting stronger chronological signaling in these workloads. LOGOS enforces temporal precedence over the bipartite entityevent graph without incurring centrality bias, achieving 83.3% Rank-1 and 100.0% Top-10 reachability. LogBERT: Healthy Baseline Requirement. To empirically ground the exclusion of stationary healthy-baseline methods, we evaluated LogBERT [16] across four datasets spanning from its intended operating regime to our target environment. To mirror live incident response, LogBERT was trained without synthetic baselines or dataset balancing. On HDFS [45], which provides pre-partitioned block identifiers and a clean healthy-anomalous split, LogBERT achieves F1 = 0.69 (P = 0.96, R = 0.54), somewhat below the published results [16]. We exclude HDFS from LOGOS’s primary evaluation because its single-subsystem failure model does not exercise cross-subsystem correlation. Outside this controlled setting, LogBERT fails to generalize. On OpenStack, severe class imbalance (0.1% anomalies) causes LogBERT to converge to the majority normal class (99.9% accuracy, F1 = 0.00). On TrainTicket, post-mortem log snapshots lack the pre-incident steady state required to learn a decision boundary, leading LogBERT to label all 3,412 evaluated sequences as anomalous (F1 = 0.00). On real enterprise field incidents, including the upgrade incident (§3), LogBERT fails across every incident tested. This progression (strong performance on the lone benchmark matching its baseline assumption, complete failure on every dataset violating it) is the empirical counterpart to this section’s argument: the assumption itself, not implementation quality, breaks in enterprise environments.

6.2

Interpretability of Precedence Forests

To evaluate whether precedence forests enable domainindependent root-cause diagnosis, we measure zero-shot Diagnosis Quality (DQ) and response consistency. A response earns a Full Diagnosis if the LLM correctly identifies groundtruth (GT) entities and the root GT subsystem, and a Partial Diagnosis if it identifies the root GT subsystem even when specific GT entities are omitted or truncated; otherwise it is a Miss. We evaluate DQ by prompting Gemini using the top 1,600 10

Full Diagnoses in only 4/25 incidents (9/25 with Partial Diagnoses). Because 7-day raw bundles (median 55 GB) exceed context limits, this baseline evaluates a truncated stream of trailing warning+ events, meaning some baseline misses reflect context truncation rather than reasoning failure. Precedence forests increase Full Diagnoses to 10/25—tracking the 0.46 capped-recall ceiling that governs exact entity matches—while post-call subsystem annotations add 10 Partial Diagnoses, reaching 20/25 (80%) overall diagnostic accuracy. On open-source benchmarks, precedence forests raise overall accuracy from 10/12 to 12/12 (100%). This gain is notable because raw open-source log streams already fit within Gemini’s context window, proving structural distillation adds diagnostic value beyond simple token compression; the remaining gap on enterprise incidents also reflects proprietary vendor binaries omitting intermediate state that open-source stack traces expose directly. Subsystem ownership further explains this diagnostic boundary: LOGOS achieves 100% diagnostic accuracy (9/9 Full + Partial) on incidents originating within the core infrastructure software, whereas accuracy on emergent third-party component failures is 69% (11/16). Crucially, all 5 enterprise Misses occur on third-party software, where proprietary vendor binaries omit intermediate runtime state. Response Consistency & Repeatability. Beyond singleexecution accuracy, precedence forests significantly improve diagnostic repeatability across independent runs. Evaluating three independent trials per method on the matched population of 20 enterprise incidents (60 trials per condition), precedence forests sustain at least a Partial Diagnosis across all three trials in 18 of 20 incidents (90%), compared to only 7 of 20 (35%) for raw-log prompting. Across all 60 trial executions, precedence forests deliver at least a Partial Diagnosis in 95.0% of runs (57/60)—with 46.7% achieving a Full Diagnosis (28/60)—whereas raw-log prompting succeeds in only 35.0% of runs (21/60) and reaches a Full Diagnosis in 13.3% (8/60). While raw logs exhibit high nominal score agreement (17/20), this is driven by consistent failure (scoring zero across all three trials in 13 incidents); in contrast, precedence forests provide high-yield, repeatable diagnostic signal without trial-to-trial degradation.

Table 7: Diagnosis Quality (DQ) across enterprise and open-source software incidents. Evaluated using Gemini on raw warning+ log text versus LOGOS’s precedence forest capped at 1,600 nodes. Full Diagnosis indicates the response identified ground-truth (GT) entities together with the GT subsystem. Partial Diagnosis indicates that while the specific GT entities were omitted or truncated, the correct GT subsystem was identified. Method

Full Diagnosis

Full + Partial

4 / 25 10 / 25

9 / 25 20 / 25

Open-Source Software Logs Gemini (Baseline) 9 / 12 LOGOS + Gemini 10 / 12

10 / 12 12 / 12

Enterprise Incidents Gemini (Baseline) LOGOS + Gemini

forest nodes. This 1,600-node prompt budget retains 0.46 enterprise recall and 1.00 open-source recall within the prompt itself (Tables 5–6), imposing a hard ceiling on Full Diagnoses because the model can only quote entities present in its prompt context. To evaluate accuracy beyond this budget constraint, we apply a post-call subsystem-impact annotation: LOGOS walks each candidate’s descendant subtree in the complete, uncapped precedence forest stored in the database and appends its real subsystem footprint to the output. A response is credited as a Partial Diagnosis if this augmented, database-verified footprint touches the GT subsystem, even if the specific GT entity was truncated from the 1,600-node prompt budget. Unlike topology-only ablations (§3), every prompt in this evaluation includes each entity’s first and last fault in the forest alongside its structural position as a root or leaf node (see [ROOT_CANDIDATE] and [DEAD_END] tags in Figure 2). The prompt frames the input as a forest of independent trees and leverages the model for semantic reasoning by instructing it to trace forward along each tree until reaching an explicit operational fault—regardless of whether that entity is temporally earliest—to prevent false attribution to benign health checks or initialization events. The prompt enforces a three-step reasoning chain: 1. Intra-Tree Propagation: Connect each independent tree from its entry point to its terminal effect, explaining the step-by-step propagation between them.

6.3

2. Cross-Tree Semantic Linking: Identify semantic links between trees to capture causal ties where entity cooccurrence was not logged.

Reduced and Early Alerting

Alert floods slow down incident detection and response by overwhelming enterprise administrators, allowing developing issues to go unnoticed for days before an outage. To be effective, progressive onset tracking must detect failures early and provide fewer, more meaningful alerts that connect system faults while bounding the diagnostic search space. Each precedence forest constructed during progressive onset tracking acts as a discrete alert—generating two forests per walk (one at onset and another upon convergence). To measure detection earliness, we evaluate the earliest temporal checkpoint at which a precedence forest enables a real LLM

3. Systemic Cause Synthesis: Scan across all trees for recurring subsystems or concepts that explain multiple independent symptoms. Rather than collapsing this reasoning into a single forced answer, the model reports every credible candidate side by side with supporting evidence and confidence scores. Results & Diagnostic Accuracy. As Table 7 shows, Gemini prompted with raw enterprise warning+ logs achieves 11

surface over the same window without LOGOS (“raw alerts”). The earliest maximum-DQ checkpoint is identified by executing an LLM call (gemini-3.1-pro-preview) at every forest alert generated during progressive onset tracking, with raw alerts evaluated at the identical checkpoint to isolate the diagnostic value of precedence forests. At their respective lead-time checkpoints, precedence forests enable a Full Diagnosis in two of five incidents (Cases 1–2) and a Partial Diagnosis in the remaining three (Cases 3– 5). In contrast, raw alerts achieve a Partial Diagnosis in only one incident (Case 2) and fail in the other four—twice constructing confident, false narratives from coincidental background events (Cases 1 and 5). Table 9 summarizes these diagnostic outcomes at each incident’s lead-time checkpoint.

Table 8: Alert lead times, volume, and search space reduction compared to enterprise reality (last 7 days of logs). Lead times are evaluated on the 20 incidents with a Full or Partial Diagnosis, reported as the earliest checkpoint at which a real LLM call on the precedence forest achieves its best diagnosis quality for that incident (§6.4). Enterprise alert volume reflects N = 22 bundles that recorded alerts shown to the administrator. LOGOS metrics span all N = 25 enterprise incidents. Metric

Enterprise

LOGOS

Impact

Lead Time

Reactive (0h)

Median 16h (Mean 25.1h)

+0h to +144h

Alert Volume

Median 1,658

Median 12

124× median per-incident reduction

Search Space

Median 55 GB

Full: 133.8 MB Forest@1600: 1.4 MB

99.8% reduction

Case 1: Latent config-store persistence failure during hypervisor upgrade. In this incident, the outage manifested at t0 as VM migration failures following a hypervisor upgrade. The root cause was a latent product defect that prevented configuration updates from being persisted to disk, causing config_store to restore a stale snapshot upon reboot (§3). Prior to t0 , the incubating fault emitted background log alerts. At t0 − 80h and t0 − 56h, the LLM reading raw alerts identified only routine automated management logins, correctly classifying them as benign. In contrast, precedence forests identified the impacted subsystems as early as t0 −80h, achieving a Partial Diagnosis. At t0 − 32h, the raw-alert diagnosis shifted to a false narrative, attributing the alerts to an out-ofband hardware-management daemon and network interface flapping. At t0 − 18h (the earliest maximum-DQ checkpoint), LOGOS’s precedence forest isolated the fault’s signature to config_store. It surfaced config_store’s read/parse errors, a virtual switch port state-save failure, and a VM diskcache failure to achieve a Full Diagnosis 18 hours prior to the reboot. The raw-alert diagnosis at t0 − 18h remained stuck on the hardware false narrative. At t0 , the outage occurred and the precedence forest maintained its Full Diagnosis anchored on config_store. In contrast, the raw-alert diagnosis abandoned the hardware story only to construct a second false narrative, blaming an in-progress hypervisor image upgrade and disabled signature verification. Across five checkpoints from t0 − 80h through t0 , raw-alert prompting constructed two false narratives and never identified the actual defect, whereas the precedence forest reached a Full Diagnosis at t0 − 18h and kept it through t0 .

call to reach its highest DQ for that incident. To evaluate alert reduction, we compare raw administrator alert volume over a 7-day window against total generated forests. Finally, to establish search-space reduction, we compare total 7-day log event volume against the event count in the final, maximal precedence forest. Table 8 summarizes our findings across the 25 enterprise incidents. For the 20 incidents with a Full or Partial Diagnosis (Table 7), LOGOS achieves a median diagnosis-verified lead time of 16 hours (mean 25.1h) before the reported incident timestamp (t0 ). Crucially, this lead time is verified empirically by evaluating LLM DQ (§6.2) across every forest alert generated during progressive onset tracking (§6.4), proving that enterprise failures incubate long before escalation and can be correctly diagnosed hours in advance. Across 22 incidents with available alert telemetry, enterprise environments logged a median of 1,658 raw alerts in their final 7 days. In contrast, LOGOS consolidates these streams into a median of 12 precedence forests over the same period (a median per-incident reduction of 124×), structuring individual alerts into coherent failure cascades. Finally, raw log bundles (median 55 GB, ∼2.5 million entries) are compressed into precedence forests with a median size of 133.8 MB (1.4 MB when capped at 1,600 nodes for LLM context), delivering a median searchspace reduction of 99.8%. The next subsection details five representative incidents, comparing precedence forests against a raw operator alert stream at the same lead-time checkpoint.

6.4

Case Studies: Early Detection

Case 2: Intermittent storage adapter disconnections and target path flapping. In this incident, the outage manifested at t0 as severe storage access failures across the host. The root cause was command failures on a specific host bus adapter (HBA), which induced resource-lock exhaustion and memoryadmission failures. Prior to t0 , the incubating fault generated recurring log alerts as a SAN target device repeatedly dropped

This subsection grounds our 16-hour median diagnosisverified lead time in five representative enterprise incidents, evaluating DQ at each incident’s earliest maximum-DQ checkpoint across two representations: (1) LOGOS’s precedence forest, evaluated using the prompting and post-call subsystemimpact annotation methodology established in §6.2, and (2) the raw stream of log alerts an enterprise console would 12

Table 9: Early-detection case studies. Lead time denotes hours before the reported incident timestamp (t0 ) at which LOGOS’s precedence forest isolates the fault signature to reach its earliest maximum-DQ checkpoint (§6.4), with raw alerts evaluated at the identical checkpoint. Miss indicates failure to surface the ground-truth cause; false narrative denotes an active misdirection where raw-alert prompting constructs an incorrect causal story from coincidental background alerts. Incident

Lead Time

Forest (at lead time)

Raw alerts (at lead time)

Latent config-store persistence failure during hypervisor upgrade (§3)

18h

Full

Miss (false narrative)

Intermittent storage adapter disconnections and target path flapping

26h

Full

Partial

Recurring fabric driver memory allocation failure and command queue exhaustion

144h

Partial

Miss

Storage-volume quiesce-timeout notification registration fault

86h

Partial

Miss

Session-scheduler configuration fault masked by coincidental network adapter flapping

18h

Partial

Miss (false narrative)

and reconnected, incrementing its target identifier on every reconnect. At t0 − 26h (the earliest maximum-DQ checkpoint), LOGOS’s precedence forest isolated this incubatory signature by linking the resource-lock and memory failures directly to recurring command errors on the affected adapter. This explicitly named the adapter and target device to achieve a Full Diagnosis 26 hours before t0 . In contrast, the LLM prompted with raw alerts over the same window independently detected path flapping. However, it attributed the alerts broadly to generic storage-network instability without pinpointing the specific adapter, yielding a Partial Diagnosis. At t0 , both representations maintained their relative accuracy: the precedence forest retained its Full Diagnosis on the specific adapter, while the raw-alert diagnosis continued to report broad storage instability.

this remained a Partial Diagnosis because the ground-truth entities were missing from the LLM response. Case 4: Storage-volume quiesce-timeout notification registration fault. In this incident, the outage manifested at t0 as cascading VM eviction failures and storage unmap errors during backup operations. The root cause was a storage volume failing to register for quiesce-timeout notifications, which freeze VM disk I/O during backup snapshots. A separate volume-format verification failure also occurred on an unrelated volume. Prior to t0 , background management operations generated sporadic warning alerts. At t0 − 86h (the earliest maximum-DQ checkpoint), LOGOS’s precedence forest linked the volume-format verification alert to the groundtruth storage subsystem to achieve a Partial Diagnosis. However, its subsystem-impact annotation (30 subsystems across 613 entities) flagged the candidate as a broad shared dependency rather than an isolated root cause. In contrast, the LLM prompted with raw alerts identified only routine management activity and yielded no diagnostic signal. By t0 − 14h and at t0 , the signal was no longer retained as the forest changed across later checkpoints. Unlike the other case studies, in Case 4 an early partial signal did not persist through t0 .

Case 3: Recurring fabric driver memory allocation failure and command queue exhaustion. In this incident, the outage manifested at t0 as total storage path loss and host isolation. The underlying cause was a third-party storage fabric driver that repeatedly failed to allocate an internal memory buffer and exhausted its command queue. Over six days prior to t0 , the incubating driver fault emitted sporadic warning alerts as storage paths dropped and degraded path redundancy. At t0 − 144h (the earliest maximum-DQ checkpoint), LOGOS’s precedence forest linked a storage-queue-depth configuration alert to the adapter’s throttling behavior. Its post-call subsystem-impact annotation isolated the storage-path configuration subsystem (37 descendant entities) to achieve a Partial Diagnosis 6 days before t0 . The raw-alert diagnosis at t0 − 144h and across six subsequent pre-incident checkpoints missed the fault entirely, misattributing alert volume to an unrelated storage-I/O accounting feature. Only at t0 − 2h did the raw-alert diagnosis detect the path resets. At t0 , the precedence forest connected the fabric driver’s memory-allocation failure directly to the resulting storage disconnects, although

Case 5: Session-scheduler configuration fault masked by coincidental network adapter flapping. In this incident, the outage manifested at t0 as widespread management console unresponsiveness. The root cause was a missing hostside session-scheduler configuration file, which caused silent management-service refresh failures across ten independent user sessions. Prior to t0 , the missing file generated recurring background alerts across active sessions, while several physical network adapters coincidentally flapped during the same window. At t0 − 18h (the earliest maximum-DQ checkpoint), LOGOS’s precedence forest linked the session-scheduler alerts recurring across all ten sessions. Its post-call subsystem13

Table 10: Sensitivity to Correlation Window (Tc ). Evaluated across 5 enterprise incidents keeping Tw = 2.0h and Kwalk = 15 constant. Increasing Tc expands average forest node size while yielding modest gains in prompt-capped recall (Recall@1600). Correlation (Tc )

Window Top-10

1.0h 2.0h (Default) 8.0h 24.0h

60.0% 80.0% 80.0% 80.0%

Table 11: Sensitivity to Window Size (Tw ). Evaluated across 5 enterprise incidents keeping Tc = 2.0h and Kwalk = 15 constant. Expanding Tw dramatically suppresses alert volume, but larger windows over-aggregate events, expanding forest size and degrading reachability.

Recall@All

Recall@1600

Mean Nodes

Window Size Top-10 (Tw )

0.87 0.87 0.87 0.87

0.61 0.61 0.66 0.66

11,426.5 11,979.7 14,000.7 14,328.1

1.0h 2.0h (Default) 8.0h 16.0h

Recall@1600

Mean Nodes

Alerts / Incident

0.87 0.87 0.85 0.85

0.61 0.61 0.61 0.56

11,182.9 11,979.7 17,526.7 17,791.3

48.4 26.2 8.4 5.4

Table 12: Sensitivity to Walk Cap (Kwalk ). Evaluated across 5 enterprise incidents keeping Tc = 2.0h and Tw = 2.0h constant. Extending walk cap allows transitive closure to naturally converge, consolidating events into fewer alerts and improving overall recall.

impact annotation isolated the host management-agent subsystem (55 entities) to achieve a Partial Diagnosis. In contrast, the LLM prompted with raw alerts at the identical pre-incident checkpoint constructed a false narrative. It attributed the preincident alerts to coincidental physical link flapping across the network adapters. At t0 , the precedence forest maintained its Partial Diagnosis based on session recurrence, whereas the raw-alert diagnosis persisted in its false narrative.

6.5

80.0% 80.0% 60.0% 60.0%

Recall@All

Kwalk Cap

Top-10

5 steps 80.0% 15 steps (De- 80.0% fault) 25 steps 80.0%

Sensitivity and Ablations

To enable effective diagnosis, LOGOS must fulfill three core operational objectives: (1) maximize recall under aggressive search-space reduction to fit LLM context limits, (2) suppress redundant alerts to mitigate operator fatigue, and (3) construct interpretable branching structures that explicitly capture fault propagation. We evaluate parameter sensitivity to confirm robustness and systematically ablate key design choices across all N = 25 enterprise incidents (Table 13) to quantify their individual contributions to these goals. Parameter Sensitivity. We evaluated parameter sensitivity across correlation window Tc , onset window Tw , and session walk cap Kwalk using a 5-incident enterprise subset, reported next. The sweeps confirm that our defaults (Tc = 2.0h, Tw = 2.0h, Kwalk = 15) achieve reasonable trade-offs: Tc bounds edge expansion, Tw balances onset responsiveness against alert volume, and Kwalk prevents alert fragmentation by allowing transitive closures to reach natural completion. Open-source benchmarks remain unaffected because their shorter execution timelines fit comfortably within these bounds. Tables 10–12 report these sweeps. All metrics report mean values across the 5 bundles. In addition to standard recall and reachability (§6.1), we track average forest size (Mean Nodes) and alert volume (Alerts/Incident). While Tw and Kwalk directly govern progressive alert generation, Tc strictly bounds edge formation within the bipartite graph. As correlation window Tc increases, events that are distant in time become eligible for inclusion in the bipartite entityevent graph. As a result, larger forests are formed as shown in Table 10; overall recall remains constant (0.87) while Recall@1600 increases slightly (0.61 → 0.66). On the other hand, the onset window Tw trades off finegrained onset detection against alert volume (Table 11).

Recall@All

Recall@1600

Mean Nodes

Alerts / Incident

0.87 0.87

0.61 0.61

9,334.3 11,979.7

31.6 26.2

0.90

0.61

12,765.3

26.0

Smaller Tw values allow failure onset to be detected early, whereas larger Tw values combine more unrelated events into the same forest, reducing Top-10 reachability (80.0% → 60.0%). While Tw = 1.0h achieves identical recall to Tw = 2.0h, it nearly doubles alert generation (48.4 vs. 26.2 alerts/incident), making Tw = 2.0h the practical default. Finally, the walk cap Kwalk controls maximum depth during progressive onset tracking. As a failure spreads across time steps, the walk continues until the transitive closure naturally terminates—meaning no new correlated events appear. If Kwalk is too low, the walk is forcibly truncated and restarted in a new session later, creating fragmented alerts. Raising Kwalk allows walks to reach natural completion, expanding forest size while consolidating related activity into fewer alerts (31.6 → 26.0 alerts/incident) and improving overall recall (0.87 → 0.90 at Kwalk = 25, Table 12). While these defaults (Tc = 2.0h, Tw = 2.0h, Kwalk = 15) serve as baseline thresholds for batch evaluation, production deployments operating over continuous streaming logs must tune these bounds based on real-time stream latency and alert-volume budgets. Architectural Ablations. Disabling individual design choices across all N = 25 enterprise incidents demonstrates their necessity (Table 13): Bounded transitive closure drives search-space reduction: a Tc = 2 h window filters a median of 85.7% (mean 69.5%) of background events, preserving 0.76 mean recall. We do not evaluate a fully unbounded (Tc = ∞) variant: unlike the memory exhaustion that caps graph baselines (§2), an unbounded window instead risks merging temporally disjoint but structurally connected events into one component, polluting the cascade with unrelated history. Widening Tc from 1 h to 24 h (Table 10 above) yields only modest Recall@1600 14

Table 13: Ablation Study Summary. Impact of each design decision on search space reduction, recall, and diagnostic performance. Design Decision

Ablation Variant

Search Space Reduction (N=25)

Recall@All

Recall@1600

Top-10 / DQ

Primary Impact

Bounded transitive closure (Tc )

Production (Tc =2h)

Events: 85.7% med / 69.5% mean

0.76

0.46

60.0%

Search space reduction only

Severity elevation

Real → No subsystem promotion

N/A

0.96 → 0.49

N/A

N/A

Recall critical

Progressive onset tracking

Flat 7-day → Windowed

N/A

0.59 → 0.76

0.31 → 0.46

52.0% → 60.0%

Recall & reachability gain

Hub-node pruning

ON → OFF

Entities: 2.8% med / 14.9% mean

0.76 → 0.77

0.46 → 0.46

DQ (Full): 10/25 → 8/25

Search space reduction; modest DQ effect

Parent-edge assignment rule

Nearest → Earliest

Graph structure only

0.76 → 0.76

0.46 → 0.46

24.2% → 97.5% leaf nodes

Recall neutral; graph interpretability

Forest structural tagging

OFF → ON

Graph structure only

0.76 → 0.76

0.46 → 0.46

DQ (Full): 5/25 → 10/25

Recall neutral; large DQ gain

gains (0.61 → 0.66) while continuing to expand forest size. Severity elevation is critical for recall; disabling its subsystemlevel severity promotion (one of its two mechanisms) causes recall to drop from 0.96 to 0.49, and disabling its log-text keyword override alone drops it to 0.65 (both measured on the raw 168h candidate pool across all N = 25 incidents, counting the one incident whose ground truth is not isolated as zero recall), because true faults that appear to be benign are dropped before graph construction. Progressive onset tracking (Tw = 2h) replaces a flat 7-day log sweep and boosts overall recall from 0.59 to 0.76 (0.31 to 0.46 capped) and increases Top-10 reachability from 52.0% to 60.0% by isolating the true onset window. Hub-node pruning removes ubiquitous hub entities and reduces the entity search space by a median of 2.8% (mean 14.9%); disabling pruning slightly increases raw graph recall (0.76 to 0.77), but it modestly degrades LLM DQ (Full Diagnoses drop from 10/25 to 8/25) because unpruned hub nodes appear as spurious root candidates. The current prompt’s explicit per-candidate semantic fault check makes the model robust to unpruned hub noise, though pruning still helps at the margin. The parent-edge assignment rule is recall-invariant in our measurements (0.76 uncapped / 0.46 capped), but nearestpreceding parent selection yields a far more informative graph structure than earliest-preceding selection. Under earliestpreceding logic, the initial root entity acts as a hub, forcing intermediate faults to attach as direct leaves; the fraction of leaf nodes rises from 24.2% to 97.5%, losing propagation information. Forest structural tagging, which adds structural tags ([ROOT_CANDIDATE] and [DEAD_END]) to the prompt, is recall-neutral (0.76 / 0.46) and produces a large DQ gain under the current prompt (Full Diagnoses rise from 5/25 to 10/25, while Full + Partial rises from 15/25 to 20/25; Partial Diagnoses alone hold flat at 10/25, since the gain is a mix of Misses converting directly to Full Diagnoses and borderline Partial Diagnoses sharpening into Full ones), confirming that

tags meaningfully guide LLM reasoning for this template.

6.6

Compute and Memory Overheads

To evaluate computational overheads, we measured processing wall-time (in hours) and peak memory usage (in gigabytes) across all 37 benchmark datasets. Figure 3 illustrates performance across the two pipeline stages plotted against total raw log lines N. The left panel shows log ingestion overheads. Execution wall-time scales linearly with N (r = 0.99) because ingestion performs a single-pass parsing step over each raw log line. Enterprise datasets exhibit a median ingestion time of 2.9 minutes (0.4–5.4 seconds for open-source datasets), reaching a maximum of 6.4 hours on the largest dataset (156.4M lines). Peak memory stays strictly bounded between 18.7 MB and 479.9 MB because logs are processed in fixedsize batches rather than loaded into memory all at once. The right panel shows graph construction overheads. Both wall-time and peak memory correlate closely with input scale N (r = 0.92–0.93) because progressive onset tracking evaluates multiple candidate onset windows across the log corpus. For enterprise datasets, median graph construction wall-time is 1.6 minutes (0.96 seconds for open-source) and peaks at 28.9 minutes on the largest corpus. Peak memory reaches 4.17 GB at the median and caps at 48.05 GB in the single worst case, remaining well within host memory capacity.

7

Related Work

Over the past two decades, a rich body of diagnostic research has addressed failure localization. In the context of this work, prior studies broadly fall into two main paradigms: (1) Domain-Augmented Methods, which rely on preexisting topology maps or CMDBs [3, 23, 34, 46], historical incident tickets and runbooks [8, 10, 22, 37], active instrumentation [2, 35, 38, 47], or graph-based ranking over metric/trace topologies [7, 25, 26, 43]; and (2) Statistical & Performance Inference Methods, which infer causal dependencies or isolate execution anomalies us15

Figure 3: Compute and memory overheads, split by pipeline stage. Both panels plot wall-time in hours (black, left y-axis) and peak memory in GB (orange, right y-axis) against total raw log lines N on a log-log scale across all 37 benchmark datasets (25 enterprise circles, 12 open-source triangles). Left: Log Ingestion, where wall-time scales linearly with N (r = 0.99) while peak memory remains bounded (18.7–479.9 MB) due to fixed-batch streaming. Right: Graph Construction, where overheads correlate with input scale N through window exploration volume (r = 0.92–0.93), reaching a peak memory ceiling of 48.05 GB in the single worst case. ing log sequence probabilities, statistical delay distributions, or transaction success rates [1, 4, 11, 16, 33, 45]. LOGOS occupies the opposite extreme: it bounds the search space in black-box environments where neither domain artifacts, historical incident corpora, active instrumentation, nor healthy operational baselines exist. In this sense, its underlying objective is distinct: it investigates the extent to which noisy log data alone can encode failure propagation. Domain-Augmented Methods. Among diagnostic paradigms that exploit domain artifacts, LOGOS resembles graph-based inference algorithms [7, 25, 26, 43] in that it relies on the premise that failures propagate along structural dependencies best captured as a directed graph. It differs from them by deriving these structural dependencies entirely post-hoc from noisy log data rather than relying on high-fidelity time-series metrics, active network probing, or pre-existing topology maps. LOGOS is also conceptually inspired by distributed tracing and request-reconstruction frameworks [5, 13, 24, 32, 38]. While explicit tracing systems (e.g., Dapper [38], XTrace [13], Canopy [24]) require unbroken TraceID header propagation, and schema-driven tools (e.g., Magpie [5]) depend on pre-authored event schemas to join local handles, LOGOS operates on unmodeled, local identifiers (e.g., task handles, disk IDs) that are frequently noisy, fragmented, or missing. LOGOS overcomes this fragmentation without schemas or headers by exploiting identifier co-occurrence across intermediate log events to stitch failure paths together transitively across subsystem boundaries. Other diagnostic frameworks rely on explicit request instru-

mentation, static code analysis, fault injection, or pre-built network topology maps [2,3,6,34,35,38,47]. Most closely related in intent to our alert-reduction mechanism is SkyNet [46], which aggregates alert floods from passive monitoring telemetry; however, SkyNet requires known network topology and hierarchy maps to group alerts, whereas LOGOS performs event correlation completely independent of system topology. Finally, LOGOS intersects with recent generative AI and agentic AIOps frameworks [8, 22, 36, 37, 42, 44, 49]. Like AIDA [44] and Xihe [36], LOGOS recognizes that failure propagation is best encoded as a directed graph rather than flat entity lists. However, unlike frameworks requiring preauthored playbooks [22,37] or historical ticket corpora [8,10], LOGOS operates with zero historical domain knowledge. LOGOS complements these frameworks by converting raw log streams into compact precedence forests to provide bounded context for LLMs when playbooks do not exist and raw logs exceed context windows. We do not benchmark directly against agentic LLM-RCA systems: each relies on a closed, organization-specific incident corpus with no public implementation, and faithfully reproducing them would require curated incident-handler libraries and historical ticket archives—artifacts whose absence is this paper’s core premise. Synthesizing such resources would test a different, better-instrumented regime than the zero-prior-knowledge environment LOGOS targets. Statistical & Performance Inference Methods. Within the second paradigm, LOGOS is similar to log-only sequence models [11,16,21,28,33,45,50,51] in that it abstracts raw log text into parameterized event templates. It is also conceptually

16

The Gap to Self-Healing. LOGOS exploits structural and temporal correlation, not causality; leveraging it for automated remediation requires domain reasoning to bridge this gap before executing corrective actions. Telemetry Gaps. When network hardware lacks text logging or adjacent domains use disjoint identifier schemes, transitive closure cannot complete and the precedence forest fractures at the unlinked boundary; silent infrastructure failures remain unrecoverable from logs alone, requiring multi-modal telemetry (topology maps, metric anomalies) to bridge these gaps.

aligned with black-box performance inference frameworks like Aguilera et al. [1] and Sherlock [4], which infer component dependencies from passive telemetry without requiring source code or explicit schemas. LOGOS differs in two ways: it assigns precedence edges directly from single instances of entity co-occurrence (individual log lines carry more than one entity, Nline > 1; Table 3) rather than statistical aggregation across thousands of repeated transactions, and it explicitly leverages dynamic entity identifiers as relational glue rather than masking them as wildcards [19, 29].

9 8

Limitations and Open Problems

Conclusion

This work shows that log-only failure diagnosis holds strong promise in enterprise domains with rich logging. By eliminating a median 99.8% of background noise in a median wall-time of 4.5 minutes while retaining 0.76 mean recall, LOGOS demonstrates that aggressive search-space reduction is achievable on raw text logs alone. Operating on 2-hour log windows, its 16-hour median diagnosis-verified lead time and 124× consolidation into structured, fault-linking alerts establish a viable design point for AIOps: rather than requiring pre-built domain artifacts or historical baselines, its compressed failure graphs support both zero-shot LLM root-cause identification (80% enterprise, 100% open-source; §6.2) and direct operator triage. LOGOS is currently being integrated into the AIOps pipeline of an enterprise cloud provider to automate incident triage and accelerate ticket resolution.

Interactivity. LOGOS executes as a single batch pass over a log bundle, without iterative refinement or operator-guided narrowing mid-investigation. It provides the initial bounded context an interactive agent or human operator begins from, rather than replacing interactive triage itself. Log Parsing. LOGOS abstracts log text into parameterized templates using lightweight vendor integration modules (§5), following standard log abstraction paradigms [18, 27, 31, 48]. This module adds a one-time, per-vendor engineering cost. Incomplete parameter masking can misclassify identical logs as distinct events, inducing template fragmentation that transitive closure overcomes via shared entities. Separately, an uncaptured log-level keyword in 1 of 25 incidents prevented severity elevation from isolating its ground-truth fault, so ground truth is detectable in only 24/25 incidents; this caps mean enterprise recall at 0.96. Maximal Cascade Selection. Isolating the maximal connected component (F ∗ ) maximizes search-space reduction but causes zero recall in 3 of 25 incidents whose root causes resided in secondary subgraphs (distinct from the 1 of 25 severity-elevation miss above; the 0.76 mean recall defined in §6.1 additionally reflects partial recall within incidents); emitting all subgraphs recovers these cases while still yielding a 2.2× net alert reduction. Ground-Truth and Scoring Boundaries. Ground-truth entities and subsystems were reconstructed directly from vendor incident reports and escalation logs rather than synthetic labeling, reflecting real-world operational diagnoses. Our scoring harness enforces strict entity identifier matching for Full Diagnoses to prevent substring false positives; consequently, a response that correctly identifies the root failure mechanism without citing specific entity tokens is conservatively scored as a Partial Diagnosis. Third-Party Subsystem Boundary. Third-party vendor software represents the engine’s primary visibility limit: while LOGOS achieves 100% accuracy (9/9) on native infrastructure faults, accuracy drops to 69% (11/16) on third-party components, accounting for all 5 diagnostic misses. Custom per-vendor parsing modules and targeted severity elevation serve as the primary engineering levers to lift this floor in heterogeneous enterprise deployments.

References [1] Marcos K Aguilera, Jeffrey C Mogul, Janet L Wiener, Patrick Reynolds, and Athicha Muthitacharoen. Performance debugging for distributed systems of black boxes. In Proceedings of the nineteenth ACM symposium on Operating systems principles (SOSP), pages 74–89, 2003. [2] Peter Alvaro, Joshua Rosen, and Joseph M. Hellerstein. Lineage-driven fault injection. In Proceedings of the 2015 ACM SIGMOD International Conference on Management of Data, pages 331–346. ACM, 2015. [3] Behnaz Arzani, Selim Ciraci, Luiz F. O. Chamon, Yibo Zhu, Hongqiang Liu, Jitu Padhye, Boon Thau Loo, and Geoff Outhred. 007: Democratically finding the cause of packet drops. In Proceedings of the 15th USENIX Symposium on Networked Systems Design and Implementation (NSDI), pages 419–435, 2018. [4] Paramvir Bahl, Ranveer Chandra, Albert Greenberg, Srikanth Kandula, David A Maltz, and Ming Zhang. Towards highly reliable enterprise network services via inference of multi-level dependencies. In Proceedings of the 2007 conference on Applications, technologies, architectures, and protocols for computer communications (SIGCOMM), pages 13–24, 2007. 17

[5] Paul Barham, Austin Donnelly, Rebecca Isaacs, and Richard Mortier. Using magpie for request extraction and workload modelling. In Proceedings of the 6th USENIX Symposium on Operating Systems Design and Implementation (OSDI), pages 259–272, 2004.

[15] Haryadi S. Gunawi, Mingzhe Hao, Riza O. Suminto, Agung Laksono, Anang D. Satria, Jeffry Adityatama, and Kurnia J. Eliazar. Why does the cloud stop computing? lessons from hundreds of service outages. In Marcos K. Aguilera, Brian Cooper, and Yanlei Diao, editors, Proceedings of the Seventh ACM Symposium on Cloud Computing, Santa Clara, CA, USA, October 5-7, 2016, pages 1–16. ACM, 2016.

[6] Benjamin Bittner, Marco Bozzano, and Alessandro Cimatti. Automated synthesis of timed failure propagation graphs. In Proceedings of the Twenty-Fifth International Joint Conference on Artificial Intelligence (IJCAI), pages 972–978, 2016.

[16] Haixuan Guo, Shuhan Yuan, and Xintao Wu. Logbert: Log anomaly detection via bert. In 2021 International Joint Conference on Neural Networks (IJCNN), pages 1–8, 2021.

[7] Pengfei Chen, Yong Qi, Pengfei Zheng, and Di Hou. Causeinfer: Automatic and distributed performance diagnosis with hierarchical causality graph in large distributed systems. In Proceedings of IEEE INFOCOM 2014, pages 1887–1895, 2014.

[17] Xiao Han, Shuhan Yuan, and Mohamed Trabelsi. Loggpt: Log anomaly detection via gpt. arXiv preprint arXiv:2309.14482, 2023.

[8] Yinfang Chen, Huaibing Xie, Minghua Ma, Yu Kang, Xin Gao, Liu Shi, Yunjie Cao, Xuedong Gao, Hao Fan, Ming Wen, Jun Zeng, Supriyo Ghosh, Xuchao Zhang, Chaoyun Zhang, Qingwei Lin, Saravan Rajmohan, Dongmei Zhang, and Tianyin Xu. Automatic root cause analysis via large language models for cloud incidents. In Proceedings of the 19th European Conference on Computer Systems (EuroSys), pages 674–688, 2024.

[18] Pinjia He, Jieming Zhu, Zibin Zheng, and Michael R Lyu. Drain: An online log parsing approach with fixed depth tree. In Proceedings of the 2017 IEEE International Conference on Web Services (ICWS), pages 33–40, 2017. [19] Shilin He, Xu Zhang, Pinjia He, Yong Xu, Liqun Li, Yu Kang, Minghua Ma, Yining Wei, Yingnong Dang, Saravanakumar Rajmohan, and Qingwei Lin. An empirical study of log analysis at microsoft. In Proceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering, ESEC/FSE 2022, page 1465–1476, New York, NY, USA, 2022. Association for Computing Machinery.

[9] Datadog, Inc. Datadog. https://www.datadoghq. com/, 2026. Accessed 2026-08. [10] Pradeep Dogga, Karthik Narasimhan, Anirudh Sivaraman, Shiv Kumar Saini, George Varghese, and Ravi Netravali. Revelio: Ml-generated debugging queries for finding root causes in distributed systems. In Proceedings of Machine Learning and Systems (MLSys), volume 4, 2022.

[20] Peng Huang, Chuanxiong Guo, Lidong Zhou, Jacob R Lorch, Yingnong Dang, Murali Chintalapati, and Randolph Yao. Gray failure: The achilles’ heel of cloudscale systems. In Proceedings of the 16th Workshop on Hot Topics in Operating Systems (HotOS), pages 150–155, 2017.

[11] Min Du, Feifei Li, Guineng Zheng, and Vivek Srikumar. Deeplog: Anomaly detection and diagnosis from system logs through deep learning. In Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security (CCS), pages 1285–1298, 2017.

[21] Peng Jia, Shaofeng Cai, Beng Chin Ooi, Pinghui Wang, and Yiyuan Xiong. Robust and transferable log-based anomaly detection. Proc. ACM Manag. Data, 1(1), May 2023.

[12] Dynatrace, Inc. Dynatrace. https://www.dynatrace. com/, 2026. Accessed 2026-08. [13] Rodrigo Fonseca, George Porter, Randy H Katz, Scott Shenker, and Ion Stoica. X-trace: A pervasive network tracing framework. In Proceedings of the 4th USENIX Symposium on Networked Systems Design and Implementation (NSDI), pages 271–284, 2007.

[22] Jiajun Jiang, Weihai Lu, Junjie Chen, Qingwei Lin, Pu Zhao, Yu Kang, Hongyu Zhang, Yingfei Xiong, Feng Gao, Zhangwei Xu, Yingnong Dang, and Dongmei Zhang. How to mitigate the incident? an effective troubleshooting guide recommendation technique for online service systems. In Proceedings of the 28th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering, ESEC/FSE 2020, page 1410–1420, New York, NY, USA, 2020. Association for Computing Machinery.

[14] Supriyo Ghosh, Manish Shetty, Chetan Bansal, and Suman Nath. How to fight production incidents? an empirical study on a large-scale cloud service. In Proceedings of the 13th Symposium on Cloud Computing, SoCC ’22, page 126–141, New York, NY, USA, 2022. Association for Computing Machinery. 18

[23] Siva Kesava Reddy Kakarla, Francis Y Yan, and Ryan Beckett. Diffy: Data-driven bug finding for configurations. In Proceedings of the ACM on Programming Languages (PLDI), volume 8, pages 199–222, 2024.

[32] Jonathan Mace, Ryan Roelke, and Rodrigo Fonseca. Pivot tracing: Dynamic causal monitoring for distributed systems. In Proceedings of the 25th Symposium on Operating Systems Principles (SOSP), pages 378–393, 2015.

[24] Jonathan Kaldor, Jonathan Mace, Michał Bejda, Edison Gao, Wiktor Kuropatwa, Joe O’Neill, Kian Win Ong, Bill Schaller, Pingjia Shan, Brendan Viscomi, Vinod Venkataraman, Kaushik Veeraraghavan, and Yee Jiun Song. Canopy: An end-to-end performance tracing and analysis system. In Proceedings of the 26th Symposium on Operating Systems Principles (SOSP), pages 34–50, 2017.

[33] Weibin Meng, Ying Liu, Yichen Zhu, Shenglin Zhang, Dan Pei, Yuqing Liu, Yihao Chen, Ruizhi Zhang, Shimin Tao, Pei Sun, and Rong Zhou. Loganomaly: Unsupervised detection of sequential and quantitative anomalies in unstructured logs. In Proceedings of the 28th International Joint Conference on Artificial Intelligence (IJCAI), pages 4739–4745, 2019. [34] Sarah Nadi, Richard C. Holt, Ian J. Davis, and Serge Mankovski. Draca: Decision support for root cause analysis and change impact analysis for cmdbs. In Proceedings of the 2009 Conference of the Centre for Advanced Studies on Collaborative Research (CASCON), pages 1–11, 2009.

[25] Srikanth Kandula, Ratul Mahajan, Patrick Verkaik, Sharad Agarwal, Jitendra Padhye, and Paramvir Bahl. Detailed diagnosis in enterprise networks. In Proceedings of the ACM SIGCOMM 2009 Conference, pages 243–254, 2009. [26] Myunghwan Kim, Roshan Sumbaly, and Sam Shah. Root cause detection in a service-oriented architecture. SIGMETRICS Perform. Eval. Rev., 41(1):93–104, June 2013.

[35] Shangshu Qian, Lin Tan, and Yongle Zhang. CSnake: Detecting self-sustaining cascading failure via causal stitching of fault propagations. In Proceedings of the 21st European Conference on Computer Systems (EuroSys ’26). ACM, 2026.

[27] Van-Hoang Le and Hongyu Zhang. Log parsing with prompt-based few-shot learning. Proceedings of the 45th International Conference on Software Engineering (ICSE), pages 2438–2449, 2023.

[36] Yanyu Ren, Xianshang Lin, Chenxu Wang, Li Chen, Shuai Wang, Kaihui Gao, Dan Li, Yunfeng Bai, Chen Tian, Xinlei Zhang, Yunguang Li, Tao Lin, and Ennan Zhai. Networked Agent Memory and Causality Representation: Experiences towards Interpretable CloudScale Root-Causing, page 787–808. Association for Computing Machinery, New York, NY, USA, 2026.

[28] Xiaoyun Li, Pengfei Chen, Linxiao Jing, Zilong He, and Guangba Yu. Swisslog: Robust and unified deep learning based log anomaly detection for diverse faults. In Proceedings of the 2020 IEEE 31st International Symposium on Software Reliability Engineering (ISSRE), pages 92–103, 2020.

[37] Manish Shetty, Chetan Bansal, Sai Pramod Upadhyayula, Arjun Radhakrishna, and Anurag Gupta. Autotsg: learning and synthesis for incident troubleshooting. In Proceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering, ESEC/FSE 2022, page 1477–1488, New York, NY, USA, 2022. Association for Computing Machinery.

[29] Zhenhao Li, Chuan Luo, Tse-Hsun Chen, Weiyi Shang, Shilin He, Qingwei Lin, and Dongmei Zhang. Did we miss something important? studying and exploring variable-aware log abstraction, 2023. [30] Qingwei Lin, Hongyu Zhang, Jian-Guang Lou, Yu Zhang, and Xuewei Chen. Log clustering based problem identification for online service systems. In Proceedings of the 38th International Conference on Software Engineering Companion (ICSE Companion), pages 102–111, 2016.

[38] Benjamin H Sigelman, Luiz Andre Barroso, Mike Burrows, Pat Stephenson, Manoj Plakal, Donald Beaver, Saul Jaspan, and Chandan Shanbhag. Dapper, a largescale distributed systems tracing infrastructure. Technical report, Google, 2010.

[31] Yudong Liu, Xu Zhang, Shilin He, Hongyu Zhang, Liqun Li, Yu Kang, Yong Xu, Minghua Ma, Qingwei Lin, Yingnong Dang, Saravan Rajmohan, and Dongmei Zhang. Uniparser: A unified log parser for heterogeneous log data. In Proceedings of the ACM Web Conference 2022, WWW ’22, page 1893–1901, New York, NY, USA, 2022. Association for Computing Machinery.

[39] Splunk Inc. Splunk. https://www.splunk.com/, 2026. Accessed 2026-08. [40] P. C. Sruthi, Zinan Guo, Deming Chu, Zhengyan Chen, and Yongle Zhang. Demystifying the fight against complexity: A comprehensive study of live debugging activities in production cloud systems. In Proceedings of the 2024 ACM Symposium on Cloud Computing, SoCC ’24, 19

[49] Xiao Zhang, Qi Wang, Mingyi Li, Yuan Yuan, Mengbai Xiao, Fuzhen Zhuang, and Dongxiao Yu. TAMO:FineGrained Root Cause Analysis via Tool-Assisted LLM Agent With Multi-Modality Observation Data in CloudNative Systems . IEEE Transactions on Services Computing, 18(06):4221–4233, November 2025.

page 341–360, New York, NY, USA, 2024. Association for Computing Machinery. [41] Robert Endre Tarjan. Efficiency of a good but not linear set union algorithm. Journal of the ACM, 22(2):215– 225, 1975. [42] Zefan Wang, Zichuan Liu, Yingying Zhang, Aoxiao Zhong, Jihong Wang, Fengbin Yin, Lunting Fan, Lingfei Wu, and Qingsong Wen. Rcagent: Cloud root cause analysis by autonomous agents with tool-augmented large language models. In Proceedings of the 33rd ACM International Conference on Information and Knowledge Management, CIKM ’24, page 4966–4974, New York, NY, USA, 2024. Association for Computing Machinery.

[50] Xu Zhang, Yong Xu, Qingwei Lin, Bo Qiao, Hongyu Zhang, Yingnong Dang, Chunyu Xie, Xinsheng Yang, Qian Cheng, Ze Li, Junjie Chen, Xiaoting He, Randolph Yao, Jian-Guang Lou, Murali Chintalapati, Furao Shen, and Dongmei Zhang. Robust log-based anomaly detection on unstable log data. In Proceedings of the 2019 27th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE), pages 807–817, 2019.

[43] Li Wu, Johan Tordsson, Erik Elmroth, and Odej Kao. Microrca: Root cause localization of performance issues in microservices. In Proceedings of the 2020 IEEE/IFIP Network Operations and Management Symposium (NOMS), pages 1–9, 2020.

[51] Xu Zhang, Yong Xu, Si Qin, Shilin He, Bo Qiao, Ze Li, Hongyu Zhang, Xukun Li, Yingnong Dang, Qingwei Lin, Murali Chintalapati, Saravanakumar Rajmohan, and Dongmei Zhang. Onion: identifying incident-indicating logs for cloud systems. In Proceedings of the 29th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering, ESEC/FSE 2021, page 1253–1263, New York, NY, USA, 2021. Association for Computing Machinery.

[44] Haoran Xu, Xuan Zeng, Xumiao Zhang, Xiaoxi Zhang, Yang Lv, Peng Zhang, Deke Guo, and Ennan Zhai. Aida: Accelerating root cause analysis for multi-vendor device failures with llm-powered reasoning. In Proceedings of the ACM SIGCOMM 2026 Conference, SIGCOMM ’26, page 770–786, New York, NY, USA, 2026. Association for Computing Machinery.

[52] Xiang Zhou, Xin Peng, Tao Xie, Jun Sun, Chao Ji, Wenhai Li, and Dan Ding. Fault analysis and debugging of microservice systems: Industrial survey, benchmark system, and empirical study. IEEE Transactions on Software Engineering, 47(2):243–260, 2021. Data via Nezha: https://github.com/IntelligentDDS/ Nezha.

[45] Wei Xu, Ling Huang, Armando Fox, David Patterson, and Michael I Jordan. Detecting large-scale system problems by mining console logs. In Proceedings of the 22nd ACM Symposium on Operating Systems Principles (SOSP), pages 117–132. ACM, 2009. [46] Bo Yang, Huanwu Hu, Yifan Li, Yunguang Li, Xiangyu Tang, Bingchuan Tian, Gongwei Wu, Jianfeng Xu, Xumiao Zhang, Feng Chen, Cheng Wang, Ennan Zhai, Yuhong Liao, Dennis Cai, and Tao Lin. Skynet: Analyzing alert flooding from severe network failures in large cloud infrastructures. In Proceedings of the ACM SIGCOMM 2025 Conference, SIGCOMM ’25, page 512–526, New York, NY, USA, 2025. Association for Computing Machinery.

[53] Jieming Zhu, Shilin He, Pinjia He, Jinyang Liu, and Michael R. Lyu. Loghub: A large collection of system log datasets for ai-driven log analytics. In Proceedings of the 34th IEEE International Symposium on Software Reliability Engineering (ISSRE), 2023. OpenStack dataset: https://github.com/logpai/loghub.

[47] Ding Yuan, Haohui Mai, Weiwei Xiong, Lin Tan, Yuanyuan Zhou, and Shankar Pasupathy. Sherlog: Error diagnosis by connecting clues from run-time logs. In Proceedings of the 15th International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS), pages 143–154, 2010. [48] Tianzhu Zhang, Han Qiu, Gabriele Castellano, Myriana Rifai, Chung Shue Chen, and Fabio Pianese. System log parsing: A survey. IEEE Trans. on Knowl. and Data Eng., 35(8):8596–8614, August 2023. 20

Related documents

• From Alert Floods to Precedence Forests: Zero-Prior-Knowledge Incident Triage with LOGOS#1186611
• Evolution of Log-Based Detection Rules in Public Repositories#1118542
• Tracing Authority: Testing Responsibility Diffusion Integrity in Algorithmic Decision Pipelines#79524
• Beyond Pixels: A Vector-to-Graph Framework for Reliable Schematic Auditing#1131466
• Pings: Constraint-First Probes for Sounding Internal Reasoning in LLMs and Black-Box Systems#708737