INSIGHT-HPC: An Interpretable System Intelligence for Global HPC Telemetry

arXiv:2611.03875v1 [cs.DC] 2 Nov 2026

INSIGHT-HPC: An Interpretable System Intelligence for Global HPC Telemetry Rupak Kadel

Jie Li

Yong Chen

Department of Computer Science Texas Tech University Lubbock, Texas rupak.kadel@ttu.edu

Department of Computer Science Texas Tech University Lubbock, Texas jie.li@ttu.edu

Department of Computer Science Texas Tech University Lubbock, Texas yong.chen@ttu.edu

Abstract—Modern high-performance computing (HPC) clusters integrate multi-generation CPUs and GPUs, which generate rich, high-dimensional telemetry streams from out-of-band baseboard management controllers (BMC), job schedulers, and facility power distribution units. Detecting anomalies within this telemetry is critical to prevent energy waste and costly node failures. Existing approaches often rely primarily on statistical deviations and require stronger labels than actual production environments can provide. In addition, these detectors have a limited operational context for interpreting alerts. We present INSIGHT-HPC, a multi-plane anomaly-detection architecture that combines statistical, workload-aware, and physics-guided evidence into operator-interpretable episodes. INSIGHT-HPC integrates heterogeneous, large-scale telemetry streams and transforms noisy minute-resolution observations into de-duplicated fault episodes with operator-facing explanations. This design allows the system to distinguish workload-explained behavior from genuine infrastructure anomalies while producing interpretable alert summaries for operators. On production HPC telemetry with weak operational labels and controlled HPCrelevant fault injections, INSIGHT-HPC achieves a stronger precision–recall balance than all evaluated baselines. The system achieves a precision of 0.913, a recall of 0.817, an F1 score of 0.862, and an AUROC of 0.896. These results demonstrate the value of combining workload context, physical consistency, and explainable episode-level fusion. Index Terms—High Performance Computing, Monitoring, Anomaly Detection, Explainability

I. I NTRODUCTION High-performance computing (HPC) systems form a foundational part of scientific infrastructure. These systems are critical for computationally intensive workloads such as engineering design, nuclear physics, materials discovery, computational biology, climate modeling, and large-scale AI workloads [1], [2]. HPC sites face the challenge of maintaining high utilization from thousands of components while also managing dense telemetry streams, aggressive power envelopes, and cooling constraints that directly affect availability, efficiency, and performance [3], [4]. At this scale, the cost of an undetected anomaly is not just a failed job. Instead, correlated hardware degradation and environmental stress can cascade across entire © 2026 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works.

racks and can even shorten component lifetimes [5], [6]. The SC’21 [7] characterization of Summit’s 200 PF pre-exascale facility across 4,626 nodes and 840,000 jobs demonstrates that power-thermal dynamics at this scale exhibit rich nonstationary structure that cannot be fully anticipated at design time. Contemporary HPC nodes expose telemetry through a layered stack of monitoring interfaces. Out-of-band baseboard management controllers (BMCs) with Redfish streaming provide per-second readings of CPU temperatures, fan RPM, inlet and return air temperatures, and system-level power draw. Workload schedulers, such as Slurm, expose per-job CPU utilization, memory usage, and job state via Slurm REST API. Facility-side smart power distribution units (PDUs) contribute per-outlet power measurements, enabling cross-plane verification between node-reported and facility-measured power. Integrating these continuously generated sources presents a Big Data challenge because they differ in schema, arrival delay and sampling semantics. CPU and GPU nodes also expose different sensor sets. Modern HPC systems often use a scalable monitoring tool to aggregate these heterogeneous sources into minute-resolution multivariate time series (MTS) comprising multiple concurrent sensor metrics per node [8]. This rich set of metrics can reveal subtle anomalies, but distinguishing genuine faults from legitimate workload dynamics remains challenging. Many HPC anomaly detectors are siloed within a single telemetry plane. This narrow focus often misses critical signals that only surface through cross-plane comparison or when thermal behavior deviates from its expected relationship with workload and power [9]. Lacking this physical grounding, these models can confuse standard workload transitions with genuine hardware faults. Residual-based physical modeling has long been a standard answer to this problem in fault detection and isolation [10], [11], but it has seen only limited use in HPC anomaly detection. Explainability is also still limited. Existing systems can often point to features that contributed to a score within a single model [1]. However, they usually cannot explain which kinds of evidence drove a final alert, whether that evidence is more consistent with a workload effect or a hardware problem, or what an operator should do next.

TABLE I C APABILITY COMPARISON OF INSIGHT-HPC WITH PRIOR HPC ANOMALY DETECTION SYSTEMS .

Capability Job-aware modeling Peer-node awareness Cross-plane telemetry reasoning Physics-guided reasoning Explainability Operator-facing alert tiers

RUAD

Prodigy

Refine

NodeSentry

GRAAFE

✗ ✗ ✗ ✗ ✗ ✗

△

✗ ✗ ✗ ✗ ✗ ✗

✓

✗ ✓ ✗ ✗ ✗ ✗

✗ ✗ ✗ ✓ ✗

Legend: ✓ Supported

✗ Not supported

To address these gaps, we present INSIGHT-HPC (An INterpretable System Intelligence for Global HPC Telemetry), a novel multi-plane anomaly-detection architecture that progressively refines statistical deviations using workload context and physical consistency before episode-level fusion. Our contributions are as follows: 1) We design workload-conditioned anomaly reasoning using Slurm job boundaries, workload profiles, and peernode behavior. 2) We introduce physics-guided validation using power, thermal, utilization, and cross-plane consistency. 3) We evaluate INSIGHT-HPC on 79 days of NSF-funded REPACSS (REmotely-managed Power Aware Computer Systems and Services) production telemetry with 29 operator-recorded failures and 140 controlled fault injections, achieving an F1-score of 0.862. 4) We generate tiered, auditable alerts with job context, violated constraints, dominant signals, and model attribution. II. R ELATED W ORK A. Supervised Anomaly Detection Early ML-based HPC anomaly detectors were mostly supervised. Tuncer et al. [12] used statistical features from hardware counters and resource-usage time series with classifiers such as kNN, decision trees, AdaBoost, and random forests. Netti et al. [13] followed a similar supervised direction by combining FINJ-based fault injection with classifiers such as SVM and random forests on the Antarex cluster. GRAAFE [14] uses graph neural networks to predict transitions from normal operation to anomalous states. However, it is difficult to maintain the labeled samples in production HPC clusters, where new hardware or workload behavior can introduce new anomaly patterns. B. Semi-supervised Anomaly Detection Semi-supervised methods reduce the labeling burden by assuming that some of the training data can be labeled. Borghesi et al. [15] proposed a semi-supervised autoencoder approach in which the model learns normal node behavior and detects deviations via reconstruction error. Proctor [16] uses autoencoder-based representation learning and then applies a supervised classifier for anomaly diagnosis. Aksar

