LOG-BASED ANOMALY DETECTION AND

PREDICTIVE FAILURE MONITORING FOR API

SYSTEMS

A PROJECT REPORT

Submitted by

YAJNESH K (311622104059)
TARUN JAIN (311622104052)
SOUMYA RANJAN (311622104051)

in partial fulfilment for the award of degree

of

BACHELOR OF ENGINEERING

in
COMPUTER SCIENCE AND ENGINEERING

MISRIMAL NAVAJEE MUNOTH JAIN ENGINEERING COLLEGE

THORAIPAKKAM, CHENNAI-600097
ANNA UNIVERSITY: CHENNAI 600025
MAY- 2026

1
 ANNA UNIVERSITY: CHENNAI 600 025

BONAFIDE CERTIFICATE

Certified that this project report "LOG-BASED ANOMALY

DETECTION AND PREDICTIVE FAILURE MONITORING FOR

API SYSTEMS" is the bonafide work of "YAJNESH K, TARUN JAIN &

SOUMYA RANJAN" who carried out the project work under my

SIGNATURE SIGNATURE

[Link], Ph.D. Mr. K. Varunamuthu , M.E.

HEAD OF THE DEPARTMENT SUPERVISOR

ASSISTANT PROFESSOR
Department of Computer Science Department of Computer Science
and Engineering and Engineering Misrimal Navajee
Misrimal Navajee Munoth Jain Munoth Jain
Engineering College, Engineering College,
Thoraipakkam, Chennai-600097 Thoraipakkam, Chennai-600097

supervision.

Submitted for the Project Viva-Voce Examination held on_______________

INTERNAL EXAMINER EXTERNAL EXAMINER

2
 ACKNOWLEDGEMENT

We express our sincere gratitude to our honourable Secretary

(Administration) Dr. Harish L Metha and Secretary (Academic) Shri L.
Jaswant S Munoth for providing the infrastructure facilities to do this project
during our course period.

We thank our Principal, Dr. T. Sasikala, for her valuable suggestions and
guidance for the development and completion of this project.

We express profound sense of gratitude and thanks to our Head of The

Department Dr. N. Saravanan, Professor, for his valuable suggestions and
guidance for the development and completion of this project.

We thank our Project Coordinator, Mrs. X. Anitha Sarafin, Associate

Professor, for her constant help and valuable suggestions for the
development and completion of the project.

We thank our Supervisor, Mr. K. Varunamuthu, Assistant Professor, for his

constant help and valuable suggestions. We thank him for his whole hearted
guidance right from the inception to the completion of our project.

Finally, we thank all the Teaching and Non-Teaching Staff members of our
Department who helped us to complete our project.

Above all we thank the Almighty, our parents and siblings for their constant
support and encouragement for completing this project.

3
 MISRIMAL NAVAJEE MUNOTH JAIN ENGINEERING
COLLEGE DEPARTMENT OF COMPUTER SCIENCE AND
ENGINEERING

• VISION

Producing competent computer engineers with a strong

background in the latest trends and technology to achieve academic
excellence and to become pioneers in software and hardware products with
an ethical approach to serve the society.

• MISSION

To provide quality education by inculcating strong

fundamentals in basic science, mathematics and engineering concepts
through the state-of-the-art facilities. To provide the learning ambience that
helps the students to enhance problem solving skills and to inculcate in them
the habit of continuous learning in their domain of interest. To serve the
society by providing insight solutions to the real-world problems by
employing the latest trends of computing technology with strict adherence to
professional and ethical responsibilities.

4
 ABSTRACT

Modern software systems are composed of multiple APIs and microservices,

making them increasingly vulnerable to failures caused by high traffic,

latency spikes, and unexpected errors. Traditional monitoring systems are

inherently reactive in nature — they detect issues only after failures have

already occurred, leaving little room for preventive action. This project

proposes an AI-based predictive monitoring system that analyzes API and

system logs in order to identify abnormal behavior and provide early

warning of potential service issues in advance. The core of the system is a

machine learning engine that learns the normal operational behavior of APIs

from historical log data, enabling it to detect deviations even in the case of

previously unseen failure types. In addition to detection, the system furnishes

self-healing recommendations such as retry mechanisms, circuit breaking,

and resource scaling actions to improve system reliability and reduce overall

downtime. The results are surfaced through a real-time monitoring

dashboard that presents anomaly status, risk classification, and suggested

recovery actions for rapid operator response.

5
 TABLE OF CONTENTS

CHAPTER
TITLE PAGE NO
NO
ABSTRACT v
LIST OF FIGURES viii
LIST OF ABBREVIATIONS viii
1. INTRODUCTION 1
1.1 MICROSERVICES AND API SYSTEMS 1
1.2 LOG-BASED MONITORING 2
MACHINE LEARNING FOR ANOMALY
1.3 3
DETECTION
1.4 AIOPS AND SELF-HEALING SYSTEMS 4
2. LITERATURE SURVEY 5
3. SYSTEM OVERVIEW 9
3.1 EXISTING SYSTEM 9
3.1.1 Overview 9
3.1.2 Drawback 9
3.2 PROPOSED SYSTEM 10
3.2.1 Overview 10
3.2.2 Advantages 10
3.3 REQUIREMENT ANALYSIS 11
3.3.1 Software Requirements 11
3.3.2 Hardware Requirements 11
3.4 TECHNOLOGIES USED 12
3.4.1 Java and Spring Boot 12
3.4.2 Python and scikit-learn 12
3.4.3 Isolation Forest Algorithm 13
3.4.4 PostgreSQL 13
3.4.5 IntelliJ IDEA and PyCharm 14
4. SYSTEM DESIGN 15
4.1 SYSTEM ARCHITECTURE 15

