Documentation Index

Fetch the complete documentation index at: https://guide.ncloud-docs.com/llms.txt

Use this file to discover all available pages before exploring further.

Cloud Insight FAQs

Prev Next

Available in Classic and VPC

This document provides answers to FAQs about Cloud Insight.

If you can't find the answer you're looking for in the following FAQs, check out the user guides to find them.

Q. What services allow me to view performance metrics using Cloud Insight?

A. For more information about services that allow you to view performance metrics using Cloud Insight, see Services that provide performance metrics.

Q. What are the meanings of Metric and Dimension?

A. A Metric means a value that you want to handle, while a Dimension means properties of a Metric. You can use Dimensions to define which server a Metric belongs to, where it is located, or what the value represents.

Q. How long do the data collection cycle and the data aggregation interval take?

  • The data collection cycle of the Metric is 1 minute. The collection cycle refers to a cycle in which the target resource sends data to Cloud Insight, independent of the aggregation interval.
    • The data is saved as collected in Cloud Insight, and is computed using various types of aggregation methods at each aggregation interval.
  • Aggregation intervals are executed in intervals of 1 minute (Min1), 5 minutes (Min5), 30 minutes (Min30), 2 hours (Hour2), and 1 day (Day1).
    • Aggregation functions such as AVG (average value), MIN (minimum value), MAX (maximum value), COUNT (number of collections), and SUM (total) of the current aggregation interval are supported.

    • Example: Assuming the following data has been collected between 00:01 and 00:05, the following table shows the expected values of the 1-minute (Min1) and 5-minute (Min5) aggregation periods.

      00:01:00 - 1
      00:02:00 - 2
      00:03:00 - 3
      00:04:00 - 4
      00:05:00 - 5
      

      Aggregation interval: 1 minute (Min1)

      Time AVG (average value) MIN (minimum value) MAX (maximum value) COUNT (number of collections) SUM (total)
      00:01 1 1 1 1 1
      00:02 2 2 2 1 2
      00:03 3 3 3 1 3
      00:04 4 4 4 1 4
      00:05 5 5 5 1 5

      Aggregation interval: 5 minutes (Min5)

      Time AVG (average value) MIN (minimum value) MAX (maximum value) COUNT (number of collections) SUM (total)
      00:01 3 1 5 5 15

Q. How can I create and use Custom Schema?

A. Cloud Insight supports various Metric types and indicators, but the Metric you want may not be supported. In this case, you can use Custom Schema and SendData APIs to freely aggregate and collect the metrics you want, and use them in Cloud Insight.

Note

For more information about Custom Schema and SendData APIs, see the following guides:

The detailed quickstart for using Custom Schema and Send Data APIs is as follows:

1. Create Custom Schema

See the Custom Schema user guide to create Custom Schema.
After creating Custom Schema, click [Examples of data transfer] to check the [Sample Data format to be transferred].

The following are examples of Custom Schema for collecting the usage of Filesystem: (As Cloud Insight provides the Filesystem-type metrics, note that this is for illustrative purposes only.)

Example of the input value when Custom Schema is created

Product Type: CustomFilesystem
  Set collection target:
    ID Dimension: instanceName
    Data Type: String
  Metrics:
  - Metric: totalSize
    Data Type: Integer
    AggregationCycle: Min1, Min5, Min30
    Aggregation: AVG
    Unit: MB
  - Metric: usedSize
    Data Type: Integer
    AggregationCycle: Min1, Min5, Min30
    Aggregation: AVG
    Unit: MB
  - Metric: availSize
    Data Type: Integer
    AggregationCycle: Min1, Min5, Min30
    Aggregation: AVG
    Unit: MB
  Dimensions:
  - Dimension: mountPoint
    Data Type: String

Example of the Sample Data format after Custom Schema is created

{
	"cw_key": "801142312146182144",
	"data": {
		"instanceName": "fe79g8ahkab",
		"totalSize": 893,
		"availSize": 260,
		"usedSize": 405,
		"mountPoint": "gh1apxl4it9"
	}
}

2. Aggregate metrics you want

Directly aggregate metric values that fit the Custom Schema data format. Create a script to access the target server and derive the desired value.

The following is an example of writing a script that follows the example above:

#!/bin/bash

MOUNTPOINT="/userDevice"

USAGES=$(df -m | grep " $MOUNTPOINT$")

totalSize=$(echo $USAGES | awk '{print $2}')
usedSize=$(echo $USAGES | awk '{print $3}')
availSize=$(echo $USAGES | awk '{print $4}')

3. Transfer Custom Metric Data through SendData APIs