△

✗ ✗ △ △

ThermADNet

DeepHYDRA

INSIGHT-HPC

✗

✗ ✓ ✗ ✗

✓ ✓ ✓ ✓ ✓ ✓

△

✓ △

✓ ✗

△

✗

△ Partial support (limited scope or integration)

et al. [17] later introduced ALBADross, an active-learningbased anomaly diagnosis framework that reduces the number of labeled samples required to diagnose known performance anomalies. ThermADNet [18] explicitly uses a semisupervised learning approach for datacenter thermal anomaly detection. DeepHYDRA [19] is a hybrid approach that combines DBSCAN with learning-based anomaly detection and is often described as semi-supervised because its training includes a supervised loss component. These systems are more realistic than fully supervised methods, while still depending upon some form of clean normal data or labeling. C. Unsupervised Anomaly Detection Unsupervised methods are attractive in production HPC because they avoid requiring dense anomaly labels. RUAD [20] remains mostly node-centric and does not use Slurm job context, so it cannot directly separate workload-driven changes from infrastructure-side faults. Prodigy [1] provides job- and node-level analysis for operators, which makes it one of the strongest prior HPC baselines for explainable anomaly detection. Refine [21] is a robust unsupervised HPC anomaly detection framework designed to handle contaminated training datasets, which directly addresses a weakness of many reconstruction-based systems. USAD [22] is an explicitly unsupervised adversarial autoencoder for multivariate timeseries anomaly detection. NodeSentry [2] treats job-boundary segmentation as part of its anomaly-detection pipeline. However, it remains mainly workload-aware and does not explicitly validate anomalies using physical consistency checks. Positioning of INSIGHT-HPC: Despite this progress, several gaps remain. Most prior systems operate within a single telemetry plane. Job context and physical consistency checks also remain underused in HPC anomaly detection, while explainability is often limited. INSIGHT-HPC addresses these gaps through a hybrid design. Table I summarizes its positioning relative to prior work. III. M ETHODOLOGY The overall system architecture of INSIGHT-HPC is shown in Figure 1. The system ingests a rich set of metrics from multiple sources, such as BMC sensors, Slurm, and PDUs, which are then preprocessed and feature-engineered. The detection pipeline comprises four phases. Phase I flags statistical outliers relative to each node’s history. Phase II runs alongside Phase

Data Sources

PHASE I

Statistical Detectors BMC Sensors Hardware Telemetry from nodes

Auditing Quality Flags

Master Table Construction Unified & Aligned Time Series

Job Schedulers & Accounting Data

Actionable Insights & Alerts

Four-phase Detection Pipeline

Data Preprocessing

Threshold Rules

PHASE II

PHASE III

Job-Aware Modeling

Physics Reasoning

Job Segmentation

Power & Thermal Model

CRITICAL Immediate Attention Required

Isolation Forest

Workload Profiling & Clustering

Adaptive Residual Scoring

LSTM Autoencoder

Peer Analysis & Job Attribution

Constraint Rules

CONFIRMED High Confidence Anomaly

PHASE IV Feature Engineering Temporal Features Rolling Statistics

PDUs Power & Energy Measurements

Episode Formation

Fusion

Gradient Boosting Classifier

CANDIDATE Needs Further Investigation

Figure 1. The high-level system architecture of INSIGHT-HPC. The system ingests telemetry from multiple sources, aligns them into a per-host table, and derives features from them. These features are fed into Phases I–III, whose outputs are fused in Phase IV into candidate episodes and emitted as operator-facing alerts.

I, detecting behavior unusual for the current workload. Phase III then interprets the resulting anomalies through physics models and constraints. Finally, Phase IV fuses the statistical, workload-conditioned, and physics-based evidence into tiered, attributable alerts that operators can act on. A. Data Preprocessing Raw HPC telemetry is not directly usable for anomaly detection because sources report at different rates and timestamps may not align. As a result, data preprocessing is more than a cleaning step; it is the stage of the pipeline that builds a consistent, usable view of system behavior. 1) Auditing: The auditing stage marks suspicious raw sensor behavior before the anomaly detectors are trained. Rather than deleting rows immediately, we attach a per-sensor quality mask indicating whether the reading is a spike, flatline, or badrange value. For spike auditing, we compute a rolling audit z-score (i.e., standard score) over a 120-sample window: zaudit =

v(t) − µroll σroll

(1)

where v(t) is the current reading, µroll and σroll are the rolling mean and standard deviation, respectively. A spike flag is raised when zaudit > 5.0 and the absolute change (δabs ) exceeds a metric-specific floor. The absolute floor prevents nearly flat signals with very small variance from producing artificially large z-scores for harmless changes. Flatlines are detected by measuring the length of consecutive repeated readings. The default threshold is 480 minutes, though it is tightened for critical sensors such as temperature. For a badrange detection, we use percentile-based expected bounds: v(t) ∈ / [p0.001 ∗ βlo , p0.999 ∗ βhi ]

(2)

where p0.001 and p0.999 are the empirical 0.1th and 99.9th percentiles, βlo = 0.95, and βhi = 1.05. The 5% buffer makes

the range slightly more tolerant to normal drift, while still excluding clearly questionable sensor values. 2) Master Table Construction: Once the raw streams are audited, we build the master table, a per-node, per-minute table that combines BMC telemetry, Slurm context, and PDU signals on a common timestamp. Every job’s interval [start time, end time] is expanded to one row per minute so it can be joined directly to telemetry timestamps. If no job is active for a minute, the table records active job count = 0, indicating the node is idle. This is needed because raw telemetry alone does not indicate whether a power jump is suspicious or whether a large job has started. Then, we perform selective masking. For instance, instead of blindly removing all flagged data, we preserve spikes during active jobs as they may be legitimate workload effects. This is important because otherwise the training data would throw away exactly the workload transitions that later phases need to understand. 3) Feature Engineering: Each aligned node-minute is converted into features capturing short-term change, longer-term drift, missing-sensor behavior, workload context, and periodic context, as summarized in Table II. Short-term change features capture how each telemetry signal changes over a short period of time. For each sensor metric, we compute the rate of change, rolling means, standard deviations, and quantiles over trailing windows of 5, 15, and 60 minutes. These features allow the detector to distinguish stable behavior from sudden jumps. The longer-term drift features calculate the longer-horizon linear drift slopes over day-scale windows for power and thermal metrics. These slopes are useful for detecting slow degradation, such as when a sensor may not appear abnormal at any given moment but may gradually drift away from its usual baseline. Missing sensor behavior features handle missingness and sensor silence. For safety-critical signals such as fan speed, system power, CPU power, and temperature, we maintain counters that record the