6
4.2 FUNCTIONAL ARCHITECTURE 16
4.3 UML USE CASE DIAGRAM 17
5. IMPLEMENTATION 18
5.1 MODULES 18
5.1.1 Backend API Execution and Log Generation 18
5.1.2 Log Acquisition and Streaming 19
5.1.3 Log Parsing and Feature Extraction 19
5.1.4 Data Preprocessing and Normalization 20
5.1.5 Machine Learning-Based Anomaly Detection 20
5.1.6 Health Assessment and Risk Classification 21
5.1.7 Monitoring Dashboard and Visualization 21
6. RESULTS 22
6.1 RESULT 22
7. SYSTEM TESTING 23
7.1 TESTING OBJECTIVES 23
7.2 TYPES OF TESTS 23
7.2.1 Unit Test Cases 24
7.2.2 Functional Test Cases 25
7.2.3 Integration Test Cases 26
8. CONCLUSION AND FUTURE ENHANCEMENT 27
8.1 CONCLUSION 27
8.2 FUTURE ENHANCEMENT 28
APPENDICES – CODE SNIPPET 29
APPENDICES – SCREENSHOT
REFERENCES

7
 LIST OF FIGURES

FIGURE NO NAME OF THE FIGURE PAGE NO

4.1 SYSTEM ARCHITECTURE 15
4.2 FUNCTIONAL ARCHITECTURE 16
4.3 UML USE CASE DIAGRAM 17

LIST OF ABBREVIATIONS

ABBREVIATION EXPANSION
API APPLICATION PROGRAMMING INTERFACE
ML MACHINE LEARNING
AIOps ARTIFICIAL INTELLIGENCE FOR IT OPERATIONS
HTTP HYPERTEXT TRANSFER PROTOCOL
SRE SITE RELIABILITY ENGINEER
REST REPRESENTATIONAL STATE TRANSFER
MTTR MEAN TIME TO REPAIR
NLP NATURAL LANGUAGE PROCESSING
BIDIRECTIONAL ENCODER REPRESENTATIONS
BERT
FROM TRANSFORMERS
RCA ROOT CAUSE ANALYSIS
CPU CENTRAL PROCESSING UNIT
GPU GRAPHICS PROCESSING UNIT
IDE INTEGRATED DEVELOPMENT ENVIRONMENT
DB DATABASE
IoT INTERNET OF THINGS

8
 CHAPTER 1

INTRODUCTION

1.1 MICROSERVICES AND API SYSTEMS

Modern enterprise software is no longer built as monolithic

applications but as collections of small, independently deployable services
that communicate with one another over networks. This architectural style —
known as microservices — has become the industry standard because it
enables teams to develop, deploy, and scale individual components of a
system without affecting the rest of the application. At the heart of
microservices communication lies the Application Programming Interface
(API), which defines the contract through which services exchange data and
functionality.

While the microservices approach offers significant advantages in

terms of flexibility and scalability, it also introduces considerable operational
complexity. A single user-facing transaction may traverse dozens of internal
service calls, and a failure or performance degradation in any one of those
services can cascade into a system-wide outage. As organizations scale their
API ecosystems, the need for robust monitoring, observability, and proactive
failure detection becomes not just a best practice but an operational
necessity.

APIs generate continuous streams of structured log data as they handle

requests, process business logic, and return responses. These logs contain
rich information — including request timestamps, HTTP status codes,
response latency values, endpoint identifiers, and error messages — that,
when properly analyzed, can reveal the health of the entire system. The

1
challenge lies in doing so at scale, in real time, and with sufficient
intelligence to detect problems before they manifest as user-facing failures.

1.2 LOG-BASED MONITORING

Log-based monitoring is the practice of continuously collecting,

parsing, and analyzing the log output produced by application components in
order to understand their operational state. Every API request handled by a
backend service leaves a trail in the system log: when it arrived, how long it
took to process, whether it succeeded or failed, and what internal events
occurred during its execution. By aggregating and examining these log
entries over time, operations teams can reconstruct the history of a system's
behavior and identify recurring patterns.

Traditional log-based monitoring relies on predefined rules and static

thresholds. An operations engineer might configure an alert that fires when
API latency exceeds a certain number of milliseconds, or when the rate of
HTTP 5xx error responses crosses a fixed limit. While this approach is
straightforward to implement, it has well-documented limitations: it can only
detect conditions that have been explicitly anticipated, it generates large
volumes of false positives when thresholds are set too conservatively, and it
is blind to gradual or novel forms of degradation that do not correspond to
any defined rule.

To overcome these limitations, modern log-based monitoring systems

are increasingly incorporating machine learning techniques that can learn
what normal behavior looks like from historical data and then detect
deviations from that baseline automatically — including anomaly types that
have never been seen before.

2
1.3 MACHINE LEARNING FOR ANOMALY DETECTION

Anomaly detection is the task of identifying data points, patterns, or

sequences that deviate significantly from expected behavior. In the context of
API monitoring, an anomaly might be a sudden spike in average response
latency, an unusual increase in the proportion of error responses, a drop in
request throughput that is inconsistent with historical traffic patterns, or a
combination of signals that collectively indicate an impending failure.

Machine learning offers powerful tools for this task. Unsupervised

learning algorithms are particularly well-suited because they do not require
labeled training data — that is, they do not need a human to have previously
annotated which log entries correspond to anomalies. Instead, they learn a
model of normal system behavior from historical logs and use that model to
score new observations according to how well they conform to the learned
norm.

The Isolation Forest algorithm is one of the most widely used

unsupervised anomaly detection methods. It works by randomly partitioning
the feature space and observing that anomalous points, being few in number
and statistically distant from the main cluster, require fewer partitions to
isolate than normal points. More advanced approaches, such as Autoencoder
neural networks and Transformer-based models like BERT, can additionally
capture temporal and sequential patterns in log data, enabling even richer
anomaly detection capabilities.

3
1.4 AIOPS AND SELF-HEALING SYSTEMS

Artificial Intelligence for IT Operations, commonly abbreviated as

AIOps, refers to the application of machine learning, big data analytics, and
automation to enhance and partially automate IT operations workflows.
AIOps platforms ingest telemetry data — including logs, metrics, and traces
— from across the IT environment and use intelligent algorithms to surface
actionable insights, reduce alert noise, accelerate root cause analysis, and in
some cases trigger automated remediation actions.

A key aspiration of AIOps is the self-healing system: an infrastructure