Organize the metric values you have aggregated directly according to the data transfer format of Custom Schema, and transfer them to Cloud Insight using SendData APIs.

The following is an example of the Custom Schema data transfer format that follows the example above:

{
	"cw_key": "801142312146182144",
	"data": {
		"instanceName": "myServer",
		"totalSize": 1180,
		"availSize": 1150,
		"usedSize": 30,
		"mountPoint": "/userDevice"
	}
}

4. View the data collected in Cloud Insight.

You can check Custom Metric data transferred to Cloud Insight when creating a Dashboard Widget, Event Rule, or Template in the Cloud Insight console.

5. Repeat it at a 1-minute interval

Once you have verified that the Custom Product Type, ID Dimension, Dimensions, and Metric are displayed correctly in Cloud Insight, repeat steps 2 and 3 above every minute using an appropriate method, such as Crontab, to collect metric values in Cloud Insight.

Q. What is agent_status metric?

A. An agent_status metric is a metric that can monitor the status of Cloud Insight Agent.
The conditions for the agent_status metric are as follows:

  • 0: When the agent is normal.
  • 1: When data is not collected for 3 minutes but the ping check succeeds.
  • 2: When data is not collected for 3 minutes and the ping check fails.

The agent_status values are processed as branches rather than consecutively. If the server is stopped while the agent is normal, the agent_status value changes from 0 to 2 rather than from 0 through 1 to 2.
Note that the ping check is performed against your server by a separate management server (ping check monitoring server). As ping check failure is not the same as a server failure, if the agent_status value is 2, you need to check the Network as well as the Agent and server status.

Q. What is the difference in data between Process data and Plugin Process data in Server (VPC)?

A. Process refers to the data related to the server's TOP 10 processes. Plugin process refers to the data related to the specific processes set by the user. Accordingly, we recommend that you use the Plugin Process feature to monitor specific processes.

Q. How can I use the Server (VPC)'s Plugin (File/Process/Port) features?

A. To use the Plugin feature, you must first configure monitoring for the specific files, processes, or ports through the API.

See the following APIs for Plugin configuration and viewing:

Plugin (File/Process/Port) Metric is Extended and requires detailed monitoring settings of the server.

See the detailed examples as follows:

(It is described based on the Plugin Process. It is similarly applied to Plugin File and Plugin Port.)

  1. Check if detailed monitoring is enabled on the server.

  2. Register the desired process for monitoring to Cloud Insight through AddProcessPlugin APIs.
    For configList of Payload, see ps -ef on Linux or tasklist on Windows.

    Payload examples

    payload = {
      "configList": [ "*httpd*", "*java*" ],
      "instnaceNo": "1234567",
      "type": "VPCServer"
    }
    
    Note

    An asterisk (*) can only be used while setting Plugin Processes. When a process name is set with a string containing an asterisk (*), the PID list of all matching processes becomes the target.

    Note

    When calling the AddPluginProcess APIs, only 1 instanceNo can be registered at a time. If multiple instanceNo values are targeted, APIs are called multiple times.

  3. Check if the Plugin Process configList is normally registered in Cloud Insight through GetAllProcessPlugin.

  4. If the Plugin Process configList is normally registered, you can check the registered process name in the Cloud Insight Console after about 2 to 3 minutes. When setting the Dashboard's Widget, the process name for the Target InstanceName to set Plugin Process is exposed as Dimensions.

  5. If you need to change or delete the Plugin Process, use UpdateProcessPlugin or RemoveProcessPlugin.

Note

If you delete Plugin Process, it does not disappear from Dimension right away. For details, see Cloud Insight troubleshooting.

Q. What is the default value if I don't select the Metric Dimension?

  • The Dimension selection differs according to the Metric.
    Example: When the Metric is Server, there is only 1 Dimension, so there is no optional Dimension. When the Metric is CPU, you can select the Dimension of cpu_idx: 0~N according to the number of CPUs.

  • If selectable Dimensions are available but none are selected, values corresponding to the Aggregation settings are displayed for all selectable Dimensions.
    Example: If no Dimension was selected under the following conditions

    Metric: CPU/used_rto
    Dimension: cpu_idx: 0, cpu_idx: 1
    Aggregation: AVG
    

    It is set as the average used_rto of cpu_idx: 0 and cpu_idx: 1 according to the Aggregation settings.

Q. If I have set the monitoring items and conditions of the Event Rule as Conditions of multiple Metrics, do all the conditions need to be met for the Event to occur?