TABLE II E XAMPLE FEATURES COMPUTED IN F EATURE E NGINEERING . Feature Group

Example Features

Short-term change Longer-term drift Missing-sensor behavior Workload context Periodic context

Inlet temperature (°C)

45 40

cpu power roc5, fan speed rmean15, etc. inlet temp slope12h, sys power slope24h, etc. fan missing streak, cpu power missing streak, etc. active job count, is running job, etc. hour sin enc, dow cos enc, etc.

Maintenance window CPU Node rpc-91-1 inlet temperature Fixed Jan-only threshold (26.3 °C)

35 30 25 20 01-01

01-15

02-01

02-15 Timeline

03-01

03-15

later models. The final output is a feature-aligned table that keeps the physical meaning of the original telemetry while also making it easier for the statistical, job-aware, and physicsguided phases to reason over node behavior. B. Phase I: Statistical Detectors Phase I scans the feature-aligned master table for behavior that appears statistically unusual at the node and minute levels. It prioritizes coverage using several complementary detectors. We use three detector families because no single method is reliable across all the failure modes observed in HPC telemetry. Threshold rules provide the simplest baseline. They target obvious conditions like high system power, high CPU temperature, high inlet temperature, fan failure patterns, idle power surges, flatlines, and sensor dropouts. Isolation Forest identifies outliers by isolating observations, rather than profiling normal data points [25]. Its score is based on how quickly a point gets isolated by random tree partitions: E(h(x))

s(x) = 2− c(n)

Figure 2. Regime shift on a CPU node rpc-91-1 after maintenance window

(3)

with duration a value has been missing. This makes prolonged sensor silence visible to the detector. The next group of features adds workload context from Slurm. For each node and minute, we encode whether the node is idle or allocated, whether multiple jobs share the node, and how recently the active job set changed. Finally, we add simple time-based periodic features to help the models learn recurring daily and weekly patterns, such as typical work schedules or periodic cooling cycles. HPC telemetry also exhibits substantial regime-dependent variation over time. Maintenance operations, firmware updates, cooling changes, and evolving workload mixes can shift the normal operating baseline of a cluster even when no fault is present [23], [24]. As shown in Figure 2, the inlet temperature baseline of a CPU node rpc-91-1 changed noticeably after a maintenance window. Without accounting for such regime shifts, rolling statistics computed over long histories may incorrectly treat normal baseline transitions as anomalies. To reduce this effect, we annotate each (node, timestamp) row with a regime identifier derived from available maintenance and operational metadata. All rolling-window and driftbased features described above are computed independently within each regime, preventing statistics from crossing regime boundaries. When regime metadata is unavailable, the identifier remains constant, and the pipeline naturally falls back to standard past-only windowing. This design allows the featureengineering stage to incorporate operational context when available while remaining compatible with fully unsupervised deployments. After feature construction, continuous features are normalized separately for each host using training-period statistics. We apply a minimum-variance floor and cap extreme normalized values to prevent unstable sensors from dominating

c(n) = 2H(n − 1) −

2(n − 1) n

(4)

where h(x) is the path length for point x, E(h(x)) is the expected path length across trees, H(i) is the harmonic number, and c(n) is the normalization constant representing the average path length of an unsuccessful search in a Binary Search Tree. We then employ the LSTM autoencoder, which is a sequence-to-sequence reconstruction model over 30-minute sliding windows [26]. It adds a temporal view by scoring whether a short telemetry window can be reconstructed as normal behavior. For each minute, we compute the mean absolute reconstruction error across all features: F

erecon (t) =

1 X |xf (t) − x̂f (t)| F

(5)

f =1

where xf (t) and x̂f (t) are the original and reconstructed values of feature f at time t. Because windows overlap, we average the errors for each minute and normalize the result per node. To prevent learning anomalies as normal behavior, we clean the training set in two passes: first by removing windows flagged by Isolation Forest, and second by removing the top 1% of highest-error windows. The phase score is the mean of these three normalized detector outputs, and a node-minute is forwarded as candidate evidence only when this score remains above a fixed threshold. Because detector scores also shift with operating conditions, we convert each output to a per-host trailing rank against its recent history. This keeps firing rates more stable across regimes and emphasizes fresh deviations over persistent plateaus. Phase I therefore treats detector outputs as screening evidence, not final fault decisions, forwarding unusual nodeminutes for later workload and physical validation.

C. Phase II: Job-Aware Modeling Phase II adds workload context and cross-node comparisons to distinguish genuine faults from workload-driven changes in power, temperature, and utilization. Running in parallel with Phase I, it reconstructs the job context for every minute and compares nodes sharing a workload. The detailed description of each stage in this phase is as follows: 1) Job Segmentation: We begin by segmenting each node’s timeline using Slurm job boundaries. The per-minute featurealigned master table produced during preprocessing is the right starting point for statistical detection, but workload-aware reasoning needs a larger unit than an individual timestamp. For that reason, we reduce the stream into contiguous segments during which the active job set on a node remains unchanged. A new segment begins when the primary job changes, when the set of active jobs changes, or when a sufficiently large telemetry gap appears. For each host h, a boundary is declared at minute t when:   bh (t) = 1 jh (t) ̸= jh (t−1)   ∨ 1 Sh (t) ̸= Sh (t−1) (6)   ∨ 1 t − tprev > 120 s where jh (t) is the primary job ID, Sh (t) is the sorted set of active job IDs, and the third clause closes a segment across telemetry gaps exceeding two minutes. Each segment is annotated with basic operational properties such as is idle, is multi job, duration min, and the total requested CPU count for the respective job IDs. Very short segments are excluded because they do not provide enough samples to build a stable workload profile. 2) Workload Profiling and Clustering: Each non-idle segment is then reduced to a compact behavioral profile. Instead of keeping a full minute-by-minute trace, we summarize the segment into roughly 30 engineered features that capture the workload’s physical signature. These include power and energy statistics, compute efficiency ratios, thermal and cooling means, and metrics on GPU nodes. These workload profiles describe the kind of workload behavior the segment represents. After these profiles are available, we partition them into workload archetypes using either K-Means or Hierarchical Density-Based Spatial Clustering of Applications with Noise (HDBSCAN), with the final choice between these two algorithms guided by the silhouette score [27]–[29]. Clusters of fewer than 10 members are merged into the nearest centroid to avoid degenerate archetypes. This clustering enables anomaly scoring relative to similar workloads. We then fit an Isolation Forest separately within each cluster, which flags a segment as suspicious if it looks abnormal relative to other segments of the same workload archetype. 3) Peer Analysis and Job Attribution: Cluster-conditioned scoring identifies segments that are unusual for a specific workload type. However, it does not directly exploit consistency among nodes executing the same job. When the same job runs across multiple nodes, those nodes should usually show comparable behavior. A node that drifts away from its

