Overview

• 1: Indicator
• 2: Alert
• 3: Log
• 4: event
• 5: ServiceWatch linked service
• 6: Custom Metrics and Logs

1 - Indicator

Indicator

Metrics are data about system performance. By default, many services provide free metrics for resources (e.g., Virtual Server, File Storage, etc.), which are provided as basic monitoring through ServiceWatch. Detailed monitoring can be used for some resources such as Virtual Server.

Indicator data is retained for 15 months (455 days), so you can view both the latest data and historical data.

Namespace

A namespace is a logical division used to distinguish and group ServiceWatch metrics. Samsung Cloud Platform service namespaces are mostly used the same as the service name, and can be found in the ServiceWatch Integrated Service List.

For custom metrics, users can define a namespace that distinguishes them from other metrics in ServiceWatch, and can define it via ServiceWatch Agent settings or OpenAPI. Detailed information about custom metrics and logs can be found in Custom Metrics and Logs.

Metric (Metric)

A metric represents a set of data points collected in ServiceWatch, sorted chronologically. A data point consists of a timestamp, the collected data, and the unit of the data.

For example, the CPU usage of a specific Virtual Server is one of the basic monitoring metrics provided by Virtual Server. The data point itself can occur in any application or activity that collects data.

Basically, the Samsung Cloud Platform service linked with ServiceWatch provides metrics for resources for free. Detailed monitoring for some resources is provided as a paid service and can be enabled in each service.

Metrics can only be viewed in the region where they were created. Metrics cannot be arbitrarily deleted by users. However, if new data is not posted to ServiceWatch, they will automatically expire after 15 months. Data points older than 15 months (455 days) expire sequentially, and when new data points are added, data older than 15 months (455 days) is deleted.

Timestamp

The timestamp of a data point is time information indicating the time at which the data point was recorded. Each metric data point consists of a timestamp (time) and data.

The timestamp consists of hours, minutes, seconds, and date.

Metric Retention Period

ServiceWatch metric data is maintained as follows.

• Data points with a collection interval set to 60 seconds (1 minute) can be used until the 15th
• Data points with a collection interval set to 300 seconds (5 minutes) are usable up to day 63
• Data points with a collection interval set to 3600 seconds (1 hour) are usable up to 455 days (15 months).

The data points that were initially collected at a short collection interval are downsampled and stored for long-term retention.

For example, if data is collected at a 1‑minute interval, it is retained in 1‑minute granularity for 15 days. After 15 days, the data continues to be retained, but can only be queried in 5‑minute intervals. After 63 days, the data is re‑aggregated and provided in 1‑hour intervals. If you need to retain metric data points longer than the metric retention period, you can store them separately via the File Download or Export to Object Storage functions.

Dimensions(Dimensions)

Key-value pair that serves as a unique identifier for the metric, allowing classification and filtering of data points.

For example, you can identify metrics for a specific server by using the resource_id dimension of the Virtual Server’s metrics.

Collection Cycle

It refers to the cycle of collecting data points for each service’s metrics, and is provided at the collection cycle predefined by each service.

Refer to each service’s ServiceWatch metrics page for the metric collection interval of each service.

For example, Virtual Server provides a collection interval of 5 minutes during basic monitoring, and provides 1 minute when detailed monitoring is enabled.

Statistics

Statistics is a method of aggregating metric data over a specified period. ServiceWatch provides data aggregated as statistics based on metric data points provided to ServiceWatch from each service. Aggregation is performed using namespace, metric name, dimensions, and data point units within the specified aggregation period.

The provided statistics are total, average, minimum, maximum.

• Total: Sum of all data point values collected during the period
• Average: During the specified period, (sum of all data pointer values during that period)/(number of data pointers during that period) value
• Minimum: the lowest value observed during the specified period
• Maximum: The highest value observed during the specified period

Unit

Each statistic has a measurement unit. Examples of units include Bytes, Second, Count, Percent, etc.

Aggregation Period

Each statistic calculates the data points of the metric collected during the selected aggregation period. The aggregation period can be chosen from 1 minute, 5 minutes, 15 minutes, 30 minutes, 1 hour, 3 hours, 6 hours, 12 hours, or 1 day, and the default is 5 minutes. The aggregation period is closely related to the collection interval of metric data points, and to obtain correct aggregation results, the aggregation period must be longer than or equal to the collection interval.