A. If multiple Conditions of multiple Metrics are set in the Event Rule, each Condition operates under the OR condition. In other words, if the Condition for an individual Metric added to the monitoring items and conditions is met, then the Event occurs.

In Cloud Insight, if multiple Metrics are selected as the monitoring items and conditions when configuring Event Rules, then Event Rules that correspond to the number of selected Target*Metrics are actually created. If you click [View all rules] when creating Event Rules, or after selecting a created Event Rule, you can view all the Event Rules that were actually created.

Example: If 2 Conditions are configured to the Event Rule for 1 VM, and the Auto Scaling policy is set as the action, then 2 Event Rules are actually created as follows:

  • Execute the Auto Scaling policy when avg_cpu_used_rto for the VM exceeds 50%.
  • Execute the Auto Scaling policy when mem_usert for the VM exceeds 50%.

Thus, if either avg_cpu_used_rto or mem_usert exceeds 50%, an Event is triggered and the Auto Scaling policy is executed.

Q. How is mem_usert of the Server (VPC) collected?

A. The mem_usert value refers to the percentage of memory used compared to the total memory, and the calculation formula is as follows:

used_mem_mb = total_mem_mb - free_mem_mb - buffuer_mb - cache_mb - slab_reclaimable_mb
mem_usert = used_mem_mb / total_mem_mb * 100

Q. How is the Filesystem Type metric collected?

A. Metrics in the Filesystem Type are registered with Mountpoint Name as a Dimension and can be collected when the following criteria are met:

  • A separate partition or device formatted with 1 of the following file systems: ext3, ext4, or xfs (based on UUID)

    > blkid
    /dev/xvda1: UUID="f95bed0a-11af-4b2c-bfcc-4afb91a68fc1" TYPE="xfs"
    /dev/xvda2: UUID="0692fdb8-bb3c-4094-83f0-fe95a339b8c1" TYPE="xfs"
    
  • Actually mounted

    > df -h
    /dev/xvda2       49G  3.6G   46G   8% /
    /dev/xvda1     1014M  183M  832M  18% /boot
    
Note

If the Filesystem is not formatted with ext3, ext4, or xfs, you can register it in /etc/fstab and mount it to collect the metrics.

> cat /etc/fstab
/dev/xvdb    /mnt/vol     vfat      defaults     0   0

The mountpoint recorded in /etc/fstab must exactly match the mountpoint resulting from the actual df -h command.

Example:
/logs/ != /logs

Q. How do I install the Agent?

Note

The Agent installation path may vary depending on the OS version. For Linux, you can check the path where the Agent is installed through the ps -ef | grep agent command. Proceed according to the installed path.

A. Access your VPC server and check the method for your OS.

Note

Installation domains are only accessible from VPC servers. To access it from the Internet environment, use the NAVER Cloud Platform open source site.

  • Linux

    • Installation package download: https://nsight.ncloud.com/agent_controller_linux_ncp.tar.gz
    • Unzip in /home1/nbpmon/: tar -zxvf agent_controller_linux_ncp.tar.gz
    • Run the Agent with root permissions: /home1/nbpmon/agent_controller_linux/install_agent.sh pub
  • Linux Bare Metal

    • Installation package download: https://nsight.ncloud.com/agent_controller_linux_pub_common_bm.tar.gz
    • Unzip in /home1/nbpmon/: tar -zxvf agent_controller_linux_pub_common_bm.tar.gz
    • Run the Agent with root permissions: /home1/nbpmon/agent_controller_linux/install_agent.sh vpc
  • Window

    • Installation package download: https://nsight.ncloud.com/agent_controller_windows_ncp.zip
    • Unzip: unzip agent_controller_windows_ncp.zip
    • Run agent: agent_controller_windows/install_agent.bat pub
    Caution

    After downloading or unzipping, the installation folder must be under the NBP folder.
    The following is an example of a wrong installation path:
    C:\Program Files (x86)\NBP\agent_controller_windows_ncp\agent_controller_windows

    The following is the correct installation path:
    C:\Program Files (x86)\NBP\agent_controller_windows

  • Window Bare Metal

    • Installation package download: https://repo-nsight.ncloud.com/agent_controller_windows_pub_bm.zip
    • Unzip: unzip agent_controller_windows_pub_bm.zip
    • Run agent: agent_controller_windows\install_agent.bat vpc
  • Install GPU insight in the KVM/BM Linux environment

    • Installation package download: wget --no-cache http://init.ncloud.com/gpu/gpu_insight/install_gpu_insight.sh
    • Add run permissions: chmod +x install_gpu_insight.sh
    • Run the Agent with root permissions: ./install_gpu_insight.sh

