Pith. sign in

REVIEW 4 major objections 4 minor 48 references

The paper claims that feeding HDFS log-event templates through a pretrained language model before a bidirectional LSTM detects anomalous blocks far better than the standard event-ID baseline, with recall 99.37% at a top-7 threshold.

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-03 08:02 UTC pith:WPGHRMB5

load-bearing objection A sensible LLM+BiLSTM pipeline for HDFS log anomaly detection, but the headline F1 is fitted on the evaluation set and the DeepLog comparison uses different top-K values, so the performance claim does not hold. the 4 major comments →

arxiv 2607.29383 v1 pith:WPGHRMB5 submitted 2026-07-31 cs.LG cs.DCcs.SE

Exploring Block Anomaly Detection In HDFS Log Data Analysis

WenYang Zhong , Tutut Herawan This is my paper
classification cs.LG cs.DCcs.SE
keywords HDFSlog anomaly detectionblock anomaly detectionlarge language modelsLSTMBiLSTMlog parsingstreaming log processing
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 tries to show that a hybrid model—language-model embeddings of log templates fed into a bidirectional LSTM—can detect anomalous blocks in HDFS logs more accurately than the standard LSTM approach that uses event IDs. The authors build an unsupervised model trained only on normal block log sequences to predict the next log event, then flag blocks whose actual next event is not among the top-k predicted candidates. On an evaluation set of all 16,838 anomalous blocks plus an equal sample of normal blocks, they report recall of 99.37%, precision of 90.605%, and F1 of 94.785% at top-7, compared with the baseline's best F1 of 85.131%. They also assemble a streaming pipeline with a file monitor, message broker, and web interface. The value, if true, is that operators can catch nearly all anomalous blocks automatically while keeping false positives around ten percent, without needing labeled anomalies for training.

Core claim

The central claim is that replacing the sparse event-ID representation in next-event log prediction with dense semantic embeddings from a pretrained language model improves block-level anomaly detection. The model is trained on log sequences from normal blocks only; at inference, a block is anomalous when the actual next event is not among the model's top-7 predicted candidates. The authors report that this LLM-BiLSTM hybrid outperforms the LSTM-based baseline on every metric, with recall rising from 86.979% to 99.370% and F1 from 85.131% to 94.785%.

What carries the argument

The mechanism is a hybrid architecture: each of the 29 log event templates is converted by a pretrained text-embedding language model into a 4096-dimensional semantic vector; sliding windows of these vectors are fed into a two-layer bidirectional LSTM with dropout, which predicts a distribution over the next event template. The semantic embedding is what carries the argument—it lets the model generalize from the meaning of events rather than treating event IDs as arbitrary symbols. A top-k decision rule converts the predicted distribution into an anomaly flag, and k=7 is chosen as the F1-maximizing threshold on the evaluation set.

Load-bearing premise

The reported numbers rest on the assumption that the sampled normal blocks and the ground-truth labels are representative enough that choosing the top-7 threshold on the evaluation set generalizes to other HDFS blocks; if that sample is unrepresentative, the recall and F1 are overfit to the test set.

What would settle it

Take a fresh, independently labeled set of HDFS blocks from a different time period, fix k=7, and measure recall and precision without any re-tuning; if recall drops well below 99.37% or false positives rise substantially, the reported performance is an artifact of threshold selection on the original evaluation set.

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

Share X Bluesky LinkedIn Reddit HN

If this is right

  • Semantic embeddings for log templates can replace one-hot event IDs in log anomaly detection and improve recall substantially.
  • Training on normal sequences alone is sufficient; labeled anomalies are needed only for threshold selection and evaluation.
  • At top-7, the model flags about 99.37% of anomalous blocks while misclassifying roughly 10% of normal blocks as anomalous—useful for screening but not for fully automated action.
  • The proposed streaming pipeline can apply this detector to incremental log records in near real time, though the authors note prediction latency remains a bottleneck.