peers is often more suspicious than the one whose absolute telemetry is simply high. To address this, we perform peergroup analysis for jobs spanning multiple nodes. For each multi-node segment, we build a running profile using telemetry accumulated up to the current minute. A node is flagged if its distance from the peer median is a robust outlier relative to the overall peer distribution, as measured by the Hampel Z-score: zicoh (T ) =

di (T ) − medianj dj (T ) . k · MADj dj (T )

(7)

where di (T ) is the distance of node i at time T , medianj dj (T ) and MADj dj (T ) are the median and median absolute deviation of these distances taken across all peer nodes j, and k is the scaling constant that is used to make the MAD equivalent to a standard deviation for normally distributed data. A 30minute warm-up precedes scoring, so that the running profile vector is stable enough for the peer median to be meaningful. We also apply a direction-aware per-minute check on system input power, because single-metric faults can be diluted in the full profile. This preserves cases in which a node draws substantially less or more power than its peers, which can indicate different failure modes. Once the peer analysis is complete, we perform job attribution. When a single job occupies a segment, attribution is trivial because the running job is the only candidate. However, when two or more jobs share a node simultaneously, it is a challenging operational case because any of the concurrent jobs could cause the same anomalous power draw. We resolve this by scoring each candidate job across four signals: power residual, onset alignment, cluster deviation, and peer coherence. We combine these signals into a weighted attribution confidence score, with the weights redistributed proportionally when a signal is unavailable. The job with the highest score becomes the primary attributed job, and the full ranked candidate list is stored and surfaced later in the operator alert as a human-readable explanation that does not depend on the learned fusion stack. Phase II, therefore, indicates whether the abnormal behavior is workload-related. The output of this stage is a set of jobaware signals, coherence scores, and the attribution evidence. These are then passed to Phase III, where the pipeline determines whether the same behavior is physically plausible. D. Phase III: Physics Reasoning Phase III tests whether anomalous observations are physically plausible by comparing telemetry with expected physical behavior. Physics-grounded constraints and a deterministic decision tree assign each detected anomaly a semantic label, producing interpretable per-minute evidence complementary to the statistical phases. 1) Power and Thermal Model: The power model uses a separate Ridge regression for each node type, trained across nodes on the training split. It predicts system input power from CPU load, memory usage, active job count, CPU package

power, memory power, mean GPU utilization and the operating regime identifier. The expected power is modeled as: P̂h (t) = β0 + β T xh (t)

(8)

where P̂h (t) is the predicted power for host h at time t, xh (t) is the feature vector describing the node’s workload and operating state, β0 is the Ridge intercept, and β is the Ridge coefficient vector. The model is trained across nodes to learn a general relationship between workload and expected power. Then it is adjusted with a host-specific bias correction to prevent false alarms due to idle behavior or hardware revisions. The final power residual is the difference between the observed power and the predicted power, plus the learned host-specific bias. Large positive or negative residuals indicate that a node is consuming more or less power than expected given its current workload. The thermal model follows the same general idea as the power model. It estimates the expected inlet temperature using a similar Ridge regression technique. The model predicts the expected inlet temperature from system input power and the operating regime. This matters because thermal faults are often not obvious from absolute temperature values alone. The model captures the expected relationship between the power draw and the temperature response. A per-node calibration step is again applied because cooling efficiency varies across rack locations and hardware placement. The thermal residual is the difference between the observed and predicted inlet temperatures. In many cases, the important signal is that temperature changes are inconsistent with the amount of power being drawn, or that temperature rises without a corresponding workload or power driver. 2) Adaptive Residual Scoring: The residuals produced by the power and thermal models are usually not interpretable without a scale. We therefore use an adaptive residual scale rather than a fixed training-period standard deviation. This is important because HPC telemetry is non-stationary, and ambient conditions, workload mix, cooling behavior, and hardware state can shift over time without indicating a fault. For each residual channel, we estimate a robust rolling scale as: σrobust (t) =

IQR[t−14d,t] (r) k

(9)

where IQR[t−14d,t] (r) is the interquartile range (IQR) of the residual r calculated over a trailing 14-day window, and k = 1.349 converts the IQR to a standard-deviation scale. This rolling scale prevents future leakage while allowing the detector to adapt to slow operating-regime shifts. The residual scale is bounded between 0.5 and 5 times the training residual standard deviation. Residual flags require |z| > 5 for power or |z| > 4 for temperature. Around job starts and ends, we reduce the residuals by multiplying them by 1 − exp(−∆/τ ), where ∆ is the time to the nearest job start or end and τ = 5 min. This adjustment applies within 20 minutes of a transition to avoid treating normal startup and shutdown behavior as faults.

