Overview

• 1: Metric
• 2: Alert
• 3: Log
• 4: Event
• 5: ServiceWatch integration service
• 6: Custom Metrics and Logs

1 - Metric

Metric

Metrics are data about system performance. By default, many services provide free metrics for resources (e.g., Virtual Server, File Storage, etc.), which are offered as basic monitoring through ServiceWatch. Detailed monitoring can be used for certain 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 separation used to distinguish and group ServiceWatch metrics. In Samsung Cloud Platform services, namespaces are generally the same as the service name, and can be found in the ServiceWatch 연계 서비스 목록.

For custom metrics, users can define a namespace in ServiceWatch to distinguish them from other metrics, and can define it via the ServiceWatch Agent settings or OpenAPI. Detailed information about custom metrics and logs can be found in 사용자 정의 지표 및 로그.

Metric (metric)

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

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

By default, the Samsung Cloud Platform services integrated with ServiceWatch provide resource metrics for free. Detailed monitoring for some resources is offered 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 the time information indicating when the data point was recorded. Each metric data point consists of a timestamp (time) and data.

A timestamp consists of hours, minutes, seconds, and a date.

Metric retention period

We maintain ServiceWatch metric data as follows.

• Data points with a collection interval set to 60 seconds (1 minute) are available for up to 15 days.
• Data points with a collection interval set to 300 seconds (5 minutes) are available for up to 63 days.
• Data points with a collection interval set to 3600 seconds (1 hour) are usable for up to 455 days (15 months).

Data points that were initially collected at a short 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 archive them separately using the File Download or Object Storage Export features.

Dimension(Dimensions)

A key-value pair that serves as a unique identifier for a metric, allowing you to classify and filter data points.

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

Collection interval

It refers to the interval for collecting data points for each service’s metrics and is provided according to the collection interval predefined by each service.

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

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

Statistics

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

The provided statistics are sum, 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 interval. The aggregation interval can be chosen from 1 minute, 5 minutes, 15 minutes, 30 minutes, 1 hour, 3 hours, 6 hours, 12 hours, or 1 day, with the default being 5 minutes. The aggregation interval is closely related to the collection frequency of metric data points, and to obtain correct aggregation results, the aggregation interval must be equal to or longer than the collection frequency.

For example, if you select average, choose 5 minutes as the aggregation period, and pick a metric with a 1‑minute collection interval, data points are collected every minute 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 a valid 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 the 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 occurs because aggregating the downsampled metric data takes time, which can cause aggregation delays.

Alert

When creating an alert policy, you can evaluate a single metric over the specified evaluation period, and if it meets the condition set based on the threshold, you can notify the user with an alert.

The alarm status is classified as Alert (alert), Normal (normal), Insufficient data (no data).

• Alert(Alert): when the metric meets the configured condition
• 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, after evaluating the alarm, if it deviates from the condition, the alarm status changes back to Normal.

For detailed information about alerts, refer to the 경보 entry.

Basic monitoring and detailed monitoring

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

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

Detailed monitoring is available only for certain 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 for Virtual Server has a collection interval of 5 minutes. When detailed monitoring is enabled, the metrics provided by default monitoring are collected at a 5 minutes → 1 minute interval.
• Basic monitoring of Object Storage is provided for basic metrics, and enabling replication metrics provides additional replication metrics.

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 the increased load.

• Alert Policy
  • Alert Status
  • Alert Evaluation
    • Evaluation Scope
    • 조건
  • Alert Notification
  • How to Handle Missing Data During Alarm Evaluation
• Alert History

Alert Policy

The alert policy can monitor metrics of the same Account and evaluate alerts for a single metric. This alert policy compares the specified threshold with metric conditions and sends a notification when the conditions are met.

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

When you enable an alert policy, evaluation of the policy starts, and according to the configured conditions, the alert status changes to Alert, with a notification sent each time the alert status changes.

The alarm policy status indicates whether the alarm policy is enabled or disabled.

You can set alert stages in the alert policy. Depending on the alert stage, the alert color (red/pink/purple) is displayed differently, allowing visual distinction of stages by color. You can filter alarm policies by their alarm level and view policies for each level.

Alert Status