For example, if you select average for the statistic, choose an aggregation period of 5 minutes, and select a metric with a collection interval of 1 minute, data points are collected at 1‑minute intervals and the average is calculated over the data points collected during the 5‑minute period. Conversely, if the aggregation period is shorter than the collection interval, it means that a normal aggregation result cannot be obtained.

Downsampling is applied for long-term storage of metric data. For example, if data is collected at a 1‑minute interval, after 15 days this data can only be queried in 5‑minute increments. If you set the aggregation period for such metrics from 5 minutes to 30 minutes, up to 5 minutes may be required to retrieve the downsampled data correctly. After 63 days, the data is re‑aggregated and provided in 1‑hour intervals. At that point, selecting an aggregation period from 1 hour to 1 day may take up to 1 hour to retrieve the data correctly. This is because aggregating the metric data after downsampling takes time, which can cause aggregation delays.

Alert

When creating an alert policy, you can evaluate a single metric over the entered evaluation range, and if it meets the condition set based on the threshold, you can provide the user with an alert notification.

The alert status is classified as Alert(Alert), Normal(Normal), Insufficient data(No data).

• Alert(Alert): when the indicator meets the set conditions
• Normal(Normal): when the indicator does not meet the set conditions
• Insufficient data(no data): when the metric data does not exist, is missing, or has not yet arrived

When the alarm status is Alert, if the alarm evaluation deviates from the condition, the alarm status changes back to Normal.

For detailed information about alerts, please refer to the Alert item.

Basic Monitoring and Detailed Monitoring

ServiceWatch provides two types of monitoring: basic monitoring and detailed monitoring.

The Samsung Cloud Platform service integrated with ServiceWatch provides basic monitoring by publishing a basic set of metrics to ServiceWatch for free. By default, if you use even one of these services, basic monitoring is automatically enabled and can be viewed in ServiceWatch.

Detailed monitoring is only available for some services and incurs charges. To use detailed monitoring, you must enable it in the service details.

Detailed monitoring options vary depending on the service provided.

• The default monitoring of Virtual Server has a collection interval of 5 minutes. When detailed monitoring is enabled, the metrics provided by default monitoring are collected at a 1‑minute interval instead of 5 minutes.

The following includes services and guides that provide detailed monitoring.

2 - Alert

Alert

You can create alerts that monitor metrics and send notifications. For example, you monitor the CPU usage and disk read/write of a Virtual Server, then send a notification to the user to handle increased load.

• Alert Policy
  • Alarm Status
  • Alert Evaluation
    • Evaluation Scope
    • Condition
  • Alert Notification
  • How to handle missing data during alarm evaluation
• Alarm History

Alert Policy

Alert policies can monitor metrics of the same Account and evaluate alerts for a single metric. These alert policies compare the specified threshold and metric conditions, and send notifications when the conditions are met.

If you disable the alert policy, the evaluation of the alert policy continues, but you can restrict sending alerts to designated recipients. If you want to temporarily stop sending alerts for resources with an alert policy set, you can use alert policy deactivation.

When you enable the alert policy, evaluation of the alert policy begins, and according to the set conditions, the alert status changes to Alert, and a notification is sent each time the alert status changes.

The alarm policy status allows you to check whether the alarm policy is enabled/disabled.

You can set alert levels for the alert policy. Depending on the alert level, the alert color (red/pink/purple) is expressed differently so that the levels can be visually distinguished by color. You can filter according to the alert policy’s alert level and retrieve the alert policy by each alert level.

Alarm Status

Alert status changes according to the alert evaluation of the alert policy. Alert status is divided into three states: Normal (Normal), Insufficient data (Insufficient data), Alert (Alert).

Alert Evaluation

For example, for a metric with a 1-minute collection interval, if you set a 1-minute evaluation window with 4 violations out of 5 evaluation counts, the evaluation interval is 5 minutes. For a metric with a 5-minute collection interval, if you set a 10-minute evaluation window with 3 violations out of 3 evaluation counts, the evaluation interval is 30 minutes.

Evaluation Scope

The evaluation scope of the alarm policy is the evaluation time range for alarm evaluation.

• It is recommended to set it to the indicator’s collection interval or a multiple of the collection interval.
• You can input up to 604,800 (7 days) seconds.

Condition

The conditions for performing alarm evaluation require a conditional operator and threshold setting.

If the namespace is Virtual Server and the metric is CPU Usage (unit: %), the alarm evaluation condition is completed as below.

Alarm Notification

If the alarm evaluation conditions are met, change the alarm status to Alert and send a notification to the recipients set in the alarm policy.