Where Pith is reading between the lines

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

  • The reported F1 is likely optimistic because top-7 was selected on the same evaluation set used for the final numbers; a threshold fixed on a separate validation set would give a fairer estimate of field performance.
  • Since rare error-related templates are almost perfectly predictive of anomalous blocks, part of the gain may come from the embedding letting the model recognize those rare events; a useful ablation would be removing rare-event blocks to see how much the hybrid adds on ordinary traffic.
  • The same embedding-plus-BiLSTM recipe could transfer to other distributed-system logs with small template vocabularies, because the language model provides shared semantics rather than dataset-specific IDs.
  • With only 29 unique templates, a 4096-dimensional embedding is computationally heavy; a smaller embedding or learnable template embedding might capture most of the benefit at lower latency—an easily testable variant.

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 / 4 minor

Summary. The paper presents an end-to-end workflow for HDFS log block anomaly detection. The core technical contribution is a hybrid model that first converts parsed log-event templates into dense embeddings using the Linq-Embed-Mistral large language model, then feeds those embeddings into a two-layer BiLSTM to predict the next log event in a block's log sequence. The model is trained only on normal blocks, making it an unsupervised next-event predictor; at prediction time, a block is flagged anomalous when the true next event is not among the model's top-K predictions. The authors evaluate this method on the Loghub HDFS dataset, report that top-7 gives precision 90.605%, recall 99.370%, and F1 94.785%, and claim that this outperforms DeepLog, which they report at its best top-3 setting. The paper also describes an HTCondor-based parallel preprocessing pipeline and a Kafka/Django-based real-time streaming and visualization system.

Significance. If the reported results were valid and reproducible, the paper would make a useful practical contribution: it demonstrates a plausible way to inject semantic information from LLM embeddings into a sequence-prediction anomaly detector for HDFS blocks, and it goes beyond a bare model by providing a complete streaming deployment architecture. The direction of replacing event IDs with semantic embeddings is reasonable and relevant to the log-anomaly-detection community. However, the evaluation as reported has a load-bearing methodological flaw: the top-K threshold is selected on the same evaluation set used to report the headline F1, the evaluation set is artificially balanced rather than reflecting the natural 2.9% anomaly rate, and the comparison with DeepLog is performed at different operating points. These issues are fixable within the scope of the manuscript, but they must be addressed before the claimed superiority over DeepLog can be considered established.

major comments (4)
  1. [§4.4.2] The central performance claim is circular. The authors state that they use all 16,838 anomaly blocks and 16,838 sampled normal blocks as the evaluation set, then examine top-K precision/recall/F1 on that set and write 'Hence we choose top 7 classes as the predicting results.' The reported F1 of 94.785% is therefore an in-sample optimum with respect to K, not a free prediction. A separate validation split (or nested cross-validation) must be used to select K, and the final metrics should be reported on a held-out test set. The current procedure overstates expected performance.
  2. [§4.2.1 and §4.4.2, Table 4.4] The evaluation set is balanced 50/50 while the natural HDFS block distribution is 97.1% normal and 2.9% anomaly. At the balanced-evaluation operating point, precision 90.605% and recall 99.370% imply an FP rate of about 10.3%. Applied to the natural prevalence of 558,223 normal blocks, this would yield roughly 57,500 false positives against 16,838 true anomalies, giving precision≈22% and F1≈37%, not 94.8%. The paper itself acknowledges in Section 6.2 that precision at 90% still 'falsely predicts a lot of normal blocks as anomaly.' The headline F1 is not representative of deployment conditions; the authors should report precision/recall/F1 at natural prevalence or provide a precision-recall curve across operating points.
  3. [§4.4.2, Table 4.4] The comparison with DeepLog is not at a matched operating point. The text says DeepLog's best performance occurs at top-3, while the proposed LLM-BiLSTM model is reported at top-7. Different top-K values lead to different precision/recall trade-offs, so Table 4.4 does not establish that the hybrid model is superior to DeepLog. The authors should compare both models across the same range of K values, or use threshold-independent metrics such as AUC-PR, and report the corresponding curves.
  4. [§3.1.2, §4.4.1] The experimental protocol for the evaluation split is under-specified. Section 3.1.2 states that the dataset is split into 80% training and 20% testing; Section 4.4.1 says 10,000 normal blocks are used with an 80/20 split for training/testing; Section 4.4.2 then uses a separately sampled set of 16,838 normal blocks 'with different seed' as the evaluation set. It is not explicitly stated that the evaluation normal blocks are disjoint from the training normal blocks, nor how the training data for the final model is chosen given that 2,000 of the 10,000 blocks are used as testing in 4.4.1. A clear, reproducible data-partitioning description is needed, including whether any of the 16,838 evaluation normal blocks overlap with blocks used for model training.