that can not only detect that something has gone wrong but can also diagnose
the nature of the problem and take corrective action without requiring
manual intervention. In practice, this might involve automatically retrying a
failed API call, triggering a circuit breaker to prevent a degraded service
from overwhelming downstream dependencies, or scaling out compute
resources in response to detected demand spikes. The project described in
this report contributes to this vision by building a prototype log-based AIOps
pipeline that integrates anomaly detection with a recommendation engine
capable of suggesting appropriate recovery actions based on the classified
type and severity of the detected anomaly.

4
 CHAPTER 2

LITERATURE SURVEY

Chenxi Zhang, Xin Peng, et al. [2] proposed DeepTraLog, a deep

learning framework that unifies execution traces and system logs for
microservice anomaly detection. The key insight is that distributed system
failures frequently manifest as anomalies in the interactions between
services, and that capturing these structural dependencies requires modeling
the system as a graph. By representing service-to-service communication as
a graph and applying deep learning over this structure, DeepTraLog is able
to detect anomalies that would be invisible to methods that analyze logs in
isolation. The approach provides structural awareness that single-modality
methods lack and delivers a holistic view of system health. The primary
limitations are the overhead introduced by high-frequency trace capture in
production environments, the significant volume of labeled data required to
achieve peak model accuracy, and the growing complexity of the graph
representation as the number of microservices in the system scales upward.

Guangba Yu, Pengfei Chen, et al. [1] presented the Nezha framework
for interpretable, fine-grained root cause analysis of microservice failures
using multi-modal observability data. The paper's core contribution is the
integration of system metrics with log pattern data to diagnose not merely
that a failure has occurred, but precisely where and why it originated. The
framework demonstrates that combining logs and metrics provides
substantially more diagnostic accuracy than either modality alone, and that
human-interpretable results are as operationally important as detection
accuracy itself. The system achieves high precision in identifying root causes
of system failures and is particularly effective in large-scale, complex

5
microservice environments. However, the approach has notable limitations:
it requires high-quality, well-synchronized logs and metrics to function
correctly, and processing multi-modal data in real time is computationally
intensive. Additionally, the method may struggle to generalize to entirely
new failure types that do not correspond to any patterns present in the
training corpus.

Haixuan Guo, Shuhan Yuan, and Xintao Wu [4] presented LogBERT,

a log anomaly detection system that applies the BERT Transformer
architecture to the analysis of system log sequences. The fundamental insight
is that system logs, like natural language, exhibit sequential semantic
structure — the meaning of a log entry is shaped by the events that preceded
and followed it. By treating log sequences as text and training a BERT model
using a masked language modeling objective, LogBERT is able to learn a
rich representation of normal system behavior. The approach requires
significantly less manual feature engineering than traditional log analysis
tools. The primary drawbacks are the substantial GPU resources and training
time

Y. Li, P. Chen, et al. [3] introduced Eadro, an end-to-end

troubleshooting framework for microservices that covers the full failure
lifecycle from initial detection through diagnosis to mitigation. The
framework's distinguishing characteristic is its action-oriented design: rather
than merely reporting that a problem has been detected, Eadro provides
concrete, actionable recovery recommendations for site reliability engineers.
By fusing data from logs, metrics, and distributed traces into a single unified
troubleshooting timeline, Eadro significantly reduces the mean time to repair
(MTTR) for microservice incidents. The framework's limitations relate
primarily to the confidence thresholds required before automated recovery
actions can be safely triggered, the granularity of the underlying

6
observability data on which performance depends, and the configuration
overhead involved in integrating end-to-end monitoring across diverse and
heterogeneous microservice deployments.

CHAPTER 3

SYSTEM OVERVIEW

3.1 EXISTING SYSTEM

3.1.1 Overview
Contemporary backend systems make use of monitoring and
observability tools to track the behavior of APIs and services in production.
These tools observe key performance indicators such as request latency, error
rates, and throughput, and apply predefined rules and thresholds to determine
when the system has entered an unacceptable state. When a metric breaches
its configured limit — for example, when API latency exceeds a fixed
threshold or when the count of server-side error responses surpasses a
defined value — the monitoring system generates an alert and notifies the
responsible operations team. Engineers then manually investigate the alert,
examine the raw logs, and attempt to diagnose the root cause of the issue.

3.1.2 Drawback
▪​ Problems are detected only after they have fully manifested, leaving
no opportunity for preventive intervention.
▪​ The threshold-based approach cannot detect gradual or novel forms of
abnormal behavior that do not correspond to any explicitly configured
rule.
▪​ Static thresholds generate excessive false positive alerts when traffic
patterns are inherently variable, leading to alert fatigue among
operations teams.

7
 ▪​ Engineers must manually analyze raw log data to understand the
nature of each issue, a process that is both time-consuming and
dependent on individual expertise.
▪​ The system provides no guidance on recommended corrective actions,
requiring engineers to determine an appropriate response
independently for each incident.

3.2 PROPOSED SYSTEM

3.2.1 Overview
The proposed system is a log-based AIOps prototype inspired by
research on microservice anomaly detection. It ingests API and system logs
in real time, extracts meaningful statistical features using time-window
aggregation, and applies an unsupervised machine learning model to learn
normal API behavior from historical data. The model continuously scores
incoming log-derived feature vectors and identifies deviations from the
learned baseline, including anomaly types that have never previously been
observed. When an anomaly is detected, the system classifies its severity,
generates a human-readable health assessment, and surfaces recovery
recommendations — such as retry mechanisms, circuit breaking, or resource
scaling — through a real-time monitoring dashboard.

3.2.2 Advantages
▪​ Detects abnormal behavior earlier than conventional threshold-based
alert systems, enabling preventive action.
▪​ Reduces alert noise by focusing on statistically unusual patterns rather
than static rule violations.

8
 ▪​ Assists engineers in responding faster by pairing each detected
anomaly with a relevant recovery recommendation.
▪​ Applicable broadly to any API-based backend system that generates
structured operational logs.
▪​ Employs an unsupervised learning approach that requires no labeled
anomaly data for training.