3) Constraint Rules: Residuals alone, however, are not sufficient to explain what kind of inconsistency is present. We therefore apply a small library of physics-grounded constraint rules. These rules are meant to check structural relationships that should hold even when no single sensor value is extreme. We apply four primary constraint rules to audit the physical consistency of the data. The dynamics constraint ensures that temperature changes are reflected in power consumption. It helps identify anomalies such as increased heat on idle nodes. A cross-plane constraint compares rack-level PDU measurements with the aggregate of individual BMC data in that rack. The discrepancies typically indicate sensor drift or reporting failures. The allocation-versus-utilization constraint identifies nodes officially assigned to a job but with no measurable activity. The cooling-response constraint identifies nodes whose inlet temperature climbs while fan speed fails to respond. To ensure result integrity, each constraint requires a sustained run of at least three to five consecutive minutes before firing, with the allocation-versus-utilization rule requiring 30 minutes to reflect the natural idle gaps within legitimate jobs. Therefore, Phase III combines residual magnitude, constraint evidence, and context weights. This stage helps suppress deviations explained by normal workload behavior, while also highlighting deviations without a meaningful explanation. The full semantic label is passed to Phase IV to generate operator-facing explanations. E. Phase IV: Fusion Phase IV receives node-local statistical signals from Phase I, workload- and peer-aware signals from Phase II, and physics residuals, constraint violations, and semantic labels from Phase III. It fuses this heterogeneous evidence into a single episode-level decision. Phases I-III are fitted without anomalyclassification targets, but known labeled fault intervals are excluded from training alongside maintenance periods and audit-flagged readings. Their thresholds are not tuned against event labels. Phase IV uses labeled episodes for supervised fusion, with a predefined feature set and validation-selected tier thresholds. Test labels do not enter fitting, feature selection or threshold tuning. 1) Episode Formation: Although the upstream phases produce per-minute evidence, reporting decisions at minute granularity are not well aligned with operational practice. HPC operators typically investigate incidents as sustained episodes involving nodes, jobs, and subsystems rather than as isolated timestamps. Moreover, excessive undifferentiated alerts can reduce trust in the detector and cause important events to be overlooked [30]. Therefore, Phase IV first groups per-minute evidence into candidate anomaly episodes before performing the final classification. A candidate episode is formed when a phase headline score is sustained above a small threshold for several consecutive minutes. Adjacent candidates separated by short gaps are merged so that intermittent or flickering faults are treated as a single event. This episode-level formulation also matches the

IV. E VALUATION AND R ESULTS In this section, we provide a detailed overview of the experimental setup, the controlled fault injections, the baseline methods, and the overall performance of INSIGHT-HPC. A. Experimental Setup We use an NSF-funded REPACSS cluster, comprising 110 CPU nodes, 8 GPU nodes, 3 login nodes, and 9 storage nodes, totaling 28,984 cores and 176 TB of system memory. Each CPU node is equipped with two AMD EPYC 9754 processors providing 256 cores and 1.5 TB of DDR5 memory per node. Each GPU node contains two Intel Xeon Gold 6448Y processors and four NVIDIA H100 NVL GPUs interconnected

29 21 21 17 13

Injection types

available ground truth, since operator tickets and node-failure records usually describe time intervals rather than individual timestamps. For each candidate episode, we condense the upstream evidence into a fixed-length feature vector. Instead of using only one summary scalar per phase, we retain the raw detector flags and supporting signals, allowing the fusion model to learn cross-phase interactions, such as the concurrence of statistical consensus in Phase I and a physics violation in Phase III. Each episode also captures context unavailable to per-minute detectors: how its evidence ranks against the host’s own recent history, how persistently each phase fired rather than only how strongly, how many hosts in the same rack had an episode open concurrently, how often that host has recently produced weak candidates, and how its evidence compares with that of its job peers. 2) Gradient Boosting Classifier: After the episodes are formed, we train a histogram-based gradient-boosting classifier on episode-level features to produce a fused anomaly probability. The fusion model learns which combinations of statistical, workload-aware, and physics-guided evidence are most predictive of true anomalies. The classifier output is mapped into three operating tiers: CRITICAL, CONFIRMED, and CANDIDATE. The CRITICAL tier emphasizes high precision, the CONFIRMED tier serves as the primary reporting point, and the CANDIDATE tier prioritizes higher recall. This tiered design lets operators choose an operating point based on the cost of missed events versus the cost of unnecessary interruptions. All three thresholds are selected on the validation split alone and are never tuned on test, and we report the validation-to-test transfer of that policy rather than a testoptimal point. To make the final output actionable, each alert is emitted as a compact explanation package rather than a numerical score alone. The package includes the fused probability, tier assignment, semantic context label, dominant contributing signals, and TreeSHAP attribution from the fusion model. When available, it also includes fired rules, violated constraints, and implicated job context. These explanations give operators a starting point for triage and make the decision auditable. Thus, Phase IV serves as the final decision layer that transforms perminute detector evidence into scored, tiered, and interpretable anomaly episodes.

13 11 10 8 7 5 5 4 3 2

0

5

10

15

20

25

30

Number of total events Real Hardware Incidents Idle power fault Peer-node divergence Cooling failure Sensor dropout

Fan RPM drop Gradual thermal drift Job excess power Stuck sensor GPU thermal runaway

Archetype drift Rack common mode Cross-plane drift Memory leak CPU exhaustion

Figure 3. Types of anomalies in the test split of the dataset.

via NVLink, each with 94 GB of HBM memory. The cluster is monitored through a centralized monitoring service backed by TimescaleDB. It ingests metrics from multiple sources, including BMC and PDU metrics and Slurm workload data.

B. Dataset and Controlled Fault Injections We evaluate INSIGHT-HPC on 79 days of heterogeneous production telemetry from the 118-node compute fleet, spanning January 1 to March 20, 2026. The dataset covers approximately 220K node-hours of monitoring and 13,266 Slurm jobs, integrating node, workload, and infrastructure telemetry. The first 59 days form the training set, the next 8 days form the validation set, and the final 12 days form the test set. A maintenance shutdown between February 14 and February 16, 2026, is masked from the training window. Ground-truth failures are sparse and often recorded only after operator investigation [31]. Because naturally occurring labeled failures provide limited coverage of the diverse failure modes encountered in HPC systems, controlled injections allow us to evaluate detector behavior across a broader and systematically defined set of operational conditions. We therefore evaluate on 169 labeled test events across 85 hosts: 29 operator-recorded failures and 140 controlled fault injections spanning HPC-relevant thermal, power, cooling, resource, sensing, and cross-plane failure modes, as shown in Figure 3. Idle-power injections add 110–220 W for 2–6 h, cooling injections raise inlet temperature by 4–6 °C for 1–2 h, and sensor dropouts last 2–3 h. These test selected signatures rather than the full diversity of production failures. Training and validation use independently generated events, and no testwindow label is used for training, threshold selection, or model selection.

TABLE III P ERFORMANCE COMPARISON OF INSIGHT-HPC AND BASELINES .

Method

Prec.

Rec.

F1

AUROC

AUPRC

INSIGHT-HPC NodeSentry Prodigy Isolation Forest LSTM-AE

0.913 0.710 0.599 0.436 0.491

0.817 0.452 0.735 0.560 0.470

0.862 0.552 0.660 0.490 0.480

0.896 0.379 0.666 0.811 0.728

0.878 0.489 0.450 0.760 0.758

C. Baseline Methods We compare INSIGHT-HPC against four established unsupervised baselines: two published state-of-the-art anomaly detection systems, Prodigy [1] and NodeSentry [2], and two standard unsupervised detectors, Isolation Forest [25] and LSTM Autoencoder [26]. All baselines are trained using the same 59-day training window and evaluated on the same temporal validation and test splits as INSIGHT-HPC. Prodigy uses healthy training data and a 99th-percentile reconstruction-error threshold. NodeSentry is fitted without labels, but its threshold maximizes validation F1. Isolation Forest and LSTM-AE use Phase I’s training data and their native anomaly flags. D. Evaluation Metrics We report precision, recall, F1, AUROC, and AUPRC, together with event recall. Phases I-III are fitted on the training data. Phase IV is fitted on labelled training and validation episodes, with validation labels also used to select its tier thresholds. Final evaluation uses the held-out test split. To absorb both imprecision in operator-recorded fault boundaries and the alignment granularity of windowed scoring, each ground-truth event is expanded into a tolerance window extending 60 minutes before its start and 30 minutes after its end. A candidate episode matches a ground-truth event if it overlaps the event’s tolerance window on the same host, on any host in the same rack for rack- or PDU-level events, or on any host for cluster-wide events. AUROC/AUPRC rank method-specific pools. Each alert episode matching at least one ground-truth tolerance window counts as one true positive (TP). An unmatched alert counts as one false positive (FP). Each event with no matching alert counts as one false negative (FN). Reported recall is TP/(TP + FN), combining matched alert episodes with missed events. We separately report event recall, the fraction of events matched by at least one alert. E. Overall Performance Table III compares INSIGHT-HPC with the baseline methods. At the validation-selected CRITICAL, CONFIRMED, and CANDIDATE thresholds, precision/recall are 0.979/0.525, 0.913/0.817, and 0.813/0.899, respectively. At the primary CONFIRMED operating point, INSIGHT-HPC achieves the best overall performance, reaching an F1-score of 0.862 with a precision of 0.913 and a recall of 0.817, with an event recall of 0.805. This represents a 31% improvement in F1 over the next strongest baseline, showing that workload-aware and physics-guided evidence adds value beyond statistical

TABLE IV P ERFORMANCE COMPARISON OF INSIGHT-HPC AND DIFFERENT COMPONENTS .

Method

Prec.

Rec.

F1

AUROC

AUPRC

INSIGHT-HPC P-I P-II P-III P-I ∧ P-II P-I ∧ P-II ∧ P-III P-I ∨ P-II ∨ P-III Majority vote (≥ 2)

0.913 0.393 0.692 0.361 0.550 0.571 0.318 0.537

0.817 0.955 0.178 0.954 0.203 0.171 0.988 0.911

0.862 0.557 0.283 0.524 0.296 0.263 0.481 0.675

0.896 0.803 0.849 0.729 0.855 0.758 0.734 0.811

0.878 0.785 0.940 0.705 0.893 0.842 0.689 0.862

TABLE V E CLIPSE CROSS - DATASET EVALUATION .

Task

Method

Prec.

Rec.

F1

AUROC

memleak

INSIGHT-HPC Prodigy NodeSentry

0.859 0.940 0.845

0.994 1.000 0.982

0.921 0.969 0.908

0.735 1.000 0.683

cpuoccupy

INSIGHT-HPC Prodigy NodeSentry

0.852 0.864 0.852

0.971 1.000 0.965

0.907 0.927 0.904

0.692 0.695 0.689

anomaly scores alone. As a sensitivity check, re-evaluating the frozen alerts with a stricter 0/15-minute tolerance instead of 60/30 minutes yields nearly unchanged precision/recall/F1 of 0.907/0.811/0.856. NodeSentry’s AUROC is low because many episodes during the cooling incident receive lower scores than GPU episodes with no matching recorded fault. F. Computational Cost and Scalability All training and inference run on a single 20-core allocation with one NVIDIA H100 GPU. The end-to-end replay pipeline, from preprocessing through training and evaluation of all four phases, over 79 days of telemetry from 118 nodes, completes in approximately 43 minutes of wall-clock time. Measured on node-limited replays of the raw telemetry at 38, 68, and 98 nodes, runtime scales nearly linearly with fleet size at 14.6 s per node plus an 850 s fixed cost (R2 = 0.997). A linear extrapolation of this fit predicts approximately 4.3 hours for 1,000 nodes on the same configuration. Frozen-model inference also scales linearly at 15.1 s per node (R2 = 0.999) for the same 79-day dataset, which is about 0.13 ms of compute per node-minute of telemetry. These timings measure throughput rather than alert delay. Classification uses features summarized over complete episodes. G. Ablation Study The contribution of each design choice in INSIGHT-HPC is shown in Table IV. All configurations use the same upstream features and event-matching protocol. The ablation compares INSIGHT-HPC against several non-learned fusion baselines that combine phase outputs using fixed Boolean logic. The OR operator (∨) reports an episode if any phase flags it as anomalous. The AND operator (∧) reports an

System input power GT event start

Power (W)

600

550

500

19:30

19:45

20:00

20:15

20:30

20:15

20:30

Time (UTC)

a) System input power spiked at 20:00 UTC

Phase score (z-units)

episode only when all required phases agree. Majority voting requires agreement from two or more phase-level detectors. INSIGHT-HPC ranks the shared Phase IV candidate pool, including candidates below alert thresholds. Isolation Forest, LSTM-AE and Boolean configurations rank flagged episodes. Prodigy ranks scored windows. NodeSentry forms episodes from at least two consecutive minutes above each host’s 75th-percentile score, merging gaps shorter than 10 minutes. It ranks them by maximum reconstruction error. AUROC/AUPRC are therefore not directly comparable across rows. The results show that neither individual phases nor fixed Boolean fusion is sufficient. P-II’s high AUPRC reflects a small, high-base-rate pool rather than stronger detection, as its recall of 0.178 shows. INSIGHT-HPC achieves the strongest overall precision-recall balance, while maintaining an F1-score of 0.862. Learned fusion outperforms the tested Boolean rules. These comparisons do not isolate each phase’s contribution under a retrained classifier.

Phase I Phase II Phase III Alert GT event start

2

1

0 19:30

19:45

20:00 Time (UTC)

b) Phase I score spiked at 20:00 UTC

Figure 4. An input-power spike triggered Phase I; Phase III validated it.

