Overview

• 1: Metrics
• 2: Alert
• 3: Log
• 4: event
• 5: ServiceWatch Integration Service
• 6: Custom Metrics and Logs

1 - Metrics

Metrics

Metrics are data on system performance. By default, many services provide free metrics for resources (e.g., Virtual Server, File Storage) which are offered as basic monitoring through ServiceWatch. Detailed monitoring can be enabled for certain resources such as Virtual Server.

Metric data is retained for 15 months (455 days), allowing access to both recent and historical data.

Namespace

Namespace is a logical separation used to distinguish and group metrics in ServiceWatch. Most Samsung Cloud Platform services use a namespace that matches the service name, which can be found in the ServiceWatch Integrated Services List.

For custom metrics, users can define a namespace that distinguishes them from other metrics within ServiceWatch, either via ServiceWatch Agent configuration or via the OpenAPI. For details on custom metrics and logs, see Custom Metrics and Logs.

Metrics

Metrics represent an ordered set of data points collected by ServiceWatch over time. Each data point consists of a timestamp, the collected value, and the unit of measurement.

For example, the CPU usage of a specific Virtual Server is one of the default monitoring metrics provided by Virtual Server. Data points can be generated by any application or activity that collects data.

By default, Samsung Cloud Platform services integrated with ServiceWatch provide free metrics for resources. Detailed monitoring for certain resources is available as a paid offering and can be enabled per service.

Metrics can only be queried in the region where they were generated. Users cannot manually delete metrics. However, if no new data is posted to ServiceWatch, metrics automatically expire after 15 months. Data points older than 15 months (455 days) are sequentially expired, and when new data points are added, those older than 15 months are deleted.

Timestamp

The timestamp of a data point indicates the time at which the data point was recorded. Each metric data point is composed of a timestamp and a value.

A timestamp consists of hour, minute, second, and date.

Metric Retention Period

ServiceWatch retains metric data as follows.

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

Data points initially collected at a short interval are downsampled for long-term storage. For example, if data is collected at a 1‑minute interval, it is retained at 1‑minute granularity for 15 days. After 15 days, the data remains available but can only be queried at 5‑minute intervals. After 63 days, the data is further aggregated and provided at 1‑hour intervals. If metric data points need to be retained longer than the retention period, they can be separately archived using the File Download or Object Storage Export features.

Dimensions

Key-value pairs that serve as unique identifiers for metrics, allowing data points to be categorized and filtered.

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

Collection Interval

Refers to the frequency at which data points for each service’s metrics are collected, as provided by the service-defined collection interval.

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

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

Statistics

Statistics define how metric data is aggregated over a specified period. ServiceWatch provides aggregated data based on the metric data points supplied by each service to ServiceWatch. Aggregation uses the namespace, metric name, dimensions, and data point units within the defined aggregation period.

The provided statistics are Sum, Average, Minimum, and Maximum.

• Sum: The sum of all data point values collected during the period.
• Average: The sum of all data point values divided by the number of data points during the period.
• Minimum: The lowest observed value during the period.
• Maximum: The highest observed value during the period.

Units

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

Aggregation Period

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

For example, if the statistic is Average, the aggregation period is set to 5 minutes, and a metric with a 1‑minute collection interval is selected, data points are collected every minute and the average is computed over the 5‑minute window. Conversely, if the aggregation period is shorter than the collection interval, valid aggregation results cannot be obtained.

Downsampling is applied for long‑term retention of metric data. For example, if data is collected at a 1‑minute interval, after 15 days it can only be queried at 5‑minute granularity. Setting the aggregation period from 5 minutes to 30 minutes for such metrics may require up to 5 minutes to retrieve the downsampled data. After 63 days, the data is further aggregated and provided at 1‑hour intervals. Selecting an aggregation period from 1 hour to 1 day may require up to 1 hour for data retrieval due to aggregation processing delays.

Alerts

When creating an alert policy, a metric is evaluated over the specified evaluation window, and if it meets the condition set based on the threshold, users receive an alert notification.

Alert states are Alert, Normal, and Insufficient data.

• Alert: The metric meets the set condition.
• Normal: The metric does not meet the set condition.
• Insufficient data: No metric data exists, the metric data is missing, or data has not yet arrived.

When the alert state is Alert, if the evaluation later falls outside the condition, the alert state reverts to Normal.

For more details on alerts, see the Alert section.

Basic Monitoring and Detailed Monitoring

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

Samsung Cloud Platform services integrated with ServiceWatch publish a basic set of metrics to ServiceWatch for free, providing basic monitoring. As soon as any of those services are used, basic monitoring is automatically enabled and visible in ServiceWatch.

Detailed monitoring is available for select services and incurs charges. To use detailed monitoring, it must be enabled in the service’s detailed settings.

The detailed monitoring options vary depending on the service.

• For Virtual Server, the default monitoring collection interval is 5 minutes. Enabling detailed monitoring changes the collection interval for those metrics from 5 minutes to 1 minute.
• Object Storage provides basic metrics for default monitoring, and enabling replication metrics adds additional replication metrics.

The following includes services that provide detailed monitoring and their guides.

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

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

A log group is a container 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 Kubernetes Engine cluster, you can group the log streams into a single log group called /scp/ske/{cluster name}.

Log Retention Policy

Log retention policy can set the period for storing log events in ServiceWatch. Log events whose 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 and is set in days.