Q. How do I install Agent in the Classic environment?

Note

The Agent installation path may vary depending on the OS version. For Linux, you can check the path where the Agent is installed through the ps -ef | grep agent command. Proceed according to the installed path.

A. Access your Classic server and check the method for your OS.

  • Linux

    • Installation package download: https://repo-nsight.ncloud.com/agent_controller_linux_ncp.tar.gz
    • Unzip in /home1/nbpmon/: tar -zxvf agent_controller_linux_ncp.tar.gz
    • Run the Agent with root permissions: /home1/nbpmon/agent_controller_linux/install_agent.sh pub-classic
  • Linux Bare Metal

    • Installation package download: https://repo-nsight.ncloud.com/agent_controller_linux_pub_common_bm.tar.gz
    • Unzip in /home1/nbpmon/: tar -zxvf agent_controller_linux_pub_common_bm.tar.gz
    • Run the Agent with root permissions: /home1/nbpmon/agent_controller_linux/install_agent.sh classic
  • Window

    • Installation package download: https://repo-nsight.ncloud.com/agent_controller_windows_ncp.zip
    • Unzip: unzip agent_controller_windows_ncp.zip
    • Run agent: agent_controller_windows/install_agent.bat pub-classic
    Caution

    After downloading or unzipping, the installation folder must be under the NBP folder.
    The following is an example of a wrong installation path:
    C:\Program Files (x86)\NBP\agent_controller_windows_ncp\agent_controller_windows

    The following is the correct installation path:
    C:\Program Files (x86)\NBP\agent_controller_windows

  • Window Bare Metal

    • Installation package download: https://repo-nsight.ncloud.com/agent_controller_windows_pub_bm.zip
    • Unzip: unzip agent_controller_windows_pub_bm.zip
    • Run agent: agent_controller_windows\install_agent.bat classic

Q. Where can I download the Agent script file for Linux?

Note

The Agent installation path may vary depending on the OS version. For Linux, you can check the path where the Agent is installed through the ps -ef | grep agent command. Proceed according to the installed path.

A. Click to_stop_start_uninstall_agent.zip and download. Unzip the downloaded file and locate the script files in the Agent directory (/home1/nbpmon/agent_controller_linux/). You can start, stop, install, or delete the Agent through the script.

Q. Do I have to have the Agent installed to monitor data in Server (VPC)?

A. You need the Agent to collect performance metrics in Server (VPC). However, since the Agent is built in by default when creating servers, you don't need to install it separately. Note that if the Agent is deleted or does not run due to the user settings, it is impossible to collect data through Cloud Insight.

Q. How do I check if the Agent is in operation?

A. Check the method for your OS.

  • Linux
    Check whether the Agent process is alive through ps -ef | grep agent. If the agent_updater.py and agent.py processes are running, the agent is working normally.
  • Window
    Check the nsight2_agent service's status. If the service has started, then it means that the Agent is in operation.

Q. How do I stop or start the Agent?

Note

The Agent installation path may vary depending on the OS version. For Linux, you can check the path where the Agent is installed through the ps -ef | grep agent command. Proceed according to the installed path.

A. See how to stop/start the Agent for your OS.

  • Linux

    • Stop agent: Run /home1/nbpmon/agent_controller_linux/stop_agent.sh.
    • Start agent: Run /home1/nbpmon/agent_controller_linux/start_agent.sh.
    • Restart agent: Run /home1/nbpmon/agent_controller_linux/restart_agent.sh.
  • Window

    • Stop agent: Run C:\Program Files(x86)\NBP\agent_controller_windows\agent.bat stop.
    • Start agent: Run C:\Program Files(x86)\NBP\agent_controller_windows\agent.bat start.

Q. How do I delete the Agent?

Note

The Agent installation path may vary depending on the OS version. For Linux, you can check the path where the Agent is installed through the ps -ef | grep agent command. Proceed according to the installed path.

A. See how to delete the Agent for your OS.

Q. How do I reinstall the Agent?

Note

The Agent installation path may vary depending on the OS version. For Linux, you can check the path where the Agent is installed through the ps -ef | grep agent command. Proceed according to the installed path.