minor comments (4)
  1. [§3.6.2] The tanh formula contains a typo: the denominator is written as e^x + e^x; it should be e^x + e^{-x}.
  2. [Figures 3.7, 3.9, 3.10] Figure numbering is inconsistent: the sliding-window example is labeled Fig. 3.1 (duplicating the parallel-computing figure), and the LSTM and BiLSTM figures are numbered 3.2 and 3.3 in the text but appear after Figure 3.10. Please renumber all figures sequentially.
  3. [§4.4.2] The table comparing DeepLog and LLM-BiLSTM is referred to as 'Table 4.5' in the text but labeled 'Table 4.4.' Please align the numbering.
  4. [§3.4] 'Radio between right cases and false cases statistic' should be 'Ratio between right cases and false cases.'

Circularity Check

1 steps flagged

Headline F1 is selected by maximizing F1 on the same evaluation set used to report it; the reported superiority over DeepLog is an in-sample optimum, not an independent prediction.

specific steps
  1. fitted input called prediction [Section 4.4.2, Top-K and Performance; Table 4.4]
    "Before evaluating the performance of the model, we should find top-k has the best anomaly detection ability. We choose all the anomaly blocks, 16838 blocks in total, and randomly sampling 16838 normal blocks (with different seed from training dataset) as evaluating dataset. ... Given that HDFS anomaly detection model needs to detect normal block and anomaly block both accurately, we need F1-Score is the highest in Top K. Hence we choose top 7 classes as the predicting results."

    The same labeled evaluation set is used both to select K=7 (by maximizing F1) and to report the headline precision/recall/F1. Therefore the reported 99.370% recall and 94.785% F1 are in-sample optima of the K-threshold, not held-out predictions. No separate validation split, repeated seeds, or error bars are provided, and the artificially balanced 50/50 evaluation set differs from the 2.9% anomaly prevalence in the raw data. The headline performance metric is thus fitted to the evaluation labels rather than independently predicted.

full rationale

The paper's core modeling idea—train an unsupervised BiLSTM on normal block sequences, use Linq-Embed-Mistral embeddings for the 29 log templates, and flag blocks whose next event is not among the top-k predicted events—is not circular by construction: the LLM embeddings and Loghub labels are external, the model is trained only on normal data, and the next-event prediction task is defined independently of the evaluation labels. There is no self-citation chain or imported uniqueness theorem. However, the central reported performance is materially compromised by threshold fitting: Section 4.4.2 uses the entire evaluation set (all 16,838 anomaly blocks plus 16,838 sampled normal blocks) to choose the top-k that maximizes F1, then reports F1/precision/recall at that same k. Thus the 99.370% recall and 94.785% F1 in Table 4.4 are in-sample optima with respect to the decision threshold, not unbiased predictions. The artificial 50/50 balance also means the numbers do not reflect the 2.9% anomaly prevalence in the raw data; at natural prevalence the same rule would have far lower precision and F1. Separately, the DeepLog comparison reports DeepLog at its best top-3 while reporting the proposed model at top-7, so the claimed superiority is not established at a matched operating point. These are evaluation/correctness problems rather than definitional circularity; the only circular step is the fitted threshold masquerading as a reported performance result, which warrants score 6.

Axiom & Free-Parameter Ledger

5 free parameters · 5 axioms · 0 invented entities

No new theoretical entities are introduced. The system's performance rests on a handful of free parameters, the most consequential being the top-K threshold fitted to the test set. The other axioms are standard domain assumptions about data quality and model transfer.

free parameters (5)
  • Top-K threshold = 7
    Selected on the evaluation set to maximize F1; the reported performance depends on this choice.
  • Sliding window size = 10
    Hand-chosen; affects the sequence context available for next-event prediction.
  • Number of training normal blocks = 10000
    Arbitrary sample from 558,223 normal blocks; affects model quality and evaluation.
  • Number of evaluation normal blocks = 16838
    Matched to the anomaly count; arbitrary, and results may vary with the sample.
  • BiLSTM hyperparameters = hidden=256, layers=2, dropout=0.2, lr=0.001
    Standard choices; no validation-based tuning is described.