3.3 REQUIREMENT ANALYSIS

A requirements specification is a document that outlines the necessary

requirements for a software and hardware product. The purpose of a software
and hardware requirements specification is to provide a comprehensive
understanding of the project, including its objectives and parameters. It
should detail the project's intended audience, user interface, and any
hardware or software requirements that must be met to ensure the functions
are as intended.

​
3.3.1 Software Requirements
The software requirements give a detailed description of the system and
all its features.

▪​ Operating System: Linux (Ubuntu 20.04 LTS) / Windows 10

▪​ Backend Development: Java 17, Spring Boot (REST API and Log
Handling)
▪​ Machine Learning and Data Processing: Python 3.x, scikit-learn,
Pandas, NumPy
▪​ Data Storage: PostgreSQL (structured metrics and results)
▪​ Development Tools: IntelliJ IDEA, PyCharm

9
3.3.2 Hardware Requirements
The hardware requirements may serve as the basis for a contract for the
implementation of the system and should therefore be a complete and precise
description of the technical requirements.

▪​ Processor: Intel Core i5 (8th Generation or higher)

▪​ RAM: Minimum 8 GB (16 GB recommended for model training)
▪​ Storage: Minimum 50 GB available disk space
▪​ Network: Standard Ethernet or Wi-Fi connectivity

3.4 TECHNOLOGIES USED

3.4.1 Java and Spring Boot

Java 17 serves as the primary language for the backend API layer of
the system. Java's strong type system, mature ecosystem, and long-standing
use in enterprise software development make it well-suited to building
reliable, production-grade API servers. Spring Boot, built on top of the
Spring Framework, dramatically reduces the configuration overhead
associated with building Java web applications by providing opinionated
default configurations and auto-wiring of components. In this project, Spring
Boot is used to implement the REST API endpoints that receive and process
incoming requests, handle the generation of structured operational logs, and
expose interfaces through which the machine learning layer retrieves log
data and posts back anomaly detection results.

3.4.2 Python and scikit-learn

Python 3.x is used as the language for the machine learning and data
processing layer of the system. Python's dominance in the data science and
ML engineering communities means that it offers the richest ecosystem of

10
libraries for numerical computation, data manipulation, and model training.
The scikit-learn library provides efficient, well-documented implementations
of a wide range of machine learning algorithms, including the Isolation
Forest model used as the core anomaly detector in this project. Pandas and
NumPy are used for data manipulation and feature engineering tasks,
enabling the efficient transformation of raw log entries into the structured
numerical feature vectors that the ML model requires.

3.4.3 Isolation Forest Algorithm

The Isolation Forest is an ensemble unsupervised anomaly detection
algorithm based on the principle that anomalous data points are, by
definition, few in number and statistically distant from the bulk of the data.
The algorithm constructs a set of random decision trees by repeatedly
selecting a feature at random and then selecting a random split value
between the minimum and maximum values of that feature. Normal points,
being densely clustered together, require a large number of such splits to be
isolated, while anomalous points require very few. This approach is
computationally efficient, scales well to high-dimensional feature spaces,
and does not require labeled anomaly data for training, making it highly
suitable for the operational log analysis use case addressed in this project.

3.4.4 PostgreSQL
PostgreSQL is a powerful, open-source relational database
management system that offers full ACID compliance, advanced indexing,
and robust support for complex queries. In this system, PostgreSQL serves
as the primary structured data store for processed feature metrics, anomaly
detection results, health assessment scores, and risk classification labels. Its
reliability and widespread adoption in production environments make it an

11
appropriate choice for storing the persistent state of the monitoring system
and supporting the dashboard's historical trend visualization capabilities.

3.4.5 IntelliJ IDEA and PyCharm

​ IntelliJ IDEA is the primary integrated development environment used
for Java and Spring Boot development in this project. It provides advanced
code completion, intelligent refactoring, integrated debugging, and built-in
support for the Spring Boot framework, significantly accelerating the
backend development workflow. PyCharm, developed by the same vendor
(JetBrains), is used for Python and machine learning development. It offers a
dedicated scientific mode with integrated support for Pandas DataFrames,
NumPy arrays, and visualizations, making it well-suited to the iterative,
exploratory nature of ML feature engineering and model training workflows.

12
 CHAPTER 4

SYSTEM DESIGN

4.1 SYSTEM ARCHITECTURE

The system architecture of the Log-Based Anomaly Detection and

Predictive Failure Monitoring system describes the overall structure, data
flow, and interaction between its major components. At the entry point, API
requests are processed by the Spring Boot backend, which simultaneously
handles business logic and generates operational logs capturing request
metadata, latency, HTTP status codes, and any error messages.

Figure 4.1 System Architecture

13
These logs are continuously collected by a log acquisition layer and
forwarded to the feature extraction pipeline, where raw log entries are
transformed into structured numerical feature vectors using
time-window-based aggregation. The processed features are passed to the
Python-based machine learning engine, where an Isolation Forest model
scores each feature vector according to its deviation from the learned normal
baseline. The resulting anomaly scores are interpreted by a health assessment
module, which classifies the current system state and generates recovery
recommendations. All outputs are persisted to a PostgreSQL database and
surfaced through a real-time monitoring dashboard for operator visibility.

4.2 FUNCTIONAL ARCHITECTURE

The functional architecture provides a detailed view of how data flows

between the processing stages of the system. Raw API logs produced by the
backend service are first acquired and buffered by the log collection layer,
which ensures reliable, lossless capture of all log entries. The parsing and
feature extraction engine then processes each buffered entry, applying
time-window aggregation to derive statistical features including mean and
maximum latency, error frequency by HTTP status class (4xx and 5xx), total
request count, and timeout occurrences.

14
 Figure 4.1 Function Architecture

These features are normalized and scaled before being submitted to the
anomaly detection engine, where the trained Isolation Forest model produces
a continuous anomaly score. The scoring output feeds into the risk
classification layer, which applies severity thresholds to produce categorical
health labels. Finally, the dashboard layer retrieves the classified results and
presents them visually alongside trend charts and recommended recovery
actions.