The alarm state changes according to the alarm evaluation of the alarm policy. The alarm state 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 attempts, 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 attempts, the evaluation interval is 30 minutes.

Evaluation Scope

The evaluation scope of an alert policy is the time range used for alert evaluation.

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

condition

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

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

Alert Notification

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

Method for handling missing data during alarm evaluation

Some resources may be unable to send metric data to ServiceWatch under certain conditions. For example, if a resource is inactive or does not exist, it will not be sent to ServiceWatch. If metrics are not collected for a certain period, the alert evaluation will change the alert status to Insufficient data.

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

• Ignore: maintains the current alarm state. (default)
• Missing: Treat missing data points as missing. If all data points within the evaluation range are missing, the alert status changes to Insufficient data.
• Breaching: Process missing data points as satisfying the threshold condition.
• Not breaching: Treat missing data points as normal when they do not satisfy the threshold condition.

Alert History

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

3 - Log

Log

By using ServiceWatch logs, you can monitor, store, and access log files collected from the resources of the service that provides the logs.

Log Group

Log groups are containers for log streams that share the same retention policy settings. Each log stream must belong to a single log group. For example, if there are separate log streams for the logs of each cluster in Kubernetes Engine, you can group the log streams into a single log group called /scp/ske/{cluster name}.

Log Retention Policy

The log retention policy allows you to set the period for retaining log events in ServiceWatch. Log events whose retention period has 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 options and is set in days.

Log stream

A log stream is a collection of log events ordered by the sequence in which they occurred from the same source. For example, all log events generated by a particular Kubernetes Engine cluster can form a single log stream.

Log Event

Log events are individual records that capture logs generated by a resource. A log event record includes two attributes: a timestamp of when the event occurred and a log message. Each message must be encoded in UTF-8.

log pattern

You can create log patterns to filter log data that matches the pattern. Log patterns define the words or patterns to search for in the log data collected by ServiceWatch, allow you to view the status of log occurrences as graphs, and serve as metrics for creating alert policies.

Log patterns are not applied retroactively to data. They are applied to log events collected after the log pattern is created.

Log pattern namespace

A namespace is a logical separation used to distinguish and group metrics. In ServiceWatch, it is divided into namespaces associated with services, namespaces for custom metrics, and namespaces for log patterns.

• Namespace associated with services such as Virtual Server
• A namespace consisting of custom metrics, i.e., the namespace of metrics collected through the custom metrics API or ServiceWatch Agent.
• Namespace of the metric generated by the log pattern

When creating metrics for a log pattern, you can either create a new namespace for the log pattern or select from existing log pattern namespaces.

Metric name

The monitored log information is the name of the metric generated by ServiceWatch. You must configure it so that the metric name does not duplicate within the namespace where the metric will exist.

Metric Value

It is the numeric value posted to the metric each time a log matching the pattern is found. For example, when counting occurrences of a specific word (e.g., Error), this value becomes 1 for each occurrence. When calculating transmitted bytes, it can be incremented by the actual number of bytes found in the log event.

default value

This is the value recorded in the log pattern for periods during log collection when no matching logs can be found. Setting the default to 0 prevents the metric from becoming irregular due to periods with no matching data.

When setting a dimension on a metric created from a log pattern, you cannot set a default value for that metric.

dimension

Dimensions are key-value pairs that further define a metric. You can add dimensions to metrics generated from log patterns. Since dimensions are part of a metric’s unique identifier, each time a unique name/value pair is extracted from logs, a new variant of that metric is created.

When you choose the log pattern format as either a whitespace-delimited pattern or a JSON format pattern, you can set the dimension, and it can be configured using one of the parameters defined in the pattern. You can assign up to three dimensions to an indicator. If a default value is set, you cannot configure dimensions. To set dimensions, you must disable the use of the default value.

Pattern format

This explains how ServiceWatch interprets data from each log event. The pattern format can be selected from three options as shown below.

• String Pattern: log containing a specific string
• Space-separated pattern: timestamps, IP addresses, strings, and other logs separated by spaces
• JSON format pattern: log containing specific JSON fields

Available regular expression syntax

When using regular expressions to search and filter log data, you must enclose the expression with %.

Patterns that contain regular expressions can only include the following.