A. If the installation was not normally performed, you can reinstall it properly in the following ways:

  • Linux

    1. Stop agent.
      Run /home1/nbpmon/agent_controller_linux/stop_agent.sh.

    2. Delete agent.
      Run /home1/nbpmon/agent_controller_linux/uninstall_agent.sh.

    3. Delete agent installation path.
      Delete /home1/nbpmon/agent_controller_linux. Be sure to back up any necessary files.

    4. Install agent.
      For more information about how to install the agent, see Q. How do I install the Agent?

  • Window

    1. Stop agent.
      Run the following command:
    C:\Program Files(x86)\NBP\agent_controller_windows\agent.bat stop
    
    1. Delete agent.
      Run the following command:
    C:\Program Files (x86)\NBP\agent_controller_windows\agent.bat uninstall
    
    1. Delete agent installation path.
      Delete C:\Program Files (x86)\NBP\agent_controller_windows. Be sure to back up any necessary files.

    2. Install agent.
      For more information about how to install the agent, see Q. How do I install the Agent?

Q. How do I check the Agent's logs?

Note

The Agent installation path may vary depending on the OS version. For Linux, you can check the path where the Agent is installed through the ps -ef | grep agent command. Proceed according to the installed path.

A. The log files can be viewed as follows, depending on your OS:

  • Linux
    You can check log files in /home1/nbpmon/agent_controller_linux/logs.

  • Window
    You can check log files in C:\Program Files (x86)\NBP\agent_controller_windows\logs.

Q. What should I do to adjust the log size of the Agent and the number of backups?

A. You can adjust the log size of the Agent and the number of backups as follows:

  1. Check the logger.py file according to your OS.

    • Linux
      /home1/nbpmon/agent_controller_linux/logger.py
    • Window
      C:\Program Files (x86)\NBP\agent_controller_windows\logger.py
  2. Edit LOG_SIZE_IN_BYTES and LOG_BACKUP_COUNT among logger.py file details.

    ...
    def get_logger(name, logfile=DEFAULT_LOG, max_bytes=LOG_SIZE_IN_BYTES, backup_count=LOG_BACKUP_COUNT):
        logger = logging.getLogger(name)
        setup_logger(logger, logfile, max_bytes, backup_count)
        return logger
    
  3. Restart Agent after editing the logger.py file.

Q. Is it necessary to understand how the actions are linked to each other to define permissions by actions using user-created policies?

A. When the main account selects specific actions to grant to a sub account, the system offers a feature to automatically select the related actions as well.

Q. When receiving Event information in SMS, what contents are contained in the SMS?

A. Cloud Insight provides an SMS notification feature for cases where an Event occurs, the Event remains unresolved, and the Event ends.
The Message formats for each situation are as follows:

Send status SMS Format
When the event occurs [Ncloud] ${RuleName} ${Level} ${InstanceName} ${Condition}
When reminding of the event [Ncloud][Remind] ${RuleName} ${Level} ${InstanceName} ${Condition}
When the event ends [Ncloud][Resolve] ${RuleName} ${InstanceName} ${Condition}

SMS is sent with minimal information due to message capacity limitations according to message characteristics.
If you need more information, it is recommended to use Integration.

Q. I am using Cloud DB products. How should I interpret the contents of the SMS that are automatically transferred when an event occurs?

A. As metrics provided by each Cloud DB type are different, check the console interface for details. The contents of the mainly used metrics are as follows:

Product Metric SMS Sample Description
Cloud DB for MySQL(VPC) mysql_active [Ncloud] DB Down:0, Threshold:== 0, Duration:1min WARNING test mysql_active=0 The test DB Server is down.
Cloud DB for MySQL(VPC) mysql_slavedelay [Ncloud] DB Down:0, Threshold:== 0, Duration:1min WARNING test mysql_slavedelay Replication of the latest data from Master to Slave is delayed (data up to 1 minute ago is reflected).
Cloud DB for MySQL(VPC) mysql_slaverun [Ncloud] DB Down:0, Threshold:== 0, Duration:1min WARNING test mysql_slaverun=0 The Slave server of the test DB is not synchronized.

Q. Event occurrence content differs from the data displayed on the Event page. Why is this?

A. The graph displayed when viewing events on the Events page from the console has a different aggregation interval (e.g., Min5) for the data viewed, depending on the event start and end dates.
To view the data that actually triggered the event rule, you must view the data with an aggregation interval of Min1.
Therefore, you can check the Min1 data by configuring the Dashboard separately or by viewing the event rule on the Event Rule page and setting the viewing period to within 1 hour in the Details menu.

Q. What are the criteria for the process name collecting ProcessPlugin?

A. In the case of ProcessPlugin, information on matching process names is collected based on /proc/{pid}/stat or /proc/{pid}/cmdline.

Q. Is there a way to stop event rule actions at specific times?

A. You can use the Planned Maintenance feature to stop actions following the occurrence of an Event.
Set the dimension for each product related to the event rule you wish to disable.