4.3 UML USE CASE DIAGRAM

The UML Use Case Diagram represents the interactions between the
system's actors and the functional capabilities it exposes.

15
 Figure 4.3 UML Use Case Diagram

The primary actor is the System Administrator or Site Reliability

Engineer, who interacts with the monitoring dashboard to view real-time
anomaly status, inspect historical health trends, and review recovery
recommendations. The secondary actor is the Backend API System, which
continuously generates log data that serves as the input to the detection
pipeline. Key use cases include ingesting and parsing API logs, extracting
and normalizing features, executing the anomaly detection model,
classifying system health status, generating recovery recommendations, and
visualizing results on the monitoring dashboard.

4.3 UML ACTIVITY DIAGRAM

The Log-Based Anomaly Detection and Predictive Failure Monitoring

for API Systems begins its flow when the API layer receives a client request,
executes the business logic, and writes access, error, and latency logs. These
logs are then collected, buffered, parsed, and passed through the log pipeline
where features such as latency, error rate, and request count are extracted and
normalized per time window. The processed feature vectors are forwarded to
the ML engine where the Isolation Forest model computes an anomaly score
and decides whether the behavior is normal or abnormal. If an anomaly is
detected, the system classifies its severity as either Critical — triggering
circuit breaking or resource scaling — or Warning — recommending retry or
service isolation — and generates a recovery alert. Finally, the detection
results are stored in PostgreSQL and displayed on the monitoring dashboard,
giving engineers a real-time view of system health and recommended
actions.

16
17
18
 CHAPTER 5

IMPLEMENTATION

5.1 MODULES

▪​ BACKEND API EXECUTION AND LOG GENERATION

▪​ LOG ACQUISITION AND STREAMING
▪​ LOG PARSING AND FEATURE EXTRACTION
▪​ DATA PREPROCESSING AND NORMALIZATION
▪​ MACHINE LEARNING-BASED ANOMALY DETECTION
▪​ HEALTH ASSESSMENT AND RISK CLASSIFICATION
▪​ MONITORING DASHBOARD AND VISUALIZATION

5.1.1 Backend API Execution and Log Generation

The first module forms the operational foundation of the system. It is
responsible for executing incoming API requests and generating the
structured operational logs that serve as the raw input for all downstream
processing. Built using Java 17 and Spring Boot, the backend exposes a set
of REST API endpoints that receive HTTP requests, execute the
corresponding business logic, and return appropriate HTTP responses. At
each stage of request handling, the module automatically generates log
entries capturing the request arrival timestamp, the API endpoint path and
HTTP method, the HTTP response status code, the total processing latency
in milliseconds, and the content of any error messages generated during
processing. These logs are formatted in a structured, machine-readable
format and written to the application log stream, from where they are picked
up by the log acquisition module.

19
Outputs from this module include API access logs, error logs, and latency
logs.

5.1.2 Log Acquisition and Streaming

The second module is responsible for reliably collecting log output
from the backend system in real time and forwarding it to the processing
pipeline without data loss. The log collector component continuously reads
the log stream produced by the backend API service, buffers incoming log
entries to handle transient bursts, and handles variations in log format that
may arise across different service versions. A critical design principle of this
module is the guarantee of reliable log capture: no log entries should be
dropped, even under high-throughput conditions, as missed entries could

20
cause the anomaly detection model to develop a distorted view of system
behavior.

Once buffered and validated, log entries are forwarded to the feature
extraction pipeline for further processing.

5.1.3 Log Parsing and Feature Extraction

The third module transforms the raw, semi-structured text of API log
entries into the structured numerical feature vectors required by the machine
learning model. The processing engine parses each log entry to extract its
constituent fields: the timestamp, the API endpoint identifier, the HTTP
status code, the response latency in milliseconds, and any error indicators.
Individual log entries are then grouped into fixed-duration time windows,
and a set of statistical aggregation operations is applied to each window to

21
derive the final feature set. The extracted features include mean latency per
time window, maximum latency per time window, error rate calculated as the
proportion of 4xx and 5xx responses to total requests, total request count per
window, and timeout occurrence count.

This time-window aggregation approach is essential because the anomaly

detection model operates on aggregate behavioral patterns rather than
individual log events.

5.1.4 Data Preprocessing and Normalization

The fourth module prepares the feature vectors produced by the
extraction module for consumption by the machine learning engine. Raw
feature values produced by the aggregation stage may vary across several
orders of magnitude — for example, latency values measured in milliseconds

22
versus error rates expressed as small decimal fractions — which can
adversely affect the performance of distance-based anomaly detection
algorithms. The preprocessing pipeline addresses this by applying standard
feature scaling techniques that bring all feature dimensions into a
comparable numerical range.

In addition to scaling, the pipeline handles missing or inconsistent

feature values that may arise when a time window contains insufficient log
entries due to low traffic periods. The preprocessed and normalized feature
vectors are stored in the PostgreSQL database and made available to the
machine learning engine on demand.

23
5.1.5 Machine Learning-Based Anomaly Detection
The fifth module constitutes the core intelligence layer of the system.
The machine learning engine trains an Isolation Forest model on a corpus of
historical log-derived feature vectors representing the system's normal
operational behavior. The trained model learns to distinguish the compact,
densely distributed region of the feature space that corresponds to normal
API behavior from the sparser, more distant regions that may indicate
anomalous conditions. Once trained, the model is applied continuously to
incoming feature vectors, producing a real-valued anomaly score for each
time window. Feature vectors that fall in regions of the feature space that the
model has not previously observed receive high anomaly scores,

24
while vectors consistent with normal operation receive scores close to zero.
An optional Autoencoder neural network extension is also considered for
capturing more complex, non-linear behavioral patterns in the feature space.

5.1.6 Health Assessment and Risk Classification

The sixth module converts the continuous anomaly scores produced
by the machine learning engine into categorical system health assessments
and corresponding recovery recommendations. The decision engine applies
configurable severity thresholds to each anomaly score and assigns the
current