• Alphanumeric - An alphanumeric character is a character that corresponds to a letter (A~Z or a~z) or a digit (0~9).
  • It can be used with A-Z, a-z, 0-9.
• The supported symbol characters are as follows.
  • :, _, #, =, @, /, ;, ,, -
  • For example, %servicewatch!% cannot be used because ! is not supported.
• The supported operators are as follows.
  • It includes ^, $, ?, [, ], {, }, |, \, *, +, ..
  • (, ) The operator is not supported.

string pattern

String pattern using regular expressions

You can search for matching patterns in log events using a regex string pattern wrapped with %(percentage) at the beginning and end. Below is an example pattern that retrieves all log events containing the ERROR keyword. Please refer to Available regex syntax.

%ERROR%

The above pattern matches log event messages like the ones below.

• [2026-02-13 14:22:01] ERROR 500 POST /api/v1/checkout (192.168.1.10) - NullPointerException at com.app.controller.CheckoutController.java:55
• [ERROR] Configuration file not found: /etc/app/config.yaml

String pattern in unstructured log events

It is a string pattern for searching strings in log events that are not in formats such as JSON. Below is an example of a log event message, and you can view log events that match various string pattern classifications.

ERROR CODE 400 BAD REQUEST
ERROR CODE 401 UNAUTHORIZED REQUEST
ERROR CODE 419 MISSING ARGUMENTS
ERROR CODE 420 INVALID ARGUMENTS

Space-separated pattern

Generate a pattern to search for matching strings in space-separated log events.

Whitespace-separated pattern example (1)

The following is an example of log events separated by spaces.

2023-10-27T10:00:01Z [INFO] 1234 login success 192.168.1.1

The above log event is a space‑separated log event that includes timestamp, logLevel, user_id, action, status, ip. Characters between brackets ([]) and double quotes ("") are considered a single field.

To create a pattern that searches for matching strings in space-separated log events, enclose the pattern in brackets ([]) and specify name-separated fields with commas (,). The following pattern parses six fields.

A pattern like [timestamp, logLevel, user_id, action, status = success, ip] can be used to find log events where the fifth field, status, is success.

Whitespace-separated pattern example (2)

abc xxx.log james 2023-10-27T10:00:01Z POST 400 1024
abc xxx.log name 2023-10-27T10:00:02Z POST 410 512

The above log event is a space‑separated log event that includes host, logName, user, timestamp, request, statusCode, and size.

A pattern like [host, logName, user, timestamp, request, statusCode=4*, size] can find log events where the sixth field, statusCode, starts with 4.

If you do not know the exact number of fields in a space-separated log event, you can use an ellipsis (…). A pattern such as […, statusCode=4*, size] represents the first five fields using an ellipsis.

AND(&&) operator and OR(||) operator can be used to create composite expressions. […, statusCode=400 || statusCode=410, size] can find log events where the sixth field, statusCode, is 400 or 410.

You can use regular expressions to provide conditions in a pattern. [host, logName, user, timestamp, request, statusCode=%4[0-9]{2}%, size] can find log events where the sixth field, statusCode, is a number that starts with 4.

JSON format pattern

You can create a pattern to search for matching strings or numeric values in JSON log events. Patterns are enclosed in curly braces ({}).

String-based JSON format pattern

• Use $. to represent JSON fields.
• The operator can use = or !=.
• The string to compare with the field can be enclosed in double quotes (""). Strings containing characters other than alphanumerics and the underscore must be enclosed in double quotes. Use an asterisk (*) as a wildcard to match text.

{ $.resourceType = "trail" }
{ $.resourceType = "%trail%" }
{ $.arrayKey[0] = "value" }

JSON format pattern that searches for numeric values

• Use $. to represent JSON fields.
• You can use numeric operators.
  • greater than(>), less than(<), equal to(=), not equal to(!=), greater than or equal to(>=), less than or equal to(<=)
• You can include addition(+) or subtraction(-) symbols. An asterisk(*) can be used as a wildcard.

{ $.errorCode = 400} 
{ $.errorCode >= 400} 
{ $.errorCode != 500 }
{ $.sourceIPAddress != 123.123.* }

Export Log Group

You can export log data from a log group to Object Storage for log retention and analysis. You can also export log groups for log data that resides in the same account.

