Pith. sign in

REVIEW 4 major objections 5 minor 38 references

A two-level pattern-mining workflow compresses 900GB of HPC logs into roughly 20MB of automaton-stored patterns and sequences, retrieves them in milliseconds, and captures near-100% of high-priority error messages.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

T0 review · deepseek-v4-flash

2026-08-01 13:17 UTC pith:PTM2IGAM

load-bearing objection A credible workflow integration with a circular accuracy metric; the compression numbers are real, the anomaly detection claim is not. the 4 major comments →

arxiv 2607.19143 v1 pith:PTM2IGAM submitted 2026-07-21 cs.DC

A Scalable Pattern Mining Workflow for Interpretable Machine Log Analysis in High-Performance Computing Environments

Shilpika Shilpika , Bethany Lusch , Eric Pershey , Carlo Graziani , Venkatram Vishwanath , Michael E. Papka This is my paper
classification cs.DC
keywords HPC log analysispattern miningsequence miningAho-Corasick automatonanomaly detectionexascale supercomputerssyslog priorityfailure prediction
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

This paper aims to establish that an end-to-end log-analysis workflow, built from pattern extraction, two-level sequence mining, and Aho-Corasick automata, can turn noisy, heterogeneous supercomputer logs into a compact, searchable representation that supports real-time monitoring and failure analysis. The authors show that 900GB of raw syslogs from an exascale-class machine compress to about 8.8MB of patterns and 12MB of sequences, with pattern retrieval taking milliseconds. They demonstrate that priority-weighted sequence mining recovers essentially all high-priority (syslog priority < 5) messages from failed jobs, and that clustering node-level pattern frequencies separates healthy nodes from error-prone ones. The significance is practical: at exascale, logs are too large and too messy for traditional analysis, and a workflow that reduces them to searchable patterns and sequences could make online anomaly detection and predictive failure analysis feasible. A sympathetic reader would take the central contribution to be the demonstrated compression-and-retrieval pipeline, with the near-100% accuracy claim applying specifically to retrieval of the high-priority messages the algorithm is designed to prioritize.

Core claim

The paper's central claim is that combining pattern mining with priority-weighted, two-level sequence mining and storing the results in Aho-Corasick finite-state automata yields a scalable workflow for exascale HPC log analysis. At Level 1, the TUP algorithm extracts top-k high-importance pattern sequences for each process within a node; at Level 2, the CLH-Miner algorithm extracts cross-level sequences across jobs and nodes. These sequences are stored in a second automaton (seq-AHO) that supports prefix lookup and autocompletion of likely next pattern IDs. The authors report that this pipeline compresses 900GB of syslogs to roughly 20MB, retrieves patterns in 0.3–3 milliseconds, and recover

What carries the argument

The workflow uses two Aho-Corasick automata—pat-AHO, which stores the static parts of log messages as patterns with unique IDs, and seq-AHO, which stores sequences of pattern IDs as strings and includes a trie for autocomplete. Two sequence-mining algorithms do the heavy lifting: TUP (top-k high-utility episode mining) extracts process-level sequences at Level 1, and CLH-Miner (cross-level high-utility itemset mining) extracts job- and node-level sequences at Level 2. Syslog priority fields are converted to importance scores (e.g., EMERGENCY=100,000, DEBUG=1) so that rare critical messages are weighted far above frequent informational ones. The automata make both retrospective and real-time

Load-bearing premise

The near-100% accuracy figures rest on the assumption that high-priority syslog lines (priority below 5) are exactly the messages that matter for failure detection, and since the algorithms are deliberately designed to retrieve those lines, the metric measures internal consistency rather than independent detection of real failures.

What would settle it

Run the workflow on logs from a period with known, labeled node or job failures, and check whether the high-priority sequences it flags align with the actual failure events; if retrieval of priority<5 lines stays near 100% but the flagged sequences do not correspond to real failures, the central claim of predictive failure analysis collapses.

Watch this falsifier — get emailed when new claim-graph text bears on it.