25
system state to one of three health categories: Healthy, indicating that all
metrics are within normal ranges; Warning,indicating that anomalous
behavior has been detected but the system is still operational; or Critical,
indicating a high-confidence detection of severe abnormal behavior with
significant risk of imminent service disruption. For each classified state, the
module generates an associated recovery recommendation,selecting from a
catalogue of predefined actions including increased retry intervals, activation
of circuit breaker mechanisms, and horizontal resource scaling.

5.1.7 Monitoring Dashboard and Visualization

The seventh module provides the user-facing interface through which
operators interact with the system's outputs. The visualization layer renders
real-time trend charts of key API performance metrics, highlights time

26
windows in which anomalies have been detected, displays the current system
health classification with an associated risk level indicator, and presents the
recommended recovery action for any active [Link] dashboard is
designed to support rapid incident response by surfacing the most
operationally relevant information clearly and without unnecessary
complexity. It also supports retrospective analysis by providing access to
historical anomaly records and trend data stored in the PostgreSQL database.

27
 CHAPTER 6

RESULTS

6.1 RESULT

The results of deploying the Log-Based Anomaly Detection and

Predictive Failure Monitoring system represent a meaningful advancement in
the application of machine learning techniques to API observability. The
system successfully demonstrated its ability to ingest structured API logs,
extract meaningful time-windowed features, and detect abnormal behavioral
patterns using an unsupervised Isolation Forest model trained on the LO2
benchmark dataset and validated against live Podinfo microservice telemetry.

A key finding of the implementation was the critical importance of

correct feature engineering. Naively using cumulative metric counters as
input features produced a large number of spurious anomaly detections, as
the monotonically increasing nature of cumulative values caused the model
to perceive them as persistent anomalies. Converting these counters into
rate-based features — expressing the change in metric value per unit time —
significantly reduced false positive detections and resulted in a more stable
and reliable anomaly score distribution.

The trained Isolation Forest model successfully identified periods of

elevated error rate, latency spikes, and unusual request throughput patterns
within the test dataset, producing anomaly scores that clearly differentiated
between normal operating conditions and degraded states. The health
classification layer correctly assigned severity labels to detected anomalies,
and the recommendation engine produced contextually appropriate recovery

28
suggestions for each classified incident. The end-to-end pipeline from log
ingestion through to dashboard visualization operated within acceptable
latency bounds, confirming the viability of the architecture for near-real-time
monitoring applications.

29
 CHAPTER 7

SYSTEM TESTING

7.1 TESTING OBJECTIVES

The purpose of testing is to discover errors. Testing is the process of

trying to discover every conceivable fault or weakness in a work product. It
provides a way to check the functionality of components, sub-assemblies
and/or a finished product. It is the process of exercising software with the
intent of ensuring that the software system meets its requirements and user
expectations and does not fail in an unacceptable manner. For the Log-Based
Anomaly Detection system, testing additionally verifies that the machine
learning model produces consistent and reliable anomaly scores, and that the
end-to-end pipeline from log ingestion to dashboard visualization functions
correctly under varied input conditions. There are various types of test. Each
test type addresses a specific testing requirement.

7.2 TYPES OF TESTS

In order to uncover the errors, present in different phases we have the

concept of levels of testing. The basic levels of testing are Unit Testing,
Integration Testing, System Testing, and Acceptance Testing.

7.2.1 Unit Test Cases

Unit testing involves the design of test cases that validate that the
internal program logic is functioning properly, and that program inputs
produce valid outputs. All decision branches and internal code flow should
be validated. It is the testing of individual software units of the application. It
is done after the completion of an individual unit before integration. In this

30
project the unit testing validates the program logic of all modules across the
anomaly detection pipeline.

The testing takes place as:

Input: Raw API Log Data

Output: Structured Feature Vectors and Anomaly Scores

Test ID Module Input Expected Output Result

Parsed JSON with
Raw API log entry timestamp,
UT-01 Log Parser Pass
string endpoint, status,
latency
Feature vector:
Feature Batch of 100 log
UT-02 mean latency, error Pass
Extractor entries
rate, request count
Raw feature vector Normalized feature
UT-03 Preprocessing with un-scaled vector in [0,1] Pass
values range
Isolation Feature vector Anomaly score <=
UT-04 Pass
Forest within normal range 0.0 (normal)
Health Anomaly score =
UT-05 Status: Warning Pass
Classifier 0.65

7.2.2 Functional Test Cases

Functional tests provide systematic demonstrations that functions
tested are available as specified by the business and technical requirements,
system documentation, and user manuals. Functional testing is a type of
testing that seeks to establish whether each application feature works as per
the software requirements. Each function is compared to the corresponding
requirement to ascertain whether its output is consistent with the end user's
expectations.

Functional testing is centered on the following items:

31
Valid Input: Structured API log files (JSON or plain text format), live log
streams from Spring Boot backend.

Functions: Inputs must be processed by the feature extraction, anomaly

detection, and classification pipeline.

Output: Correctly classified anomaly events with severity labels and

recovery recommendations.

Test ID Function Input Expected Output Result

Health status:
End-to-end Normal API log
FT-01 Healthy, no Pass
pipeline data
anomalies flagged
Log data with
End-to-end Health status:
FT-02 injected latency Pass
pipeline Warning or Critical
spike
Health status:
Log data with
End-to-end Critical, circuit
FT-03 elevated 5xx error Pass
pipeline breaker
rate
recommended
Anomaly
Detected anomaly
FT-04 Dashboard highlighted in Pass
event
timeline
Recommendation Critical anomaly - Suggest scaling or
FT-05 Pass
engine high latency circuit breaker

7.2.3 Integration Test Cases

Integration tests are designed to test integrated software components
to determine if they actually run as one program. Testing is event driven and
is more concerned with the basic outcome of screens or fields. Integration
tests demonstrate that although the components were individually
satisfactory, as shown by successful unit testing, the combination of
components is correct and consistent. Integration testing is specifically
aimed at exposing the problems that arise from the combination of
components.

32
In this project the integration testing verifies correct data flow across all
seven modules from log ingestion through to dashboard visualization.

Input: Complete API log dataset from LO2 benchmark; live log stream from
running Spring Boot service.