Q. How can I monitor a server's time offset (NTP offset) in Cloud Insight?

A. To monitor the time offset, first create a Custom Schema in Cloud Insight, and then collect metrics using a script appropriate for the operating system (Linux or Windows).

Create Custom Schema

Create a Custom Schema to store the collected NTP metrics.

Enter the following items in the Custom Schema:

Metric (Linux)

Metric Data Type
ntp_system_time FLOAT
ntp_last_offset FLOAT
ntp_rms_offset FLOAT
ntp_root_delay FLOAT
ntp_stratum INTEGER
ntp_leap_status INTEGER

Metric (Windows)

Metric Data Type
ntp_last_offset FLOAT
ntp_root_delay FLOAT
ntp_stratum INTEGER
ntp_leap_status INTEGER
ntp_synced INTEGER
ntp_reachable INTEGER
Note

Because the metrics collected on Linux and Windows differ, configure the appropriate metrics for each environment to ensure proper operation.

1. Linux environment (based on chrony)

This method collects the synchronization status of the chrony service already running on the system as a Custom Metric without requiring any additional packages.

To check NTP metrics in a chrony environment:

$ chronyc tracking
Reference ID    : A9FEA97B (169.254.169.123)
Stratum         : 3
System time     : 0.000012345 seconds slow of NTP time
Last offset     : -0.000008721 seconds
RMS offset      : 0.000015234 seconds
Root delay      : 0.012345678 seconds
Leap status     : Normal

Key metrics to collect

Field Meaning
ntp_system_time Local-server time offset (s).
ntp_last_offset Time offset measured at the last synchronization (s).
ntp_rms_offset Long-term average of offset (s).
ntp_root_delay Round-trip delay to the stratum 0 clock server (s).
ntp_stratum Server stratum level.
ntp_leap_status Synchronization/leap second status (Normal = normal, transmitted value = integer 0).

Collect script (/usr/local/bin/ntp_metric.sh)

#!/bin/bash
set -euo pipefail

CW_KEY="YOUR_CW_KEY"                  # 19-digit numeric key issued when creating the Custom Schema
ACCESS_KEY="YOUR_NCP_ACCESS_KEY"
SECRET_KEY="YOUR_NCP_SECRET_KEY"
DIM_KEY="YOUR_ID_DIMENSION_KEY"       # ID Dimension name registered in the Custom Schema
DIM_VALUE="$(curl -s --max-time 5 http://169.254.169.254/latest/meta-data/serverName)"

API_HOST="https://cw.apigw.ntruss.com"
URI="/cw_collector/real/data"
METHOD="POST"

TRACKING=$(chronyc tracking) || { echo "Failed to run chronyc (chrony not installed)"; exit 1; }

# System time: "X seconds slow/fast" → slow values are negative
read -r ST_VAL ST_DIR < <(awk '/^System time/{print $4, $6}' <<<"$TRACKING") || true
[ "${ST_DIR:-}" = "slow" ] && SYSTEM_TIME="-${ST_VAL}" || SYSTEM_TIME="${ST_VAL:-}"

# Remove the leading "+" to prevent positive offsets from breaking the JSON number format
LAST_OFFSET=$(awk '/^Last offset/{print $4}' <<<"$TRACKING" | tr -d '+')
RMS_OFFSET=$( awk '/^RMS offset/ {print $4}' <<<"$TRACKING" | tr -d '+')
ROOT_DELAY=$( awk '/^Root delay/ {print $4}' <<<"$TRACKING" | tr -d '+')
STRATUM=$(    awk '/^Stratum/    {print $3}' <<<"$TRACKING")
LEAP=$(       awk -F': ' '/^Leap status/{print $2}' <<<"$TRACKING")

case "$LEAP" in
  "Normal")        LEAP_CODE=0 ;;
  "Insert second") LEAP_CODE=1 ;;
  "Delete second") LEAP_CODE=2 ;;
  *)               LEAP_CODE=3 ;;
esac

: "${SYSTEM_TIME:=0}" "${LAST_OFFSET:=0}" "${RMS_OFFSET:=0}" "${ROOT_DELAY:=0}" "${STRATUM:=0}"

BODY="{\"cw_key\":\"$CW_KEY\",\"data\":{\"$DIM_KEY\":\"$DIM_VALUE\",\"ntp_system_time\":$SYSTEM_TIME,\"ntp_last_offset\":$LAST_OFFSET,\"ntp_rms_offset\":$RMS_OFFSET,\"ntp_root_delay\":$ROOT_DELAY,\"ntp_stratum\":$STRATUM,\"ntp_leap_status\":$LEAP_CODE}}"