If this is right

  • Compression from 900GB of raw logs to roughly 20MB of patterns and sequences makes the full corpus searchable in memory, enabling retrospective analysis on a single node.
  • Millisecond-level pattern retrieval and per-process sequence mining around 0.3 seconds make the workflow plausible for real-time or near-real-time monitoring on production systems.
  • The two-level hierarchy (process → node → job) yields job-level error signatures, allowing jobs to be grouped by shared failure modes and distinguishing user-specific behavior.
  • The compressed pattern-ID format can feed downstream LLM-based pipelines, including retrieval-augmented generation, which cannot ingest terabyte-scale raw text logs directly.
  • If the near-100% retrieval of high-priority messages holds more broadly, it provides a fast filter that reduces the search space for root-cause analysis and failure diagnosis.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Editorial inference: The reported 'accuracy' only verifies that the algorithms retrieve the high-priority log lines they were explicitly designed to prioritize; it does not independently validate that those lines correspond to actual failures, so a separate ground-truth evaluation would be needed to support the stronger predictive-failure claim.
  • Editorial inference: The automaton autocomplete suggests a natural extension—using stored sequences to predict the next error pattern in an online stream—but the paper does not measure whether autocompleted sequences actually precede failures in time, leaving lead-time prediction untested.
  • Editorial inference: The pattern-ID compression scheme could generalize to other multi-source telemetry (sensor, network, power) if the same extraction step were applied, but the authors explicitly note that root-cause analysis would require combining text data with numeric and event data, which is outside this workflow's scope.
  • Editorial inference: Because minimum-importance thresholds and priority scores are set by the user, the workflow's effectiveness depends on domain expertise; automating importance detection, which the paper lists as future work, would make it more turnkey and less subjective.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. The paper proposes an end-to-end workflow for mining interpretable patterns and pattern sequences from raw text-based HPC logs. Retrospective analysis extracts message templates with Aho-Corasick automata (pat-AHO), assigns importance scores based on syslog priorities, mines co-occurring patterns using TUP (level 1) and CLH-Miner (level 2), and stores the resulting sequences in a second automaton (seq-AHO) for fast lookup and autocomplete. The authors report compressed storage of 900 GB of logs into ~20 MB, millisecond retrieval times, and 96–100% "accuracy" for retrieving high-priority log lines, and conclude that the workflow enables online anomaly detection and predictive failure analysis.

Significance. If properly validated, the proposed workflow could be a useful engineering contribution: it offers a compact, interpretable representation of HPC logs, embarrassingly parallel level-1 mining, and an automaton-based structure for sequence lookup and autocompletion. The storage compression and retrieval timings are interesting. However, the central quantitative claim is not supported by the evaluation as written. The accuracy metric is defined relative to the algorithm's own priority labels rather than any ground truth about failures or anomalies, and the case study is anecdotal. The paper's advertised predictive and online capabilities go beyond what the experiments demonstrate. The strengths are the workflow design and the reported scale, but the evaluation would need substantial revision before the main claims can be accepted.