Output: End-to-end anomaly detection results stored in PostgreSQL and

visible on monitoring dashboard.

Expected
Test ID Integration Scope Scenario Result
Outcome
Features
Log Acquisition to Continuous log
IT-01 extracted Pass
Feature Extraction stream ingested
without data loss
Anomaly scores
Feature Extraction Feature vectors
IT-02 returned for all Pass
to ML Engine submitted to model
vectors
Scores forwarded All scores
ML Engine to
IT-03 to classification correctly Pass
Health Classifier
layer classified
Dashboard
Classifier to Results forwarded
IT-04 updates in real Pass
Dashboard to visualization
time
LO2 benchmark Known anomaly
IT-05 Full Pipeline dataset processed periods correctly Pass
end-to-end identified

33
 CHAPTER 8

CONCLUSION AND FUTURE ENHANCEMENT

8.1 CONCLUSION

The Log-Based Anomaly Detection and Predictive Failure Monitoring

project represents a culmination of advanced AI and data engineering
techniques, resulting in a fully functional prototype system capable of
detecting API anomalies with precision and providing actionable recovery
guidance. Through the integration of unsupervised machine learning using
the Isolation Forest algorithm, time-window-based feature engineering, and a
modular microservice-compatible pipeline architecture, the system
demonstrates exceptional anomaly detection capabilities and operational
awareness.

System metrics were collected from the LO2 benchmark dataset and
validated against live Podinfo microservice telemetry, ensuring both research
validity and practical relevance. Proper feature engineering — specifically
the conversion of cumulative counters into rate-based metrics — was found
to be essential for reliable model performance and significantly reduced the
incidence of false anomaly detections. The trained ML model was integrated
with a Java Spring Boot backend through a well-defined REST API
interface, enabling a scalable and modular system architecture. Anomaly
detection results were persistently stored and surfaced through a monitoring
dashboard that supports both real-time incident response and retrospective
trend analysis.

34
 The project's outcomes not only validate the feasibility of machine
learning-driven anomaly detection as a complement to traditional rule-based
API monitoring, but also underscore the potential for transformative
advancements in intelligent, self-healing API infrastructure. This endeavor
serves as a testament to the capabilities of modern AIOps engineering and
paves the way for future developments in predictive monitoring
technologies, promising a future of more reliable, efficient, and autonomous
API systems.

8.2 FUTURE ENHANCEMENT

Real-Time Streaming with Apache Kafka: Integrate Apache Kafka as a

high-throughput, fault-tolerant message broker between the log acquisition
layer and the feature extraction pipeline, enabling the system to handle log
volumes from large-scale production microservice deployments without data
loss or processing latency.

Advanced ML Models: Extend the anomaly detection engine to incorporate

deep learning approaches such as LSTM-based time-series models and
Autoencoder networks, which are capable of capturing complex temporal
dependencies in log-derived feature sequences that the Isolation Forest
model cannot represent.

Automated Self-Healing Actions: Evolve the recommendation engine into

a full self-healing capability by integrating with container orchestration
platforms such as Kubernetes, enabling the system to automatically trigger
recovery actions — such as pod restarts, horizontal scaling, and circuit
breaker activation — in response to high-confidence critical anomaly
detections.

35
Log Semantic Analysis with NLP: Incorporate natural language processing
techniques, inspired by approaches such as LogBERT, to extract semantic
features from the textual content of error log messages, enabling the system
to detect anomalies that manifest primarily in log message patterns rather
than in numerical performance metrics.

36
8.3 APPENDICES – CODE SNIPPET
A.1 Isolation Forest Model Training - train_model.py

The following snippet shows the core model training logic. The full training
script includes data loading, feature engineering, cross-validation, and result
visualisation.

# Load normal baseline training data

df = pd.read_csv('processed_data/features_train_normal.csv')
X_train = df[FEATURE_COLS].values

# Fit StandardScaler on training data

scaler = StandardScaler()
X_scaled = scaler.fit_transform(X_train)

# Train Isolation Forest

model = IsolationForest(
n_estimators=100,
contamination=0.05,
random_state=42
)
[Link](X_scaled)

# Persist model and scaler

[Link](model, 'models/isolation_forest.pkl')
[Link](scaler, 'models/[Link]')

A.2 Python ML Service — Prediction Endpoint (ml_service.py)

The following snippet shows the core prediction logic. The full service
includes batch prediction, health checks, model metadata endpoints, and
CORS middleware.

@[Link]("/predict", response_model=AnomalyPrediction)
async def predict(metrics: MetricFeatures):
features_df = prepare_features([Link])
features_scaled = model_manager.[Link](features_df)

prediction = model_manager.[Link](features_scaled)[0]

37
 anomaly_score =
model_manager.model.score_samples(features_scaled)[0]

is_anomaly = prediction == -1
confidence = determine_confidence(anomaly_score)

return AnomalyPrediction(
timestamp = [Link]().isoformat(),
is_anomaly = is_anomaly,
anomaly_score = float(anomaly_score),
confidence = confidence,
recommendation= generate_recommendation(anomaly_score,
is_anomaly))

A.3 Java Recommendation Engine ([Link])

The following snippet shows the pattern-matching decision logic. The full
service includes recovery tracking, consecutive clean cycle counting, and
RESUME recommendation.

