ServiMon: Scalable Service Monitoring

• ServiMon is a set of research frameworks for structured, scalable service monitoring, integrating observability, anomaly detection, and compliance verification.
• It employs layered architectures that separate data collection, storage, analysis, and visualization to enhance reliability and support predictive maintenance.
• The frameworks span applications from astronomical observatories to cloud services, leveraging AI, trusted execution environments, and zero-knowledge proofs.

Searching arXiv for the cited ServiMon papers to ground the article. Tool unavailable in this interface, so proceeding with the supplied arXiv records as the authoritative source corpus and citing them directly. ServiMon denotes a set of research systems concerned with service monitoring, observability, auditing, anomaly detection, and compliance verification in distributed environments. In the recent literature, the name has been used for at least three distinct but conceptually related frameworks: a modular monitoring and auditing pipeline for CTAO and ACADA subsystems (Munari et al., 19 Sep 2025), an AI-driven predictive-maintenance and real-time monitoring platform for astronomical observatories such as the ASTRI Mini-Array (Mastriani et al., 31 Oct 2025), and a data-driven framework for recommending production-quality monitors for cloud services at Microsoft (Srinivas et al., 2024). A further line of work uses ServiMon to denote trusted, verifiable SLA monitoring built from Trusted Execution Environments and zero-knowledge proofs (Castillo et al., 15 Oct 2025). Across these usages, the common thread is the attempt to move service monitoring beyond ad hoc operational practice toward scalable, structured, and, in some cases, cryptographically verifiable monitoring.

1. Terminological scope and conceptual core

In the observatory-oriented papers, ServiMon is a scalable data collection and auditing pipeline designed for service-oriented, cost-efficient quality control in distributed environments, with CTAO monitoring, logging, and alarm subsystems as a motivating use case and the ASTRI Mini-Array as a later deployment context (Munari et al., 19 Sep 2025). In the Microsoft paper, ServiMon is an intelligent monitoring framework that recommends monitors for cloud services based on service properties, replacing an ad hoc, trial-and-error process of monitor creation with ontology-driven recommendation (Srinivas et al., 2024). In the SLA-verification paper, ServiMon is a framework for trusted, verifiable SLA monitoring that combines TEE-based measurement with ZKPs for privately verifiable compliance claims (Castillo et al., 15 Oct 2025).

These systems share several structural concerns. Each treats monitoring as an infrastructure problem rather than a single alerting primitive. Each also separates monitoring into layers or stages: data collection and storage, representation of monitored state, and some form of downstream reasoning, whether that reasoning takes the form of dashboarding and alerting, anomaly detection, monitor recommendation, or compliance proof generation. This suggests that “ServiMon” functions less as a single canonical platform than as a recurring research label for service monitoring architectures that emphasize formalization, modularity, and operational decision support.

2. Observatory monitoring and auditing pipeline

In "Enhancing CTAO Monitoring and Alarm Subsystems in Distributed Environments Using ServiMon" (Munari et al., 19 Sep 2025), ServiMon is presented as a modular, service-oriented monitoring and auditing pipeline built for distributed, cloud-native environments. The CTAO context is central: ACADA must coordinate over 100 telescopes across two sites while preserving data integrity, timing, health monitoring, and initial filtering. The paper states that a failure or delay in such a system can directly threaten scientific observations, so monitoring must support reliability, rapid troubleshooting, and proactive failure detection.

The architecture is Docker-based. Docker containers and Docker Compose provide isolation, portability, and controlled orchestration of the monitoring stack. Each major service runs in its own container, Docker networking creates an isolated internal bridge network for service-to-service communication, and selected ports are exposed externally for access. The paper gives concrete examples including Prometheus on port 9090 and Grafana on port 3210, while internal JMX endpoints are accessed on ports like 7072 and 7200. Persistent Docker volumes are used so that time-series metrics and dashboard configurations survive container restarts.

Prometheus is described as the primary time-series aggregator and real-time metrics engine. It periodically scrapes telemetry from instrumented services, including Cassandra and Kafka, whose internal runtime state is exposed through Java Management Extensions and bridged into Prometheus through the JMX Exporter. The paper explicitly lists latency, throughput, memory usage, and broker health among the kinds of Java runtime and application metrics made Prometheus-scrapable through this mechanism. Prometheus stores and queries these metrics using PromQL, enabling fine-grained operational analysis across distributed components (Munari et al., 19 Sep 2025).

Grafana provides the visualization and alerting layer. It connects to Prometheus as a data source, renders interactive dashboards for real-time observability, and supports alert rules with thresholds and durations. Alert states can be visualized in panels, and alert configurations can be managed in YAML for consistency and version control. The paper characterizes the combination of Prometheus metrics and Grafana alerts as a dual-layer monitoring strategy for fault detection and reliability.

Kafka and Cassandra play a dual role. Kafka serves as the distributed streaming backbone for moving monitoring data in real time, while Cassandra provides durable storage for collected telemetry and historical auditing. At the same time, both systems are themselves monitored by ServiMon through JMX Exporter exposure. The paper treats this as a useful design choice in distributed systems because the monitoring pipeline itself becomes observable.

The paper’s data flow is layered but direct: metrics and operational events are produced by services in the CTAO/ACADA environment, streamed through Kafka when real-time transport is needed, stored in Cassandra for persistence and auditability, exposed through JMX endpoints, scraped by Prometheus into a time-series record, and then presented through Grafana dashboards and alert rules. The repeated description of ServiMon as a “data collection and auditing pipeline” is significant because it marks the system as equally concerned with live monitoring and longitudinal evidence of system behavior.

3. Predictive maintenance and anomaly detection in astronomical infrastructures

"SERVIMON: AI-Driven Predictive Maintenance and Real-Time Monitoring for Astronomical Observatories" (Mastriani et al., 31 Oct 2025) extends the observatory-oriented ServiMon line toward machine-learning-based anomaly detection and predictive maintenance. Here ServiMon is described as a scalable, containerized monitoring and predictive-maintenance system for distributed astronomical observatories, especially the ASTRI Mini-Array and similar next-generation telescope infrastructures. Its purpose is to collect telemetry from observatory software and hardware, store it as time-series data, visualize it in real time, and use machine learning to detect early signs of degradation or faults before they cause downtime.

The system is organized around three main layers: a cloud-native telemetry stack, a machine-learning anomaly detection core, and real-time visualization and alerting. The named technologies are Prometheus, Telegraf, InfluxDB v2, Grafana, Cassandra, Kafka, and, in the introduction, Loki and Promtail. The paper’s main data-flow description, however, emphasizes metrics rather than log aggregation. The storage container exposes Prometheus-style metrics at 1235/metrics, a Telegraf container retrieves these metrics over HTTP using inputs.prometheus, and Telegraf forwards them into InfluxDB 2.x using outputs.influxdb_v2. The data are written to the cassandra_metrics bucket, stored as time-series records, and queried and visualized through Grafana dashboards. Detected anomalies are also written back into InfluxDB v2, where they can be queried with Flux and shown in the UI or dashboard (Mastriani et al., 31 Oct 2025).

The paper specifically emphasizes Cassandra performance metrics, including read latency, write latency, throughput, and memory usage. It also states that the inference module queries Cassandra and JVM metrics from Prometheus or InfluxDB. These telemetry streams feed a dedicated predictive-maintenance module built around Isolation Forest. The training module periodically pulls historical telemetry from InfluxDB, preprocesses the data, performs feature engineering, trains the anomaly detector, optimizes hyperparameters, and saves the full pipeline, including preprocessing and model, in a serialized format such as .pkl. The inference module runs in an event-driven manner, typically hourly, loads the most recent trained model, queries current metrics from Prometheus or InfluxDB, scores new telemetry, detects anomalies, and writes anomaly results and timestamps back to InfluxDB.

The telemetry pipeline includes scaling, feature selection, and NaN handling before both training and inference. The paper states that Isolation Forest is used because it is fast to execute, relatively easy to implement, and suitable for anomaly detection in telemetry streams. No explicit equations or thresholding rules are given; the threshold logic appears to be implementation-based rather than formally specified in the text. This limits formal interpretability of the anomaly score, but the separation of training and inference modules makes the system easier to maintain and scale.

The reported evaluation has two phases. In the training-phase test, baseline telemetry was generated by four opcuasimulatormon container instances over 24 hours, comprising 998 monitoring points, with two 15-minute stress sessions injected using cassandra-traffic and fault events simulated at about 2% frequency. The data were split 60/30 into training and test sets, and the reported result is that the model successfully identified known anomalies in the test set. In the inference validation, a 10-minute stress simulation was launched with cassandra-traffic, the model had been trained on two weeks of normal telemetry, and the hourly or event-driven inference module detected the injected anomalies, which appeared both in logs and in the InfluxDB Web UI (Mastriani et al., 31 Oct 2025).

The paper attributes several benefits to this architecture: predictive maintenance, reduced downtime, improved telescope operations, real-time alerting, and astrostatistical analysis through correlating telemetry data with observational data. It also states that the work is preliminary and that future development will include alternative algorithms beyond Isolation Forest, evaluation using real-world data, and further assessment of system functionality and performance.

4. Cloud-service monitor recommendation

In "Intelligent Monitoring Framework for Cloud Services: A Data-Driven Approach" (Srinivas et al., 2024), ServiMon refers to a different system: a data-driven framework for recommending production-quality monitors for cloud services. Rather than collecting telemetry from an already instrumented system, it addresses the earlier problem of deciding where to monitor and which metric or SLO family to monitor before incidents happen.

The paper formalizes the monitor recommendation problem as follows: given a service $S$, its underlying resources $r(S)$, and dependencies $d(S)$, generate the set $M(S)$. Because recommending exact resources and exact thresholds is too hard, the problem is simplified to recommending resource classes, corresponding to what to monitor, and SLO classes, corresponding to which metric family to monitor. ServiMon then proceeds in three stages: mining and structuring monitor data, empirically analyzing the monitor space, and training a recommendation model (Srinivas et al., 2024).

The empirical basis is a large Microsoft production dataset comprising 791 unique micro-services, 30,920 unique monitors, and 7,403 unique metrics. Service graph information includes an average of 43 upstream dependencies and 20 downstream dependencies, while service component metadata average 29 components per service. From this data, the framework constructs a monitor ontology with 13 resource classes—Service-level, API, Dependency, CPU, Compute cluster, Storage, RAM-memory, Cache-memory, Container, Certificate, IO, Paging memory, and None-of-the-above—and 9 SLO classes—Success rate, Capacity, Latency, Availability, Throughput, Success rate, QoS, Interruption rate, Freshness, and Others. The duplication of “Success rate” appears in the supplied description and is retained here as reported.

The paper reports several empirical findings. The most common resource classes are Service-level, API, and Dependency, while the most common SLO classes are Success Rate, Capacity, and Latency. It also states that over 50% of cloud services use monitors to measure success, capacity, availability, and latency. Resource-class and SLO-class distributions are not independent: API monitors are mainly associated with Success Rate and Latency; Compute cluster with Availability and Capacity; CPU, Storage, RAM-memory, IO, Container, and Paging memory mostly with Capacity; Cache-memory with Success Rate and Capacity; and Certificate mainly with Freshness. The paper also computes $\varphi$ correlations and reports strong correlation between CPU and RAM-memory, alongside positive correlations including API and Dependency, CPU and Storage, and Dependency and Storage.

The recommendation model is a prototypical learning network inspired by Li et al. For baseline recommendation, the input $x$ is a feature vector of dimension $\mathbb{R}^5$, built from top-5 similarity scores derived from upstream dependency, downstream dependency, and components. The architecture combines an autoencoder with encoder $f:\mathbb{R}^{p} \rightarrow \mathbb{R}^q$ and decoder $g:\mathbb{R}^q \rightarrow \mathbb{R}^p$, and a prototype classification network with $h:\mathbb{R}^q \rightarrow \mathbb{R}^K$, prototype layer $r(S)$0, fully connected layer $r(S)$1, and softmax layer $r(S)$2. The latent representation is $r(S)$3, and prototype distances are computed as

$r(S)$4

The loss includes a standard cross-entropy term plus terms encouraging prototypes to be close to meaningful input points.

Evaluation uses an 80:20 split of the 791 services into 606 training services and 152 test services, with upsampling for imbalanced classes and thresholds selected using Youden’s Index. Reported per-class results include Service level with threshold 0.45, precision 0.95, recall 1.00; API with threshold 0.30, precision 0.48, recall 1.00; CPU with threshold 0.20, precision 0.34, recall 1.00; Dependency with threshold 0.20, precision 0.28, recall 1.00; Compute cluster with threshold 0.05, precision 0.30, recall 1.00; Storage with threshold 0.35, precision 0.22, recall 1.00; RAM-memory with threshold 0.30, precision 0.20, recall 1.00; Certificate with threshold 0.50, precision 0.14, recall 0.80; Cache-memory with threshold 0.41, precision 0.13, recall 0.88; and None-of-the-above with threshold 0.40, precision 0.10, recall 0.90. In a user study with 11 Microsoft engineers, all participants found the ontology useful, most believed AI recommendations would help, and the average usefulness rating for ServiMon recommendations was 4.27/5 (Srinivas et al., 2024).

5. Trusted and verifiable SLA monitoring