major comments (4)
  1. [Section V, Tables III and IV] The accuracy metric is circular. The text states: "Accuracy is measured by whether the algorithm retrieves all high-priority sequences." Since TUP and CLH-Miner are explicitly designed to mine high-importance patterns (Section III-B), the 96–100% figures measure recall relative to the input priority labels, not detection or prediction quality. Table IV's own note admits the metric only checks retrieval of sequences identified by level 1. This does not support the conclusion in Section VI of "near 100% accuracy for rare, high-priority messages" enabling "online anomaly detection and predictive failure analysis." Moreover, the "rare" characterization is contradicted by the data: Table III rows show high-priority lines constitute 96–99.8% of log lines in several files. A valid evaluation must use a ground-truth failure or anomaly set (e.g., jobs with non-zero exit codes) and report precisio
  2. [Section V, overall evaluation] No baselines are provided. The paper dismisses Drain and Spell in Section II as "fragile" and "heuristic," but no empirical comparison on the same dataset is reported. Without comparison to standard log parsers, sequence-mining baselines, or simple counting/priority-threshold methods, the claimed advantages of the workflow cannot be assessed. The paper should report at least a runtime, compression, and detection-quality comparison on a common benchmark or on the same exascale logs.
  3. [Section IV-B, case study] The case study is qualitative: 8 jobs from 2 users, with visual inspection of scatter plots and descriptions of "unique signatures." No quantitative analysis connects the mined sequences to the job outcomes (the underlined jobs with non-zero exit status are not enumerated, and no sequence-level statistics are given for failed vs. successful jobs). The paper states that root-cause analysis is out of scope, but without linking sequences to actual failures, the claim of "predictive failure analysis" is unsupported. At minimum, the authors should report whether specific sequences are statistically more frequent in or predictive of failed jobs.
  4. [Section V-A, performance evaluation] The real-time claim is not tested. Table II reports retrieval times for individual strings of 65–1094 characters, which is only a microbenchmark of the automaton lookup. The full real-time pipeline—raw log ingestion, variable-part removal, pattern ID assignment, sequence lookup, and autocomplete—is never evaluated as an online stream. Tables III and IV report offline per-file processing times, not end-to-end online latency. The paper should either add a streaming benchmark or temper the "online" language in Section VI.
minor comments (5)
  1. [Section III-B] "the sequence mining (pat-AHO)" appears to be a typo; the intended reference is likely seq-AHO.
  2. [Section V-A, Table II] The text says "The ID column is a unique file ID," but Table II has no ID column. Either add the column or remove the sentence.
  3. [Section IV-A4, Figure 5] The PCA cluster analysis is described qualitatively. Please report preprocessing, number of components, explained variance, and any cluster validation metric. Without these, the visual separation into "head node," "error-prone nodes," and "server node" is not substantiated.
  4. [Section III-B and Table I] The importance scores in Table I are free parameters, and the text claims that "setting a larger difference ... yields more accurate results" without showing any sensitivity analysis. A short ablation over importance-score scalings would make the method more reproducible.
  5. [References] Reference [28] is incomplete (no authors, title, or venue beyond a URL). Please cite the canonical TUP paper. Also, reference [19] is a Wikipedia URL; a more durable citation is preferable.

Circularity Check

2 steps flagged

Accuracy metric is circular: near-100% accuracy is defined as retrieval of the high-priority messages the mining algorithms are explicitly designed to find.

specific steps
  1. self definitional [Section V-A, Tables III-IV; Section III-B]
    "Accuracy is measured by whether the algorithm retrieves all high-priority sequences. We are only looking for high-priority sequences, as they are fewer in number and more critical than warning, alert, and informational messages... Note that if level 1 missed a high-importance pattern, then that would be missed by level 2 as well, since the input to level 2 is the output of level 1. The accuracy only indicates whether level 2 sequence mining retrieves all the high-importance sequences identified by level 1."

    The target set is defined by the same importance scores that drive the algorithms: Section III-B states TUP identifies 'top K patterns with high importance' and that 'Assigning the importance scores forces the algorithm to focus more on the rare critical messages.' High Priority Lines are priority<5. Thus 'accuracy' is a recall check that a high-importance-focused miner found high-importance lines in the same logs from which the sequences were mined. The 96-100% figures restate the algorithm's objective; they do not validate anomaly detection or failure prediction, despite the conclusion's claim of 'near 100% accuracy for rare, high-priority messages.'

  2. other [Section III-A real-time analysis and Section VI conclusion]
    "If the sequence is present, we can perform a lookup in the seq-AHO (trie data structure) to identify the next likely pattern IDs and their past occurrences count."

    The real-time 'prediction' is a trie lookup over sequences previously mined and stored from the same historical logs; the 'next likely' IDs are exactly the stored suffixes. No held-out or future data is used, and no predictive accuracy is measured. The conclusion's 'online anomaly detection and predictive failure analysis' therefore reduces to replaying stored continuations rather than an independent predictive result.

full rationale