Method for handling missing data during alarm evaluation

Some resources may not be able to send metric data to ServiceWatch under certain conditions. For example, if a specific resource is inactive or does not exist, it will not be sent to ServiceWatch. If metrics are not collected for a certain period, the alarm state will be changed to Insufficient data by the alarm evaluation.

ServiceWatch provides a way to handle missing data during alarm evaluation. The missing data handling methods are as follows:

• Ignore: Maintain the current alarm state. (default)
• Missing: Treat missing data points as missing. If all data points within the evaluation range are missing, the alarm state switches to Insufficient data state.
• Breaching: Treat as satisfying the threshold condition for missing data points.
• Not breaching: Process as normal for missing data points that do not satisfy the threshold condition.

Alert History

The change history for alarm status is recorded in the alarm history. The alarm history can be viewed for 30 days.

3 - Log

Log

ServiceWatch logs allow you to monitor, store, and access log files collected from the resources of the services that provide logs.

Log Group

A log group is a container for log streams that share the same retention policy settings, each log stream must belong to one log group, for example, if there are separate log streams for the logs of each Kubernetes Engine cluster, the log streams can be bundled into one log group named /scp/ske/{cluster name}.

Log Retention Policy

The log retention policy allows you to set the period during which log events are stored in ServiceWatch. Log events that have expired are automatically deleted. Log The retention period assigned to the group applies to the log streams and log events belonging to the log group.

The retention period can be selected from the following, and it is set in units of days.

Log Stream

A log stream is a collection of log events that are ordered by the time they occurred, from the same source, for example, all log events occurring in a specific Kubernetes Engine cluster can constitute one log stream.

Log Event

A log event is an individual record of a log that occurs from a resource. The log event record includes two properties: a timestamp of when the event occurred and a log message. Each message must be encoded in UTF-8.

Export log group

You can export log data from the log group to Object Storage for log archiving and log analysis, and you can also export log data within the same account to the log group.

To start logging group export, you must create an Object Storage bucket to store log data.

Exporting a log group can take a long time depending on the amount of log, when exporting a log group, you can specify a specific stream within the log group, or specify a time range to reduce the time it takes to export the log group.

Exporting a log group can only be executed once at a time for the same Account. To run another log group export, the current export task in progress must be completed.

4 - event

The event represents a change in the environment in the Samsung Cloud Platform service.

Most events generated in Samsung Cloud Platform services are received by ServiceWatch. Events of each service can be viewed and processed in the ServiceWatch of the same Account.

Refer to the list of services that send events via ServiceWatch and the events those services send in the ServiceWatch Event Reference.

Each service sends events to ServiceWatch based on Best Effort delivery. Best Effort delivery means that the service attempts to send all events to ServiceWatch, but occasionally some events may not be delivered.

When a valid event is delivered to ServiceWatch, ServiceWatch compares the event with the rules and then sends a notification to the alert recipients set in the event rule.

Event Rules

You can specify the actions that ServiceWatch performs on events delivered from each service to ServiceWatch. To do this, create an event rule. An event rule specifies which events are delivered to which targets.

Event rules evaluate the event when it arrives. Each event rule checks whether the event matches the rule’s pattern. If the event matches, ServiceWatch processes the event.

You can generate matching rules for incoming events based on the event data criteria (called an event pattern). If an event matches the criteria defined in the event pattern, the event is delivered to the target specified in the rule.

• Event rules basically allow you to specify a notification recipient to receive alerts when an event occurs.
• The event rules are planned to be expanded to include multiple services of the Samsung Cloud Platform as targets for receiving events when events occur. (Planned for 2026)

To create an event rule, please refer to How-to Guides > Creating Event Rules.

Event Source

ServiceWatch can select the event source as the Samsung Cloud Platform service name. You can select the service name of the event you want to receive as the event source.

Event Type

The Samsung Cloud Platform service has its own resource type. Event types are classified the same as resource types, and you select the type of events from the event source to use in event rules.

The following are the event types of Virtual Server.

For other event types available in ServiceWatch, please refer to ServiceWatch Event.

Event

The event can select all events that occur from the event type of the event source, and can select specific events.

The following are some events of the Server event type of Virtual Server.

For other events available in ServiceWatch, see ServiceWatch Event.

Applied Resources

Set the event pattern for selected events on all resources or specific resources.

Event Pattern

If you select all event sources, event types, events, and applied resources, the event pattern setting for the event rule will be completed.

The following is an example of an event pattern set in ServiceWatch’s event rule.