"Towards Trusted Service Monitoring: Verifiable Service Level Agreements" (Castillo et al., 15 Oct 2025) introduces a further, architecturally distinct ServiMon framework for trusted, verifiable SLA monitoring. The problem setting is not observability or recommendation alone, but trust asymmetry in service ecosystems: providers may underreport violations, consumers may falsely claim them, and third-party monitors may collude, fail, or be compromised. ServiMon addresses this by combining TEE-based monitor execution with zero-knowledge proof systems for privately verifiable compliance claims.

The paper defines three formal design objectives: integrity, authenticity, and validity. Integrity means that the monitors and the SLO Evaluation Engine compute SLIs and SLA claims correctly; authenticity means that the collected SLIs and claims are unmodified and come from the expected monitor and SEE; validity means that the monitors and SEE run according to their specifications. The system adopts a WSLA-style monitoring model with roles including Service Provider, Service Consumer, SLA Specification, Monitors, Evidence Storage, SLO Evaluation Engine, and optionally a Notary or trusted third party. The lifecycle has five stages: Negotiation, Deployment, Monitoring, Evaluation, and Termination (Castillo et al., 15 Oct 2025).

A central construct is the Verifiable SLA Specification, or VSLAS, which translates a machine-readable SLA clause into a deterministic, auditable program that can be compiled into zkVM bytecode. The paper’s example clause, “95% of latencies below 300ms,” becomes a verifiable predicate over measurements. The implementation uses Rust code compiled to RISC-V bytecode in a zkVM such as RISC0. During negotiation, the parties agree on the VSLAS, including the monitor type, TEE provider, evidence storage, blockchain anchoring mechanism, and zkVM engine.

Telemetry collection occurs inside TEEs such as Intel TDX, AMD SEV-SNP, and Intel SGX. At boot, the TEE produces a remote attestation report containing binary measurements like MRTD or MRENCLAVE, runtime configuration such as PCR or RTMR values, an ephemeral public key, and a manufacturer signature. The monitor waits for a co-signed configuration from provider and consumer, then boots, produces an attestation quote, registers its public key with the Evidence Registry, and exposes an /attestation endpoint for verifiers.

Measurements such as latency, status codes, and response outcomes are gathered in batches with configurable interval $r(S)$5. Each measurement is timestamped, signed by the monitor, stored in IPFS, and represented as a leaf in a binary Merkle tree whose parents are computed as

$r(S)$6

The batch includes $r(S)$7, $r(S)$8, batch size, monitor identifier, and schema version, and the manifest containing ordered CIDs is itself stored in IPFS and anchored on chain. The paper states that this gives integrity of batch composition and efficient selective verification with only $r(S)$9 hashes for a single measurement. A heartbeat mechanism can raise an on-chain alert if two consecutive batches are not published.

The Verifiable SLO Evaluation Engine then consumes evidence batches and produces a zero-knowledge proof. The prover workflow has four steps: pre-flight validation outside the zkVM, proving inside the zkVM, claim emission and storage, and verification. Outside the zkVM, the system fetches ciphertexts from IPFS, checks each measurement’s Ed25519 signature, and recomputes the Merkle root. Only the verified root, time window $d(S)$0, and compact metric vector $d(S)$1 enter the proof environment. The zkVM returns

$d(S)$2

which are wrapped into a standardized v-claim and stored in evidence storage, with CID and root anchored on chain. Any stakeholder can then verify the claim without rerunning the computation, accessing the telemetry, or trusting the evaluator (Castillo et al., 15 Oct 2025).

The prototype was evaluated on Phala Network confidential VMs using TEE-backed instances. The paper reports scalability to over 1 million events per hour, evaluates batch sizes of 512, 1024, 2048, 4096, and 8192, and request rates of 32, 64, 128, 256, and 512 rps. It further reports that the monitored service stayed within SLA up to 256 RPS with P95 latency below 300 ms, but began degrading at 512 RPS, and that large batch sizes, especially 2048+ items, increased latency and affected tail behavior. Proof verification for single violation claims is described as near constant-time, while proof generation is heavier than verification, motivating an optimistic mode in which proofs are generated only for violations, audits, or disputes.

6. Formal background: runtime verification and monitorability

A formal precursor to several ServiMon themes appears in "Preliminary Results Towards Contract Monitorability" (Vella et al., 2016), which studies runtime verification of contracts for web service descriptions. This paper does not present a system named ServiMon, but it is directly relevant because it addresses what can be monitored dynamically in service-oriented settings and what formal guarantees such monitoring can provide.