The paper's central quantitative claim rests on an evaluation definition that is circular. In Section V, accuracy is defined as whether the sequence miners retrieve all high-priority sequences, where the miners' objective is precisely to find high-importance patterns (Section III-B). The high-priority lines in Tables III and IV are the same lines the importance scores direct TUP and CLH-Miner to recover, measured on the same data used to build the sequences. The 96-100% figures are therefore a recall check on the input, not an independent validation of anomaly detection or failure prediction. The Level 2 caveat explicitly concedes that accuracy only reflects Level 1's identified sequences. The real-time autocomplete channel similarly returns previously stored suffixes from seq-AHO, so the conclusion's 'predictive failure analysis' is not supported by any held-out predictive experiment. No baseline comparison or ground-truth failure labels are provided; the case study is anecdotal. I find no separate self-citation circularity; the circularity is in the evaluation metric itself, warranting a score of 8.

Axiom & Free-Parameter Ledger

5 free parameters · 3 axioms · 0 invented entities

The paper does not introduce new physical or conceptual entities; its assumptions are about the structure of log data and the semantics of priority levels. The most consequential free parameters are the importance scores and the minimum-importance thresholds, which directly shape the output sequences and the reported accuracy.

free parameters (5)
  • Importance scores for syslog priorities = EMERGENCY=100000, ALERT=90000, CRITICAL=70000, ERROR=60000, WARNING=8000, NOTICE=2000, INFO=1, DEBUG=1
    Table I assigns weight values to priority classes. The authors state that 'setting a larger difference in importance scores between lower- and higher-priority log messages yields more accurate results,' indicating these values were tuned to make the algorithm produce favorable output.
  • Top-k parameter for TUP = 10 (stated in Section IV-B-1)
    The number of top sequences extracted at level 1 is set to 10; no sensitivity analysis is given.
  • Minimum importance threshold = 10, 100, 1000, 5000 (Table IV)
    The user must choose a threshold that determines which sequences to keep; the paper lists 'automating the setting of the minimum support variable' as future work, acknowledging the parameter's arbitrary nature.
  • Time window length for sequence extraction = Not specified numerically
    The 'rules specify the maximum time window length and the number of sequences to extract within it' (Section IV-B), but the actual window length is not reported, leaving a crucial parameter unstated.
  • Deduplication interval = 10 seconds
    The paper states 'We retain only the unique messages at every 10-second interval at the process level.' This interval is a user-chosen parameter that directly influences which patterns are considered co-occurring.
axioms (3)
  • domain assumption Log messages have a stable non-variable part that can be extracted as a pattern by removing variable fields.
    Section III-A states the non-variable part is 'retained and saved' as a pattern. If message templates evolve or variable parts are not cleanly separable, pattern IDs become unstable, breaking the entire workflow.
  • domain assumption The syslog priority field (or user-assigned importance) correctly reflects the operational importance of a message.
    The entire weighting scheme in TUP and CLH-Miner, and the evaluation metric that focuses on 'high-priority' lines, assumes that priority levels such as ERROR/CRITICAL are the ones that matter for detecting faults. The paper provides no evidence that low-priority lines cannot be harbingers of failures.
  • ad hoc to paper Co-occurrence of patterns within a process and within a short time window constitutes a meaningful sequence that can characterize job failures.
    The workflow defines sequences as patterns that co-occur temporally after deduplication. There is no external validation that these co-occurrence groups correspond to actual causal chains or failure modes; the case study is anecdotal.

pith-pipeline@v1.3.0-alltime-deepseek · 14255 in / 6646 out tokens · 60606 ms · 2026-08-01T13:17:39.671758+00:00 · methodology

0 comments
read the original abstract