TIMESTAMP=$(date +%s%3N)
SIG_MSG=$(printf '%s %s\n%s\n%s' "$METHOD" "$URI" "$TIMESTAMP" "$ACCESS_KEY")
SIGNATURE=$(printf '%s' "$SIG_MSG" | openssl dgst -sha256 -hmac "$SECRET_KEY" -binary | openssl base64 -A)

curl -sS --max-time 10 -w '\nHTTP %{http_code}\n' -X "$METHOD" "${API_HOST}${URI}" \
  -H "Content-Type: application/json" \
  -H "x-ncp-apigw-timestamp: $TIMESTAMP" \
  -H "x-ncp-iam-access-key: $ACCESS_KEY" \
  -H "x-ncp-apigw-signature-v2: $SIGNATURE" \
  -d "$BODY"

Register Cron

Save the collection script as /usr/local/bin/ntp_metric.sh and make it executable. Add it to Cron to run every minute.

# 1. Grant execution permissions
chmod +x /usr/local/bin/ntp_metric.sh

# 2. After running crontab -e, add the following line (runs every minute):
* * * * * /usr/local/bin/ntp_metric.sh >/dev/null 2>&1

Verify data collection

About 2-3 minutes after registering the script with Cron, create a widget in the Cloud Insight console to verify that data is being collected properly.

  1. In the console, navigate to Menu > All Services > Management & Governance > Cloud Insight > Dashboard.
  2. Click [Create dashboard], enter a dashboard name, and click [Create].
  3. For Product Type, select the Custom Schema created earlier. For Metric, select the metric you want to view.
  4. If data points appear in the widget at 1-minute intervals, the data is being collected properly.

Recommended notification thresholds

The recommended thresholds for setting up Custom Metric-based notifications are as follows:

Metric Warning Critical Description
ntp_last_offset Outside ±0.1 s Outside ±1.0 s Latest measured time offset.
ntp_stratum 4 or more 6 or more Excessive Stratum level.
ntp_leap_status Other than 0 - Leap second imminent or synchronization error.
Note

In addition to the chrony method above, you can use a Telegraf input plugin or Python with a library such as ntplib to collect measurements directly from multiple NTP servers. If you operate a standardized collector or need to compare measurements across multiple NTP servers, select the method appropriate for your environment.

2. Windows environment (based on w32tm)

This method collects NTP metrics using the w32tm command and performance counters built into Windows.

Key metrics to collect

Field Meaning
ntp_last_offset Most recently measured time offset (s).
ntp_root_delay Round-trip delay to the stratum 0 clock server (s).
ntp_stratum Server stratum level.
ntp_leap_status Synchronization/leap second status (0=Normal).
ntp_synced NTP synchronization status (1 = synchronized, 0 = failed).
ntp_reachable Reference NTP server reachability (1 = reachable, 0 = failed).

Collect script (C:\Scripts\ntp_metric.ps1)

#Requires -Version 5.1

[CmdletBinding()]
param(
    [string]$CwEndpoint = 'https://cw.apigw.ntruss.com/cw_collector/real/data',
    [string]$CwKey      = 'YOUR_CW_KEY',              # 19-digit numeric key issued when creating the Custom Schema
    [string]$AccessKey  = 'YOUR_NCP_ACCESS_KEY',
    [string]$SecretKey  = 'YOUR_NCP_SECRET_KEY',
    [string]$DimKey     = 'YOUR_ID_DIMENSION_KEY',    # ID Dimension name registered in the Custom Schema
    [string]$LogFile    = "$env:ProgramData\ntp_metric\ntp_metric.log",
    [switch]$DryRun
)

$ErrorActionPreference = 'Stop'
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

function Write-Log([string]$msg) {
    $dir = Split-Path $LogFile
    if (-not (Test-Path $dir)) { New-Item -ItemType Directory -Path $dir -Force | Out-Null }
    ("{0}  {1}" -f (Get-Date -Format 'yyyy-MM-dd HH:mm:ss'), $msg) | Add-Content -Path $LogFile
}

# Current synchronization source
$source = (& w32tm /query /source).Trim() -replace ',.*',''
if (-not $source -or $source -match 'Local CMOS|Free-running') {
    $source = 'time.windows.com'; $synced = 0
} else { $synced = 1 }

