Protocol

Overview

This protocol defines the monitoring function within ODS-RAM.

The monitoring function continuously tracks the operational status of data transactions and provides functionality for the early detection of anomalies and failures. Based on data collected and aggregated through the logging function, this function enables real-time status awareness, system visualization, and early detection of anomalies.

Abstract Normative Specification

• The system SHALL provide the capability to calculate metrics from data collected by the logging function.

  • Rationale: To enable appropriate monitoring of various conditions.

• The system SHOULD provide dashboards for the visualization of metrics.

  • Rationale: To improve visibility of system status and usability.

• The system MAY provide functionality to notify users or intervene in the system when metrics meet user-specified conditions.

Concepts and Roles

The following concepts are required for this protocol:

Concept	Description
Data Provider	An entity that sends data stored in a data store to a Data Consumer.
Data Consumer	An entity that receives data from a Data Provider.
Payment Service	An entity selected by the Data Provider outside this protocol to perform payment processing.

Scope

The scope of monitoring covers each module that composes Open Dataspaces.

The primary targets of this monitoring function are as follows. As Open Dataspaces handles sensitive data, in addition to general data persistence functions, evidence and trace information are also included as monitoring targets.

• Communication Status of Integrated Services and APIs: Monitors traffic volume, error rates, response times, and related metrics based on communication data passing through the system and its communication history. Also manages the number of requests, success rates, types of failures, and processing times for each integrated service or API.

• System Resource Status: Monitors resources such as CPU, memory, disk capacity, and network bandwidth. If thresholds defined by the system or services are exceeded, anomalies are detected and alerts are issued. Based on collected data, periodic reports and trend forecasts may be generated to support operational improvement activities.

• Security Status and Audit: Through monitoring system components such as networks and processes, as well as the behavior of individual functions, detects behavior that deviates from normal behavior from a security perspective at an early stage. Also provides functionality for audit evidence purposes.

Normative Requirements

• External interfaces SHOULD be provided through APIs with consideration for integration with other operational management tools and AI-based analysis services.

• The system SHOULD provide dashboards for visualizing metrics. Users MAY be allowed to customize dashboards.

• When monitoring metrics and detecting anomalies, the system SHOULD notify the System Administrator. The purpose of anomaly detection includes not only monitoring service operation status but also monitoring system security status. Thresholds MAY be set for various metrics as a means of anomaly detection.

  Examples of metrics include:

  • Service downtime

  • Response time and error rates in requests or service processing

  • System resources

  • Communication volume from specific IP addresses

  Examples of notification methods include:

  • Email

  • Instant messaging

  • System integration using webhooks

• When anomalies are detected, the system MAY provide functionality to automatically intervene in the system by operating system resources or processes. However, the target systems and scope of intervention MUST be defined in advance. Security policies and permission scopes configured by the System Administrator MUST be complied with. Details of interventions MUST be recorded in logs for audit purposes and MUST be traceable as response history.

  • Rationale: To maintain service continuity at the time of anomaly detection while minimizing unnecessary intervention and potential security risks.

• Metrics MAY be stored separately from logging data. In such cases, traceability with logging information SHOULD be ensured using timestamps and trace IDs.

  • Rationale: To improve the efficiency of metric management while maintaining consistency with logging information, thereby enhancing data traceability and analytical accuracy.

• The system MAY provide functionality to generate reports for external audits based on the collection and processing of service-specific logs.