Modern supercomputers housed in High Performance Computing (HPC) environments generate massive volumes of log data daily, revealing intricate information and performance metrics about these complex systems. The sheer size and heterogeneous nature of HPC logs, especially text data, pose significant challenges for traditional analytical techniques. Consequently, more complex workflows are necessary for pattern extraction when analyzing these logs, enabling the discovery of underlying patterns and anomalies that may indicate system faults and help predict future failures and inefficiencies. Our log analysis workflow investigates a combination of advanced pattern-matching and mining techniques applied to HPC log analysis. By systematically identifying frequent log patterns and pattern sequences in log messages and storing them in a finite-state automaton, such as the Aho-Corasick automaton, our workflow enables automated detection of frequent errors and fault events. To extract these patterns and sequences, we leverage information about system hierarchy and message priority. We then correlate and cluster the identified error sequences with job logs, revealing groups of applications with similar or dissimilar error signatures. This approach yields insights that inform improvements and guide real-time monitoring efforts. Our research establishes that pattern mining is vital for unlocking the full potential of log data by enabling real-time analysis and contributing to more resilient, scalable HPC systems. We demonstrate the effectiveness of our approach through summary statistics and a case study on an exascale-class system supercomputer.

Figures

Figures reproduced from arXiv: 2607.19143 by Bethany Lusch, Carlo Graziani, Eric Pershey, Michael E. Papka, Shilpika Shilpika, Venkatram Vishwanath.