# offset — stripchart (numeric output is locale-independent)
$offset = $null
try {
    foreach ($line in (& w32tm /stripchart /computer:$source /dataonly /samples:1)) {
        if ($line -match '([+-]\d+\.\d+)\s*s') { $offset = [double]$Matches[1] }
    }
} catch { Write-Log "stripchart failed: $_" }
# fallback: Service-calculated offset (us)
if ($null -eq $offset) {
    try {
        $us = (Get-Counter '\Windows Time Service\Computed Time Offset' -ErrorAction Stop).CounterSamples[0].CookedValue
        $offset = [math]::Round($us / 1e6, 9)
    } catch { Write-Log "Computed Time Offset counter failed: $_" }
}

# Stratum, Root Delay, and Leap (based on English labels)
$stratum = $null; $rootDelay = $null; $leap = $null
try {
    $status = (& w32tm /query /status /verbose) -join "`n"
    if ($status -match 'Stratum:\s*(\d+)')         { $stratum   = [int]$Matches[1] }
    if ($status -match 'Root Delay:\s*([\d\.]+)s') { $rootDelay = [double]$Matches[1] }
    if ($status -match 'Leap Indicator:\s*(\d+)')  { $leap      = [int]$Matches[1] }
} catch { Write-Log "query/status failed: $_" }

$data = @{
    ntp_last_offset = $offset
    ntp_root_delay  = $rootDelay
    ntp_stratum     = $stratum
    ntp_leap_status = $leap
    ntp_synced      = $synced
    ntp_reachable   = [int]($null -ne $offset)
}
$data[$DimKey] = (Invoke-RestMethod -Uri 'http://169.254.169.254/latest/meta-data/serverName' -TimeoutSec 5).Trim()   
$clean = @{}; foreach ($k in $data.Keys) { if ($null -ne $data[$k]) { $clean[$k] = $data[$k] } }
$body = @{ cw_key = $CwKey; data = $clean } | ConvertTo-Json -Depth 5 -Compress

Write-Host "[payload] $body"
if ($DryRun) { Write-Log "DryRun payload=$body"; return }

# Sign with IAM Signature v2 before sending
$ts        = [string][long]([DateTimeOffset]::UtcNow.ToUnixTimeMilliseconds())
$uriPath   = ([Uri]$CwEndpoint).AbsolutePath
$sigMsg    = "POST $uriPath`n$ts`n$AccessKey"
$hmac      = New-Object System.Security.Cryptography.HMACSHA256
$hmac.Key  = [Text.Encoding]::UTF8.GetBytes($SecretKey)
$signature = [Convert]::ToBase64String($hmac.ComputeHash([Text.Encoding]::UTF8.GetBytes($sigMsg)))
$headers = @{
    'x-ncp-apigw-timestamp'    = $ts
    'x-ncp-iam-access-key'     = $AccessKey
    'x-ncp-apigw-signature-v2' = $signature
}
try {
    Invoke-RestMethod -Uri $CwEndpoint -Method Post -Headers $headers -ContentType 'application/json' -Body $body -TimeoutSec 5 | Out-Null
    Write-Log "send OK offset=$offset stratum=$stratum leap=$leap synced=$synced"
} catch {
    Write-Log "send failed: $_"
    exit 1
}

Register schtasks

To register schtasks to run the collection script every minute:

schtasks /Create /TN "NTP-Metric" /TR "powershell.exe -NoProfile -ExecutionPolicy Bypass -File C:\Scripts\ntp_metric.ps1" /SC MINUTE /MO 1 /RU SYSTEM /RL HIGHEST /F

Verify data collection

About 2-3 minutes after registering the script with schtasks, create a widget in the Cloud Insight console to verify that data is being collected properly.

  1. In the console, navigate to Menu > All Services > Management & Governance > Cloud Insight > Dashboard.
  2. Click [Create dashboard], enter a dashboard name, and click [Create].
  3. For Product Type, select the Custom Schema created earlier. For Metric, select the metric you want to view.
  4. If data points appear in the widget at 1-minute intervals, the data is being collected properly.

Recommended notification thresholds

The recommended thresholds for setting up Custom Metric-based notifications are as follows:

Metric Warning Critical Description
ntp_last_offset Outside ±0.1 s Outside ±1.0 s Latest measured time offset.
ntp_stratum 4 or more 6 or more Excessive Stratum level.
ntp_synced - 0 Sync failed.
ntp_reachable - 0 NTP server unreachable.
Note

The above metric examples and thresholds are based on general web service standards. Financial and trading systems may require stricter standards. Adjust and use them according to your environment.

Notification settings

Values transmitted using this method are collected in Cloud Insight as Custom Schema metrics. To set up a notification, create a notification rule for the registered metric in the Cloud Insight console using the recommended thresholds above.

Note

For more information about Custom Schema and SendData APIs, see the following guides: