MONITRS: Multi-domain Monitoring Approaches

• MONITRS is a research label applied to four distinct domains—observatory control, runtime verification, remote sensing datasets, and cloud service recommendations.
• In the Cherenkov Telescope Array, it integrates high-volume monitoring, logging, and alarm handling to enable real-time fault detection and maintenance.
• In runtime and disaster monitoring, MONITRS enhances computational efficiency and provides structured, data-driven insights, while in cloud operations it infers monitor classes via prototypical learning.

Searching arXiv for the papers associated with “MONITRS” to ground the article in the cited literature. MONITRS is a reused research label rather than a single standardized system. In the cited literature, it denotes four distinct artifacts: an integrated Monitoring, Logging, and Alarm capability within the Cherenkov Telescope Array’s Array Control and Data Acquisition System (ACADA); a multi-property temporal-logic runtime-monitoring framework implemented as LoomRV; a multimodal disaster-monitoring dataset and benchmark built from FEMA events, Sentinel-2 imagery, and news text; and an intelligent monitoring framework that recommends monitor classes for cloud services from production telemetry and service metadata (Costa et al., 2021, Demir et al., 13 May 2026, Revankar et al., 22 Jul 2025, Srinivas et al., 2024).

1. Research usage and disambiguation

The term MONITRS appears in multiple technical domains with different expansions, objectives, and computational substrates. In observatory operations, it refers to operator-facing monitoring, logging, and alarm handling. In runtime verification, it names a shared-monitor construction for many temporal properties. In Earth observation, it identifies a disaster-monitoring dataset and benchmark. In cloud operations, it denotes a recommendation framework for deciding what monitors a service should have.

Usage of MONITRS	Domain	Core object
Monitoring, Logging, and Alarm capability	CTA/ACADA observatory operations	Operational telemetry, logs, alarms
Multi-property monitoring / LoomRV	Runtime verification	Shared temporal-logic monitor
Multimodal Observations of Natural Incidents Through Remote Sensing	Remote sensing and MLLMs	Dataset and QA benchmark
Intelligent monitoring framework	Cloud services	Monitor recommendation system

This multiplicity matters because the same label can otherwise be mistaken for a single lineage of monitoring software. The literature instead shows domain-local acronym formation: each MONITRS instance is tied to a separate research problem, separate methodology, and separate evaluation regime. This suggests that MONITRS functions as a project-specific name rather than a field-wide technical standard (Costa et al., 2021, Demir et al., 13 May 2026, Revankar et al., 22 Jul 2025, Srinivas et al., 2024).

2. MONITRS in ACADA for the Cherenkov Telescope Array

Within CTA’s Array Control and Data Acquisition System, MONITRS denotes the integrated Monitoring, Logging, and Alarm capability responsible for turning housekeeping, engineering, environmental, and software-status streams into operational intelligence. The Monitoring System acquires monitoring and logging information from array elements and records all monitoring data made available by telescopes and other array devices. These data are immediately available for the operator interface and quick-look quality checks, while also being stored for later detailed inspection. The stated operational purpose is a systematic approach to fault detection and diagnosis supporting corrective and predictive maintenance and aiming to minimize downtime (Costa et al., 2021).

The scale assumptions are explicit. ACADA expects about 200,000 monitoring points sampled between 1 and 5 Hz, with a maximum write rate of 26 Mbps for monitoring, including alarms, and about 1 Gbps for logging data. The paper characterizes the resulting monitoring and logging streams as “big data” primarily because of volume and velocity rather than variety, since their structure is defined through Avro schemas. MON, the umbrella term for the Monitoring System and Logging System together, is supervised through the ACADA Resource Manager: the Monitoring and Logging Supervisor receives startup and shutdown commands from the Resource Manager, forwards them to MON subsystems, and reports its own status back into the supervision tree (Costa et al., 2021).

Several internal components perform higher-level interpretation rather than simple persistence. The Environmental Conditions Inspector aggregates data from central calibration devices and other environmental sources, groups related data elements, computes environmental status indicators, and stores the resulting status. The Monitoring Value Inspector addresses irregular, unevenly spaced time-series data by re-sampling monitoring information into a regular frequency, processing monitoring events, and raising alarms if values remain above a threshold for a predefined period. On the logging side, the Logging System collects software logs provided by elements using the control framework, software logs of the observation scripts, and software logs produced by low-level firmware, the last of which may require reformatting. A Logs Analyzer examines stored logs to trigger additional alarms and warnings for the technical crew (Costa et al., 2021).