H. Portability Beyond BMC Telemetry To test portability beyond BMC telemetry, we evaluate INSIGHT-HPC on the Eclipse dataset used by Prodigy [1]. This dataset provides 240 labeled job-node pairs across four HPC applications and two anomaly types (memleak and cpuoccupy), which are evaluated as two binary tasks of 160 samples each following Prodigy’s protocol. Its telemetry differs substantially from ours: 156 Linux /proc counters at 1 Hz, without temperature, fan, power, or useful peer-divergence signals. The traces are also pre-sliced into 22–56-minute pairs rather than collected as continuous multi-week streams. This setup lets us compare against Prodigy on its native benchmark and against NodeSentry [2] under the same protocol. Under this protocol, only Phase I of our model is exercised. Phase II is disabled under this protocol because its peer-divergence signal is uninformative when the anomaly is applied to all four nodes of a job, and Phase III is not applicable because the dataset lacks the physical signals required by this phase. Our model therefore reduces to Phase I’s Isolation Forest and LSTM-Autoencoder stack, ported without code modification. For a fair comparison, we followed Prodigy’s evaluation protocol, which includes three random seeds and an 80/20 split for the healthy training pool. We tuned our thresholds on a disjoint 30% validation set and reserved the remaining 70% for the final test phase. NodeSentry uses four clusters, matching Eclipse’s four applications, with the same splits. With only Phase I available, INSIGHT-HPC performs similarly to Prodigy, as shown in Table V. It trails by only a small margin on memleak (0.921 vs. 0.969 F1) and cpuoccupy (0.907 vs. 0.927), while still outperforming NodeSentry. I. Case Studies 1) Idle Power Fault: INSIGHT-HPC raised a CRITICALtier alert on a CPU node rpc-97-1. Figure 4 shows the anomaly onset. The 240-minute injection (a sustained +130W draw on an idle node with no Slurm allocation, 2026-03-10 20:00 UTC) was bracketed minute-for-minute by a 240-minute alert.

Explainable Alert: Idle Node Power Excess Target: CPU node rpc-97-1 Detection phase: Episode onset: Associated job: Likely cause:

Severity: CRITICAL

Phase I, supported by Phase III 2026-03-10 20:00 UTC None Parasitic process or firmware issue

Operator action. Investigate within 15 min. CPU node rpc-97-1 drew sustained power above its 7-day idle baseline despite having no active job. Schedule the node for reboot if no legitimate background activity is identified. Supporting evidence. System input power moved from a baseline of 472.3 W to 602.7 W (+130.4 W, +28% of baseline). • Phase III physics residual reached 9.1σ, outside the model-expected envelope for this node. • Phase I rule that fired: Idle Power Surge •

Figure 5. Explainable alert generated by INSIGHT-HPC.

The node remained idle for the preceding 24 hours. Phase I’s IDLE POWER SURGE rule and Phase III’s physics evidence both begin at the fault onset in replay. Note that Figure 4b plots each phase’s bounded episode-formation score in z-units, which compresses large residuals. Figure 5 shows the operatorfacing alert card. 2) False Positive Rescue: During training-period replay, a Slurm job started at 08:57 UTC on 2026-01-04 on GPU node rpg-93-7 and drove system input power from a 690 W idle baseline to bursts near 915 W, as shown in Figure 6. It caused Phase I to spike to 2.6σ. However, Phase II found the workload behavior routine and Phase III found no physics violation (|z| ≤ 1.3), so the fusion stage suppressed the episode to NONE and no operator alert was issued. V. C ONCLUSION AND F UTURE W ORK In this paper, we presented INSIGHT-HPC, a multiplane anomaly-detection architecture for HPC telemetry.

Phase I trigger at 09:06 UTC

System input power Slurm job active (from 08:57 UTC)

Final decision → NONE

Power (W)

900

800

700 08:30

08:45

09:00

09:15

09:30

Time (UTC)

Figure 6. A workload-explained power burst on GPU node rpg-93-7.

INSIGHT-HPC progressively refines statistical anomaly evidence using workload context, peer behavior, and physical consistency before episode-level fusion. Across 79 days of production telemetry with 29 operator-recorded failures and 140 controlled fault injections, it achieved 0.913 precision, 0.817 recall, and 0.862 F1 while producing auditable operatorfacing alerts. The present evaluation is retrospective. Future work will study long-term online deployment and adaptation under evolving workloads. VI. ACKNOWLEDGMENT We are thankful to the anonymous reviewers for their valuable feedback. This research is supported in part by the National Science Foundation under grants OAC-2404438 and CNS-1939140 (A U.S. National Science Foundation IndustryUniversity Cooperative Research Center on Cloud and Autonomic Computing). We used ChatGPT-5.5 to assist with improving grammar and sentence clarity. All ideas and content remain original. R EFERENCES [1] B. Aksar, E. Sencan, B. Schwaller, O. Aaziz, V. J. Leung, J. Brandt, B. Kulis, M. Egele, and A. K. Coskun, “Prodigy: Towards unsupervised anomaly detection in production hpc systems,” in Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis, 2023, pp. 1–14. [2] S. Xia, Y. Sun, X. Pan, Y. Yuan, S. Zhang, S. Hu, L. Tao, Y. Li, and J. Feng, “Effective node-level anomaly detection in hpc systems via coarse-grained clustering and fine-grained model sharing,” in Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis, 2025, pp. 1180–1194. [3] A. Netti, W. Shin, M. Ott, T. Wilde, and N. Bates, “A conceptual framework for hpc operational data analytics,” in 2021 IEEE International Conference on Cluster Computing (CLUSTER). IEEE, 2021, pp. 596– 603. [4] E. Bautista, M. Romanus, T. Davis, C. Whitney, and T. Kubaska, “Collecting, monitoring, and analyzing facility and systems data at the national energy research scientific computing center,” in Workshop Proceedings of the 48th International Conference on Parallel Processing, 2019, pp. 1–9. [5] S. Sankar, M. Shaw, and K. Vaid, “Impact of temperature on hard disk drive reliability in large datacenters,” in 2011 IEEE/IFIP 41st international conference on dependable systems & networks (DSN). IEEE, 2011, pp. 530–537. [6] S. Han, P. P. Lee, F. Xu, Y. Liu, C. He, and J. Liu, “An {In-Depth} study of correlated failures in production {SSD-Based} data centers,” in 19th USENIX Conference on File and Storage Technologies (FAST 21), 2021, pp. 417–429.