{
	"source": [ // namespace
		"Virtual Server"
	],
	"detail-type": [ // event type
		"Server"
	],
	"detail": {
		"event": [ // individual event
			"Compute Virtual Server Create End"
		]
	},
	"resources": [ // individual resources
		"srn:{offerring}::{account_id}:{region}::virtualserver:server/{resource_id}"
	]
}

{
	"source": [ // namespace
		"Virtual Server"
	],
	"detail-type": [ // event type
		"Server"
	],
	"detail": {
		"event": [ // individual event
			"Compute Virtual Server Create End"
		]
	},
	"resources": [ // individual resources
		"srn:{offerring}::{account_id}:{region}::virtualserver:server/{resource_id}"
	]
}

To create an event rule, please refer to How-to Guides > Creating Event Rules.

Event Notification

If the event pattern is satisfied, an alert is sent to the notification recipient set in the event rule.

5 - ServiceWatch linked service

You can check the services linked with ServiceWatch.

Metrics and Log Monitoring

Below you can see the service that integrates ServiceWatch with metric and log monitoring.

Event

Below you can check the service that links ServiceWatch with events.

6 - Custom Metrics and Logs

ServiceWatch can collect user-defined custom metrics defined by the user and can collect log files from resources created by the user.

There are two ways to collect custom metrics and logs.

First, you can install the ServiceWatch Agent directly on the resource, set the resources to be collected, and collect them.
The second is that you can collect custom metrics and logs through the OpenAPI/CLI provided by ServiceWatch.

ServiceWatch Agent

You can install the ServiceWatch Agent on the user’s resources such as Virtual Server/GPU Server/Bare Metal Server to collect custom metrics and logs.

ServiceWatch Agent Constraints

ServiceWatch Agent Network Environment

ServiceWatch Agent is designed to collect data using OpenAPI by default, so to install and use it on server resources, external communication via the Internet must be possible. Please create an Internet Gateway in the VPC where the resources are located and set a NAT IP on the server resources so that they can communicate with the outside.

ServiceWatch Agent Supported OS Image

The OS images available for ServiceWatch Agent are as follows.

Provides the same as the OS Image provided by Virtual Server. Please refer to Virtual Server > OS Image provided version.

Quick Guide for Using ServiceWatch Agent

Below, we introduce a quick guide for collecting OS metrics and logs of Virtual Server in a Linux environment.

Node Exporter Installation and Configuration

1. Refer to Node Exporter installation and install Node Exporter on the server for collecting custom metrics.
   • If you install Node Exporter, you can collect OS metrics through Node Exporter in addition to the metrics provided by ServiceWatch’s default monitoring.
2. ServiceWatch Agent Settings refer to and after downloading the ServiceWatch_Agent zip file, configure and run the ServiceWatch Manager.
   • Refer to the examples/os-metric-min-examples folder in the zip file to set at least two metrics and run the ServiceWatch Agent.

ServiceWatch Custom Metrics and Logs API

You can collect custom metrics and logs through the OpenAPI/CLI provided by ServiceWatch.

Custom metric data and custom logs can be delivered to ServiceWatch via ServiceWatch OpenAPI/CLI, allowing you to view visualized information in the Console.

Create Custom Metric Metadata

To collect metric data generated from user resources or applications, rather than metrics provided by Samsung Cloud Platform services (e.g., Virtual Server), into ServiceWatch, you need to create custom metric metadata.

For detailed information on creating custom metric metadata, see CreateCustomMetricMetas.

Create Custom Metrics

After generating custom metric metadata, you can deliver the resulting metric data to ServiceWatch using the CreateCustomMetrics API.

The transmitted metric data can be queried, separated by the configured namespace.

For detailed information on creating custom metric data, refer to CreateCustomMetrics.

Indicator Data Query

Metric data, including custom metrics, can be queried using the Console and the ListMetricInfos, ListMetricInfos API.

For detailed information on metric data retrieval, refer to ListMetricInfos and ListMetricData.

Log Stream Creation

A ServiceWatch log group is required for custom log collection. Log groups can only be created in the Console. After creating a log group in advance, you can use the log stream creation API to create a log stream to be delivered to ServiceWatch.

For detailed information on creating a log stream, refer to CreateCustomLogStream.

Log Event Creation

To collect custom logs, after creating log groups and log streams, we use the log event creation API to deliver individual log messages (log events) to ServiceWatch.

For detailed information on creating log events, refer to CreateCustomLogEvents.