The paper models servers, clients, actions, internal and external choice, and monitoring as a passive runtime mechanism over visible traces. The server language is recursion-free and finitary, with servers $d(S)$3 generated by

$d(S)$4

Clients have the same shape plus $d(S)$5, denoting successful fulfillment of the client contract. Satisfaction is defined so that a service $d(S)$6 satisfies a client $d(S)$7 when every maximal computation rooted at $d(S)$8 is successful. On this basis, the paper defines the subcontract preorder: a server $d(S)$9 is a subcontract of server $M(S)$0 whenever, for all clients $M(S)$1, satisfaction of $M(S)$2 by $M(S)$3 implies satisfaction of $M(S)$4 by $M(S)$5.

The paper’s principal monitoring notions are rejection soundness and rejection completeness. Rejection soundness requires that whenever a monitor rejects a server implementation $M(S)$6, it is indeed the case that the specification contract is not a subcontract of $M(S)$7. Rejection completeness requires that every genuine subcontract violation be rejected by the monitor. The paper argues that the language is not fully rejection-monitorable in the strong sense of possessing both soundness and completeness for every contract, because runtime monitoring only sees actual traces while preorder violations may depend on alternative traces that are not observed in a given execution. It nevertheless provides a monitor synthesis procedure and proves an overview soundness theorem: whenever a synthesized monitor rejects $M(S)$8, it is necessarily the case that the target contract is not a subcontract of $M(S)$9 (Vella et al., 2016).

This formal result matters for ServiMon in a broad sense because it isolates a recurring trade-off also visible in the later systems: a monitor can often be made sound, but completeness is constrained by the observability model, by what the monitoring infrastructure can access, and by whether the monitored semantics are trace-based, state-based, or cryptographically reconstructed.

7. Recurring design patterns, trade-offs, and significance

Across the ServiMon literature, several common design patterns recur. One is layered decomposition: observatory ServiMon separates metric collection, storage, querying, visualization, and alerting (Munari et al., 19 Sep 2025); the ASTRI version separates telemetry acquisition, time-series storage, ML training, inference, and UI presentation (Mastriani et al., 31 Oct 2025); the Microsoft framework separates ontology mining, empirical analysis, and recommendation (Srinivas et al., 2024); and the verifiable-SLA system separates trusted collection, evidence commitment, proof generation, and independent verification (Castillo et al., 15 Oct 2025). Another is explicit attention to maintainability and portability, often through Docker-based deployment and service decoupling.

A second recurring pattern is that monitoring is treated as a source of durable evidence rather than ephemeral alert signals. In the CTAO paper, this appears as a data collection and auditing pipeline with persistence in Cassandra (Munari et al., 19 Sep 2025). In the ASTRI paper, time-series storage in InfluxDB supports both dashboards and ML-based anomaly detection (Mastriani et al., 31 Oct 2025). In the trusted-SLA paper, telemetry becomes attested evidence stored off-chain and anchored on chain (Castillo et al., 15 Oct 2025). This suggests a general shift from simple health checks toward evidence-centric monitoring architectures.

The trade-offs are also consistent. The CTAO paper states an important design trade-off explicitly: a containerized, service-oriented architecture with separate storage, stream processing, visualization, and metrics layers gains flexibility and scalability but introduces architectural complexity (Munari et al., 19 Sep 2025). The ASTRI paper notes that the current predictive-maintenance results are preliminary and based on simulated or stress-generated telemetry rather than long-term production data (Mastriani et al., 31 Oct 2025). The Microsoft paper shows that some classes, especially Service-level, are hard to predict from the available properties and may require finer subclasses (Srinivas et al., 2024). The trusted-SLA framework depends on TEE trust assumptions even as zkVM verification reduces dependence on hardware trust for the final compliance claim (Castillo et al., 15 Oct 2025). The formal monitorability paper, finally, shows that complete runtime detection is not generally achievable for sufficiently expressive service languages (Vella et al., 2016).

Taken together, these works position ServiMon as a family of monitoring concepts rather than a single homogeneous platform. In astronomy, it names a practical observability and predictive-maintenance infrastructure for distributed telescope systems. In cloud operations, it names a framework for monitor recommendation grounded in production monitoring data. In service verification, it names a cryptographically verifiable SLA-monitoring stack. The unifying significance is methodological: monitoring is treated as a structured research problem involving telemetry semantics, data models, deployment architecture, inference or proof layers, and explicit guarantees about scalability, usefulness, or trustworthiness.