[7] W. Shin, V. Oles, A. M. Karimi, J. A. Ellis, and F. Wang, “Revealing power, energy and thermal dynamics of a 200pf pre-exascale supercomputer,” in Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis, 2021, pp. 1–14. [8] J. Li, G. Ali, N. Nguyen, J. Hass, A. Sill, T. Dang, and Y. Chen, “Monster: an out-of-the-box monitoring tool for high performance computing systems,” in 2020 IEEE international conference on cluster computing (CLUSTER). IEEE, 2020, pp. 119–129. [9] C. Chen, G. Wang, J. Sun, and W. Xu, “Detecting data center cooling problems using a data-driven approach,” in Proceedings of the 9th Asiapacific workshop on systems, 2018, pp. 1–8. [10] R. Isermann, Fault-diagnosis systems: an introduction from fault detection to fault tolerance. Springer Science & Business Media, 2005. [11] I. Hwang, S. Kim, Y. Kim, and C. E. Seah, “A survey of fault detection, isolation, and reconfiguration methods,” IEEE transactions on control systems technology, vol. 18, no. 3, pp. 636–653, 2009. [12] O. Tuncer, E. Ates, Y. Zhang, A. Turk, J. Brandt, V. J. Leung, M. Egele, and A. K. Coskun, “Diagnosing performance variations in hpc applications using machine learning,” in International Conference on High Performance Computing. Springer, 2017, pp. 355–373. [13] A. Netti, Z. Kiziltan, O. Babaoglu, A. Sı̂rbu, A. Bartolini, and A. Borghesi, “A machine learning approach to online fault classification in hpc systems,” Future Generation Computer Systems, vol. 110, pp. 1009– 1022, 2020. [14] M. Molan, M. S. Ardebili, J. A. Khan, F. Beneventi, D. Cesarini, A. Borghesi, and A. Bartolini, “Graafe: Graph anomaly anticipation framework for exascale hpc systems,” Future Generation Computer Systems, vol. 160, pp. 644–653, 2024. [15] A. Borghesi, A. Bartolini, M. Lombardi, M. Milano, and L. Benini, “Anomaly detection using autoencoders in high performance computing systems,” in Proceedings of the AAAI Conference on artificial intelligence, vol. 33, no. 01, 2019, pp. 9428–9433. [16] B. Aksar, Y. Zhang, E. Ates, B. Schwaller, O. Aaziz, V. J. Leung, J. Brandt, M. Egele, and A. K. Coskun, “Proctor: A semi-supervised performance anomaly diagnosis framework for production hpc systems,” in International Conference on High Performance Computing. Springer, 2021, pp. 195–214. [17] B. Aksar, E. Sencan, B. Schwaller, O. Aaziz, V. J. Leung, J. Brandt, B. Kulis, and A. K. Coskun, “Albadross: Active learning based anomaly diagnosis for production hpc systems,” in 2022 IEEE International Conference on Cluster Computing (CLUSTER). IEEE, 2022, pp. 369– 380. [18] M. S. Ardebili, A. Acquaviva, L. Benini, and A. Bartolini, “Elevating datacenter resilience with thermadnet: A thermal anomaly detection system,” Future Generation Computer Systems, vol. 179, p. 108311, 2026. [19] F. K. Stehle, W. Vandelli, F. Zahn, G. Avolio, and H. Fröning, “Deephydra: A hybrid deep learning and dbscan-based approach to time-series anomaly detection in dynamically-configured systems,” in Proceedings of the 38th ACM International Conference on Supercomputing, 2024, pp. 272–285. [20] M. Molan, A. Borghesi, D. Cesarini, L. Benini, and A. Bartolini, “Ruad: Unsupervised anomaly detection in hpc systems,” Future Generation Computer Systems, vol. 141, pp. 542–554, 2023. [21] E. Sencan, Y.-C. Lee, C. Casey, B. Schwaller, V. J. Leung, J. Brandt, B. Kulis, M. Egele, and A. K. Coskun, “Refine: A robust approach to unsupervised anomaly detection for production hpc systems,” in ISC High Performance 2025 Research Paper Proceedings (40th International Conference). Prometeus GmbH, 2025, pp. 1–12. [22] J. Audibert, P. Michiardi, F. Guyard, S. Marti, and M. A. Zuluaga, “Usad: Unsupervised anomaly detection on multivariate time series,” in Proceedings of the 26th ACM SIGKDD international conference on knowledge discovery & data mining, 2020, pp. 3395–3404. [23] Í. Goiri, T. D. Nguyen, and R. Bianchini, “Coolair: Temperatureand variation-aware management for free-cooled datacenters,” ACM SIGPLAN Notices, vol. 50, no. 4, pp. 253–265, 2015. [24] A. Naug, A. Guillen, R. Luna, V. Gundecha, C. Bash, S. Ghorbanpour, S. Mousavi, A. R. Babu, D. Markovikj, L. D. Kashyap et al., “Sustaindc: Benchmarking for sustainable data center control,” Advances in Neural Information Processing Systems, vol. 37, pp. 100 630–100 669, 2024. [25] F. T. Liu, K. M. Ting, and Z.-H. Zhou, “Isolation forest,” in 2008 eighth ieee international conference on data mining. IEEE, 2008, pp. 413–422.

[26] P. Malhotra, A. Ramakrishnan, G. Anand, L. Vig, P. Agarwal, and G. Shroff, “Lstm-based encoder-decoder for multi-sensor anomaly detection,” arXiv preprint arXiv:1607.00148, 2016. [27] J. B. McQueen, “Some methods of classification and analysis of multivariate observations,” in Proc. of 5th Berkeley Symposium on Math. Stat. and Prob., 1967, pp. 281–297. [28] R. J. Campello, D. Moulavi, and J. Sander, “Density-based clustering based on hierarchical density estimates,” in Pacific-Asia conference on knowledge discovery and data mining. Springer, 2013, pp. 160–172. [29] P. J. Rousseeuw, “Silhouettes: a graphical aid to the interpretation and validation of cluster analysis,” Journal of computational and applied mathematics, vol. 20, pp. 53–65, 1987. [30] F. Voutsas, J. Violos, and A. Leivadeas, “Mitigating alert fatigue in cloud monitoring systems: A machine learning perspective,” Computer Networks, vol. 250, p. 110543, 2024. [31] A. Das and A. Aiken, “Prolego: Time-series analysis for predicting failures in complex systems,” in 2023 IEEE International Conference on Autonomic Computing and Self-Organizing Systems (ACSOS). IEEE, 2023, pp. 77–86.

Related documents

• Plenty of Room in the Middle: Revealing Opportunities on a GPU Cluster via Fine-Grained Monitoring#1473582
• Plenty of Room in the Middle: Revealing Opportunities on a GPU Cluster via Fine-Grained Monitoring#1467653
• GICC: A High-Performance Runtime for GPU-Initiated Communication and Coordination in Modern HPC Systems#134526
• Characterizing the I/O Behavior of HPC Applications through Modeling and Simulation#618541
• Scheduling Coflows in Multi-Core OCS Networks with Performance Guarantee#1063890