The Array Alarm System complements MON by gathering, filtering, exposing, and persisting alarms raised by ACADA processes and supervised array elements. It collects alarms from telescopes, array calibration systems, environmental monitoring instruments, and ACADA itself; it also creates new alarms by analyzing and correlating system software logs and system hardware status. Its architecture comprises an Alarm Collector, Alarm Filter, Alarm Rules Database, Alarm Storage, and an AAS Supervisor connected to the Resource Manager’s supervision tree. The Alarm Filter applies defined rules to filter, merge, and reduce alarms before they are stored and sent to operators through the human-machine interface. The implementation stack is integrated with ALMA Common Software and uses Java, Apache Maven, Eclipse Milo for OPC-UA, Apache Avro, Apache Kafka, Elastic Filebeat, Logstash, Apache Cassandra, and Docker. The paper identifies reliability, performance, scalability, and availability as the operational goals, and points to future machine-learning integration for anomaly detection, failure prediction, and complex-event handling (Costa et al., 2021).

3. MONITRS/LoomRV in multi-property temporal logic monitoring

In runtime verification, MONITRS refers to a multi-property monitoring framework whose implementation name is LoomRV. Its central departure from conventional practice is the replacement of “one monitor per property” with one shared monitor for many properties. The framework targets Past-time LTL and Past-time MTL, compiling multiple formulas into a shared directed acyclic graph of unique subformulas while preserving one designated root node, and therefore one output, per property. The monitored grammar is given as $\varphi \coloneqq \bot \mid p \mid \neg \varphi \mid \varphi_1 \wedge \varphi_2 \mid \prev\varphi \mid \varphi_1 {a}{b} \varphi_2$, with $p \in P$, $\prev\varphi$ as the Previous operator, and $\varphi_1 {a}{b} \varphi_2$ as timed Since (Demir et al., 13 May 2026).

The frontend performs bottom-up compilation with a content-addressable node database keyed by structural hashes. The hash includes the operator type, predicate name for atomic predicates, child identifiers for unary operators, interval bounds for temporal operators, canonicalized child pairs for commutative operators such as $\wedge$ and $\vee$, and ordered child pairs plus interval bounds for Since. If a structurally equal node already exists, its identifier is reused; otherwise a new node is created. The paper’s example merges $\varphi_1=\once_{[0,10]}(p \wedge q)$ and $\varphi_2=H(p \wedge q)$ into a shared graph containing a single copy of $p$, $q$, and $p \in P$0, with property-specific roots retained for $p \in P$1 and $p \in P$2. This is the formal basis of subformula reuse across properties (Demir et al., 13 May 2026).

Execution is data-oriented. After compilation, the shared DAG is serialized into a linearized execution schedule: a contiguous array of node records in strict topological order, with children preceding parents. Each node record stores an operator tag, two child indices, temporal bound parameters, persistent state across timesteps, and current output. The runtime then evaluates the array in a single forward scan per timestep. A major implementation contribution is the zero-allocation double-buffered arena, consisting of a previous-state buffer and a current-state buffer. Nodes read from the previous buffer and already-computed regions of the current one, write new state sequentially into the current buffer, and then the buffers are swapped at the end of the timestep. The paper argues that this contiguous, double-buffered layout improves spatial locality, avoids heap allocations in the hot loop, and supports incremental updates naturally. For a shared DAG with $p \in P$3 nodes and maximum bound $p \in P$4, the arena capacity is statically bounded by $p \in P$5 (Demir et al., 13 May 2026).

The evaluation compares LoomRV with Reelay, a single-property monitoring tool based on the same compositional sequential-network style but without cross-property sharing. Even in single-property settings, LoomRV Sequential improves throughput because of the linearized schedule and arena layout: the paper reports median speedups around $p \in P$6 in discrete time and around $p \in P$7 with JSON or $p \in P$8 with binary input in dense time. The strongest gains come from true multi-property execution. For 30 properties monitored simultaneously, the reported speedup is 11.7× in discrete time and 7.3× in dense time relative to Reelay-Sequential on the cited benchmarks, while the abstract summarizes multi-property improvements as 2× to 4.5× and 6× to 12× per property compared to conventional single-property monitoring. The framework is thus positioned as a first-class solution for large specification sets in high-performance and resource-constrained systems (Demir et al., 13 May 2026).

4. MONITRS as a multimodal disaster-monitoring dataset and benchmark

In remote sensing, MONITRS expands to “Multimodal Observations of Natural Incidents Through Remote Sensing.” It is a dataset and benchmark designed to make satellite-based disaster monitoring more language-aware, temporally grounded, and scalable. The construction pipeline uses the FEMA Disaster Declarations Areas / OpenFEMA dataset as the event source, filters for events with county, state, event name, start date, and end date, then searches the web for news reports using queries built from those fields and retains the first five Google Search API results per event. News text is parsed with Gemini 2.0-flash to extract proper-noun locations, which are geocoded, and the union of those locations is used to choose a square satellite patch covering the maximum number of named places (Revankar et al., 22 Jul 2025).

The dataset links five modalities: temporal satellite imagery, natural-language event descriptions, precise geotagged locations, question-answer pairs, and event-level metadata from FEMA. Imagery consists of RGB Sentinel-2 scenes with 10 m/pixel resolution and an average revisit time of 5 days. Each image patch covers 5.12 × 5.12 km² at 512 × 512 pixels. For each disaster, the dataset includes all available imagery during the FEMA event duration plus a 10-day buffer before and after the event. Natural-language annotations are generated from article text and dates alone, not from imagery, and are explicitly constrained to visible, remotely observable phenomena such as flooding, burn scars, cloud formations, structural damage, lava flows, or coastline changes. The paper emphasizes that the result is not merely a caption dataset but a multimodal disaster-monitoring corpus supporting geolocation, temporal reasoning, and visual question answering (Revankar et al., 22 Jul 2025).

Scale is one of its defining properties. The paper reports 9,996 disaster incidents, described in the abstract and introduction as “more than 10,000 FEMA disaster events,” with an average of 4.13 satellite images per event and 18.14 days per event sequence. The events are concentrated in U.S. disaster-prone regions, especially Louisiana, Texas, and Florida, and show a seasonal peak in September. MONITRS-QA, the associated benchmark, contains multiple-choice and open-ended questions generated both from templates and from event-specific LLM prompting. The event-level split is 44,308 QA pairs for training and 10,196 for testing, specifically designed to avoid temporal or spatial leakage by splitting by event rather than by image or question (Revankar et al., 22 Jul 2025).

The empirical results are framed as evidence that existing MLLMs are not inherently good at disaster monitoring, especially on temporal and location grounding. On the multiple-choice benchmark, baseline event-classification accuracy is about 49.72% for VideoLLaVA, 48.88% for TEOChat, and 50.07% for Gemini 2.0-flash; temporal grounding falls to 11.11%, 15.15%, and 18.02%, respectively; location grounding is 17.11%, 15.50%, and 13.74%. After fine-tuning TEOChat on MONITRS-QA for 1 epoch with batch size 4, using roughly one-fifth of the training set and 3 hours on 3 A6000 GPUs, the reported accuracies are 88.69% for event classification, 70.72% for temporal grounding, and 23.25% for location grounding, with improvements over all baselines significant at $p \in P$9. On generated VQA, the fine-tuned model also leads in MCQ accuracy, BLEU, METEOR, and ROUGE-L. The paper is explicit about limitations: U.S.-only coverage due to FEMA dependence, Sentinel-2’s 10 m/pixel resolution and roughly 5-day revisit, RGB-only imagery, possible imperfections in LLM-generated annotations, and the persistent difficulty of location grounding (Revankar et al., 22 Jul 2025).

5. MONITRS as an intelligent monitoring framework for cloud services

A different MONITRS appears in cloud operations as an intelligent monitoring framework for recommending what a service should monitor. The starting point is the observation that monitor creation in production cloud services is often ad hoc, reactive, and dependent on tribal knowledge. The paper formalizes a monitor as a collection of triplets of the form resource, metric, and alerting logic, $\prev\varphi$0, but then simplifies the recommendation problem because raw resources are too granular and alert logic is a separate anomaly-detection problem. In Microsoft’s internal data representation, monitors are described with functionality-groups $\prev\varphi$1, and MONITRS recommends two abstractions instead of exact monitors: resource classes, corresponding to “what to monitor,” and SLO types, corresponding to “which metrics to monitor” (Srinivas et al., 2024).

The ontology is mined from production data covering 791 unique micro-services, 30,920 unique monitors, and 7,403 unique metrics, together with dependency and component metadata. Thirteen resource classes are identified: Service-level, API, Dependency, CPU, Compute cluster, Storage, Ram-memory, Cache-memory, Container, Certificate, IO, Paging memory, and None-of-the-above. The paper also identifies 9 major SLO classes and lists Success rate, Capacity, Latency, Availability, Throughput, QoS, Interruption rate, Freshness, and Others. Label extraction is iterative and combines NLP augmentation with direct expert-guided labeling. Reported labeling quality is high for resource classes, with average precision 0.9423, recall 0.9530, and F1 0.9476, and lower but still substantial for SLO classes, with average precision 0.7944, recall 0.8311, and F1 0.7967 (Srinivas et al., 2024).