axioms (5)
  • domain assumption Ground-truth block labels from the Loghub dataset are correct.
    Training and evaluation rely on these labels; the paper performs no independent verification.
  • domain assumption Log parsing into 29 event templates is accurate and complete.
    All sequences and embeddings derive from these templates; errors would propagate through the pipeline.
  • domain assumption Pretrained LLM embeddings of event templates carry enough semantic signal to improve next-event prediction over raw token IDs.
    The hybrid model's design premise; not independently validated beyond the single comparison to DeepLog.
  • domain assumption HDFS log sequences are sufficiently stationary that a model trained on 2008-era Loghub logs generalizes to production.
    The dataset is old; modern HDFS versions may produce different event patterns.
  • standard math Training and evaluation blocks are independent and the sample is representative.
    Standard i.i.d. assumption; temporal correlations across blocks are not examined.

pith-pipeline@v1.3.0-daily-deepseek · 18473 in / 10073 out tokens · 103563 ms · 2026-08-03T08:02:10.750751+00:00 · methodology

0 comments
Cite this review

Pith. "Pith review of Exploring Block Anomaly Detection In HDFS Log Data Analysis." pith.science (2026). https://pith.science/paper/WPGHRMB5

@misc{pith2026260729383,
  author       = {Pith},
  title        = {Pith review of: Exploring Block Anomaly Detection In HDFS Log Data Analysis},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/WPGHRMB5}},
  note         = {Machine review of arXiv:2607.29383}
}
Share X Bluesky LinkedIn Reddit HN
read the original abstract

In recent years, with the development of big data technology, increasingly more companies use HDFS for data processing and storage. As a result, the maintenance of distributed file systems has become an extremely important part of data management. As the function of server systems is becoming increasingly diversified and their services are becoming complex, the logs, recording real-time events make it easier for system operators to locate the failures and errors that happened in the server systems to make server always available. HDFS, a distributed file system, which contains large data sets, will record a large number of logs. Moreover, the logs are not always structured data, they are not stable as well. However, to detect the problems that occur in the system by checking one log by one log, it's complicated and boring work for the system operators. Using machine learning techniques and natural language processing techniques to detect the HDFS block anomaly will help the system operators to locate and fix the anomaly rapidly and accurately. This paper proposes a streaming HDFS log block anomaly workflow. It helps maintenance practitioners to use parallel computing network in processing historical log, and construct LLM-BiLSTM hybrid deep learning model to detect anomaly block in HDFS, then build streaming log pipeline based on Kafka to give one real-time HDFS log block anomaly detection solution.

Figures

Figures reproduced from arXiv: 2607.29383 by Tutut Herawan, WenYang Zhong.

