FaultTrack

FaultTrack reads the per-service Prometheus metrics around an alert, predicts which kind of fault it is (cpu, mem, disk, socket, delay or loss), and names the service where the fault most likely started with a separate rule.

Model … · generated … · API docs (Swagger UI) · source on GitHub

Headline

Fault-type macro F1 on grouped 5-fold cross-validation across all three systems, grouped by case so that windows of one case never sit in both train and test. Mean ± std across folds, with min–max.

Fault type, macro F1 (model)
Fault type on an unseen system (leave-one-system-out)
Mean ± std across 3 held-out systems. Details below.
One-vs-rest ROC AUC (model)
Suspect-service hit rate (rule, not the model)
Share of windows where the most-anomalous service is the injected one. No training involved.

Per-class results

Precision, recall and F1 for each fault type, pooled over the held-out folds of the grouped cross-validation.

Per-class metrics (model)
FaultPrecisionRecallF1Rows

Confusion matrix: rows are the true fault, columns the predicted one. Shaded cells hold more windows, and every cell shows its count.

predicted
Confusion matrix (counts of windows), true fault by predicted fault

Detection delay

Macro F1 when the model sees only the first seconds of metrics after the alert. Mean ± std across folds, with min–max.

Macro F1 by seconds of data after the alert
SecondsMacro F1Min–max

Generalizing to an unseen system

Leave-one-system-out trains on two of the RCAEval RE2 systems and tests on the third. This is the situation of a team running FaultTrack on its own cluster.

Macro F1 with one system held out
Held-out systemMacro F1

Sample held-out cases

A few cases from the held-out folds. The misses are kept. The Model column marks the fault type (from the model); the Rule column marks the suspect service (from the rule).

Sample cases: model fault and rule suspect service
CaseTrue faultModel saysProbabilityModel Injected serviceRule suspectsRule

Runbook tree