To start exporting a log group, you must create an Object Storage bucket to store the log data.

Exporting a log group can take a long time depending on the amount of logs. When exporting a log group, you can reduce the export duration by specifying particular streams within the log group or by defining a time range.

Log group export can only be executed one at a time per account. To start another log group export, the ongoing export task must be completed.

You can delete a log group’s export history after the export succeeds or after the export cancellation is completed. Canceling a log group export does not delete the saved file exported from the log group. To delete the saved file exported from the log group, delete the stored file directly in Object Storage.

4 - Event

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

ServiceWatch receives events generated by most Samsung Cloud Platform services. Events from each service can be viewed and processed in the ServiceWatch of the same Account.

Refer to the ServiceWatch Event Reference for the list of services that send events to ServiceWatch and the events they send.

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 configured 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 defines which events are sent to which targets.

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

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

• Event rules can, by default, designate the recipients who will receive notifications when an event occurs.
• The event rules are planned to be expanded to include multiple Samsung Cloud Platform services as recipients when events occur. (Planned for 2026)

To create an event rule, refer to How-to Guides > Create Event Rule.

Event source

In ServiceWatch, the event source can be selected as a 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 types. Event types are classified the same as resource types, and you select the type of events from the event source to use in an event rule.

The following are the event types of a Virtual Server.

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

Event

Events can select either all events generated from an event source’s event type or specific events.

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

For other events available in ServiceWatch, refer to ServiceWatch Event.

Applied Resources

Set an event pattern for the selected event on all resources or a specific resource.

event pattern

When you select the event source, event type, event, and target resource, the event pattern configuration for the event rule is 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, refer to How-to Guides > Create Event Rule.

Event Notification

If the event matches the pattern, a notification is sent to the alert recipients configured in the event rule.

5 - ServiceWatch integration service

You can view services integrated with ServiceWatch.

Metrics and Log Monitoring

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

event

Below you can see the service that integrates ServiceWatch with events.

6 - Custom Metrics and Logs

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

There are two ways to collect custom metrics and logs.

The first method is to install the ServiceWatch Agent directly on the resource, configure the resources to be collected, and collect them.
The second option is to collect custom metrics and logs using the OpenAPI/CLI offered by ServiceWatch.

ServiceWatch Agent

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

ServiceWatch Agent Constraints

ServiceWatch Agent network environment

The ServiceWatch Agent is designed to collect data using OpenAPI by default, so installing and using it on server resources requires external communication over the Internet. Please create an Internet Gateway in the VPC where the resources reside and configure a NAT IP on the server resources to enable communication with the outside.

ServiceWatch Agent Supported OS Image

The OS images available for the ServiceWatch Agent are as follows.

Provides the same as the OS Image provided for Virtual Server. Refer to Virtual Server > OS Image 제공 버전.

Quick Guide for Using ServiceWatch Agent

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

Installing and Configuring Node Exporter

1. Refer to Node Exporter installation and install Node Exporter on the server to collect custom metrics.
   • When you install Node Exporter, you can collect OS metrics through Node Exporter in addition to the metrics provided by ServiceWatch’s default monitoring.
2. Refer to ServiceWatch Agent 설정, then download the ServiceWatch_Agent archive, configure the ServiceWatch Manager, and run it.
   • By referring to the examples/os-metric-min-examples folder in the archive, you can run the ServiceWatch Agent by configuring at least two metrics.

ServiceWatch Custom Metrics and Logs API

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

You can deliver custom metric data and custom logs to ServiceWatch via the ServiceWatch OpenAPI/CLI, and view the visualized information in the Console.

Create custom metric metadata

To collect metric data generated from a user’s resources or applications—not the metrics provided by Samsung Cloud Platform services (e.g., Virtual Server, etc.)—into ServiceWatch, you must create custom metric metadata.

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

Create custom metric

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

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

For detailed information on generating custom metric data, see CreateCustomMetrics.

Metric Data Query

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

For detailed information on retrieving metric data, see ListMetricInfos and ListMetricData.

Create log stream

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 that will be delivered to ServiceWatch.

For detailed information on creating a log stream, see CreateCustomLogStream.

Log Event Creation

To collect custom logs, after creating a log group and log stream, 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.