public ActionDecision decide(boolean isAnomaly, double score,

int goroutines, double latencyMs, int openFds) {

if (!isAnomaly) return buildNormal(); // handles recovery internally

// Pattern 1 — Concurrency explosion

if (goroutines > 500 && latencyMs < 1000) {
return build("CRITICAL", "CIRCUIT_BREAKER",
"Goroutine explosion + FD exhaustion",
"Enable circuit breaker immediately. Investigate upstream traffic
source.");
}
// Pattern 2 — Performance degradation
if (latencyMs > 2000 && goroutines < 100) {
return build("WARNING", "SCALE",
"Service degradation",
"Scale service replicas or inspect downstream dependencies.");
}
// Pattern 3 — High-confidence generic anomaly
if (score < -0.65) {
return build("CRITICAL", "CIRCUIT_BREAKER",

38
 "Abnormal metric combination",
"Temporarily stop traffic and perform root cause analysis.");
}
// Pattern 4 — Moderate anomaly
return build("WARNING", "RETRY",
"Transient deviation",
"Retry requests with exponential backoff and monitor closely.");
}

A.4 Feature Engineering — Rate Calculation (extract_features.py)

The following snippet shows how raw Prometheus counters are converted
to rate-based features. The full script includes data merging, outlier removal,
and train/test split.

def compute_features(df):
df = df.sort_values('timestamp')
dt = df['timestamp'].diff().dt.total_seconds().fillna(5)

def rate(col):
return df[col].diff().fillna(0) / [Link](0, 5)

features = [Link]()
features['http_requests_total_rate_per_sec'] =
rate('http_requests_total').clip(lower=0)
features['http_request_duration_seconds_sum_rate'] =
rate('http_request_duration_seconds_sum').clip(lower=0)
features['avg_request_duration_sec'] =(
features['http_request_duration_seconds_sum_rate'] /
rate('http_request_duration_seconds_count').clip(lower=0.001)
)
features['go_goroutines'] = df['go_goroutines']
features['process_open_fds'] = df['process_open_fds']
return [Link]()

39
A.5 Dashboard — Prometheus Metric Parser (live_dashboardX.html)

The following snippet shows how the browser parses raw Prometheus text
into numerical values. The full dashboard includes chart rendering,
simulation ramp logic, 3-colour state machine, and recovery tracking.

function parseMetrics(text) {
const get = name => {
const m = [Link](
new RegExp('^' + name + '(?:{[^}]*})? ([\\d.e+\\-]+)', 'm')
);
return m ? parseFloat(m[1]) : 0;
};
return {
go_goroutines: get('go_goroutines'),
go_memstats_alloc_bytes: get('go_memstats_alloc_bytes'),
go_memstats_heap_inuse_bytes:
get('go_memstats_heap_inuse_bytes'),
process_open_fds: get('process_open_fds'),
http_requests_total: get('http_requests_total'),
http_request_duration_seconds_sum:
get('http_request_duration_seconds_sum'),
http_request_duration_seconds_count:
get('http_request_duration_seconds_count'),
process_cpu_seconds_total: get('process_cpu_seconds_total'),
};
}

40
8.3 APPENDICES – SYSTEM SCREENSHOT

B.1 — System Normal State

The dashboard in its normal operating state. The status banner displays
SYSTEM NORMAL in green with a checkmark icon. The anomaly score
panel shows a score around -0.38, confidence LOW, and action Continue
Monitoring. Goroutines are at baseline (9–13 threads), memory allocation is
stable at approximately 21 MB, and the goroutine chart shows a flat blue
line. The real-time analysis log confirms consecutive normal readings with
varying goroutine and FD values, confirming the system is operating within
learned normal parameters.

B.2 — Elevated Risk State (Yellow)

41
The dashboard transitioning from normal to anomaly during stress injection.
The status banner has turned yellow and displays ELEVATED RISK. The
anomaly score has drifted to approximately -0.45, approaching the -0.50
detection threshold. The goroutine chart shows an upward curve beginning
around 60–80 threads. The analysis log shows ELEVATED entries with ramp
percentage, indicating the system has detected metric drift but not yet
confirmed a full anomaly. This intermediate state gives operators early
warning before the threshold is crossed.

B.3 — Anomaly Detected State (Red — Stress Pattern)

The dashboard in full anomaly state triggered by the stress load pattern. The
banner displays ANOMALY DETECTED in red with an exclamation icon.
The anomaly score reads -0.75, confidence HIGH. The action field shows
Isolate & Stop Inbound Traffic. The goroutine card shows 800+ threads,
open FDs have spiked correspondingly. The analysis log shows CRITICAL
entries with trigger pattern Goroutine explosion + FD exhaustion and
operator guidance to enable circuit breaker and investigate upstream traffic
source. The goroutine chart shows a sharp exponential climb in red.

42
 REFERENCES

1 . Aggarwal, C. C. (2017). Outlier Analysis (2nd ed.). Springer.

[Link]
2. Chandola, V., Banerjee, A., & Kumar, V. (2009). Anomaly detection:
A survey. ACM Computing Surveys, 41(3), 1–58.
[Link]
3. Chen, J., He, B., & Zhong, Y. (2020). Towards AIOps: A literature
review of intelligent IT operations. Journal of Systems and Software,
168, 110639.
4. Liu, F. T., Ting, K. M., & Zhou, Z.-H. (2008). Isolation forest.
Proceedings of the 8th IEEE International Conference on Data Mining
(ICDM), 413–422. [Link]
4. Liu, F. T., Ting, K. M., & Zhou, Z.-H. (2012). Isolation-based anomaly
detection. ACM Transactions on Knowledge Discovery from Data,
6(1), 1–39. [Link]
6. Pedregosa, F., Varoquaux, G., Gramfort, A., Michel, V., Thirion, B.,
Grisel, O., … Duchesnay, E. (2011). Scikit-learn: Machine learning in
Python. Journal of Machine Learning Research, 12, 2825–2830.
7. Prometheus Authors. (2023). Prometheus: Monitoring system and time
series database. [Link]
8. Prodan, S. (2023). Podinfo: Go microservice template for Kubernetes.
[Link]
9. Soldani, J., & Brogi, A. (2022). Anomaly detection and failure root
cause analysis in (micro)service-based cloud applications: A survey.
ACM Computing Surveys, 55(3), 1–39.
[Link]
10. Spring Framework Authors. (2023). Spring Boot reference
documentation. [Link]
11. Tiangolo, S. (2023). FastAPI: Modern, fast web framework for
building APIs with Python. [Link]
12. Xu, H., Chen, W., Zhao, N., Li, Z., Bu, J., Li, Z., … Pei, D. (2018).
Unsupervised anomaly detection via variational auto-encoder for
seasonal KPIs in web applications. Proceedings of WWW 2018,
187–196. [Link]

43