Figure 1
Figure 1. Figure 1: Log Pattern Mining Workflow Overview including Aho–Corasick, for matching log records and builds a log-matching tool [20]. Bellekens et al. (2014) present GLoP, a GPU library for security log analysis with GPU-accelerated Aho–Corasick [21]. Potharaju et al. (2013) use Aho–Corasick inside NetSieve to compute frequencies of repeated phrases extracted from network trouble tickets [22]. Konchagin et al. (2018)… view at source ↗
Figure 2
Figure 2. Figure 2: Most frequent log patterns grouped by projects. The x-axis shows distinct log message patterns (pattern IDs) and the y-axis shows the corresponding [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Most frequent log patterns grouped by identifiers (top) and users (bottom). Identifiers indicate the source component or subsystem generating a log [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: Error patterns in a force-directed scatterplot of jobs versus timestamps. [PITH_FULL_IMAGE:figures/full_fig_p006_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: PCA plot of the node-level variation in log messages computed by [PITH_FULL_IMAGE:figures/full_fig_p006_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: Overview of the sequence mining workflow. [PITH_FULL_IMAGE:figures/full_fig_p007_6.png] view at source ↗
Figure 7
Figure 7. Figure 7: Error patterns in a force-directed scatterplot of jobs versus timestamps. Each point is a log pattern seen in a process of a job’s node. The size of the [PITH_FULL_IMAGE:figures/full_fig_p008_7.png] view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

38 extracted references · 1 canonical work pages

  1. [1]

    Big data meets hpc log analytics: Scalable approach to understanding systems at extreme scale,

    B. H. Park, S. Hukerikar, R. Adamson, and C. Engelmann, “Big data meets hpc log analytics: Scalable approach to understanding systems at extreme scale,” in2017 IEEE International Conference on Cluster Computing (CLUSTER), 2017, pp. 758–765

    2017

  2. [2]

    Instruction-tuned llms for parsing and mining unstructured logs on leadership hpc systems,

    A. M. Karimi, J. Y . Choi, C. Q. Cao, and A. Khan, “Instruction-tuned llms for parsing and mining unstructured logs on leadership hpc systems,” 2026. [Online]. Available: https://arxiv.org/abs/2604.05168

    Pith/arXiv arXiv 2026

  3. [3]

    Logmaster: Mining event correlations in logs of large-scale cluster systems,

    X. Fu, R. Ren, J. Zhan, W. Zhou, Z. Jia, and G. Lu, “Logmaster: Mining event correlations in logs of large-scale cluster systems,” in2012 IEEE 31st Symposium on Reliable Distributed Systems, 2012, pp. 71–80

    2012

  4. [4]

    Clusterlog: Clustering logs for effective log-based anomaly detection,

    C. Egersdoerfer, D. Dai, and D. Zhang, “Clusterlog: Clustering logs for effective log-based anomaly detection,” 2023. [Online]. Available: https://arxiv.org/abs/2301.07846

    Pith/arXiv arXiv 2023

  5. [5]

    Assessing data usefulness for fail- ure analysis in anonymized system logs,

    S. Ghiasvand and F. M. Ciorba, “Assessing data usefulness for fail- ure analysis in anonymized system logs,” in2018 17th International Symposium on Parallel and Distributed Computing (ISPDC), 2018, pp. 164–171

    2018

  6. [6]

    Epic: Generative ai platform for accelerating hpc operational data analytics,

    A. M. Karimi, W. Shin, J. Hines, T. Ghosal, N. S. Sattar, and F. Wang, “Epic: Generative ai platform for accelerating hpc operational data analytics,” 2025. [Online]. Available: https://arxiv.org/abs/2509.16212

    arXiv 2025

  7. [7]

    Clairvoyant: a log-based transformer-decoder for failure prediction in large- scale systems,

    K. A. Alharthi, A. Jhumka, S. Di, and F. Cappello, “Clairvoyant: a log-based transformer-decoder for failure prediction in large- scale systems,” inProceedings of the 36th ACM International Conference on Supercomputing, ser. ICS ’22. New York, NY , USA: Association for Computing Machinery, 2022. [Online]. Available: https://doi.org/10.1145/3524059.3532374

    arXiv 2022

  8. [8]

    Time machine: Generative real-time model for failure (and lead time) prediction in HPC systems,

    K. A. Alharthi, A. Jhumka, S. Di, L. Gui, F. Cappello, and S. McIntosh-Smith, “Time machine: Generative real-time model for failure (and lead time) prediction in HPC systems,” in2023 53rd Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN), 2023, pp. 508–521. [Online]. Available: https://doi.org/10.1109/DSN58367.2023.00054

    arXiv 2023

  9. [9]

    Analyzing and predicting job failures from HPC system log,

    J.-W. Park, X. Huang, and C.-H. Lee, “Analyzing and predicting job failures from HPC system log,”The Journal of Supercomputing, vol. 80, pp. 435–462, 2024. [Online]. Available: https://doi.org/10.1007/ s11227-023-05482-y

    2024

  10. [10]

    Analyzing a lifetime of failures on a cray xc40 supercomputer,

    K. A. Brown, T. Mallick, Z. Lan, R. B. Ross, and C. D. Carothers, “Analyzing a lifetime of failures on a cray xc40 supercomputer,” in Proceedings of the Cray User Group, ser. CUG ’25. New York, NY , USA: Association for Computing Machinery, 2025, p. 103–114. [Online]. Available: https://doi.org/10.1145/3757348.3757360

    arXiv 2025

  11. [11]

    Sentilog: Anomaly detecting on parallel file systems via log-based sentiment analysis,

    D. Zhang, D. Dai, R. Han, and M. Zheng, “Sentilog: Anomaly detecting on parallel file systems via log-based sentiment analysis,” inProceedings of the 13th ACM Workshop on Hot Topics in Storage and File Systems, ser. HotStorage ’21. New York, NY , USA: Association for Computing Machinery, 2021, p. 86–93. [Online]. Available: https://doi.org/10.1145/3465332.3470873

    arXiv 2021

  12. [12]

    ModuleLog: Module based approach to anomaly detection in parallel file system logs,

    C. Egersdoerfer, D. Dai, and D. Zhang, “ModuleLog: Module based approach to anomaly detection in parallel file system logs,” https: //ninercommons.charlotte.edu/record/4157?ln=en&v=pdf, 2022, [Ac- cessed 07-05-2026]

    2022

  13. [13]

    Mela: A visual analytics tool for studying multifidelity hpc system logs,

    F. Shilpika, B. Lusch, M. Emani, V . Vishwanath, M. E. Papka, and K.-L. Ma, “Mela: A visual analytics tool for studying multifidelity hpc system logs,” in2019 IEEE/ACM Industry/University Joint International Workshop on Data-center Automation, Analytics, and Control (DAAC), 2019, pp. 13–18

    2019

  14. [14]

    A multi-level, multi-scale visual analytics approach to assessment of multifidelity hpc systems,

    S. Shilpika, B. Lusch, M. Emani, F. Simini, V . Vishwanath, M. E. Papka, and K.-L. Ma, “A multi-level, multi-scale visual analytics approach to assessment of multifidelity hpc systems,” in2024 IEEE 24th Interna- tional Symposium on Cluster, Cloud and Internet Computing (CCGrid), 2024, pp. 478–488

    2024

  15. [15]

    An incremental multi-level, multi-scale approach to assessment of multifidelity hpc systems,

    Shilpika, B. Lusch, V . Vishwanath, and M. E. Papka, “An incremental multi-level, multi-scale approach to assessment of multifidelity hpc systems,” inProceedings of the SC ’24 Workshops of the International Conference on High Performance Computing, Network, Storage, and Analysis, ser. SC-W ’24. IEEE Press, 2025, p. 1576–1587. [Online]. Available: https://...

    arXiv 2025

  16. [16]

    Spell: Streaming parsing of system event logs,

    M. Du and F. Li, “Spell: Streaming parsing of system event logs,” in 2016 IEEE 16th International Conference on Data Mining (ICDM), 2016, pp. 859–864

    2016

  17. [17]

    Drain: An online log parsing approach with fixed depth tree,

    P. He, J. Zhu, Z. Zheng, and M. R. Lyu, “Drain: An online log parsing approach with fixed depth tree,” in2017 IEEE International Conference on Web Services (ICWS), 2017, pp. 33–40

    2017

  18. [18]

    Efficient string matching: an aid to bibliographic search,

    A. V . Aho and M. J. Corasick, “Efficient string matching: an aid to bibliographic search,”Commun. ACM, vol. 18, no. 6, p. 333–340, Jun

  19. [19]

    https://en.wikipedia.org/wiki/AhoCorasick algorithm, [Accessed 06-05- 2026]

    2026

  20. [20]

    Efficient multi-pattern log matching in go language,

    F. Halas, “Efficient multi-pattern log matching in go language,” 2014. [Online]. Available: https://is.muni.cz/th/xbva1/thesis.pdf

    2014

  21. [21]

    Glop: Enabling massively parallel incident response through gpu log processing,

    X. J. A. Bellekens, C. Tachtatzis, R. C. Atkinson, C. Renfrew, and T. Kirkham, “Glop: Enabling massively parallel incident response through gpu log processing,” inProceedings of the 7th International Conference on Security of Information and Networks, ser. SIN ’14. New York, NY , USA: Association for Computing Machinery, 2014, p. 295–301. [Online]. Availa...

    arXiv 2014

  22. [22]

    Juggling the jigsaw: towards automated problem inference from network trouble tickets,

    R. Potharaju, N. Jain, and C. Nita-Rotaru, “Juggling the jigsaw: towards automated problem inference from network trouble tickets,” inProceed- ings of the 10th USENIX Conference on Networked Systems Design and Implementation, ser. nsdi’13. USA: USENIX Association, 2013, p. 127–142

    2013

  23. [23]

    On the efficient application of aho-corasick algorithm in process mining,

    A. M. Konchagin and A. A. Kalenkova, “On the efficient application of aho-corasick algorithm in process mining,” inAnalysis of Images, Social Networks and Texts. Cham: Springer International Publishing, 2018, pp. 371–377

    2018

  24. [24]

    Constructing the knowledge base for cognitive it service management,

    Q. Wang, W. Zhou, C. Zeng, T. Li, L. Shwartz, and G. Y . Grabarnik, “Constructing the knowledge base for cognitive it service management,” in2017 IEEE International Conference on Services Computing (SCC), 2017, pp. 410–417

    2017

  25. [25]

    Deterministic memory-efficient string matching algorithms for intrusion detection,

    N. Tuck, T. Sherwood, B. Calder, and G. Varghese, “Deterministic memory-efficient string matching algorithms for intrusion detection,” in IEEE INFOCOM 2004, vol. 4, 2004, pp. 2628–2639 vol.4

    2004

  26. [26]

    A high throughput string matching architecture for intrusion detection and prevention,

    L. Tan and T. Sherwood, “A high throughput string matching architecture for intrusion detection and prevention,” inProceedings of the 32nd Annual International Symposium on Computer Architecture (ISCA), 2005, pp. 112–122

    2005

  27. [27]

    A memory- efficient reconfigurable aho-corasick fsm implementation for intrusion detection systems,

    V . Dimopoulos, I. Papaefstathiou, and D. N. Pnevmatikatos, “A memory- efficient reconfigurable aho-corasick fsm implementation for intrusion detection systems,” inInternational Conference on Embedded Computer Systems: Architectures, Modeling and Simulation (IC-SAMOS), 2007, pp. 186–193

    2007

  28. [28]

    philippe-fournier- viger.com,

    S. Rathore, S. Dawar, V . Goyal, and D. Patel, “philippe-fournier- viger.com,” https://www.philippe-fournier-viger.com/spmf/TUP.pdf, [Accessed 07-05-2026]

    2026

  29. [29]

    THUE: discovering top-k high utility episodes,

    S. Wan, J. Chen, W. Gan, G. Chen, and V . Goyal, “THUE: discovering top-k high utility episodes,”CoRR, vol. abs/2106.14830, 2021. [Online]. Available: https://arxiv.org/abs/2106.14830

    Pith/arXiv arXiv 2021

  30. [30]

    Mining cross-level high utility itemsets,

    P. Fournier-Viger, Y . Wang, J. C.-W. Lin, J. M. Luna, and S. Ventura, “Mining cross-level high utility itemsets,” inTrends in Artificial Intelligence Theory and Applications. Artificial Intelligence Practices: 33rd International Conference on Industrial, Engineering and Other Applications of Applied Intelligent Systems, IEA/AIE 2020, Kitakyushu, Japan, S...

    doi:10.1007/978-3-03 2020

  31. [31]

    Mining cost-effective patterns in event logs,

    P. Fournier-Viger, J. Li, J. C.-W. Lin, T. T. Chi, and R. Uday Kiran, “Mining cost-effective patterns in event logs,”Know.-Based Syst., vol. 191, no. C, Mar. 2020. [Online]. Available: https://doi.org/10.1016/j. knosys.2019.105241

    arXiv 2020

  32. [32]

    Sequence detection in event log files,

    I. Mavroudopoulos, T. Toliopoulos, C. Bellas, A. Kosmatopoulos, and A. Gounaris, “Sequence detection in event log files,” inInternational Conference on Extending Database Technology, 2021. [Online]. Available: https://api.semanticscholar.org/CorpusID:232283442

    2021

  33. [33]

    Log pattern mining for distributed system maintenance,

    J. Chen, P. Wang, S. Du, and W. Wang, “Log pattern mining for distributed system maintenance,”Complexity, vol. 2020, no. 1, p. 6628165, 2020. [Online]. Available: https://onlinelibrary.wiley.com/doi/ abs/10.1155/2020/6628165

    work page doi:10.1155/2020/6628165 2020

  34. [34]

    Discovery of frequent episodes in event logs,

    M. Leemans and W. M. P. van der Aalst, “Discovery of frequent episodes in event logs,” inData-Driven Process Discovery and Analysis, P. Cer- avolo, B. Russo, and R. Accorsi, Eds. Cham: Springer International Publishing, 2015, pp. 1–31

    2015

  35. [35]

    Online system problem detection by mining patterns of console logs,

    W. Xu, L. Huang, A. Fox, D. Patterson, and M. Jordan, “Online system problem detection by mining patterns of console logs,” in2009 Ninth IEEE International Conference on Data Mining, 2009, pp. 588–597

    2009

  36. [36]

    pyahocorasick &#x2014; ahocorasick documentation — pyaho- corasick.readthedocs.io,

    “pyahocorasick &#x2014; ahocorasick documentation — pyaho- corasick.readthedocs.io,” https://pyahocorasick.readthedocs.io/en/latest/ #testimonials, [Accessed 06-05-2026]

    2026

  37. [37]

    Redis reference — redis.io,

    “Redis reference — redis.io,” https://redis.io/docs/latest/develop/ reference/, [Accessed 06-05-2026]

    2026

  38. [1975]

    Available: https://doi.org/10.1145/360825.360855

    [Online]. Available: https://doi.org/10.1145/360825.360855

    arXiv