Figure 3.2
Figure 3.2. Figure 3.2: Fig.3.2 [PITH_FULL_IMAGE:figures/full_fig_p008_3_2.png] view at source ↗
Figure 3.3
Figure 3.3. Figure 3.3: Fig.3.3 [PITH_FULL_IMAGE:figures/full_fig_p008_3_3.png] view at source ↗
Figure 3.4
Figure 3.4. Figure 3.4: Fig.3.4 [PITH_FULL_IMAGE:figures/full_fig_p009_3_4.png] view at source ↗
Figure 3.5
Figure 3.5. Figure 3.5: Fig.3.5 [PITH_FULL_IMAGE:figures/full_fig_p009_3_5.png] view at source ↗
Figure 3.6
Figure 3.6. Figure 3.6: Fig.3.6 [PITH_FULL_IMAGE:figures/full_fig_p009_3_6.png] view at source ↗
Figure 3.8
Figure 3.8. Figure 3.8: Fig.3.8 [PITH_FULL_IMAGE:figures/full_fig_p014_3_8.png] view at source ↗
Figure 4
Figure 4. Figure 4 [PITH_FULL_IMAGE:figures/full_fig_p022_4.png] view at source ↗
Figure 4
Figure 4. Figure 4 [PITH_FULL_IMAGE:figures/full_fig_p028_4.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

48 extracted references · 1 canonical work pages

  1. [1]

    Abnormal events in HDFS logs are extremely rare compared to normal events, resulting in a serious imbalance in the data set

  2. [2]

    1.3 Research Questions

    Logs contain a mixture of structured and unstructured data. 1.3 Research Questions

  3. [3]

    How to analyze unstructured data -- text-based with timestamp log to find out pattern behind HDFS log?

  4. [4]

    How to process imbalanced dataset the abnormal events only weight in extremely small part of the whole events?

  5. [5]

    What is the suitable machine learning method to improve accuracy of detecting anomaly in HDFS and predict potential anomaly in system? 1.4 Research Objectives

  6. [6]

    To build an effective anomaly detection system, it is essential to first study the existing models and techniques used for anomaly detection in HDFS logs or similar environments

    To investigate previous anomaly detection models. To build an effective anomaly detection system, it is essential to first study the existing models and techniques used for anomaly detection in HDFS logs or similar environments. This involves reviewing both classical and modern approaches, including statistical methods, clustering-based techniques, and ma...

  7. [7]

    The steps like data normalization, handling missing values, and noise reduction are crucial for ensuring that the models receive clean and meaningful input

    To explore feature extraction data preprocessing method. The steps like data normalization, handling missing values, and noise reduction are crucial for ensuring that the models receive clean and meaningful input

  8. [8]

    To investigate a novel hybrid model to improve the performance of anomaly detection. In this paper, I will attempt to use Large Language Model(LLM) to improve the ability of comprehending the syntax meaning of HDFS log and time series model to capture the feature of it

  9. [9]

    By comparing the two models, it aims to evaluate their effectiveness in identifying rare anomalies

    To compare the performance of different Model in anomaly detection. By comparing the two models, it aims to evaluate their effectiveness in identifying rare anomalies. This comparison will involve assessing their precision, recall, F1 score, and computational efficiency, as well as their ability to handle imbalanced datasets and mixed data types. 1.5 Rese...

    2022

  10. [10]

    Validate the transformation process, whether the unstructured text has been already fitted into predefined meta data of structured data

  11. [11]

    3.3.3 Log Parsing Based on Zhu, et al (2023) research[28], HDFS log events can be summarized into a log template

    Drop the empty value in the dataset, delete the whole row, which only the column id has value, else hasn’t. 3.3.3 Log Parsing Based on Zhu, et al (2023) research[28], HDFS log events can be summarized into a log template. HDFS log events carry parameters about IP addresses, Block information and Programme output, files path and so on. Those parameters can...

    2023

  12. [12]

    When HDFS detection system monitors the status of blocks, it can’t provide the prediction result instantly

    Although LLM+LSTM hybrid model used in this paper has a better performance, it is much more time-consuming model. When HDFS detection system monitors the status of blocks, it can’t provide the prediction result instantly

  13. [13]

    But given that HDFS operations are quite frequent, log events will generate quite frequently, the workflow doesn’t design big data framework to process massive real-time log events

    The real-time streaming log processing workflow has the ability to process real-time data. But given that HDFS operations are quite frequent, log events will generate quite frequently, the workflow doesn’t design big data framework to process massive real-time log events

  14. [14]

    HDFS log anomaly detection is required high anomaly detecting rate and low false positive rate, although precision reaching 90%, it still falsely predicts a lot of normal blocks as anomaly, it still will give maintenance practitioners a lot of maintenance working burden. In summary, LLM+LSTM hybrid model proposed in this research improve the ability of HD...

  15. [15]

    Lohr, S. (2012). The age of big data. New York Times, 11(2012)

    2012

  16. [16]

    Big Data, Big Impact: New Possibilities for International Development.https://www3.weforum.org/docs/WEF_TC_MFS_BigDataBigImpact_Brie fing_2012.pdf

    World Economic Forum.(2012). Big Data, Big Impact: New Possibilities for International Development.https://www3.weforum.org/docs/WEF_TC_MFS_BigDataBigImpact_Brie fing_2012.pdf

    2012

  17. [17]

    (2013, May)

    Sagiroglu, S., & Sinanc, D. (2013, May). Big data: A review. In 2013 international conference on collaboration technologies and systems (CTS) (pp. 42-47). IEEE

    2013

  18. [18]

    F., & Gupta, N

    Uddin, M. F., & Gupta, N. (2014, April). Seven V's of Big Data understanding Big Data to extract value. In Proceedings of the 2014 zone 1 conference of the American Society for Engineering Education (pp. 1-5). IEEE

    2014

  19. [19]

    Dean, J., & Ghemawat, S. (2008). MapReduce: simplified data processing on large clusters. Communications of the ACM, 51(1), 107-113

    2008

  20. [20]

    (2010, May)

    Shvachko, K., Kuang, H., Radia, S., & Chansler, R. (2010, May). The hadoop distributed file system. In 2010 IEEE 26th symposium on mass storage systems and technologies (MSST) (pp. 1-10). Ieee

    2010

  21. [21]

    HDFS Architecture - Introduction.https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop- hdfs/HdfsDesign.html

    Apache HDFS (2024,Oct). HDFS Architecture - Introduction.https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop- hdfs/HdfsDesign.html

    2024

  22. [22]

    Sandhya, M., Ladda, A., & Dulhare, U. N. (2018). A Review: Map Reduce Framework for Cloud Computing. International Journal of Engineering & Technology, 7(4.6), 13-16

    2018

  23. [23]

    Gholamian, S., & Ward, P. A. (2021). A comprehensive survey of logging in software: From logging statements automation to log mining and analysis. arXiv preprint arXiv:2110.12489

    Pith/arXiv arXiv 2021

  24. [24]

    Kannan, P. (2015). Beyond hadoop mapreduce apache tez and apache spark. San Jose State University. URL: http://www. sjsu. edu/people/robert. chun/courses/CS259Fall2013/s3/F. pdf (дата обращения 02.08. 2016)

    2015

  25. [25]

    Apache TEZ Overview Introduction

    Apache TEZ (2024, Nov). Apache TEZ Overview Introduction. https://tez.apache.org/

    2024

  26. [26]

    AN EXPLORATORY SURVEY OF HADOOP LOG ANALYSIS TOOLS

    Allam, S. (2018). An Exploratory Survey of Hadoop Log Analysis Tools. Sudhir Allam," AN EXPLORATORY SURVEY OF HADOOP LOG ANALYSIS TOOLS", International Journal of Creative Research Thoughts (IJCRT), ISSN, 2320-2882

    2018

  27. [27]

    Xie, Y., Yang, K., & Luo, P. (2021). Logm: Log analysis for multiple components of hadoop platform. IEEE Access, 9, 73522-73532

    2021

  28. [28]

    (2019, July)

    Patil, A., Wadekar, A., Gupta, T., Vijan, R., & Kazi, F. (2019, July). Explainable LSTM model for anomaly detection in HDFS log file using layerwise relevance propagation. In 2019 IEEE Bombay Section Signature Conference (IBSSC) (pp. 1-6). IEEE

    2019

  29. [29]

    (2021, May)

    Yang, L., Chen, J., Wang, Z., Wang, W., Jiang, J., Dong, X., & Zhang, W. (2021, May). Semi-supervised log-based anomaly detection via probabilistic label estimation. In 2021 IEEE/ACM 43rd International Conference on Software Engineering (ICSE) (pp. 1448 - 1460). IEEE

    2021

  30. [30]

    J., Le, Y., Du, Y., Liao, X.,

    Xiao, T., Quan, Z., Wang, Z. J., Le, Y., Du, Y., Liao, X., ... & Li, K. (2023). Loader: A log anomaly detector based on transformer. IEEE Transactions on Services Computing, 16(5), 3479-3492

    2023

  31. [31]

    (2021, July)

    Guo, H., Yuan, S., & Wu, X. (2021, July). Logbert: Log anomaly detection via bert. In 2021 international joint conference on neural networks (IJCNN) (pp. 1-8). IEEE

    2021

  32. [32]

    (2022, July)

    Bogatinovski, J., Madjarov, G., Nedelkoski, S., Cardoso, J., & Kao, O. (2022, July). Leveraging log instructions in log -based anomaly detection. In 2022 IEEE International Conference on Services Computing (SCC) (pp. 321-326). IEEE

    2022

  33. [33]

    Chen, S., & Liao, H. (2022). Bert -log: Anomaly detection for system logs based on pre - trained language model. Applied Artificial Intelligence, 36(1), 2145642

    2022

  34. [34]

    Lee, Y., Kim, J., & Kang, P. (2023). Lanobert: System log anomaly detection based on bert masked language model. Applied Soft Computing, 146, 110689

    2023

  35. [35]

    K., Luo, W., & Liu, S

    Sun, Y., Keung, J., Zhang, J., Yu, H. K., Luo, W., & Liu, S. (2024, July). Unveiling hidden anomalies: Leveraging smac-lstm for enhanced software log analysis. In 2024 IEEE 48th Annual Computers, Software, and Applications Conference (COMPSAC) (pp. 1178 - 1183). IEEE

    2024

  36. [36]

    Wang, S., Jiang, R., Wang, Z., & Zhou, Y. (2024). Deep learning-based anomaly detection and log analysis for computer networks. arXiv preprint arXiv:2407.05639

    Pith/arXiv arXiv 2024

  37. [37]

    İ., Özelgül, S

    Saygılı, M. İ., Özelgül, S. B., Öztürk, İ. S., Karaca, K. Ö., Gedik, A. O., & Akcayol, M. A. (2024, September). Anomaly Detection on Servers Using Log Analysis. In 2024 8th International Artificial Intelligence and Data Processing Symposium (IDAP) (pp. 1 -5). IEEE

    2024

  38. [38]

    Zhou, J., Qian, Y., Zou, Q., Liu, P., & Xiang, J. (2022). Deepsyslog: Deep anomaly detection on syslog using sentence embedding and metadata. IEEE Transactions on Information Forensics and Security, 17, 3051-3061

    2022

  39. [39]

    (2017, October)

    Du, M., Li, F., Zheng, G., & Srikumar, V. (2017, October). Deeplog: Anomaly detection and diagnosis from system logs through deep learning. In Proceedings of the 2017 ACM SIGSAC conference on computer and communications security (pp. 1285-1298)

    2017

  40. [40]

    Kafka documentation

    Apache Kafka (2024). Kafka documentation. https://kafka.apache.org/documentation/

    2024

  41. [41]

    Dong Jae Kim. (2022). Log Dataset [Data set]. Zenodo. https://doi.org/10.5281/zenodo.7439296

    work page doi:10.5281/zenodo.7439296 2022

  42. [42]

    Zhu, J., He, S., He, P., Liu, J., & Lyu, M. R. (2023, October). Loghub: A large collection of system log datasets for ai -driven log analytics. In 2023 IEEE 34th International Symposium on Software Reliability Engineering (ISSRE) (pp. 355-366). IEEE

    2023

  43. [43]

    Vaswani, A., Shazeer, N., Parmar, N., Uszkoreit, J., Jones, L., Gomez, A. N., ... & Polosukhin, I. (2017). Attention is all you need. Advances in neural information processing systems, 30

    2017

  44. [44]

    Muennighoff, N., Tazi, N., Magne, L., & Reimers, N. (2022). MTEB: Massive text embedding benchmark. arXiv preprint arXiv:2210.07316

    Pith/arXiv arXiv 2022

  45. [45]

    & Sohn, J

    Choi, C., Kim, J., Lee, S., Kwon, J., Gu, S., Kim, Y., ... & Sohn, J. Y. (2024). Linq-Embed- Mistral Technical Report. arXiv preprint arXiv:2412.03223

    Pith/arXiv arXiv 2024

  46. [46]

    Wang, L., Yang, N., Huang, X., Yang, L., Majumder, R., & Wei, F. (2023). Improving text embeddings with large language models. arXiv preprint arXiv:2401.00368

    Pith/arXiv arXiv 2023

  47. [47]

    Jiang, A.Q., Sablayrolles, A., Mensch, A., Bamford, C., Chaplot, D.S., Casas, D.D., Bressand, F., Lengyel, G., Lample, G., Saulnier, L., Lavaud, L.R., Lachaux, M., Stock, P., Scao, T.L., Lavril, T., Wang, T., Lacroix, T., & Sayed, W.E. (2023). Mistral 7B. ArXiv, abs/2310.06825

    Pith/arXiv arXiv 2023

  48. [48]

    Hochreiter, S., & Schmidhuber, J. (1997). Long short-term memory. Neural computation, 9(8), 1735-1780

    1997