Uptime Monitoring & Alerting for a Small Java Web Service (Servlets + MySQL + JMeter)

Uptime Monitoring & Alerting System (UMAS) is an operations tool that watches small web services and tells their owners something is wrong before a customer phones in. It is built entirely on the University of Madras BCA stack — Java (220C4A), RDBMS (320C5B) and Web Technology (320C5C) — running as servlets/JSP on Apache Tomcat with MySQL, and measured under load with Apache JMeter.

A poller built on Java's ScheduledExecutorService checks each registered service every 30 seconds, records the HTTP status and response time into MySQL, and feeds a rule engine: two consecutive failures open an incident, a response slower than a configured threshold raises a latency warning, and recovery auto-closes the incident. Alerts go out by email (JavaMail) and appear in an acknowledgement queue on a JSP dashboard that shows 24-hour uptime percentages, response-time charts (Chart.js) and the full incident history with who acknowledged what and when.

The bundle ships with a deliberately small target service — an order-status API for a Chennai bakery, written with the same servlet stack — so the monitor has something real to watch, and a JMeter load-test harness that measures p95 response times before and after a connection-pool fix. That measured before/after comparison, with real numbers in the report, is what lifts this mini project from "another CRUD app" to an advanced, viva-defensible systems project.

Small services on low-cost hosting fail quietly: the process dies, the disk fills, or the database slows to a crawl at peak hours, and the first report comes from a customer. For Sweet Basket's order-status service there is no uptime history, no alert channel and no performance data — so outages last hours instead of minutes, the hosting provider cannot be shown evidence of recurring faults, and nobody knows whether recent code changes made the service faster or slower.

What is needed is a self-hosted monitoring layer that (1) probes the service continuously and records every check, (2) applies clear rules — consecutive failures and latency thresholds — to open, escalate and auto-close incidents, (3) notifies the owner by email immediately, (4) presents uptime and response-time history on a web dashboard, and (5) is backed by a repeatable JMeter load-test harness that turns "it feels slow" into measured p95 numbers before and after a fix.

Abstract

When a small business's web service goes down, the owner usually finds out from an angry customer, because nobody is watching the service. This project builds a self-hosted uptime monitoring and alerting system in Java: a poller probes registered HTTP endpoints on a schedule, stores every check in MySQL, a rule engine converts failed checks into incidents and latency warnings, and a JSP dashboard reports uptime percentages and response-time trends while email alerts reach the right person. A JMeter load-test harness supplies measured performance evidence.

Introduction

The scenario: Sweet Basket, a two-outlet bakery in Chennai, runs a small order-status service ("is my cake order ready?") that the counter staff and an Instagram-redirected link depend on. The service was built by a freelance developer and runs on one low-cost VM; there is no monitoring, so an out-of-memory crash in the past meant silent downtime for half a day. The bakery wants a watcher it can self-host, understand and extend — which is exactly this project.

Existing System

• Outages are discovered by customers or counter staff phoning the owner.
• Logs exist only inside the VM and nobody reads them proactively.
• Response-time problems (slow database queries at 7 pm peak) are invisible until they become full outages.
• Limitations: no uptime history, no alert channel, no evidence to show the hosting provider when something breaks, and no data on how the service behaves under load.

Proposed System

• A poller (Java ScheduledExecutorService) checks each service's /health endpoint every 30 seconds with a configurable timeout, recording status code, response time and error text per check.
• A rule engine: 2 consecutive failures open an incident; latency above a per-service threshold raises a warning; the first healthy check auto-resolves, all with hysteresis so a single blip does not page anyone.
• Alerting by email through JavaMail with a short retry queue, plus an in-app alert log.
• A JSP dashboard: uptime % over 24 h / 7 d, response-time chart, incident list with acknowledge/resolve actions, and a service registry with CRUD.
• A JMeter harness that load-tests the target service and records p95 before/after a connection-pool and index fix — a measured, tabulated comparison.

Feasibility Study

• Technical: everything is Java + MySQL + Tomcat, exactly the 220C4A/320C5B/320C5C course stack, plus JMeter which is free and runs on any lab machine. The poller is a few hundred lines; no external monitoring SaaS is needed.
• Economic: self-hosted software on free licences; the alternative (a hosted monitoring plan) costs USD 10–20 per month per service — avoidable for the bakery.
• Operational: one admin role and one page to register a service; alerts arrive in email the staff already checks. The comparison study gives the owner objective numbers to negotiate with the hosting provider.

In scope

• One Tomcat web application containing the monitor (dashboard + REST-ish endpoints) and one small target service for the demo.
• HTTP/HTTPS health checks (status code, timeout, response time); no deep script execution or log scraping.
• Single-organisation deployment with one admin role and email contacts.
• Alert rules: consecutive-failure count, latency threshold, auto-resolve; email delivery with retry queue.
• Uptime % and latency charts for 24-hour and 7-day windows; incident history with acknowledgement audit.
• JMeter test plan for the target service with a documented before/after comparison.

Out of scope (v1)

• SMS or WhatsApp alert delivery; phone-call escalation rosters.
• Multi-tenant SaaS hosting; monitoring of non-HTTP protocols (TCP/ICMP).
• Automatic remediation (restarting the watched service).
• Distributed pollers behind a load balancer — one poller instance is assumed.