The empirical study shows that monitor structure is statistically nonuniform rather than arbitrary. At the resource level, Service-level, API, and Dependency are the most common classes. At the SLO level, Success rate, Capacity, and Latency dominate, and more than 50% of services monitor success rate, capacity, availability, and latency. The paper further reports that SLO distributions vary significantly by resource class under chi-squared testing. API is associated mostly with Success rate and Latency; Compute cluster with Availability and Capacity; CPU, Storage, Ram-memory, IO, Container, and Paging memory predominantly with Capacity; Cache memory with Success rate and Capacity; and Certificate mostly with Freshness. Co-occurrence analysis using the phi coefficient finds strong correlation between CPU and RAM memory, a positive relationship between API and Dependency, and positive co-occurrence between CPU and Storage, while Service-level and IO show negligible correlation with many others. These results underpin the claim that monitor recommendation can be treated as a learnable, structured prediction problem rather than a purely manual craft (Srinivas et al., 2024).

The recommendation model uses service properties derived from upstream dependencies, downstream dependencies, and physical or logical components, together with similarity over top-$\prev\varphi$2 neighboring services. A scoring equation is given as $\prev\varphi$3, where $\prev\varphi$4 is cosine distance or similarity over service-property vectors. To improve on this collaborative-filtering baseline, the paper proposes a prototypical learning architecture composed of an autoencoder and a prototype classification network. The encoder $\prev\varphi$5 maps inputs to latent vectors $\prev\varphi$6, and the prototype layer computes squared $\prev\varphi$7 distances to learned prototype vectors, $\prev\varphi$8. Training is performed on an 80:20 split of 791 services, with training-only upsampling to handle class imbalance. The reported class-specific results include Service level at precision 0.95 and recall 1.00, API at 0.48 and 1.00, CPU at 0.34 and 1.00, and lower-density classes such as Certificate and Cache-memory with lower precision. In a user study, 11 of 30 invited engineers participated, all found the ontology useful, most believed AI recommendations would help, and the sample system received an average usefulness rating of 4.27 out of 5 (Srinivas et al., 2024).

6. Cross-cutting structure, recurrent motifs, and major differences

Across these four uses, MONITRS consistently denotes an intermediate layer that converts raw observables into more actionable outputs, but the object being acted upon differs sharply. In CTA operations, the inputs are telescope, calibration, environmental, and software-state streams, and the outputs are persisted telemetry, filtered alarms, and operator-facing HMI state (Costa et al., 2021). In runtime verification, the inputs are valuations of atomic predicates over a trace, and the outputs are per-property verdicts produced from a shared DAG with a single-pass execution model (Demir et al., 13 May 2026). In remote sensing, the inputs are FEMA records, news articles, geocoded place mentions, and Sentinel-2 sequences, and the outputs are temporally grounded multimodal supervision and QA benchmarks for MLLMs (Revankar et al., 22 Jul 2025). In cloud operations, the inputs are existing production monitors and service metadata, and the outputs are class-level recommendations about what kinds of resources and SLOs a new service should monitor (Srinivas et al., 2024).

The differences are equally important. Only the CTA system uses MONITRS to denote an integrated operational subsystem explicitly comprising monitoring, logging, and alarms. The LoomRV usage belongs to formal runtime verification and is concerned with shared subformula evaluation, memory layout, and asymptotic throughput rather than operator observability. The disaster-monitoring usage names a dataset and benchmark rather than a live monitoring service. The cloud MONITRS framework does not monitor a running service directly; it recommends monitor classes from historical production practice. A common misconception is therefore that MONITRS names one canonical monitoring architecture. The literature shows the opposite: the same acronym is applied to observatory control, temporal-logic execution, multimodal remote sensing, and monitor recommendation, with only a family resemblance at the level of transforming raw inputs into structured decisions or supervision (Costa et al., 2021, Demir et al., 13 May 2026, Revankar et al., 22 Jul 2025, Srinivas et al., 2024).

This comparison also highlights distinct notions of “intelligence” in monitoring. In CTA, intelligence is correlation, alarm reduction, and future anomaly-detection integration. In LoomRV, it is algorithmic reuse through structural hashing, topological scheduling, and arena-based execution. In the remote-sensing benchmark, it is the supervision signal enabling fine-tuned MLLMs to reason over disaster progression. In cloud operations, it is the inference of monitor ontologies from production fleets and the use of prototypical learning to recommend resource classes. The term MONITRS thus indexes a broad research concern—making monitoring computationally and operationally useful—while remaining semantically local to each domain-specific system.