Log Stream

A log stream is a collection of log events sorted in the order they occurred from the same source. For example, all log events generated in a particular Kubernetes Engine cluster can constitute a single log stream.

Log Event

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

Log Pattern

You can create a log pattern to filter log data that matches the pattern. A log pattern defines the words or patterns to search for in the log data collected by ServiceWatch, allows you to view the status of log occurrences in a graph, and creates metrics that can be used to generate 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 for distinguishing and grouping 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
• Namespace composed of custom metrics, the namespace of metrics collected via the custom metrics API or ServiceWatch Agent
• Namespace of the metric created by the log pattern

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

Indicator Name

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

Indicator 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

It is the value recorded in the log pattern during periods when no matching logs can be found while collecting logs. Setting the default to 0 can prevent the metric from becoming irregular due to periods with no matching data in all such intervals.

If you set a dimension for a metric generated by a log pattern, you cannot set a default value for that metric.

Dimension

A dimension is a key-value pair that defines a metric additionally. You can add dimensions to metrics generated from log patterns. Since a dimension is part of a unique identifier for a metric, each time a unique name/value pair is extracted from the log, a new variant of that metric is created.

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

Pattern Format

This explains how ServiceWatch interprets data in 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: logs separated by spaces such as timestamps, IP addresses, strings, etc.
• JSON format pattern: logs containing specific JSON fields

Available regular expression syntax

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

Only the following can be included in patterns that contain regular expressions.

• Alphanumeric - Alphanumeric refers to characters that are letters (A~Z or a~z) or numbers (0~9).
  • A-Z, a-z, 0-9 can be used as.
• The supported symbol characters are as follows.
  • :, _, #, =, @, /, ;, ,, -
  • For example, %servicewatch!% cannot be used because ! is not supported.
• The supported operators are as follows.
  • This 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 of the regex. Below is an example of a pattern that searches all log events composed of the ERROR keyword. Please refer to the Available Regex Syntax.

%ERROR%

  The above pattern matches log event messages like the following.
* <code>[2026-02-13 14:22:01] ERROR 500 POST /api/v1/checkout (192.168.1.10) - NullPointerException at com.app.controller.CheckoutController.java:55</code>
* <code>[ERROR] Configuration file not found: /etc/app/config.yaml</code>

##### String pattern in log events without format
String pattern for searching strings in log events that are not in formats like JSON.
Below is an example of a log event message, and you can see the log events that match according to various string pattern classifications.

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

  



Category
Pattern
Matching log event message




single string
ERROR CODE
log event containing ERROR
ERROR CODE 400 BAD REQUEST
ERROR CODE 401 UNAUTHORIZED REQUEST
ERROR CODE 419 MISSING ARGUMENTS
ERROR CODE 420 INVALID ARGUMENTS


Multiple strings (And condition)
ERROR REQUEST
log events containing the strings ERROR and REQUEST
ERROR CODE 400 BAD REQUEST
ERROR CODE 401 UNAUTHORIZED REQUEST


Multiple strings (Or condition)
?ERROR ?400
log events containing the ERROR or 400 string
ERROR CODE 400 BAD REQUEST
ERROR CODE 401 UNAUTHORIZED REQUEST
ERROR CODE 419 MISSING ARGUMENTS
ERROR CODE 420 INVALID ARGUMENTS


Exact matching string
“BAD REQUEST”
log event containing the exact phrase “BAD REQUEST”
ERROR CODE 400 BAD REQUEST


Exclude specific string
ERROR -400
A pattern where some terms are included and other terms are excluded. Enter - before the string you want to exclude. The following are log events that include the string ERROR and exclude the string 400
ERROR CODE 401 UNAUTHORIZED REQUEST
ERROR CODE 419 MISSING ARGUMENTS
ERROR CODE 420 INVALID ARGUMENTS




  Table. String pattern in log events without format





#### Space-separated pattern

Create a pattern to search for matching strings in log events separated by spaces.

##### Space-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 log event above is a space-separated log event that includes <code>timestamp</code>, <code>logLevel</code>, <code>user_id</code>, <code>action</code>, <code>status</code>, <code>ip</code>. Text between brackets (<code>[]</code>) and double quotes (<code>""</code>) is considered a single field.

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

<code>[timestamp, logLevel, user_id, action, status = success, ip]</code> can find log events where the 5th field, <code>status</code>, is <code>success</code>.

##### Space-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 6th 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 like […, statusCode=4*, size] is a pattern that represents the first five fields with an ellipsis.

You can also create composite expressions using the AND (&&) operator and the OR (||) operator. A pattern such as […, statusCode=400 || statusCode=410, size] can find log events where the 6th field, statusCode, is 400 or 410.

You can use regular expressions to provide conditions for a pattern. A pattern such as [host, logName, user, timestamp, request, statusCode=%4[0-9]{2}%, size] can find log events where the sixth field, statusCode, is a number starting 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 non-alphanumeric characters and underscore symbols 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

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

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

Export Log Group

From the log group, you can export log data to Object Storage for log retention and log analysis. You can export log groups for log data in the same Account.

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

The log group export operation can take a long time depending on the amount of logs. When exporting a log group, you can reduce the export operation time by specifying a particular stream within the log group or by specifying a time range.

Log group export can only be executed one at a time on the same Account. To run another log group export, the current export task must be completed.

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

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 Integration Service

You can check 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.