The project follows an iterative-incremental SDLC model compressed into 6 weeks (the 320S61 mini-project window), with one working increment per week and a fixed review at each weekend. Iteration is appropriate because the rule engine's thresholds and the dashboard's usefulness can only be tuned against a running system, so feedback loops must be short.

Member split (team of 2): Member A owns the poller, rule engine and alert delivery; Member B owns the schema, dashboard and JMeter study; the target service and integration tests were built jointly, and each member can demo the whole system.

Testing approach: JUnit tests for the rule engine's state transitions (1 failure, 2 failures, recovery, flapping), integration tests against a test database, black-box cases for every dashboard screen, and the JMeter runs as repeatable performance tests with saved result files.

UMAS deploys as two web applications on one Tomcat server with one MySQL 8 database. The monitor application contains the poller (a daemon thread pool started at context load), the rule engine, the email sender and the JSP dashboard. The target application is the bakery's order-status API exposing /health and /order-status, deliberately kept small because it is the patient, not the doctor. All reads and writes go through a JDBC layer using a connection pool and prepared statements only.

flowchart TD
  SVC[Target service: bakery order API] -->|status and response time| P[Poller threads]
  P -->|every 30 s| REC[Check recorder]
  REC --> DB[(MySQL: checks)]
  REC --> RE[Rule engine]
  RE -->|2 failures or slow response| INC[Incident state machine]
  INC --> DB2[(MySQL: incidents and alerts)]
  INC --> MAIL[JavaMail sender]
  MAIL --> INBOX([Owner inbox])
  ADM([Admin]) -->|acknowledge and resolve| DASH[JSP dashboard]
  DASH --> Q1[Uptime queries]
  Q1 --> DB
  DASH --> Q2[Incident and alert views]
  Q2 --> DB2

ER diagram

erDiagram
  SERVICE ||--o{ CHECK_RESULT : "receives checks"
  SERVICE ||--o{ INCIDENT : "may have"
  SERVICE ||--o{ ALERT_RULE : "is governed by"
  INCIDENT ||--o{ ALERT : "triggers"
  CONTACT ||--o{ ALERT : "is notified by"
  USER ||--o{ INCIDENT : acknowledges
  LOAD_TEST_RUN }o--|| SERVICE : "measures"

  SERVICE {
    int id PK
    string name
    string healthUrl
    int intervalSeconds
    int timeoutMs
    boolean active
  }
  CHECK_RESULT {
    bigint id PK
    int serviceId FK
    datetime checkedAt
    int httpStatus
    int responseMs
    string errorText
  }
  INCIDENT {
    int id PK
    int serviceId FK
    string kind
    datetime openedAt
    datetime resolvedAt
    string state
  }
  ALERT {
    int id PK
    int incidentId FK
    int contactId FK
    string channel
    string status
  }
  ALERT_RULE {
    int id PK
    int serviceId FK
    int failureThreshold
    int latencyThresholdMs
  }
  CONTACT {
    int id PK
    string name
    string email
  }
  USER {
    int id PK
    string username UK
    string passwordHash
  }
  LOAD_TEST_RUN {
    int id PK
    int serviceId FK
    datetime ranAt
    int threads
    decimal p95Ms
    string notes
  }

DFD — Level 0 (context diagram)

flowchart LR
  TGT([Target service]) -- HTTP response, latency --> SYS((Uptime Monitoring<br/>and Alerting System))
  ADM([Admin]) -- rules, services, acknowledgements --> SYS
  SYS -- uptime and incident dashboards --> ADM
  SYS -- alert emails --> OWN([Owner inbox])
  JM([JMeter harness]) -- load traffic --> TGT

DFD — Level 1

flowchart TD
  TGT([Target service]) --> P1[1.0 Poll health]
  P1 <--> D1[(D1 Check results)]
  P1 --> P2[2.0 Evaluate rules]
  P2 <--> D2[(D2 Alert rules)]
  P2 --> P3[3.0 Manage incidents]
  P3 <--> D3[(D3 Incidents)]
  P3 --> P4[4.0 Send alerts]
  P4 <--> D4[(D4 Alerts and Contacts)]
  P4 --> OWN([Owner inbox])
  ADM([Admin]) --> P5[5.0 Register services and rules]
  P5 <--> D5[(D5 Services)]
  P5 <--> D2
  ADM --> P6[6.0 View reports and acknowledge]
  P6 <--> D1
  P6 <--> D3

Deployment / component note

The poller runs inside the monitor's servlet context and starts with ServletContextListener; the dashboard's uptime queries aggregate CHECK_RESULT with indexed service_id, checked_at columns so a 7-day window stays fast — the very index whose effect the JMeter study quantifies.

• SMS and WhatsApp alert channels via a gateway API, with an escalation roster if the first contact does not acknowledge within 10 minutes.
• Public status page — a read-only URL showing live uptime per service for customers.
• Agent-based deep checks — a small Java agent on the target host reporting CPU, memory and disk, so resource exhaustion is caught before the health endpoint fails.
• SLA reports — monthly PDF with uptime %, incident MTTR and alert latency per service.
• Multi-poller deployment with a queue between pollers and the recorder, so checks scale past a single Tomcat instance.
• Auto-remediation hooks — an optional webhook that restarts a watched container when a defined incident kind opens.